It's pretty well-known that the EXE format differs between NT 3.1 and all later versions of Windows, and trying to start any such executable file in NT 3.1 will result in an "unexpected error 11". Less known, however, is that four bytes is all that needs to be changed to turn any 32-bit executable into a NT 3.1 executable.

How it's done, you ask? Well, here's how:

* Open the EXE file you'd like to convert in a hex editor.
* Locate the "PE" signature. It signifies the start of the 32-bit executable, and should be somewhere near the beginning of the file. For this example, let's say the PE signature is found at 0xF0.
* From the beginning of the signature, go 0x48 bytes forward. In this example, you would now be at 0x138.
* You should see four bytes saying "04 00 00 00". Change this to "03 00 0A 00".
* Save the file.

This file is now a NT 3.1 executable.

The problem? It's mostly useless. Since Windows NT 3.1 is missing many, many functions implemented in later versions of Windows, I've as of now been unsuccessful in getting anything to work with this method. Maybe something will spring up this way, but I doubt it.

does this also work with 32-bit drivers (SYS)?

I haven't tried it with drivers, but I think their format is slightly different, so it would need some adaption.

for example, I want to use the NT 3.5 atapi cdrom driver on NT 3.1.

I'm still investigating drivers, but here's what I found so far:

* From the PE header, after 0x38 bytes you'll find "20 00 00 00 20 00 00 00". For NT 3.1, this needs to be "00 02 00 00 00 02 00 00".
* Again from the PE header, go 0x50 bytes forward and you'll find two 32-bit (four bytes long) numbers, for example "00 23 00 00" and "60 02 00 00". They're little endian (least significant bit first), so flip the numbers around ("00 00 23 00" and "00 00 02 60"). NT 3.1 needs them to be a multiple of 512 (decimal, hex 0x200), so you'll have to round them up - in this example, from 0x2300 to 0x2400 and from 0x260 to 0x400. Flip the numbers back ("00 24 00 00" and "00 04 00 00") and enter them like this.
* Directly after that comes a checksum. NT checks this checksum, so you'll need something that can recalculate and write a new checksum. For example, editbin, found with some Microsoft SDKs (dunno which ones) can do this: "editbin /release driver.sys".

I haven't tested any of this yet, but this should be a start.

Just as a technical summary, what you are doing is changing the Major/Minor Subsystem Version (04 00 00 00 - 4.0, 03 00 0A 00 - 3.10). This is actually a technique not limited to getting 4.0 apps running on 3.10 - its the same mechanism that prevents say, certain Vista apps (mostly those included with the OS) from running on XP, and 7 on Vista.

Obviously the reason here is because it's expected that it requires that version in order to have its dependencies satisfied. You commented yourself on how this rarely works.

It's always good to read the proper Microsoft documentation of the PE format, it's a very illuminating read:

http://msdn.microsoft.com/en-us/library/windows/hardware/gg463119.aspx

Why not use the IDE CD-ROM driver from Aztech for Windows NT 3.1? This may sound a little nieve, but has anyone compiled the Atapi source code from Windows NT 3.5 DDK using Windows NT 3.1 tools in order to see if the driver will work in Windows NT 3.1?

that one works on NT 3.1, but not for the text-based CD setup (booting from CDINSTALL.img)

Wait... that's open source? I was honestly never aware of it. I might give it a shot.

the NT 3.5 DDK is not open source.

I've tried building the ATAPI driver from the NT 3.5 DDK, and it compiled perfectly fine. I injected it into my NT 3.1, however it seems to suffer from the 150 MB bug as well, so it really isn't any different from the Aztech driver. I haven't tried whether it can be inserted during setup, but I doubt it.

can you release it please? I would like to test it for the text-based setup.

Here you go:

http://depositfiles.com/files/yz6ocvlb9

hmm it does not get recognized by the text CD setup.

Oh, heh. You'll need an OEMSETUP.INF and a DISK1 file.

The OEMSETUP.INF can be copied from the Aztech driver, just change AZTIDECD.SYS to ATAPI.SYS. DISK1 is simply an empty file, the only important thing is that it's present.

edit: actually, for SETUP, you'll need the TXTSETUP.OEM from the Aztech driver, and change the driver name within that file. Sorry again.

I mean, I put your drive as a SCSI adapter (for example, I renamed it to aha154x.sys to make it immediately recognized) but it does not get recognized in the CDINSTALL.IMG image.

...oh. Well in that case, it really is the same as the Aztech driver. So while it was a nice try, the effort was ultimately wasted.

we will have to wait for someone to implement an ISA/EISA SCSI adapter for Qemu x86 then

nope, just someone needs to modify the atapi.sys code so it doesn't use the SCSI IDs that Windows NT 3.1's setup reserves for hard drives.

...oh? Are you able to elaborate? With the atapi.sys source code, this shouldn't be hard at all to do.

well, the Aztech one is an example.

Ok, I'm confused. If the Aztech is an example of what your shooting for then why doesn't it work? Aztidecd.sys appears to be just a modified version of Atapi.sys.

from the cdinstall.img, when I put it as a SCSI adapter (for example, renamed to aha154x.sys), it bombs out saying there's an error, I can provide you a screenshot if you want (but it works when NT 3.1 is already fully installed).

I'm smelling that the problem with setup is the very same problem that prevents CDs less than 150 MB from being read. Now the question is what causes this problem - is it a timing issue, or something entirely different?

Later on I might try commenting out all the error code to see where the problem is.

Work this work the other way around?