Sometimes I need to do a little bit of retro-computing (not with virtual machines) to support some ancient hardware.

As far as compatibility is concerned, I have yet run across any weird piece of software that specifically requires Windows ME, 2000, Vista or Windows 8 to run that cannot be run with an OS one step up.

Windows 98 SE generally displaces anything from Windows 95 to Windows 98.

Windows 2000/XP usually run anything that are meant for NT starting from 4.0.

Windows NT 3.51 usually run Win32s programs that works on Win 3.1, except it’s way more stable.

Installation Order

The OSes should be installed from old to new:

• DOS/Win 3.1 + 98 (SE)
• XP
• Windows 7

Reorganize boot menu

Windows XP installs a NT52 style (NTLDR) boot menu that recognizes DOS as a partition to boot. Windows 7 installer will install a NT60 style (BCD) boot menu that that the NTLDR loader as an OS (it’s called Earlier version of Windows) instead of directly booting to Windows XP. This means to get to Windows XP / DOS, you’ll have to select twice.

We can fix this by EasyBCD, which rebuilds the bootloader options for the installed OSes. Doing it with bcdedit is a major pain in the arse. There are some quirks to watch out for in the process no matter which path you choose:

• You might need to boot into safe mode if the current BCD is locked.
• Whatever OS that you are currently in calls itself C: and everybody else shifted according to the partition order.
• When setting drive letter for the boot menu item, observe the drive letter scheme currently seen by the host OS. i.e. use C: when referring to the currently booted OS
• Do not take up on EasyBCD’s offer to detect the drive letter automatically. They are likely to be wrong guesses that won’t boot, likely because of the shifting C: issue.

While you are at EasyBCD, it also offer the option of booting ISO (optical drives) and IMA (floppy) images, which I find it convenient for making the PC a tech service station.

Note that the DOS menu provided by EasyBCD went through an extra layer of indirection called GRUB4DOS, so it’s not as native as going through NT60 (BCD) > NT52 (NTLDR) > DOS in the sense that it installed foreign stuff not made by Microsoft such as Grub.

Tip about bcdedit

• Some old versions of bcdedit’s /? menu did not tell you about the /store switch, which is necessary to manipulate foreign BCD files instead of the host BCD (that you used to boot to the current Windows you are working in).

For some very old system that doesn’t support hardware USB CD-ROM (ISO) emulators (or it only has USB 1.1 ports which is begrudgingly slow), there’s a way to put your installer in a HDD/SSD (IDE/SATA) and boot the installer image on them. Turns out it’s quite easy. All you need to do is copy the set of entire Windows installation files in an MBR drive with partition set active, then write the boot sector to it!

1. Make sure your HDD is in MBR, not GPT
2. Make a partition that’s bootable (can be NTFS) by marking it as Active (Active partition only make sense with MBR. That’s why you should make your disk MBR)
3. Copy all the files from Windows CD image to the drive
4. Run the following code the build the boot sector for the drive. One interesting twist is that you must run this command from the drive letter you want to rebuild the boot sector (or it’ll refuse to run) yet you have to specify what drive letter to rebuild the boot sector! Let’s call the drive P:\

P:\:> bootsect /nt60 P:\

The /nt60 is the modern boot manager for Windows 7 and above. /nt52 is Windows XP and old NT style (NTLDR) boot manager. Miss the old days when I was using winnt /b!

Firewall exception for “File and Printer Sharing” is not enabled by default. Check the boxes below to enable CIFS/SMB sharing.

Enabling “File and Printer Sharing” also enables pinging into the said Windows 10 machine since this group also enable “Echo Request – ICMPv4) that the details can be seen in Advanced Firewall Config rules.

Command line shortcuts

netsh advfirewall firewall set rule group="Network Discovery" new enable=Yes
netsh advfirewall firewall set rule group="File and Printer Sharing" new enable=Yes

