Start Me Up

If it doesn't work either, then I can add some checks to narrow down the problem. Btw: You got surprisingly far in the booting process. Once the graphic issue is solved, you will most likely see the graphical user interface of Windows 2000.

The blue screen you got means in many situations that the graphics driver was not able to list any display mode. You could try my universal graphics driver for Windows 2000. But the chances are no way close to 100% that this will fix the problem. It might be a problem with videoprt.sys or no access to the VGA configuration registers.

Are you using the vanilla VGA.sys + VGA.dll as graphics driver or something from Windows XP?

I had a look at your project and made a bit of experience, which I'd like to share. trying it out I tried the iso file by mounting it as a CD drive in a virtual machine (VirtualBox). I selected 64 MB of RAM, which is the minimum system requirement for Windows 2000 Professional, and then I booted from CD. After a short moment of loading the installation greeted my with an error message complaining about the amount of system memory. Also, the message was in the wrong language and I had no ability to change the language. Attachment: memory.png I turned off the virtual machine, increased the amount of memory to 128 MB, which is the minimum system requirement for Windows 2000 Server to Datacenter. But when booting again I was shown the same error message. So I increased the amount again to 256 MB with the same result. So I continued with 512 MB with the same result. When I increased the amount to 1 024 MB the error message no longer appeared. Instead a black screen was shown for about 3 minutes with seemingly no disc activity. Attachment: black.png. After these 3 minutes the screen turned to something colorful but again with seemingly no disc activity. Attachment: colorful.png After 7 minutes in total I aborted the test. Afterwards I increased the amount of memory to 1 536 MB and retried but ended up with the same results (3 minutes black screen then something colorful). the documentation I had a look at the documentation and was pleased to see that at least something exists. Missing documentation is unfortunately a problem with many projects. So I went through it and tried to learn something from it. The documentation starts with claiming that it is a NT6.x installer, using the Window 10 setup to install Windows 2000. Well, Windows 10 is not NT6.x. Here is an overview of the Windows versions and their brand names: Brand name|date of release|version|major version|minor version Windows 2000|December 1999|5.0|05|h|0|h Windows experience (XP) 32 Bit|August 2001|5.01|5|h|1|h Windows experience (XP) 64 Bit|?|5.02|5|h|2|h Windows Server 2003|March 2003|5.02|5|h|2|h Windows Server 2003 R2|?|5.02|5|h|2|h Windows Vista|January 2007|6.00 (build 6000)|6|h0|h Windows Server 2008|March 2008|6.00 (build 6001)|6|h|0|h Windows 7|October 2009|6.01 (build 7600)|6|h|1|h Windows Server 2008 R2|October 2009|6.01 (build 7600)|6|h|1|h Windows 8|?|6.02|6|h|2|h Windows Server 2012|?|6.02|6|h|2|h Windows 8.1|?|6.03|6|h|3|h Windows Server 2012 R2|?|6.03|6|h|3|h Windows 10|?|10.00|10|h|0|h Windows Server 2016|10.00|10|h|0|h If your installer is really based on Windows Vista, it would explain, why it failed with the minimum system requirement regarding memory of Windows 2000. I did not check the system requirement of the processor, but Windows 2000 is fine with a Pentium processor - it does not need a Pentium Pro processor. Windows Vista will not work on a Pentium processor, as far as I know, but I haven't tested it and could be wrong. Legal perspective In your documentation you claim to distribute your project under the MIT license. The files in the iso, on the other hand, seem to be files from Microsoft which are covered by the EULA (not the MIT license). And this brings legal issues regarding copyright. There are only very few countries (like Iran) where distributing files from Microsoft is legal. In some additional countries (like Germany) the distribution is legal, as long as it is done for a scientific purpose. However, when it is not for a scientific purpose (like the general distribution to end users after the beta test is done), then it is also illegal in these countries. So this gets you in the situation, that you can work on your project but you cannot distribute anything to the general public. Which means, you are doing everything just for yourself. It will not serve the Windows 2000 community. As a matter of fact, as long as you keep yourself bussy with this project, you don't work on anything that will be helpful to anyone else. So if all you want to do is install Windows 2000 on a specific computer then just buy a cheap and compatible one on the second hand market. Use it to install Windows 2000 and then mount the hard disc in your favourite computer. It will save you a lot of time. Maybe you could explain your plans about the legal issue if I misunderstood them. Summary The drastic increment of the system requirements make your installer less compatible than a vanilla Windows 2000 disc. Your installer might work for you and some other people which struggle to get through the first phase of the installation. I think it will be difficult to reduce the system requirements as long as you are using so much stuff that you haven't written yourself. The legal issue is very hard to solve if you plan to ship Microsoft's property to end users. It looks as if you are building a spider web. It it useless and you get caught in it. The more time you invest in this project the more difficult it will become for you to let go again and drop the project by coming to the conclusion that all your invested development time is wasted. We had a similar discussion in the discord server a while ago. Some developers started to backport stuff from newer versions of Windows. I warned them about the issue that these files, once completed, could not be distributed to the general public. Folks continued with the backporting. After a while one of the developers involved wanted to announce the progress to the general public in the WinRaid forum (or whatever it is called). His post was quickly deleted. So he posted it here in the MSFN forum where the rules are not enforced so strictly. But still, it would have been much better, if all this precious development time went into something that doesn't need to be hidden somewhere. In politics we have a similar situation with the project "Ukraine". The NATO spent billions and billions into project "Ukraine" and now that nearly everyone knows that the NATO lost the war, they just can't let go. They spend some more billions, send some more ammunition, send some more wonder weapons like the Panzerhaubitze 2000, the Challenger, the Himars, the Taurus. They try to keep Selensky in power for a bit longer but the war is lost. All their spendings are wasted and Ukraine is on the brink of bankruptcy, unable to pay back all the money they borrowed. But they just can't let go, because they spent so much into this project.

