Jump to content
MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. ×

Windows XP x86 on modern 2-in-1


HyperbolicEllipsoid
 Share

Recommended Posts

2 hours ago, HyperbolicEllipsoid said:

I'm currently running a minimal version of Windows 8.1 x64 since it doesn't work very well on 10.

The hardware ID for PCI Express Root Complex is ACPI\VEN_PNP&DEV_0A08.

Yep, but maybe the missing (or failing) driver is connected to *something* else.

Try getting devcon from here:

It should run in 8.1 (as Administrator).

Open a command prompt navigate to where you put it (let's say C:\myfolder\ ) and in it run:
devcon driverfiles *>driverfiles.txt

(it will take some time to run)

then run

devcon hwids *>hwids.txt

then compress to .zip the C:\myfolder\driverfiles.txt and C:\myfolder\hwids.txt and attach it to a reply.

jaclaz

Edited by jaclaz
  • Upvote 1
Link to comment
Share on other sites


I also pulled together the Intel SD Host Controller driver. Is there any way to tell if it is compatible with XP, assuming it is of any use at all?

{unredistributable attachment removed}

Edited by dencorso
1st violation of Rule #1.b...
Link to comment
Share on other sites

On 7/31/2020 at 8:10 AM, RainyShadow said:

@HyperbolicEllipsoid

That driver will not work on XP.

The one Ximonite provided should be fine. You may need a corresponding txtsetup.oem for it though.

 

This discussion may be helpful:

 

OK, I did some searching and found this driver {unredistributable attachment removed}:

 

After reading through that entire thread, I'm a bit less confident that this will work. It seems like they tried everything and couldn't get past the BSOD errors. Still, I would like to give it a shot. I realize now that I probably also need a driver for USB 3.0 support since this laptop only has two USB 3.0 ports. Is it possible to get the Intel® USB 3.0 eXtensible Host Controller Driver on Windows XP?

Edited by dencorso
2nd violation of Rule #1.b...
Link to comment
Share on other sites

24 minutes ago, HyperbolicEllipsoid said:

OK, I did some searching and found this driver:

This seems to be for Win8, just like the other one you posted.

About USB, check in BIOS/EFI settings if you can switch it to USB2 mode for now. There are some USB3 drivers floating around the net, but better start simple first.

  • Upvote 1
Link to comment
Share on other sites

1 hour ago, RainyShadow said:

This seems to be for Win8, just like the other one you posted.

About USB, check in BIOS/EFI settings if you can switch it to USB2 mode for now. There are some USB3 drivers floating around the net, but better start simple first.

Oh, I thought you meant that it wasn't x86. @Ximonite, do you happen to know where that .inf came from? I'd love to get the driver files if they are available.

I checked the UEFI settings and while there is no setting to disable USB 3.0, there is a Legacy USB support option as well as the ability to change mass storage device emulation type. I'll set the installation media to CD-ROM and see if that allows me to boot off of the USB drive rather than an external CD drive.

Link to comment
Share on other sites

This isn't related to mass storage drivers, but according to this post, this is what causes the ACPI error I was having (STOP: 0x000000A5 (0x00000011, 0x00000008, 0xF6D3A1C8, 0x20120913):

Quote

- 0xA5 (0x11, 0x08, ..., ...) unknow error in _AMLILoadDDB, probably fail after parsing DSDT/SSDT table, solved

Patch (by diderius6):
- Ignore status of _AMLILoadDDB in _ACPIInitializeDDB
(v5512 jl short .text:00036214 => nop, nop)

Unfortunately, I'm a newb and I have no idea what that patch is or how to apply it.

The post also says that some generic Microsoft USB 3.0 driver works in Windows XP:

Quote

Intel released USB3.x drivers only for Windows 7/8/10, so there were many attempts to use drivers of
other usb chip manufacturers. Most of them do not work at Intel hardware, some works, but have problems with PAE or USB3 ports.

Following drivers confirmed to work in normal and PAE environment, solved, three solutions:
1) Microsoft Generic v6.2.9200.16384/v6.2.9200.22453 from Windows 8.0
2) AMD v1.1.0.0145 (need amdxhci_adresscalc_fix)
3) Fresco Logic v3.6.9.0 (extended to 32 ports)

I can't seem to find that specific version of the driver, but then again I don't really know where to look. What are some places I might find it?

EDIT: I found this, maybe it would work?

Edited by dencorso
1st violation of Rule #2.a...
Link to comment
Share on other sites

Well, it is not that you are a newb, it is not like the link explained it much.

To try applying the patch you need to have the ACPI.SYS which version ends in  v.5512

Then you need a hex editor (any will do)

You need to open the file and check that at offset 0x00034214 there are bytes (I believe):

7C xx
corresponding to JL:
http://faydoc.tripod.com/cpu/jl.htm

with the hex editor replace those two bytes with:
90 90

correspondng to nop, nop.

Quote

Patch (by diderius6):
- Ignore status of _AMLILoadDDB in _ACPIInitializeDDB
(v5512 jl short .text:00036214 => nop, nop)

