Well, I do all of my projects in Rust now. Even little scripts I’d usually write in Python I often find myself grabbing Rust for. I’m comfortable with using Rust for pretty much any project at this point, that I decided that for a long-ish term stream project (ultimately a snapshot fuzzer for NT), I would want to do this in Rust.
The very first thought that comes to mind is to just build a MIPS executable from Rust, and just… run it. Well, that would be great, but unfortunately there were a few hiccups.
Imagine that – running Rust code on Windows NT 4.0 on MIPS led to some hiccups.
The author likes exotic, if you have to read the compiler code to figure out what the target and then have to write your own ELF loader you might be pretty far of the reservation. 🙂
He is pretty clear that this is more driven by enjoyment than practicality. It is probably not the case that legions of devs will end up using Rust to create applications targeting Windows NT 4.0–especially not on MIPS.
That said, it seems like the end result is going to be quite a functional Rust implementation that would allow the rest of us mere mortals to write somewhat normal looking Rust code that should more or less just work. That is kind of exciting even if it is target few of us care about.
The really amazing thing is that his driving objective appears to be using Rust to test Windows NT 4.0 on MIPS itself and to uncover bugs in the operating system. It is hard to understand what the practical motivation for that could be beyond fun and learning. It is not like Microsoft is going to be excited to receive a bunch of bug reports against Windows NT 4.0 on MIPS!!
You have to admit though–cool stuff. Also, as deep a dive as this is, I am quite impressed it was not much, much harder. It reflects really well on Rust.
> It is not like Microsoft is going to be excited to receive a bunch of bug reports against Windows NT 4.0 on MIPS!!
NT 4 on MIPS is from a very different era. When MIPS support was dropped, patches stopped immediately – so NT 4 on MIPS has Service Pack 1, whereas Intel has Service Pack 6a plus an update rollup and some extras. Some of the bugs may be MIPS specific, but it’s also quite likely that they were already fixed, and the fixes for MIPS were never released.
Using NT 4 on MIPS really highlights just how many changes happened across NT 4’s life. It received IE6, the Active Desktop shell update, plus tons of redistributables for common controls, Windows Installer, .NET, debugging tools, DirectX, media player…none of which exist on MIPS. MIPS is surprisingly painful to use, not because of emulation (on a modern CPU emulating MIPS is relatively fast) but because of all the missing pieces that NT 4 Intel has.
NT4 was one of the first “Perennial” releases of Windows, IE a version that just “stuck around” in production for years. It took at least 5 (maybe 8 if you discount Win2K) for a true Server grade OS to ship from Redmond, which is eons in the technology space, especially in the 90’s, when we were moving (quite quickly) from command driven TUI systems to GUI’s with High Fidelity sound and full 24-bit colour video. Frankly, it’s a miracle that Windows NT could keep up.
A lot of people forget that Microsoft for a brief period of time was the world’s largest Unix vendor, so they had some server background.
I have seen DOS-based systems in some kind of production for decades. I think it’s more of a “this works don’t touch it” type of mentality, about very specific systems that don’t require anything but the original functionality under which they were conceived.
This applies to just about every OS from any vendor.
Microsoft shipped a server grade OS before NT4/ Win2k era.. Xenix.
I’ve only encountered NT 4 once, in 2008. I had the get data off of a client’s old server, which wasn’t easy without FAT32 support…