There are 2 (or 3) post SP4 Windows updates which fix USB problems during the installation. But, they are both for the second phase when you see the graphical user interface. So my guess is, that Windows 2000 somehow uses the BIOS for keyboard input support during the first phase while you see the text based user interface. KB823086.htm KB829759.htm KB838417.htm

Is there some more information available or maybe a link to a project website?

Yes, Windows 2000 does support the installation of drivers while the Windows installation is still using a text mode. At the beginning of the installation you are being asked to press [F6] to install additional drivers. Is there any specific problem you encountered? Are you looking for a solution to use additional drivers without the need to press a key on your keyboard?

Maybe it's possible to get the universal graphics driver for Windows 2000 running on XP. It supports your J1900 up to 4k while the official driver from Intel supports no more than 1920x1200 I think.

Alright, we are getting somewhere: The analysis is complete. code.htm has been updated. It contains a side-by-side comparison now, showing all versions, including my new proposal to fix this issue. It seems as Microsoft has never changed anything in this function so all 3 versions from Windows Server 2008 are affected. With other words: I doesn't seem as if there is any official update for any version of Windows. The help file has been updated accordingly. --- The alpha test was completed. At the end of the test there were no bugs nor any regressions left. We are ready for the beta test. --- I am looking for a brave beta tester, who is willing to install the prerelease version (ENU) of the update and keep it for about 2 weeks on the computer. I am especially interested in a beta tester who uses his system to play games, because games sometimes do unusual stuff regarding graphics. But I guess I can' t be fussy so I appreciate any help I get. We are looking for any regressions this update might cause like false colors, inability to deal with transparency, system crashes or data corruption. If you like to participate in the beta test, please let me know. If you need a different language (like ITA or RUS), that can be arranged without much trouble. You will need to make a backup of your system, if it contains anything you can't loose. Also, keep in mind, that loss of data can also happen on USB flash drives connected to the test system. If you don't like to participate then don't install the prerelease version, please. The beta test is a necessary step. Once it is done there will be a final release for end users. It will be smaller in size (less than 200 KB if all goes according to the plan) and for all languages.

