[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: Windows 2000 SP4 (was Re: APM bug)

From: Leonardo E. Reiter
Subject: [Qemu-devel] Re: Windows 2000 SP4 (was Re: APM bug)
Date: Tue, 05 Apr 2005 17:33:10 -0400
User-agent: Debian Thunderbird 1.0 (X11/20050116)

Iain et al,

Here are some things we've discovered about Service Pack 4 and QEMU..

1. You can go from no service pack to SP4 using KQEMU for the x86 on x86 case, and that works fine. It does not work with i386-softmmu on the same processor for example unless you have KQEMU installed.

2. Without using KQEMU, you will have to install all service packs leading up to and include 4 in order (i.e. SP2, then SP3, etc.); but *beware*: SP3 has a dreaded Microsoft bug that will prevent things from booting. This is a known Microsoft bug that happens to manifest all the time (based on our testing) on QEMU. My suggestion for an easy work-around is this:

        a. Install SP2 and reboot
        b. save the file c:\winnt\system32\dllcache\msgina.dll somewhere
           safe (i.e. your My Documents directory, etc.)
        c. Install SP3 but *do not* let it restart (check the box) after
           it's done
        d. Once you exit SP3 installation, copy the saved msgina.dll
           from step b into both the c:\winnt\system32 and
           c:\winnt\system32\dllcache directories.  First you will have
           to rename the existing msgina.dll's in those directories to
           something else since they are in use.  But be quick, because
           the System File Checker which is not easy to disable will
           restore them before you know it (after you rename them but
           before you restore the saved version)
        e. Restart the computer

I suggest you backup your hard disk image that contains Windows 2000 either before you start doing all this or after you install SP2 successfully and shut down, just in case something goes wrong. If all goes well, Win2K should boot, but if not, you can probably still use the System Recovery mode or something to fix it. Your safest bet is to make a backup first.

After you get past this SP3 mess, you can then install SP4. I suggest you download the SP2-4 installers from http://www.microsoft.com instead of using Windows update (which will only fetch SP4 anyway). Just do a search in the download area to find each one.

After you get SP4 installed, beware of the following 2 major problems:

1. schannel.dll will fail to start and therefore IE will have a 0-bit cipher strength, no matter what you do (additional updates, etc). Microsoft suggests you restore 2-3 DLLs in this case (including schannel.dll), but it doesn't work in QEMU. What you might want to do is grab the DLL's (schannel.dll and rsabase.dll, and I can't recall the other one) from SP3 or even SP2 and try that. It probably won't work, but if it does, please let us know. In the event viewer the error message appears to be useless - saying that schannel failed to start the RSA engine with an error code 0x57, which we can't find the meaning for in that context yet. If anyone has any clues, I'd love to hear!

(note that 0-bit cipher in IE causes Windows Update to stop working too)

2. Add/Remove Programs will stop working - showing nothing installed as far as applications go. You'll see what looks like a broken graphic link with the text 'Computer graphic' in the place where your list of installed apps should be. You can usually overcome this by installing the Windows Installer 3.0 (get it from microsoft.com) after you install SP4 and restart.

Keep in mind that item 1 did not fail like that with KQEMU enabled. We didn't test item 2 yet with KQEMU.

At this point we are thinking there is an instruction emulation/translation error somewhere that of course doesn't show up with KQEMU because it's likely running native. We're still trying to track it down in the QEMU code, but any ideas or suggestions from anyone would be gladly appreciated. At first we thought it had to do with the 80-bit FP ops not using the "l" versions of various glibc math functions (i.e. sqrt, etc.), but a quick test of replacing those with the "l" versions made no difference here, and slowed down a lot of other stuff tremendously. I'll send a follow-up note to the list with some other findings so anyone who wants to can comment, but there are other issues that we have encountered as well.

Best regards,

Leo Reiter

Leonardo E. Reiter
Vice President of Engineering

Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501

reply via email to

[Prev in Thread] Current Thread [Next in Thread]