Jump to content

looking for up to date solution for Windows 2000 install on modern hardware + acpi support


Recommended Posts

Posted (edited)

Let me address the USB regression first, since it is easier to deal with. It's just a lot of work on my side to gather the information.

The issue you described sounds like the issue that was fixed with the Windows 2000 update "KB829759". This is a non security related bug fix for USB. The report on this update mentions

  • 100% CPU load,
  • unrecognized USB devices and
  • the error codes 28 and 31 in the device manager.

With a vanilla Windows 2000 installation and service pack 4 integrated or installed afterwards, you should have the following files on your computer:

  • hidclass.sys - 2003-06-19 - 5.00.2195.6655
  • hidusb.sys - 1999-10-04 - 5.00.2142.1
  • openhci.sys - 2003-06-19 - 5.00.2195.6675
  • uhcd.sys - 2003-06-19 - 5.00.2195.6655
  • usb.inf - 2003-06-19 - 5.00.2195.6717
  • usbaudio.sys - 1999-10-12 - 5.00.2150.1
  • usbcamd.sys - 1999-09-27 - 5.00.2135.1
  • usbd.sys - 2003-06-19 - 5.00.2195.6658
  • usbehci.sys - 2003-06-19 - 5.00.2195.6709
  • usbhub.sys - 2003-06-19 - 5.00.2195.6689
  • usbhub20.sys - 2003-06-19 - 5.00.2195.6655
  • usbintel.sys - 1999-09-25 - 5.00.2134.1
  • usbport.sys - 2003-06-19 - 5.00.2195.6681
  • usbprint.sys - 2003-06-19 - 5.00.2195.6655
  • usbscan.sys - 2003-06-19 - 5.00.2195.6655
  • usbser.sys - 2003-06-19 - 5.00.2195.6655
  • usbstor.inf - 1999-12-10 - 5.00.2195.1
  • usbstor.sys - 2003-06-19 - 5.00.2195.6655

The report mentions that the bug was introduced with the following versions:

  • usbehci.sys - 2003-01-15 - 5.00.2195.6655
  • usbhub20.sys - 2003-01-15 - 5.00.2195.6655
  • usbport.sys - 2003-01-20 - 5.00.2195.6657

And that the bug was fixed with the following versions:

  • hidclass.sys - 2003-09-21 - 5.0.2195.6824
  • openhci.sys - 2003-09-21 - 5.0.2195.6824
  • uhcd.sys - 2003-09-21 - 5.0.2195.6824
  • usb.inf - 2003-10-08 - 5.00.2195.6863
  • usbd.sys - 2003-09-21 - 5.0.2195.6824
  • usbehci.sys - 2003-09-21 - 5.0.2195.6824
  • usbhub20.sys - 2003-09-21 - 5.0.2195.6824
  • usbport.sys - 2003-09-21 - 5.0.2195.6824

So the files from service pack 4 are affected by this issue.

Some of these files are included in various Windows updates:

hidclass.sys

  1. RTM - 1999-10-25 - 5.00.2163.1
  2. KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6655
  3. KB818129 - 2003-01-15 - 5.00.2195.6655
  4. KB820759 - 2003-01-15 - 5.00.2195.6655
  5. KB827675 - 2003-09-13 - 5.00.2195.6820
  6. KB829759 - 2003-09-21 - 5.00.2195.6824
  7. KB838989 - 2003-12-12 - 5.00.2195.6882
  8. KB843503 - 2003-12-12 - 5.00.2195.6882

hidusb.sys

  1. RTM - 1999-10-04 - 5.00.2142.1

openhci.sys

  1. RTM - 1999-10-26 - 5.00.2164.1
  2. KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6675
  3. KB818129 - 2003-04-23 - 5.00.2195.6739
  4. KB819895 - 2003-05-08 - 5.00.2195.6743
  5. KB820759 - 2003-05-08 - 5.00.2195.6743
  6. KB823715 - 2003-07-22 - 5.00.2195.6789
  7. KB827675 - 2003-09-13 - 5.00.2195.6820
  8. KB829759 - 2003-09-21 - 5.00.2195.6824
  9. KB838989 - 2003-12-12 - 5.00.2195.6882
  10. KB843503 - 2004-06-11 - 5.00.2195.6940
  11. KB843540 - 2004-06-11 - 5.00.2195.6940

