Inside Windows 2000

part 1

A talk from Dave Probert on the design of the NTOS kernel. Shame Microsoft didn’t put this anywhere people could have found this 20+ years ago, just as a shame they never opened up NTOS like they did that even tepid Windows Research Kernel. It goes without saying this is the ‘Linux is a cancer’ generation, with the crazed idea that looking at Linux would contaminate Windows.




Too little, too late I guess. It would have been an interesting foundation a long time ago.

And of course the ongoing work behind the scenes making Windows fully 64bit compatible on the Alpha at the time.

Installing Microsoft Java on Windows 2000 SP4

So yeah, I’m using some old crap software, and it wants MS Java. Great. Ive installed Windows 2000 + SP4, IE6, and then to install MS Java and I get this error:

protected system component?

protected system component?

The Microsoft VM you are attempting to install is a protected system component and can only be updated with a later release of the operating system or service pack.

Well as far as I know, msjavx86-5.0.3810.0 is the last release of MS Java, so what to do?

Apparently all you have to do is rename it to ‘msjavwu.exe’ and it’ll install.

MS Java on IE6

MS Java in action

And there we go, Microsoft Java is working.

Thanks to the java test site that I’ve used over the years:

Loading NT 4.0 & Windows 2000 on Hyper-V

In this attempt to get NT 4.0 running on my machine, here is what I did. This holds true for 2008r2, and 2012 along with the Windows 10 preview.

old versions of Windows are not supported, but with a little bit of fun from PowerShell you can get them to work.

First make sure you run PowerShell as Administrator!

PS C:\WINDOWS\system32> get-vm

Name State CPUUsage(%) MemoryAssigned(M) Uptime Status
—- —– ———– —————– —— ——
NT40 Off 0 0 00:00:00 Operating normally
Windows 2000(wks) Off 0 0 00:00:00 Operating normally

As you can see here I have two virtual machines.  Both of them are ‘off’ since there is no memory assigned, nor is there any uptime.  It’s weird to me how they are “Operating normally’ since they aren’t running but I guess that’s a feature.  Make sure the VMs are powered off before trying to do this.

Restricting the CPU capabilities was the checkbox to enable in the first version of Hyper-V.  Now it’s hidden from the user, so you need to enable this in Power Shell.

First let’s check a VM:

PS C:\WINDOWS\system32> Get-VMProcessor NT40 | fl CompatibilityForOlderOperatingSystemsEnabled

CompatibilityForOlderOperatingSystemsEnabled : False

As you can see it’s disabled.  Now to enable it with:

PS C:\WINDOWS\system32> Set-VMProcessor NT40 -CompatibilityForOlderOperatingSystemsEnabled $true

Now we can verify it’s turned on:

PS C:\WINDOWS\system32> Get-VMProcessor NT40 | fl CompatibilityForOlderOperatingSystemsEnabled

CompatibilityForOlderOperatingSystemsEnabled : True

And we are good to go.

NT 4.0 Service Pack 6 on Hyper-V / Windows 10 Technical Preview 9879

NT 4.0 Service Pack 6 on Hyper-V / Windows 10 Technical Preview 9879

Now for the networking part, remember to remove the existing network adapter, and add the ‘legacy’ network adapter.  On my PC there was an additional snag, which is that every time a VM reboots, or is powered on the legacy adapter will receive NO packets.  Go into the Hyper-V console, and disconnect the legacy adapter, and reconnect it, and network traffic will flow.

And additional note on installing Windows 2000.  You *MUST* change the HAL uppon instalation.  By default it’ll detect an ACPI system, but the driver ACPI.SYS will bluescreen the VM.  Hit F5 when it prompts about storage adapters, and select the ‘STANDARD PC’ HAL from the list.

Just to make the flags more clear

Upgrading through Windows NT; Windows 2000

I’ve always thought Windows 2000 was weird, from the moment it proclaims that it is built on NT Technology! No doubt this was from some kind of marketing slip up, but I guess at this point it was clear who was going to come up with the great names of Windows from here on out.

On the way to upgrading my Windows NT 4.0 install to Windows 2000, I got this interesting prompt:


