The branch jazz-nt is an attempt at reproducible base NT hard disk images. It contains INPs that allow 3.1, 3.51, and 4.0 to be constructed from scratch. Their properties have left me less than satisfied, and part of it is due to the nature of the platform itself. I desire to have all the operating system versions have a consistent partitioning scheme, and that is part of my constraint.

At present, these images are constructed with two partitions. The first 10MB partition is for the ARC firmware (it contains osloader.exe, which is the Windows NT boot loader), while the second (and logical) partition is the operating system itself. Due to the way Windows NT enumerates partitions, the ARC partition is drive letter C: and that puts the operating system partition on D:. There is nothing technically wrong with this setup, but it conflicts with muscle memory assumptions that Windows is always on the C: drive. Additionally, the Visual C++ 4.0 installer defaults to installing to C:\MSDEV and if you just clicked through the installer, it'll quickly fail as C: doesn't have anywhere close to the required disk space.¹

I wish to redo these images before submitting them for inclusion in the MAME software list.

Alternative One

I could create the operating system partition first (which would be primary), and leave the ARC partition at the end (now logical). The machine is OK with this layout, but only Windows NT 3.1 seems to properly support it. It will install osloader.exe onto the appropriate partition and leave the operating system partition independent of the boot loader. This allows, for instance, the OS drive to be converted to NTFS and the machine still boots and remains functional.

Windows NT 3.51 and 4.0 are much less happy with that layout. They will install osloader.exe onto the first partition regardless of what the machine configuration identifies as the ARC partition. It will remain empty and the operating system partition is locked into remaining as FAT.

This causes issues if the same instructions should apply to all the OS versions, since downstream users should be starting from a blank NVRAM state.

Alternative Two

I could just keep to a singular partition for the entire disk. ARC and the Windows NT operating system share the same partition. This locks the operating system into FAT without any ability to convert to NTFS. At least all the versions should be happy in this setup. The OS does function fine on FAT, but it lacks some extra features NTFS offers, such as compression and ACLs. NT 3.1 requires NTFS in order to use long names, because its FAT driver is limited to 8.3 names (the 3.5x discs have a FS31UPD that might change this, but I haven't actually tested it, nor will it be incorporated into the base images for MAME).

Conclusion

I think given the limitations and options, the second of these alternatives is the most desirable. For a single-disk NT system, it leaves only a C: hard disk partition, leaving A: to the floppy drive and D: to the CD-ROM drive. It causes the MIPS system to feel much like the typical scenario for an x86 system too. Muscle memory and the Visual C++ installer are both satisfied here.

If one really needs or wants to play around with NTFS on these systems², the addition of a second (or more) SCSI hard disk is trivial. Keeping the OS partition as FAT actually has a couple strong advantages, namely that it can be mounted on any host operating system without risk of corruption, and if you really wanted to, pmagic on the PC could be used to resize the partition without much risk (I haven't tested it, but I don't see any spots where the MIPS workstation should complain; it's just an MBR partition table and FAT file system).

Addendum: Windows NT 3.5

I still have been unable to install this version from a clean state, even though upgrading from 3.1 is fine. I do not consider an upgrade that depends on another hard disk image to be in congruence with the goal of reproducible CHDs. It still BSODs after the text mode setup in any disk layout I have tried, and it is not recoverable from there.

---

1. ^{^} Even Microsoft couldn't help but hard-coding C: into their installer rather than using the %SystemDrive% environment variable.
2. ^{^} Or if someone really disagrees with all the choices I've made, installing from scratch is still an option.