uhcd.sys

  1. RTM - 1999-10-05 - 5.00.2143.1
  2. KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6655
  3. KB818129 - 2003-04-23 - 5.00.2195.6739
  4. KB820759 - 2003-04-23 - 5.00.2195.6739
  5. KB827675 - 2003-09-13 - 5.00.2195.6820
  6. KB829759 - 2003-09-21 - 5.00.2195.6824
  7. KB838989 - 2003-12-12 - 5.00.2195.6882
  8. KB843503 - 2003-12-12 - 5.00.2195.6882

usb.inf

  1. RTM - 1999-12-10 - 5.00.2195.1
  2. KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6717
  3. KB829759 - 2003-10-08 - 5.00.2195.6863
  4. KB838989 - 2004-06-01 - 5.00.2195.6936
  5. KB843503 - 2004-06-07 - 5.00.2195.6939

usbaudio.sys

  1. RTM - 1999-10-12 - 5.00.2150.1
  2. KB891069 - 2005-01-10 - 5.00.2195.7019

usbcamd.sys

  1. RTM - 1999-09-27 - 5.00.2135.1
  2. KB836111 - 2004-03-16 - 5.00.2195.6883

usbd.sys

  1. RTM - 1999-10-09 - 5.00.2147.1
  2. KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6658
  3. KB818129 - 2003-04-23 - 5.00.2195.6739
  4. KB820759 - 2003-04-23 - 5.00.2195.6739
  5. KB827675 - 2003-09-13 - 5.00.2195.6820
  6. KB829759 - 2003-09-21 - 5.00.2195.6824
  7. KB838921 - 2003-12-12 - 5.00.2195.6882
  8. KB838989 - 2003-12-12 - 5.00.2195.6882
  9. KB843503 - 2004-05-28 - 5.00.2195.6935
  10. KB838417 - 2004-12-07 - 5.00.2195.7008

usbehci.sys

  1. KB810090 - 2003-01-15 - 5.00.2195.6655
  2. KB818129 - 2003-01-15 - 5.00.2195.6655
  3. KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6709
  4. KB820759 - 2003-05-13 - 5.00.2195.6745
  5. KB827675 - 2003-09-19 - 5.00.2195.6823
  6. KB829759 - 2003-09-21 - 5.00.2195.6824
  7. KB838989 - 2003-12-12 - 5.00.2195.6882
  8. KB843503 - 2003-12-12 - 5.00.2195.6882

usbhub.sys

  1. RTM - 1999-11-12 - 5.00.2181.1
  2. KB810090 - 2003-01-15 - 5.00.2195.6655
  3. KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6689
  4. KB838771 - 2004-03-16 - 5.00.2195.6883
  5. KB838921 - 2004-04-01 - 5.00.2195.6884
  6. KB838417 - 2004-12-02 - 5.00.2195.7006

usbhub20.sys

  1. KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6655
  2. KB818129 - 2003-01-15 - 5.00.2195.6655
  3. KB820759 - 2003-01-15 - 5.00.2195.6655
  4. KB827675 - 2003-09-13 - 5.00.2195.6820
  5. KB829759 - 2003-09-21 - 5.00.2195.6824
  6. KB838989 - 2004-01-16 - 5.00.2195.6891
  7. KB843503 - 2004-01-16 - 5.00.2195.6891

usbintel.sys

  1. RTM - 1999-09-25 - 5.00.2134.1

usbport.sys

  1. KB810090 - 2003-01-20 - 5.00.2195.6657
  2. KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6681
  3. KB818129 - 2003-04-28 - 5.00.2195.6741
  4. KB820759 - 2003-04-28 - 5.00.2195.6741
  5. KB827675 - 2003-09-13 - 5.00.2195.6820
  6. KB829759 - 2003-09-21 - 5.00.2195.6824
  7. KB838989 - 2004-03-23 - 5.00.2195.6885
  8. KB843503 - 2004-06-16 - 5.00.2195.6941

usbprint.sys

  1. RTM - 1999-10-26 - 5.00.2164.1
  2. KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6655
  3. KB883528 - 2004-08-17 - 5.00.2195.6968

usbscan.sys

  1. RTM - 1999-10-13 - 5.00.2151.1
  2. KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6655

usbser.sys

  1. RTM - 1999-10-15 - 5.00.2153.1
  2. KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6655
  3. KB838417 - 2004-12-02 - 5.00.2195.7006

usbstor.inf

  1. RTM - 1999-12-10 - 5.00.2195.1