There are some news on this topic. ------- The list of affected operating systems is now available in the help file: affected_operating_systems.png ------- I created the first prototype of an updater. It is capable of installing a new version of win32.sys and deinstalling it again: updater.png It comes in 24 languages, however, the end user will only see the language of the installed operating system. ------- First tests with the version 5.00.2196.0001V1 have shown, that the proposed solution is flawed. I documented my findings in the help file in the topic "version history" in the subtopic "version 1". ------- I have extracted 3 versions of win32k.sys from Windows Server 2008: Version 6.0.6002.18005 should contain a non fixed version of the function CreateXlateObject Version 6.0.6003.20665 should contain Microsoft's first attempt to fix the function CreateXlateObject Version 6.0.6003.20785 should contain Microsoft's second and final attempt to fix the function CreateXlateObject ------- My new suggestion would be to do a side-by-side comparison to figure out how Microsoft fixed this issue. There is a new version of code.htm online with some space to document the analysis. However, the cells are still empty. ------- That's all I got so far.

Thanks for the feedback. I read that this happens when the file is stored on a network drive or opened with an UNC path but it is supposed to work from a local disc. Anyway, it's just a few htm files and 1 css file compressed into a single chm file. It doesn't even contain java script or anything fancy. Todo: New Damage X (新DamageX) pointed out, that this issue could be related to ZDI-19-982. If this is true, then someone has found a way to exploit this issue to compromise security. Also, it would mean that there might be an official bug fix for newer versions of Windows out there which can be analysed to improve this update. I will check this soon. Edit: ZDI-19-982 leads to KB4525239

@tomasz86 Thank you. That's a veritable goldmine. Keep it online, please.

Well, I did. I am glad that it works for you anyway. Btw: If I remember correctly, I run into the problem on a system with a H2O BIOS from Insyde. The system works more or less ok with Windows 2000's original acpi.sys and ACPI-PC selected.

Backporting a newer version of ACPI.sys to Windows 2000 lead to an unstable system. The issue could not be resolved. No one involed knew what the many changes between the ACPI.sys from Windows 2000 compared to the new one was. So folks just tried to somehow force Windows 2000 to boot with the new ACPI.sys. Eventually Windows 2000 booted with ACPI 2.0 support. At this moment everyone just dropped everything and moved on with something else. That's why it was a waste of time. My suggestion would be to start with ACPI.sys from Windows 2000 and do small and clear changes step by step. Yes, I can help with the binary patching. I do a lot of low level programming. But I am not going to do everything alone.

Hello Windows 2000/XP fans, while I was working on a graphics driver, I noticed random crashes (blue screens) which were hard to reproduce. They don't happen often, but when using a display mode with 16 colors (for example 640x480x16 colors) they seem to happen more often than with other color depths. Eventually I was able to narrow down the problem and came to the conclusion, that the root cause is a buffer overrun in the function "CreateXlateObject" in the file "win32k.sys". This buffer overrun sometimes caused a random crash. In the most cases it happened within win32k.sys. I observed, that this issue is not fixed even in the newest version of win32k.sys from a Windows 2000 update from April 2016. An old version of win32k.sys from Windows XP has the same problem. I don't know which Windows XP update contains the newest version of win32k.sys for Windows XP, so I could not validate whether this issue was ever fixed - and if so: how. So I thought about what to do and came up with the idea, to write a Windows update of my own to fix this bug. So far I gathered necessary information and wrote a help file which contains most of what I know about the nature of this issue and how it can be fixed: OTSKB.chm There is some more auxilliary information available, which I do not plan to distribute among end users: code.htm Eventually, I fixed the win32k.sys from Windows 2000 manually with a hex editor to test the proposed solution: 5.00.2196.0001.zip The update, which would do this automatically and then install the new file automatically, is not written, yet. I would appreciate some feedback before I continue writing the update. Please let me know what you think. Maybe I just got it all wrong, don't know. Edit: Title has been changed from "request for comment" to "looking for a beta tester".