One nice thing vs the OS/2 upgrade path is that Windows NT converts filesystems, not blindly encourages into new filesystems and destroys your data. While upgrading using Qemu I ran into this ‘disk full’ snag that either has to be fixed by using the -win2k-hack flag, or by the following advice:

There are problems when installing Windows 2000. Windows setup will generate a lot of edb*.log files, one after the other containing nothing but blank spaces in C:\WINNT\SECURITY which quickly fill the virtual hard disk. A workaround is to open a Windows command prompt as early as possible during setup (by pressing Shift+F10) which will allow you to remove these log files as they appear by typing:
del %windir%\security\*.log

With that in mind the Windows 2000 upgrade takes a while to complete.  This is largely from some bizarre fault with Qemu.  But it will complete.

Windows 2000 adds quite a few things from NT 4.0, including:

  • the new shell
  • USB Support
  • Plug & Play (although it hid in NT 4.0 SP3)
  • NTFS defragmentation
  • no more bluescreen boots
  • Active Directory (from the server side)
  • support for multiple displays

After performing the upgrade, I did find that there was some weirdness going on, as I now had no network, and no sound!  So looking at the device manager I got this strange error as administrator!

Not an Administrator?

Well that is odd, looking at the hardware pane below…


I don’t understand what went wrong here, but basically all the hardware is screwed up. In the meantime I’m installing SP4 for Windows 2000 to see if that helps in the slightest.  The only plus side is that my old applications work well.

I just found out, the local security database is screwed up! running:

esentutl /P secedit.sdb

then deleted the log files in the %systemroot%\security directory.

seems to have fixed it.  Also I did this:

Start>Programs>Administrative Tools>Local Security Policy> Expand
“Local Policies” click on “User Rights Assignement” and double click on
“Load and unload device drivers”. Make sure that Administrators are
Assigned To and put a check mark in the “Local Policy Setting” box.

I’m still having issues even trying to upgrade to XP so … hold tight.

Windows 2000 Professional

I went ahead and re-upgraded my NT 4.0 but this time with the correct -win2k-hack flag, and still had to delete log files, but most of the hardware is in place.  However I still do get errors saying my administrator user isn’t an administrator to correct anything.

I remember at the time more and more users that would try to game on Windows 98 moving onto either NT 4.0 or Windows 2000.  At the time there was a feeling that Windows 2000 was ready for ‘normal users’, there even was project Neptune at Microsoft to try to make this happen but best I can figure it slipped but someone liked what they saw, and they combined it with other components for Whistler AKA Windows XP. With Windows 2000 all the RISC fans basically saw the writing on the wall for mainstream RISC support.  It was effectivly over, the Pentium PRO and it’s ilk had basically destroyed the MIPS/PowerPC/Alpha market.

Windows 2000 saw four service packs, and the number of platforms NT was supported on cut down from four to one.  There was hopes of a Windows 2000 for the new Itanium but the pre-release 2000 for the Itanium looks far more like a Windows .NET server beta which it probably is.

It wasn’t until 2001 when the successor to 2000 was released, Windows XP.

Installing Windows 2000 on Qemu 0.14.0

Well good news on the Qemu front, I haven’t tried Windows 2000 in a while, but it installs without any major issues on Qemu 0.14.0.

First I created a 4GB disk..

qemu-img.exe create -f qcow2 win2.disk 4G
Formatting ‘win2.disk’, fmt=qcow2 size=4294967296 encryption=off cluster_size=0

Then I’m firing up Qemu like this:

qemu.exe -L pc-bios -m 512 -hda win2k.disk -net nic,model=pcnet -net user -redir tcp:4444::3389 -cpu pentium -soundhw sb16,adlib -cdrom windows2000.iso -boot d

I’ve setup the AMD PCNet ethernet adapter, and some soundblaster/adlib fun. What the heck.

Since I’m using my MSDN stuff, I figured I’d install Advanced Server.. not that I need the clustering or anything, but what the hell, it sounds exciting. Anyways in the old days we needed to add this -win2k-hack which forced the disks into extra slow mode (PIO). The good news is that we don’t have to worry about that anymore.