usbstor.sys

  1. RTM - 1999-09-30 - 5.00.2138.1
  2. KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6655
  3. KB823086 - 2003-07-11 - 5.00.2195.6773
  4. KB817765 - 2003-11-06 - 5.00.2195.6871
  5. KB841880 - 2004-05-27 - 5.00.2195.6934
  6. KB890202 - 2004-12-10 - 5.00.2195.7009

Let me know if the USB problem still exists after updating the USB related files with the Windows updates. And if it does still exist, what changes you have made to usb.inf to fix the problem on your system. That would be helpful. Thank you.

If I find some time again, I will look into the other problem, which is the real blocker for you at the moment.

Edited by Start Me Up
version number of usbscan.sys for SP4 corrected

Posted (edited)

I performed some tests on hardware of mine to reproduce the bluescreen you see. The test results after switching from Standard PC to ACPI PC are as follows:

test system #1:

  • processor brand name: Atom 230
  • processor manufacturer name: Intel
  • BIOS brand name: BIOS setup utility
  • BIOS manufacturer name: American Mega Trends

Test result:

No bluescreen, boots flawlessly.

test system #2:

  • processor brand name: Atom D525
  • processor manufacturer name: Intel
  • BIOS brand name: CMOS setup utility
  • BIOS manufacturer name: Award Software

Test result:

No bluescreen, boots flawlessly.

test system #3:

  • processor brand name: Atom D2550
  • processor manufacturer name: Intel
  • BIOS brand name: ASRock UEFI setup utility
  • BIOS manufacturer name: American Mega Trends

Test result:

No bluescreen, boots flawlessly.

test system #4:

  • processor brand name: Atom E3815
  • processor manufacturer name: Intel
  • BIOS brand name: visual BIOS
  • BIOS manufacturer name: Intel

Test result:

Bluescreen as follows:

  • 0x0000001e: KMODE_EXCEPTION_NOT_HANDLED
  • 0xC0000005: STATUS_ACCESS_VIOLATION
  • 0xbffe1aaa: address of the code that caused the bugcheck
  • 0x00000000: 
  • 0x00000010: address of the target that was accessed
  • 0xbffd8000: base address of ACPI.sys, version 5.00.2195.6920

test system #5:

  • processor brand name: Atom E3815
  • processor manufacturer name: Intel
  • BIOS brand name: H2O
  • BIOS manufacturer name: Insyde

Test result:

No bluescreen, boots flawlessly.

test system #6:

  • processor brand name: Atom N280
  • processor manufacturer name: Intel
  • BIOS brand name: hp Thin Client setup utility
  • BIOS manufacturer name: American Mega Trends

Test result:

No bluescreen, boots flawlessly.

test system #7:

  • processor brand name: Core i5-3337U
  • processor manufacturer name: Intel
  • BIOS brand name: H2O
  • BIOS manufacturer name: Insyde

Test result:

No bluescreen, boots flawlessly.

---

When you try to install vanilla Windows 2000 with service pack 4 and ACPI PC selected, does the setup hang like it does with your other iso?

Edited by Start Me Up
Posted

based off my windows 2000 sp4 iso package ( only "usb.in_" (effectively usb.inf) was modified for the related files, 
i did not touch anything else in the iso for the following files below ):

