I wonder how long it'll be before they release the source for the earliest Windows versions. The fact that they still have the source for this very old DOS at least gives hope that they also do for old Windows.
Windows has always been more than modular enough for any repurposing and there were licenses that were not tied to specific hardware so you could use them even today.
Which is to say no one is stopping you from building a COPILOT.VBX for VisualBasic 3.0.
I had a win2k machine that was my daily (at home) that was fine until idk about 2006, at which point something happened (muons?) and it would go into some kind of panic state just after bringing up the desktop. Hive corruption. I tried on and off for a couple of years to repair it, no luck. It wasn't just about the files on the HD, it was easy enough to transplant the drive and read/write anything, it was that I really liked the way I had the environment configured. Sure, it was all kind of moot, but it became a kind of personal windmill to resurrect this old thing. In the end, I booted an XP CD in it, and selected 'upgrade', and voila, it was Duncan Idaho, back from the dead.
Anyway.. loved win2k, but not a fan of the hive.
https://devblogs.microsoft.com/oldnewthing/20030808-00/?p=42...
Further case in point -- the AXP64 port (64-bit Alpha) of NT didn't have the ability to run 32-bit Alpha software. If you want that, you have to develop WoW64. So in this hypothetical "port Win2k to 64-bit processors", you would need to create WoW64 from scratch. Alternatively, rebuild a lot of software which is old enough to run on Win2k but also aware of 64-bits.
Or take the AXP approach and literally treat AMD64 as a strange 32-bit CPU, not unlike the x32 port for Linux. At that point you have no binary ABI compatibility with any Windows port, and will need a custom compiler port, and compile all executables from scratch.