Visual C++ 2.0 on Windows NT 3.1

Discuss any beta and abandonware applications.
Post Reply
3155ffGd
User avatar
Posts: 391
Joined: Wed May 02, 2012 12:57 am

Visual C++ 2.0 on Windows NT 3.1

Post by 3155ffGd »

I only read about it randomly in a comments section, but apparently, it is possible to install Visual C++ 2.0 in Windows NT 3.1.

The installer will warn you that it's designed for a newer version of Windows NT, but you can click "Ignore" and it will install anyway and work perfectly.

Visual C++ 2.0 has a lot of advantages over the first release, for example it supports __int8, __int16, __int32 and (admittedly undocumented) __int64 platform-agnostic datatypes, as well as being an actual IDE with the individual tools like RC etc. no longer being confined to separate executables.

That said, there are a few caveats:

* Visual C++ 2.0 will make NO attempt to create NT 3.1 compatible binaries. The documentation will not tell you which functions and values are exclusive to NT 3.5, so you have to be careful about the functions you use and e. g. consult the reference included with Visual C++ 1.0. That being said, as long as you use only NT 3.1 functions the applications will work fine.
* Visual C++ 2.0 will link only to OLE2 by default and doesn't even have OLE1 libraries at all, you have to copy those (olecli and olesvr) from Visual C++ 1.0 if you want to link to OLE1 to stay NT 3.1 compatible.
* CRT functions will be linked to MSVCRT20.DLL by default which does not ship with NT 3.1. Though that problem existed in Visual C++ 1.0 as well (which links to MSVCRT10.DLL), only the NT 3.1 SDK links to CRTDLL.DLL which is included with NT 3.1.
* Some of the documentation still refers to Daytona, generally the quality of the documentation is very lacking, for example the included knowledge base has truncated KB numbers.

Interestingly, besides MSVCRT20.DLL, Visual C++ 2.0 will also drop runtimes for CTL3D32.DLL, MFC 3.0 and ODBC (a newer version than the one included with SQL Server, from what I can tell). No idea if there's any use to this.

I don't think there's a lot of applications that can be made to work like this, esp. because of the Win32 API being lacking in general in NT 3.1 (for example, CompareString only exists in W but not in A... why?), so usually you will end up with missing exports in kernel32 and the like where there is not much you can do about it.

Interestingly though, despite being completely undocumented you CAN link to ntdll.dll if you can figure out what the prototypes should be because at least the DDK has a working ntdll.lib that Visual C++ will happily link to if dropped in the lib directory. I wonder if there's anything to be gained from that, except of course abusing exploits to crash the system from user mode because ntdll.dll did not have any sanity checks in these early versions of NT.

Post Reply