hidclass.sys - 2003-06-19 - 5.00.2195.6655 - yes includes same version, but there's a file with same name in 
another folder ( driver.cab ) in lowercase that is actually a lower file version at 5.0.2163.1. the reason why i find 
this important is if i wanted to replace these files with your updated / fixed versions, i want to be sure im replacing 
them correctly in all appropriate areas, and im not sure if i need to also replace that lower case version too? i know 
that i also have to replace the "_" versions as well, by creating an extra copy and convert it to that format, such 
as in the case of "hidclass.sy_", but i dont know if i also need to modify other areas. 
hidusb.sys - 1999-10-04 - 5.00.2142.1 - same 
openhci.sys - 2003-06-19 - 5.00.2195.6675 - same in "sp4.cab", but in "driver.cab", it reads 5.0.2164.1
uhcd.sys - 2003-06-19 - 5.00.2195.6655 - same in "sp4.cab", but in "driver.cab", it reads 5.0.2143.1 
usb.inf - 2003-06-19 - 5.00.2195.6717 - appears to be the same, driver version 5.00.2195.6717 
usbaudio.sys - 1999-10-12 - 5.00.2150.1 - same
usbcamd.sys - 1999-09-27 - 5.00.2135.1 - same
usbd.sys - 2003-06-19 - 5.00.2195.6658 - same in "sp4.cab", but in "driver.cab", it reads 5.0.2147.1
usbehci.sys - 2003-06-19 - 5.00.2195.6709 - same 
usbhub.sys - 2003-06-19 - 5.00.2195.6689 - same in "sp4.cab", but in "driver.cab", it reads 5.0.2181.1
usbhub20.sys - 2003-06-19 - 5.00.2195.6655 - same 
usbintel.sys - 1999-09-25 - 5.00.2134.1 - same
usbport.sys - 2003-06-19 - 5.00.2195.6681 - same
usbprint.sys - 2003-06-19 - 5.00.2195.6655 - same in "sp4.cab", but in "driver.cab", it reads 5.0.2164.1
usbscan.sys - 2003-06-19 - 5.00.2195.6655 - same in "sp4.cab", but in "driver.cab", it reads 5.0.2151.1
usbser.sys - 2003-06-19 - 5.00.2195.6655 - same in "sp4.cab", but in "driver.cab", it reads 5.0.2153.1
usbstor.inf - 1999-12-10 - 5.00.2195.1 - could only find "usbstor.in_", once expanded, driver version 
said 5.00.2183.1
usbstor.sys - 2003-06-19 - 5.00.2195.6655 - same in "sp4.cab", but in "driver.cab", it reads 5.0.2138.1

I may not individually test such updates if i could somehow integrate the necessary files into another custom iso 
to test, because at the moment, my system isn't bootable anymore and i'd have to start fresh anyways, and so i would 
rather just make another custom iso to test as the next attempt. The issue would be if any windows updates / unofficial 
updates would override the files with older / not functional ones, but upon extracting various packages, such as 
update rollup 1 / uu rollup v11, only the uu rollup v11 ( Windows2000-UURollup-v11-d20141130-x86-ENU ) installs 
newer hidclass.sys and usbser.sys, so i dont think it would be a problem. Though i ought to check inside those updates 
you linked for more details.  

As for vanilla windows 2000 sp4 install with ACPI PC selected, yes, it does the same thing, it hangs at "setup is starting windows 2000". 

Posted

Ok i see you didn't mention different / newer versions for hidusb.sys, usbintel.sys, and usbscan.sys, does that mean i dont need updates for these? Other than that, I do need to request for some other files, for "KB891069" ( usbaudio.sys ), "KB890202" ( usbstor.sys ), and "KB883528"  (usbprint.sys ), i cannot extract the files from the package, the .sys files are not there, and only appear to be installed via a windows 2000 system. Can you link these, same for "KB838921 ( usbhub.sys ) and usbser.sys ( unless the vanilla sp4 one is ok ). i actually didnt mention KB838417 for usbser.sys, because from one site, it mentions that this update is listed as problematic, causing BSOD on usb 1 devices, so no to 7006 version?  

Posted (edited)
18 hours ago, cov3rt said:

... there's a file with same name in another folder ( driver.cab ) in lowercase that is actually a lower file version at 5.0.2163.1. the reason why i find this important is if i wanted to replace these files with your updated / fixed versions, i want to be sure im replacing them correctly in all appropriate areas, and im not sure if i need to also replace that lower case version too? i know that i also have to replace the "_" versions as well, by creating an extra copy and convert it to that format, such as in the case of "hidclass.sy_", but i dont know if i also need to modify other areas.

You came up with the theory that you need to make changes to the files "driver.cab" and "sp4.cab" for a second time now. I guess that the guide you mentioned but didn't bother to link is this one. It contains the approach to modify the file "driver.cab".

I told you that you should not make any changes to them. I further explained that the file "driver.cab" is a back up storage for RTM files and the file "sp4.cab" is a back up location for service pack 4 files. I further added that people who don't know how the system file protection works mess with these files to destroy the mechanism to a degree that it doesn't work anymore because it has no source anymore to restore overwritten system files. Also, that you add additional problems to your system if you do so.

Since I wrote this message just a few days ago, I don't think that you have forgotten about it  So my theory is, that you ignored it because you are convinced that the information is incorrect but don't have any facts to prove your point.

Since you said that this is an important point to you and I don't want to end up in an endless loop where I tell you that you are messing with the wrong files and you try to do it anyway, let's go through this.

  • people who don't know how the file protection works mess with driver.cab and sp4.cab

One of my claims is, that people, who don't know how the file protection mechanism works, mess with these files.

