Francois Thunus wrote in a message to Mike Bilow:

 MB> driver and Windows NT (in 3.51 and earlier) which was written 
 MB> by people who had access to the OS/2 HPFS source code; NT 
 MB> itself was originally developed on OS/2.

 FT> If I'm not mistaken, NT was developped by the people who did
 FT> HPFS in the first place...

Sort of, but the point I was trying to make is that it is a lot easier to
do things (such as boot from an installable file system) when you have
access to the source code.

 FT> If I remember it well, HPFS was originally developped by 
 FT> Microsoft during the joint venture IBM/MS to develop OS/2 1.0. 
 FT> IBM was to write the operating system and MS the GUI (My OS/2 
 FT> 1.3 Box says: MicroSoft OS/2, and no, I'm not selling :-).

This is not quite right.  It would be more accurate to say that IBM
designed OS/2 and wrote the specifications, and then they expected
Microsoft to code it.  This was essentially what happened through the OS/2
1.2 release, which was the version in which HPFS was introduced.

 FT> Then MS and IBM parted, but each retained some right to the 
 FT> other's code. That explain why OS/2 supports windows programs. 

The split occurred when Microsoft decided to change the "OS/2
3.0" project into the NT project, apparently without telling IBM.  As
a result, IBM took over OS/2 development, producing OS/2 1.3 and all later
versions on its own.

 FT> NT evolved from the common 1.0 OS/2 code, which explains why it 
 FT> supports 1.xx OS/2 programs and HPFS, and why MSC supports OS/2 
 FT> 'up to 5.1 if my memory serves me).(It may be what you mean by 
 FT> NT was developped on OS/2).

No, I mean that the people developing NT were actually running OS/2 1.2 as
they were writing NT.  When the development began for what became NT was
started in mid-1990, it was officially announced as "OS/2 3.0"
and was expected to be backward compatible with prior versions of OS/2.  As
Windows 3.0 started selling well, the decision was made at Microsoft to
base the new project on the Windows API rather than the OS/2 API.  This
forced a break with IBM, since IBM was committed to serve existing OS/2
customers.  When IBM found out what Microsoft was doing, it became an issue
for the lawyers and resulted in the split negotiated in 1992.

 FT> The os/2 2.0 was a large rewrite to make OS/2 32 bit, and 
 FT> Microsoft no longer had acces to that code.

Some pieces of OS/2 were extensively rewritten in the move to 32 bits, but
other components were not.  This proved, I think, to be a wise choice for
purely technical reasons.  As I have explained several times here, the use
of 16-bit code does not result in a processing penalty if the code is small
model, and nearly all device drivers are small model.  Some components,
particularly the graphics engine, had to be rewritten for 32-bit processing
in order to get good performance, but things such as COM.SYS make no
difference.  The one great exception is that OS/2 still to this day uses a
16-bit interface to file system drivers, although it is possible to get
around this.  HPFS.IFS is still 16-bit code, but at least it is highly
tuned and optimized 16-bit code and IBM is probably afraid to change it too
much.

Anyone interested in a more practical explanation of how to write 32-bit
device or file system drivers where 16-bit would be officially required is
referred to:

32DRV160.ZIP  368K 11-30-96  32 bit device and IFS support driver. Provides 32
                             bit kernel services (DevHelp) and utility
                             functions to 32 bit ring 0 code (device drivers
                             and installable file system drivers).
 
-- Mike


---