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.
The day they would make Windows 2000 codebase open source (or source available) would be the day I could die happy (although I'd probably be long dead anyways by the time there's a glimmerof chance of it happening). What a beautiful, smooth-running operating system it was.
They will never release the code for anything that new because at that point, there's tons of licensed third-party code and the codebase is so large that going through everything to verify ownership would not be feasible. The code to NT 4 and XP have been leaked though.
I suspect Windows 2000 (and NT based stuff in general) is too near to modern Windows to be (officially) released. DOS is long dead, but modern Windows still uses the NT kernel and Win32 and so on, and they probably don't want to give an official peek behind the curtain, even if it's an over a quarter century old version.
And what would you do with the Windows 2000 source? It's 32 bit x86 code and the driver model for Windows has changed significantly since those days so it wouldn't run on modern x86-64 hardware anyway. Maybe it would run in a VM but I wouldn't care to bet on it.
Making Windows NT 64-bit is very different from porting it to a 64-bit CPU. Case in point, the NT 4 (and Win2K) releases for the Alpha CPU were technically 64-bit (so far as the CPU lacked a "32-bit mode") but were functionally 32-bit, with all pointers truncated to 32-bits.
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.
OP said source available was acceptable. not even asking for compiler access which is also widely available.
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.
Except for "the hive". Remember the hive? Sort of an alternate registry, in addition to the actual registry. Granted, it was pretty invisible, until it got corrupted.
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.
You know, that's possible, I wouldn't be surprised. This was 20 years ago. I only recall a sense that the w2k system seemed more complicated than XP in that area.