You were asking which of the files in these cabinet files need to be overwritten and read a guide which documents how to modify the cabinet files. This indeed shows that you don't know how the file protection mechanism works while you are one of those persons who want to mess with the files so it is evidence that my point is actually correct

  • driver.cab contains RTM files

Another claim of mine is that the file "driver.cab" contains RTM files.

Now that you inspected the content of this cabinet file you noticed that there are files with exactly the version numbers as I listed as RTM files. The only difference you found was with the file "usbstor.inf". You said, that you found the version "5.0.2138.1". Yes, this true for the english edition of Windows 2000. The english edition contains an outdated version of this file. The arabic edition, for example, uses the version "5.00.2195.1" as listed in one of my previous posts. This is strong evidence that my point regarding the content of the cabinet is correct.

  • sp4.cab contains SP4 files

Another claim of mine is that the file "sp4.cab" contains SP4 files.

While you did your inspection you also checked out the file "sp4.cab". If you compare the version numbers you found with the version numbers I listed, you will once again notice that they are indeed SP4 files. This is strong evidence that my point regarding the content of the cabinet file is correct.

  • driver.cab and sp4.cab should not contain anything else than what they already have

Another claim of mine is that the mentioned cabinet files should not contain anything else than what they already have.

Official post SP4 Windows updates install new files without changing the content of the 2 mentioned cabinet files. This is strong evidence that my point, that the cabinet files should not be changed, is correct.

  • messing with driver.cab or sp4.cab can cause problems

Another claim of mine is that when someone performs modifications to these 2 cabinet files then this can cause problems, like being unable to switch the HAL.

It was quite a while ago but nevertheless there was a point in time when I discovered the directory "driver cache" and wondered what it was for. It contained the discussed cabinet files and some other files. At the end of the day it used up disk space and I did not know what these file were for. So I thought, since it is some kind of cache, it probably doesn't hurt to empty it. So I deleted the content. I think that went well for a while. But when I wanted to switch the HAL I couldn't do it anymore because the required files for the new HAL weren't available anymore. So maybe a better directory name would be "driver repository".

At a different time I changed a file within one of the cabinets. I created a new cabinet file but of course it wasn't exactly the same as the old one. Maybe I used a different compression method or screwed up something else. Anyway, the result was, that I could not boot anymore. Now this isn't strong evidence for anything but it is still nonetheless some evidence that messing with these cabinet files can indeed cause problems.

And these reasons and this experience I made lead to my viewpoint.

Now I could still be wrong about my theory how the system file protection of Windows 2000 works and how an update of system files works, but what evidence do you have to support your theory that the cabinet files might need to be modified anyway?

Edited by Start Me Up
Posted (edited)

About a year ago there was an announcement by a user who goes by the handle "Windows 2000 Warrior" about some work on ACPI support in Windows 2000. In his announcement he stated:

Quote

InsydeH2O BIOS is not fully tested yet. Currently, it still presents problems at the "Setup is starting Windows 2000" phase.

@windows2 are you still around? Is there any news on this issue?

Edited by Start Me Up
Posted

I did look at the thread you linked before all this but it was more on general guidelines on how to integrate the related files and does not really provide any other info. The thing is on the topic of replacing files in sp4.cab / driver.cab, etc, i asked chatgpt on it ( yes, i know chatgpt can be often wrong ), but according to them, they said that it makes most sense to replace the files in all areas they are currently located in ( specifically confirming on sp4.cab/driver.cab ), as well as the "_" versions of the files for wherever they are located,

However, there are things where chatgpt may not always tell you unless you ask about it, so it does not mean my approach is correct either, but rather that there may be additional steps i need to do that i haven't done yet. 

On the HAL switching or whatever, i dont think that is because of incorrect replacement of files, because i also used blackwingcat's iso packages without modifying them and trying the same approach ( standard pc to ACPI PC from device manager ) and it still had the same problems as i had mentioned in my earlier posts. I also tried the vanilla 2K pro sp4 iso you requested ( nothing modified at all ) in exactly the same way as the other routes, ( standard pc to ACPI PC from device manager ) and no difference. 

Posted (edited)

Regarding the USB updates:

To extract files there is the command line option "-c" for old updates and "-x" for new updates. With other words:

  1. Click "Start"
  2. Click run
  3. enter "cmd.exe"
  4. Drag and drop the update (the exe file) into the command prompt so the address is inserted.
  5. Then add a space and then "-x" and press enter.