jaclaz

Edited by jaclaz
  • Upvote 2
Link to comment
Share on other sites

20 hours ago, HyperbolicEllipsoid said:

do you happen to know where that .inf came from? I'd love to get the driver files if they are available.

It was from the latest Intel Chipset Drivers I could find.

Intel doesn't provide .sys files in their drivers. They use .sys files that are included in Windows.

  • Upvote 1
Link to comment
Share on other sites

9 hours ago, jaclaz said:

Well, it is not that you are a newb, it is not like the link explained it much.

To try applying the patch you need to have the ACPI.SYS which version ends in  v.5512

Then you need a hex editor (any will do)

You need to open the file and check that at offset 0x00034214 there are bytes (I believe):

7C xx
corresponding to JL:
http://faydoc.tripod.com/cpu/jl.htm

with the hex editor replace those two bytes with:
90 90

correspondng to nop, nop.

jaclaz

Thanks so much for explaining this. I'm probably doing this wrong (I've never edited hex before), but which bytes to I change at 0x00036214? I'm not sure exactly what to look for, but it doesn't look like there are any bytes corresponding to JL. Do I just change that one byte to 90?Capture.PNG.3ae9664cc88f1fa8290b7cd17a45c25a.PNG

Link to comment
Share on other sites

 

1 hour ago, HyperbolicEllipsoid said:

0x00036214?

He meant offset 34214.

And there is a version of sdbus.sys that is 5.1.2600.5512, that you should be able to locate in X:\WINDOWS\system32\drivers (in XP of course). And if it's there then it should be on the install medium, which should allow setup to detect it, in conjunction with the Intel inf. So I do believe that ACPI is a bigger issue than storage controllers.

Edited by win32
Link to comment
Share on other sites

6 hours ago, win32 said:

 

He meant offset 34214.

And there is a version of sdbus.sys that is 5.1.2600.5512, that you should be able to locate in X:\WINDOWS\system32\drivers (in XP of course). And if it's there then it should be on the install medium, which should allow setup to detect it, in conjunction with the Intel inf. So I do believe that ACPI is a bigger issue than storage controllers.

No, the original post says offset 36214.

If the storage driver is already included, maybe I could follow the instructions in this PDF using <warez> to install Windows XP with a patched ACPI.SYS to the eMMC? I'll include the {unredistributable attachment removed} unmodded ACPI.SYS v5512 for reference:

 

EDIT: Just saw this. It looks like it's supposed to be done after installation? Should I install an unmodded version of XP to the eMMC, then do this patch?

Edited by dencorso
Banned on Rule #1.a & 1.b (two violations on the same post)!
Link to comment
Share on other sites

The problem is that the OP is not clear.

There are basically two ways to "look at" a .exe or .sys:
1) easy, in a hex editor, where you only see bytes
2) difficult, in a disassembler/debugger, where you see the actual (disassembled) instructions (and each stupid program has its own different way to show data)

Clearly someone like  Mov AX, 0xDEAD or diderius6 (Dietmar) look at it in a disassembler (otherwise they would have no way to find what is needed to be changed).

Normally, once the patch has been devised and tested, the instructions are translated in hex editor values, ie, something like:

0x111111 7C 48 -> 90 90

This is what has NOT happened in this case.

It is possible that the

 jl short .text:00036214

actually means "jump if less to 00036214", i.e. the 00036214 is the "landing address" of the jump.

IF this is the case, since the JL instruction is 7C, and it is  a "short" jump, then there must be within the 255 bytes before address 0x0036214 a 7C byte followed by a byte expressing the difference between 0x0036214 and the jump instruction location.

BUT there is still something that doesn't work, normally a number prepended with one or more 0's is a hex number, but it makes no sense, and the file is 187.776 bytes in total, and 0x00036214=0x36214= 221716 decimal, so that address must be decimal, but it is "queer".

Anyway, since there is no 7C in the 256 bytes before offset 36214, there must be something else we don't understand or translate correctly, maybe the .text:00036214 is a reference of another type, only meaningful when the file is loaded in the disassembler or in memory or *whatever*, but more probably the reference is to actual hex addresses of an already modded acpi.sys

On the thread you found on Win-raid there are a few zillions already modified files, some based on 5512, most on Longhorn (5048) *any* number for XP64, finding something is impossible or nearly impossible.

Your best option is to ask for help/support on Win-raid.

Before that, just try the file from here:
https://www.win-raid.com/t4134f45-Modded-ACPI-Drivers-Depot-XP.html

it is from the "other" branch (Longhorn).

If it works, it works, if it doesn't, ask for assistance there.

jaclaz

 

 

[1] Dietmar (only for the record) is a much esteemed member of many technical boards, but he is specialized in periodically appearing from nowhere, drop on the table one or more fantastic ideas/solutions/whatever, completely fail to document them properly, then disappear for long stretches of time, then - sometimes - he makes a new thread with all his things re-ordered and understandable, sometimes he doesn't.

 

Edited by jaclaz
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.

×
×
  • Create New...