I tried to make my own driver unloadable first, because this should be easier than unloading vga.sys. When the user tries to remove the graphics circuit from the device manager, then my driver receives the following IRPs: DispatchPnP gets called with: IRP_MJ_PNP IRP_MN_QUERY_DEVICE_RELATIONS RemovalRelations DispatchPnP does: create a list with 1 entry (the DeviceObject it received) call IofCompleteRequest DispatchPnP returns: STATUS_SUCCESS DispatchPnP gets called with: IRP_MJ_PNP IRP_MN_QUERY_REMOVE_DEVICE DispatchPnP does: IRP.IoStatus.Status = STATUS_SUCCESS call IofCompleteRequest DispatchPnP returns: STATUS_SUCCESS DispatchPnP gets called with: IRP_MJ_PNP IRP_MN_REMOVE_DEVICE DispatchPnP does: call DispatchPnP of videoprt.sys DispatchPnP returns: STATUS_SUCCESS DispatchPnP gets called with: IRP_MJ_PNP IRP_MN_QUERY_DEVICE_RELATIONS RemovalRelations DispatchPnP does: create a list with 1 entry (the DeviceObject it received) call IofCompleteRequest DispatchPnP returns: STATUS_SUCCESS DispatchPnP gets called with: IRP_MJ_PNP IRP_MN_QUERY_REMOVE_DEVICE DispatchPnP does: IRP.IoStatus.Status = STATUS_SUCCESS call IofCompleteRequest DispatchPnP returns: STATUS_SUCCESS DispatchPnP gets called with: IRP_MJ_PNP IRP_MN_CANCEL_REMOVE_DEVICE DispatchPnP does: call DispatchPnP of videoprt.sys DispatchPnP returns: STATUS_INVALID_DEVICE_STATE Afterwards the display is removed from the device manager but the graphics circuit is still there. Also, the device manager asks for a restart to complete the removal. So I think for the display the process is: QUERY_DEVICE_RELATIONS -> QUERY_REMOVE_DEVICE -> REMOVE_DEVICE And for the graphics circuit the process is: QUERY_DEVICE_RELATIONS -> QUERY_REMOVE_DEVICE -> CANCEL_REMOVE_DEVICE For some unknown reason Windows decides not to continue with the graphics circuit removal process.

.

I do not have an external graphics card to test your theory. The integrated graphics circuits I have can't be removed from the system, because they are a subcircuit of the chipset or the processor. If the vga.sys driver is still blocking the system from going into sleep because it's still running in the background, is it still possible somehow to remove the blockade? Edit: I think what I need to do, is basicly to find a save and clean way to unload vga.sys and make sure it gets loaded again if my driver gets unloaded. Well, thank you @jumper. I think you gave me the crucial information I was missing.

Hello developers, in Windows 2000 we have the situation, that if there is a non-plug-and-play-capable driver active, then the shutdown options "standby" and "hibernation" are not available. For example the driver vga.sys of Windows 2000 prevents the system from going into standby mode. When vga.sys is replaced with a plug-and-play-capable driver by installing one and then restarting, then the power options are available. My graphics driver is capable of performing mode switching and turning off the display after a certain time of inactivity directly after the installation. But the additional power options are only available after the user has restarted the computer. videoprt.sys and my driver do not receive any IRP_MJ_POWER queries until the system has been restarted. When I try to enter the standby mode manually by calling ntdll.dll/NtSetSystemPowerState before the reboot I get a STATUS_CANCELLED and a STATUS_SUCCESS after the reboot. I am out of ideas about what the operating system is waiting for and why it needs the restart. Does anyone have an idea what the problem could be? Many thanks.