To integrate an update into a Windows installation CD:

  1. Insert the vanilla Windows CD into your CD drive.
  2. Copy all files to a directory with a short and simple path like "C:\cd".
  3. Use the command line option "-s:C:\cd\" to integrate the files into the CD directory.
  4. Now the vanilla Windows CD has turned into a custom CD.
  5. Burn it as bootable data disk.

However, I don't think that the update "KB836111" has the command line switch "-s". But with the newer ones this should work.

Regarding the main problem:

Now that you tried basicly everything that both of us could think of, I think we have a problem that can't be solved easily. You tried it your way and you tried it my way and it failed anyway. So maybe you are forced to use Standard PC after all. Or some different hardware. But that's not quite what you wanted. Well, there were some outdated core component files that can be updated, but who knows whether this will get you anywhere 

KB2535512.7z

KB2676562.7z

Maybe you are right and the files from the updates haven't even been loaded yet when the hang happens. But they might still be nice to have.

Edited by Start Me Up
Posted

If you can still answer on the usbser.sys / usbhub.sys version 700x known to be problematic, that would help. yes, most of this ( both acpi and usb related ) is something i have to figure out mainly on my own at this point probably, but it would help to know if i can get another perspective before i do any more modifications. Here is the thread mentioning the usb problematic updates"

"

Posted (edited)

Well, I read the post a while ago but I don't have the hardware to reproduce the bug. Here are the files if you like to experiment.

Edited by Start Me Up
Posted (edited)

Ok so fortunately i found a workable route, though the system hasn't gone through rigorous testing, with some important things missing / some apparent bugs, restart issues, etc. Basically i started fresh and used again "YSI_Win2kPro_R3.3_DEV-TEST-processr.iso" obtainable from here "http://static.skver.space/w2k/isos/", but this time before installing, i disabled "multi core" in bios, and used IDE mode instead of AHCI. on setup, i used f5 option "Advanced Configuration and Power Interface (ACPI) PC )", and wallah, it no longer got stuck at "Setup is starting windows 2000". 

Right after install though, it stalled out with a loading cursor, i waited a while, then manually shut off the system, and it rebooted normally into desktop to finish up some stuff. Now i won't be able to document all the stuff i did up to this point. But i did want to document this here to help others, and give the assurance that acpi support on modern hardware is more feasible, just that you need to carefully examine your bios very well. in my case, i didnt think multi core setting would matter, but it made all the difference here, though i did have to also use IDE mode as well in particular. 

I used videoprt.sys 5.0.2195.6833 + acpi.sys 5.1.2600.7777 to get basic functionality from the intel hd 3000 graphics. i had black/blue screen earlier on boot with other videoprt.sys versions. i installed the gpu driver using the executable, link for the gpu driver can be obtained from the following "https://web.archive.org/web/20140830162901/http://w2k.flxsrv.org/cgi-bin/dl.cgi?file=win2k_145111.exe". I do have .net framework 3.5 sp1 installed ( ran setup.cmd to install ) obtainable from blackwingcat's site ( https://win2k.org/wlu/wluen.htm ), but im not sure if that's absolutely required for the gpu to work, it seems to be only for the control panel thing which i did test working. 

The instability issues im having inside the os though could partially be / indirectly affected by too much usable ram at the moment ( 4 GB installed ), so i plan on limiting this to 2 GB ( boot settings ) and seeing if it helps in any way.

Also for those dual booting, you can still re-enable the multi core bios setting later on, but you must immediately go to windows 2000 safe mode right after to disable the exclamation / problematic processor name with also the "unknown device" right underneath it in the same section of device manager, or else the system will become unbootable. For some reason, you dont need to disable the exclamation processor when the "multi core" setting is disabled, though im not sure if the "unknown device" that shows in safe mode is directly because of enabling "multi core" or if it had already existed there when "multi core" setting was disabled. 

 

Edited by cov3rt
Posted
On 5/17/2026 at 5:20 PM, Start Me Up said:

About a year ago there was an announcement by a user who goes by the handle "Windows 2000 Warrior" about some work on ACPI support in Windows 2000. In his announcement he stated:

@windows2 are you still around? Is there any news on this issue?

It's actually been a long time since the last update to this project, we need more time and will. the BSOD issues on devices without a serial COM port make things hard , and I've discussed with Rairii the possibility of creating a solution that would allow us to debug via Ethernet cable as exemple. so an interface in the HAL intended for serial debugging send/receive one byte at a time should implimented , 

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
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...