Just out of good housekeeping, I’d like to move user folder to another drive letter so I can back it up quickly for re-installing Windows or plan program storage better (anything that can be re-installed, I don’t care to back it up).

There’s a lot of warning about messing with redefining where %userprofile% points to (which is %systemdrive%\Users\%username%) or using symbolic links (such as subst) for file redirection. So I’m sticking to the officially supported ways that doesn’t involve scripting or messing with the registry, i.e. move only the ones Microsoft expects users to be able to move it themselves.

I’ve identified these folders are safe to move:

The basic user shell folders

For a newly installed Windows 10, that’s basically every subfolders in %userprofile% itself!

Here’s the dumb way to do it which is taught nearly everywhere since Windows 7: using the location tab in these special shell folders:

They told you the hard and dangerous way modifying the registry, namely HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders:

It’d be a pain in the ass to do it for 13 folders in Windows 10 (much less in Windows 7 so it was reasonable to do it this way back in the days). Turns out through experimentation, I figured that you can just move the shell folders to your chosen the destination folder, and the shell folders (which are decorated with extra features) can figure out they are being moved register the notifiers (aka the registry) properly, which is all the steps in location tab condensed to one drag and drop!

I observed the registry location and see what are the impact of the moves. A bunch of new entries are created corresponding to the 13 subfolders being moved

I believe those are the unique names for the named folder as their superficial name can change without having program confused about their nature.

I noticed only 6 core subfolders (which are the bread and butter ones that was there since Windows 7) is updated with the new path.

The others that are not changed are heavily tied to programs you installed (AppData) and Windows Explorer config (start menu, right-click explorer context menus) and IE stuff (cache and cookies). These data do not relate to the typical files users must backup but the configuration files that store user preferences. This is why I’m not surprised when Microsoft tells people not to mess with them because old software cruft might not handle them in a unified way after 20+ years of evolution.

App/Tiles (Metro UI) data starting Windows 8

Easus’ blog page might have confused the shell folders with files for Metro UI (Apps) and thought this is another way of moving files, which isn’t. This is the additional step specific to Tiled App files:

What I forgot to annotate above is “New apps will save to:” will also generate a \WindowsApps\MutableBackup folder. Such “Program Files” is owned by ‘SYSTEM’ account and “WindowsApps” is owned by ‘TrustedInstaller’ account, which you cannot clean them up after you changed your mind without first taking ownership and give yourself full permissions. Here are the folders created by the first item of the “Change where new contents is saved” page:

It’s usually more convenient to move the shell folders to {target drive}:\%username% that’s shared with the special folders for the Apps with the same name so Apps and programs can share files with a common folder. But technically these are two split concepts and you are free to make them separate.

The registry is not where you should muck with the path. Please let Windows’s proper user interface (shell folder’s Location folder handling) do it as registry is just one of the many places they will manage the settings. Also remember moving these special (aka shell) folders do not move your %userprofile% which is your home folder that things like Powershell starts with by default (I had to change the working directory and there isn’t a variable associated with the {target drive}:\%username% because variables to those special folders do not manage their root.

Basically allowing multiple users logged into Windows at the same time boils down to modifying 12 dwords (32-bit words) or 48 bytes in termsrv.dll and the content and location (byte offset) varies depending on which version it is.

The rest is just fighting with file lock behavior, Windows self-repair, updates, anti-virus and things that tries to ‘correct’ the modified file so the changes stick. These are hell of hard and tedious.

RDP wrapper was the tool to do this but it stopped updating since 2017 so it won’t track any updates and newer versions pushed later.

There is a tool called autoupdate that rides on top of RDP wrapper which automates the process for each version that was pushed out with the (byte location, byte values) defined in a config file called rdpwrap.ini.

Basically extract all the zip files to the same folder and copy the latest INI file along with it, run the helper routine

autoupdate -taskadd

to add the startup hook (running helper\autoupdate__enable_autorun_on_startup.bat does the same thing) then run the main routine

autoupdate

That’s it!