Windows NT, Visual C++ 1.0, Fortran PowerStation 1.0 for DOS, and MASM 6.1

[yuhong...@hotmail.com]

What do you think?

----
Do you know why you get error messages indicating that the
RtlExAllocateHeap function in NTDLL does not exist when you try to run
MASM 6.1, Fortran Powerstation 1.0 for DOS, or Visual C++ 1.0 in
Windows NT? That is because these programs are Win32 console programs
compiled for a beta version of Windows NT 3.1 (to be exact, the
October 92 or earlier beta) that were bound with the DOSXNT (actually
Phar Lap's TNT) DOS extender. In the March 93 beta, you could still
run these programs, but the support for these programs were removed in
the final version of NT 3.1. B2Fix had to be released to fix these
programs. Visual C++ 1.5, Fortran Powerstation 1.0a for DOS and MASM
6.11 are programs compiled for the final version of Windows NT 3.1.
In my opinion, that is an indication that the developers of these
products did not even consider what would happen if it ran on the
final version of NT 3.1. Fortran Powerstation for DOS made this
mistake worse by shipping the prerelease tools with it and it build
all applications using them without the programmer realizing it. This
means that hundreds of Win32 console applications designed for
prerelease version of NT that is bound with the DOSXMSF DOS extender
was made without the programmers realizing it, even long after NT 3.1
was released. To make matters worse, these applications were called
"32-bit DOS extended applications". I wonder what was the consequence
of this mistake for MS support. Probably the only reason it got away
with this mistake was NT was not popular before new version of these
products was released that were compiled for the final version of NT
3.1 in December 1993.

Another mistake of this kind is when FORTRAN PowerStation for DOS
graphic programs failed to run on 95 or NT, and it is because the
graphics library in this product required the program to run as a 32-
bit DOS extended program, not a native Win32 console program. Calling
Win32 console programs that are bound with a DOS extender that
emulated the Win32 API "32-bit DOS extended programs" encourages this
kind of mistake.

BTW, I wonder whether the FORTRAN Powerstation for DOS and FORTRAN
Powerstation for NT products could be combined, sharing the same tools
but different IDEs and debuggers.

[yuhong...@hotmail.com]

BTW, this was in 1992-1993, MS is much better at dogfooding nowadays.
For example, despite Windows Server 2003 SP1 being compiled with a
prerelease compiler, no copies of msvcr80.dll that comes from it
shipped with it.

[yuhong...@hotmail.com]

And MS is careful to use _MSC_FULL_VER if nesserary, not just
_MSC_VER.

Though oops:
http://blogs.msdn.com/bwelcker/archive/2005/04/23/411324.aspx

[yuhong...@hotmail.com]

With VC 2005, to facillate security updates, MS decided to put
msvcr80.dll in the system32 directory again.

The reason SxS was used for VC 2005 runtimes on XP+ is probably
because it lets you run two programs compiled with different builds of
VC 2005, even if both was dynamically linked. The manifest that is
contained in each program bind them to the appoprate build of the VC
2005 runtimes.