Dean Kent said:
I seem to recall that Win32S was made available prior to Win95, but I may be
mistaken. It seemed to be a 'transition' tool so that developers could
start writing '32 bit' code that would run under Win95 when it arrived (and
perhaps WinNT).
Win32S was available before Win95, as was NT 3.51 (I believe NT 3.5 was the
first easily-availble version of NT - marketing's idea of persuading people
that it was a mature product). Win32s implemented some of the Win32 api
from NT - it allowed programs to use a full 32-bit address space, but did
not support multi-tasking. It was mainly used for "big" programs, like CAD,
or development tools, which could take advantage of the better memory
management. Back in the days when MS made at least a token attempt at
pretending they could co-operate with other people, the aim was that Win32s
would be a portable api for use on Win3.1, NT, and Win95 (which was due out
"real soon now"), along with other systems including OS/2 and unix systems.
Of course, after giving IBM a license to put win32s 1.25 into OS/2 Warp, MS
immediately upped the version number to 1.30 (the version number being the
only real change) so that new win32s programs would refuse to run on OS/2.
Incidently, the only win32s program MS ever made, AFAIK, was freecell.
I seem to recall that the WinNT effort followed the failed OS/2
partnership
WinNT caused the failure - MS realised that they did not have full control
of OS/2, so they started the WinNT project behind IBM's back, with a fair
amount in common at the base (which they were legally allowed to do). NT
has far more in common with OS/2 in its guts than it does with VMS.
with IBM. I think it was specifically meant to replace OS/2 1.1 (or 1.2,
whichever was the last MS release). This brings me back to my original
assertion - WinNT was not written to be portable, nor to be upgradable. It
was written to be 32-bit. I find it difficult to believe that in their
WinNT was written to be 32-bit - it followed mainly from OS/2 2.0 (the
original OS/2 1.x was 16-bit, in common with Win3.x). But it was written to
be portable, within certain restrictions - it required a 32-bit
little-endian cpu. It ran on PowerPCs, MIPs (this was in fact the main
platform for NT), Alpha, and x86. Even though all but the x86 had 64-bit
variants, and all ran best in big-endian rather than little-endian mode,
WinNT stuck to 32-bit little-endian.
haste to come out with WinNT that the MS developers took into consideration
the chance that they might have to run on different platforms. If there
was one code base, I think there would not be the 'problem' of supporting
multiple platforms. Consider DB2, which *was* written with portability in
mind. It took several weeks (or perhaps several days) to port it to x86-64,
and it runs on virtually every platform imaginable specifically because of
this.
Porting applications between architectures is not nearly as much work as
porting an OS. Original windows (Win3.x, then Win9x) has had lots of
architecture-specific code and assembly language scattered randomly about
the code base, making them a porting nightmare. Original NT 3.5 was nicely
modular, with the main code in C and only a few specific bits being
architecture-specific. This made it fairly easily portable. The same
applies to Linux, *bsd, etc. NT 4.0 onwards re-introduced the spagetti
organisation, as code (in particular, graphics code) was made
architecture-specific in the name of performance. Thus the NT platforms
died one after one as the maintainance costs sky-rocketed, and the cpu
manufacturers refused to pay MS' development costs.
Porting applications, on the other hand, is far easier. You have to
consider the effect of having 64-bit integers, and you might have to
consider endian issues, but mostly (if the original code is well-written)
its a matter of re-compiling and testing the new binary.