Drivers and tools to run Windows XP on newer hardware

You need to login to view this posts content.

 

Where is last version of WinXPPAE 2.0 patch for download?

 

Download link is in the first post of this thread!

 

@daniel_k

All the registry keys above are OK in all the cases below:

1) acpi 5048 + Kernel Mode Driver Framework 1.9 + Intel USB3 HCSwitch for XP (Gen4 Series8 C220 and later) :

The USB 3.0 driver can't be initialized (code 37 in the devices manager)
It's strange because KMDF 1.9 comes from the archive file provided by @PPeti66x ???
As I can't install the USB 3.0 driver, I have not installed the switcher.

2) acpi 5048 + Kernel Mode Driver Framework 1.11 + Intel USB3 HCSwitch for XP (Gen3 Series7 C216 and older):

No USB 3.0 speed, the switcher doesn't works.

3) acpi 5048 + Kernel Mode Driver Framework 1.11 + Intel USB3 HCSwitch for XP (Gen4 Series8 C220 and later):

All is OK, I have USB 3.0 speed, but the shutdown or reboot process hang and I must press the power button of the computer.
It's seems that this is the switcher that hang the shutdown or reboot process.

Any idea ?

 

You need to login to view this posts content.

 

@daniel_k

WPCRSET has resolved the issue with the shutdown or reboot process.
I guess that mean that the issue comes from the HCSwitch driver.

Regards

 

You need to login to view this posts content.

 

Installation report:
Tried installing KMDF 1.11 and xHCI(generic) to already running 2003Server x86 PAE on Haswell/C220/8G RAM machine.

The machine's UEFI had the setting:

Code:

One Of: USB3.0 Controller:, $Setup[0x1A4], QuestionId: 0x7D, Size: 1, Min: 0x0, Max 0x0, Step: 0x0
One Of Option: Smart Auto, Value (8 bit): 0x3 (default)
One Of Option: Auto, Value (8 bit): 0x2
One Of Option: Enabled, Value (8 bit): 0x1
One Of Option: Disabled, Value (8 bit): 0x0
One Of Option: Manual, Value (8 bit): 0x4
End One Of

Note that this is from debug page, normally only three of them (Smart Auto, Manual, Disabled) are available,
so I hand-edited Setup efivar on UEFI shell. (I'm still lost how to actually open debug page)

Disabled-> EHCI only (as usual).
Enabled-> EHCI disappears, xHCI appears but device just gave error 10.
Manual-> both EHCI and xHCI appears, but xHCI device error (ditto).
Auto-> ditto.
Smart Auto-> ditto.

... so in short, it didn't work. Perhaps ACPI trap?
I feel it nonsense for "Enabled" giving no working device at all, but that was it.

As I can't stop the machine for so long, I just gave up and uninstalled, ... to fail.
KMDF didn't appear on uninstall list, I manually run spuninst.exe, then it left KMDF device as-is and spit errors on reboot.

No worries, I already cleaned them manually, we're used to do that now and then, just reporting...

TIA!

 

Well, if DSDT had opcode unknown for acpi.sys, doesn't it result in BSoD?
This machine boots normal with plain 2003R2, just without xHCI. Because of that I was off guard.

After that I began poking around DSDT and, yes, something looks actually sneaky; if I read correctly, XHC is activated only when _SB.PCI0._OSC is called with some signature, right?

Code:

    Scope (_SB)
    {
        Device (PCI0)
        {
            Method (_OSC, 4, Serialized)  // _OSC: Operating System Capabilities
            {
                Local0 = Arg3
                CreateDWordField (Local0, Zero, CDW1)
                CreateDWordField (Local0, 0x04, CDW2)
                CreateDWordField (Local0, 0x08, CDW3)
                If (^XHC.CUID (Arg0))
                {
                    Return (^XHC.POSC (Arg1, Arg2, Arg3))
                }
                ElseIf ((OSYS >= 0x07DC))
                {
                    If ((XCNT == Zero))
                    {
                        ^XHC.XSEL ()
                        XCNT++
                    }
                }
--snip--

        Device (XHC)
        {
            Method (POSC, 3, Serialized)
            {
                CreateDWordField (Arg2, Zero, CDW1)
                CreateDWordField (Arg2, 0x08, CDW3)
                If ((XHCI == Zero))
                {
                    CDW1 |= 0x02
                }

                If (!(CDW1 & One))
                {
                    If ((CDW3 & One))
                    {
                        ESEL ()
                    }
                    ElseIf (((CDID & 0xF000) == 0x8000))
                    {
                        If ((Arg0 > One))
                        {
                            XSEL ()
                        }
                        Else
                        {
                            CDW1 |= 0x0A
                        }
                    }
                    ElseIf ((Arg0 > 0x02))
                    {
                        XSEL ()
                    }
                    Else
                    {
                        CDW1 |= 0x0A
                    }
                }

                Return (Arg2)
            }
--snip--

In addition to this, I found _SB.EHC1.HUBN._STA and _SB.XHC.RHUB._STA both seem to pretend absent for anything before Vista, but as EHCI is working normal now, it might be non-critical. ... or not.

 

Ouch, now I understand. Thanks for explanation.
(now I'm not sure from which the problem is coming, the existence of QWordPrefix(0E) or the change of default arithmetic width, but it doesn't matter, it certainly can't work.)

Will retry with acpi.sys replacement at next down time.

 

You need to login to view this posts content.

 

I don't understand where is difference? All files reported by your patcher are in system32. Are there any other checks?

These files was expanded before Windows capturing and deploying from SP3.cab.

Code:

set KrnlLst=halacpi.dll, halapic.dll, halmps.dll, halaacpi.dll, halmacpi.dll, hal.dll, ntkrnlmp.exe, ntkrnlpa.exe, ntkrpamp.exe, ntoskrnl.exe
for %%A in (%KrnlLst%) do (
    if exist "%WINDIR%\Driver Cache\i386\%%A" (
      copy "%WINDIR%\Driver Cache\i386\%%A"  hals\ >nul
    ) else (
      expand "%CAB%" -F:%%A  hals\ >nul
    )
)
 
    ren hals\hal.dll halstd.dll >nul
    copy hals\ntoskrnl.exe hals\ntkrnlup.exe >nul
    ren hals\ntoskrnl.exe ntkrnlst.exe >nul

Also my hal.dll is "created" from halmacpi.dll during first boot by Longhorn NTLDR.

EDIT: I'm going to upload you latest testing ISO where you can reproduce / encounter same problem.

 

I would like to do it, but patcher do nothing for me... I don't understand why patcher reports me - "File XXX was not found". All files exist in proper location. I also tried HEX comparing my hal.dll and halmacpi.dll, exact match. I also tried ntkrpamp.exe copy to ntkrnlpa.exe, so these files now are also same and I'm still without success. Same result - nothing is patched. And yes, I have SFC disabled so these files are not overwriten from dllcache.
I have no idea how to process patching if all files exist and nothing happends.

Any idea why it doesn't allow me to patch is welcome