Hmmm, so we need at ACPI rev.<2 a entry at RSDT to SLIC, at ACPI rev.>=2 a entry at XSDT to SLIC............. the only idea I've got: -Replace the entry at XSDT to BOOT with a entry to SLIC. Boot table is remained since RSDT has got an entry to it as well, but don't know if there will be any issues... IMO the BOOT table isn't very important, probably less important than MCFG............ -Exchange the location of RSDT and XSDT isn't possible. This will result to a 64 bit address entry to RSDT and a 32 bit entry to the XSDT. I've consulted the ACPI spec. again. The RSD PTR spec. says that the address entry to XSDT must be the second one and has to be a 64 bit address. To violate the rule causes probably to issues..... Since we cannot change RSD PTR I fear that we have no other chance..... The main question I would like to get an answer is: Does it affect if I have got an entry at RSDT only to a table which originally has got two entries (at RSDT and XSDT). Especially at 64 bit OS..........if not we are OK...... To implement that 'last resort routine MCFG / BOOT' doesn't harm......since you've got VM you can test for possible issues........also someone else should try WoW MCFG extensively and watch out for possible issues....... I'm still without Vista, but I'm planning to upgrade my sys. I'm very sorry that I cannot support you doing any tests at this moment.......
Flagmax, I've thought about the Wow project. IMO it isn't possible to patch ALL bioses to make it activate. There is Vistaloader alternatively. There are bioses at which Vistaloader fails. Sure WoW gets better and better when it will work with more and more bioses. I think we have to set priorities. Please let me set mine (just my opinion) -patch half mapped SLICS, status: done. -introduce new SLIC in front of RSDT if possible, status done. -replace MCFG / BOOT entry at XSDT, status not fully realised -extend RSDT(ACPI1), status realised, but not implemented less priority: (planed at updates) -extend XSDT (ACPI2) -VM support: No matter if realised for all VM bioses. Why? You can try to mod any VM bios as long as you want. You'll never get a bricked mobo. What do you think, or what is your goal regarding next WoW release? What about to release MCFG version plus acpi1 support (extend RSDT) to gather info? This version will be great already. Please note that is just my opinion. And yes, the more Wow can patch the better it will be, that's true.....my respect to your program skills.
I need more information: Multiboot OS? Where is Vista and where is xp? How many physical HDDs have you got? Where is bootmgr located? After installation of WoW 3.00 what exactly happened? You must install WoW 3.00 from Vista to where bootmgr is located. Are you using a original version of Vista (no softmod)? Also note: WoW 1.x writes MBR. WoW 2.x and 3 not. Alternatively install WoW 1.04. Boot to OS where bootmgr is located and try to install WoW 1.04. Bootmgr is a hidden systemfile!
Are you using a clean installation of Vista, no BiE edition? Have you disabled UAC before? Could you please post a screenshot of C:\ with hidden files shown? I have to see if the renaming commands are applied. Thanks. Edit: I have to go now. I'll reply later this day.
Yen: WOW code started to get very messy with bugs popping up everywhere. So I've decided to start from scratch. Please take a look at attached pdf and let me know if you find something missing or wrong. Edit: I've finished coding for ACPI1.0 following the flowchart. The code is clean and organized now Hopefully on Sunday I will do ACPI2.0...
Please clarify, do 1.x versions leave file system alone (bootmgr, etc) and only modify the MBR (and copy the floppy image to \WoW) Or do all versions modify bootmgr? I'd use the 1.4 if it only modifies the MBR and not windows files (aside from the copy of the floppy image).
Flagmax, I'm WOWed.. I've read your pdfs, great work...... Unfortunately I have to go on-the-job training. When I'm back I'll test WoW at some machines. Thank you again for your hard work, I really appreciate. TiME-SPLiNTER, BiE edition can cause issues. WoW is made for untouched Versions of Vista. Anyway, there is something wrong: WoW.IMG should be inside WoW folder. Rename manually: bootmgr to bootmgrv grldr to bootmgr and retry. sadsac. Yes, WoW 1.x versions don't rename any Vista file and writes MBR. 2.X and 3 are renaming some files. WoW 5.x is the latest to try.......no install yet, boot floppy and cd to try. If you want, any help is appreciated. After some results I'll make MBR and NOMBR version of WoW 5 as well....... If you have WoW 1.x installed already you can get WOWfloppy_5.0_auto_HP.IMG, rename it to WoW.IMG and replace it at WoW folder and reboot.
You're welcome. Without your skills also If you find the time next days you can remove debug info. I'll open a new sticky and pack it as MBR and NOMBR version when I'm back home again.
One more question: At your workflow ACPI2.pdf, you ask for 4 zero bytes after XSDT. Is it a typo and does it ask for 8 byte since the entry to extend has to be 8 bytes (64 bit address)?
Good Eye!!! Its a typo. Code: Check8bytesXSDT: callGetXSDTinESIendEDI;load xsdt address movecx, gs:[edi];grab table SIG after XSDT cmpecx, 0;is it zero? jnzfoundsometableXSDT movecx, gs:[edi+4];grab 4 more bytes cmpecx, 0;is it zero? jnzfoundsometableXSDT IntroSlicXSDT:
Could one of you explain precisely how WoW works -- only as it pertains to loading? (not an explanation about slic emulation). Is the following correct: 1. Boots to grub 2. Grub automatically chooses DOS OS 3. Run WoW (which is a DOS program?) 4. Wow somehow chains to Vista partition. What I'm wondering is could I setup a small DOS partition as the first partition (having the contents of the WoW floppy image), run WoW executable and then chain to Vista partition? Is grub absolutely required? And if so, why? I'm like to suppress all the grub text, and if setting up a small DOS partition would do this...