And the installer comes up without any issues….

And for the hell of it, let’s go NTFS. Go ahead and go thru the rest of the install steps, and then it’ll be ready to reboot.

The only ‘issue’ I’ve seen, and it goes for physical installs to is you’ll come up to when it’s detecting physical hardware and it’ll freeze right here.

Move the mouse hit some keys… And it’ll move. Otherwise, you’ll be sitting on this screen for a long long time. But Windows 2000 did the same thing on physical hardware too. Also it’s best to be moving the mouse around when the GUI boot completes otherwise it may just seemingly lock. I’ve had this issue on ‘fine’ Dell equipment too..

I like the terminal services & remote administration mode…

Even though with Qemu you can send the frame buffer out via VNC, but RDP is more robust.. not to knock VNC. Anyways Windows 2000 will continue to do it’s thing… So sit back and it’ll keep on chugging…

Registering components takes a while… Windows 2000 had a BIG push moving everything into COM objects, which sounded like a great idea, but it takes a while to register all this stuff… And it gave us the incredible DCOM protocol to go forward. Too bad it doesn’t NAT for crap, but it’s amusing watching it ‘MEOW’ around the network.

Then we are on to saving the settings…

Which isn’t too fast either. Waggle the mouse a bit, for the hell of it. And keep on waiting.

And then…

And we are done!

So now Qemu will reboot the image.. The Windows 2000 ISO’s can optionally not boot so ignore it, and..

Hopefully no inaccessible boot device errors…

And now starting up…

And here we are! Now just to send a control alt delete…

I know this is hard for some people, but there is no ‘clean’ way to hit control alt delete, you just hit control+alt+2 which will bring you to the console which then you can send in the command by typing in…

sendkey ctrl-alt-delete

And then to switch back, it’s control+alt+1 … Easy, right?

And then you can login and all is well.

Another tip is to use a USB tablet once Windows 2000 is installed. This allows for a ‘seamless’ pointer, so you don’t have to worry with the control+alt to release the window.

-usbdevice tablet

Well although netware 3.x & 4.x seem to have catastrophic issues, Windows 2000 certainly works well!

Migrating Windows 2000 servers to Proxmox/VE

I’m not going to get into the a super amount of detail here… Maybe the next server I do, but not right now. The mergeide registry addition didn’t work for me. Maybe it’s because this was an old server that was converted to VMWare?

It was Windows NT 4.0 when it was physical, then it was converted to VMWare 2.x back when that was new, then upgraded to Windows 2000, then migrated across to VMWare 3.x where it sat dormant. However it now needed to be brought back to life, so the first step was to remove the old VMWare tools. And that proved to be an episode on it’s own (make copies of all your VMWare Tools ISO’s!!).

Once that was squared away, I kind of expected to load mergeide.reg, then shut down SQL Server, fire up SelfImage, and transfer away. But I was instead greeted with a BSOD, the infamous *** STOP: 0x0000007B (0x818B51B0, 0xC00000010, 0x00000000,0x00000000) INACCESSIBLE_BOOT_DEVICE

So I tried manually adding in the IDE drivers, and then using BartPE to quickly copy the c:\winnt\system32\config\system* files. Well that didn’t work either.

Much to my luck, Proxmox/VE includes SCSI emulation, because it’s based on KVM which in turn uses the hardware framework from Qemu. So it can use the sym_895a.sys driver from LSI which can be downloaded from here. So within Windows 2000, on VMWare I was able to load up the LSI/SYM scsi driver (which hides in the miniport directory on the zip file).

With the driver loaded, I shut down the VM yet again, booted back up with BartPE, and re-copied over the system registry files (c:\winnt\system32\config\system*) along with the scsi driver (c:\winnt\system32\drivers\sym_895a.sys). Now with those in place, I could then finally reset the VM on Proxmox/VE and get this….

So in the end it is finally transfered, I used the ‘pcnet’ Ethernet adapter to maintain the same NIC drivers. So far all seems pretty snappy with it.