RE: [Gnu-arch-users] tla1.2 on cygwin

[Parker, Ron]

> From: Adrian Irving-Beer [mailto:address@hidden
> Sent: Tuesday, March 02, 2004 10:49 PM

> Well, NT is/was an OS/2 kernel with a Windows GUI.  Win95/98/ME were a
> DOS kernel with a Windows GUI.  I don't know if the GUIs shared common
> code, but certainly all the system-level stuff is fairly separate.

Actually, NT had its own kernel pretty much from the beginning, having
worked in the guts of both operating systems I do not see how they could
share much of a code base.  Especially given that only OS/2 1.3 code ever
made it into NT.  At least early on NT had support for the OS/2 file system,
HPFS, and NTFS _is_ based upon HPFS with some improvements.

> I believe the core of the OS/2 kernel was 'personalities' -- one
> personality when talking to DOS programs, one when talking to another
> class of programs, etc.

NT has subsystems, similar to the OS/2 personalities.  Originally the
subsystems were Win32, Win16, OS/2 and POSIX.  IMO, the latter three were
only offered as part of a plan to migrate developers to NT.  Even though NT
came out in 1993, it only supported OS/2 version 1.3.  I do not believe it
ever had support for 2.x.  OS/2 version 1.3 was not a truly preemptive
multithreaded multitasking operating system and it was designed to run on
80286 systems using their half-implemented protected mode.  So as far as I
can tell, it could not have been used as the basis for NT, which originally
was a fully preemptive fault-tolerant microkernel 80386 OS.  Yes, I said
fault tolerant at least in one sense.  The file system layers were well
enough implemented in 3.1 to allow you to yank the power cord out of the
wall on a running system without corrupting the file system.  You can thank
all the DEC VAX hands that MS hired to design and work on NT for that.  But,
such resilience has long since disappear, ca. NT 3.5.

The Win16 support has always been implemented in a Windows-On-Windows (WOW)
subsystem, that thunks to the 32-bit side.  Once, OS/2 ceased to be a factor
it was dropped from NT (around version 3.5-4.0).  The POSIX support was
never more than a bullet point used to lure Open system developers.  If you
dug below the surface it was fairly crippled and segregated from the rest of
the OS.  The only real development that was done on it beyond the original
release was by outside entities under a source license from MS.  MS only
bought Interix's POSIX subsystem once Linux started to look like it might be
a threat.  It's not as easy to develop a well mannered POSIX system as it is
to whip out a quick and dirty browser.  POSIX people are strange, they
actually expect their software to work and adhere to standards.  I don't
think MS has the talent to properly interpret and implement the POSIX
standards themselves.

As others have pointed out this POSIX subsystem, now called SFU, is still
segregated from the Win32 subsystem for the most part and may not trivially
share files back and forth.  (In that respect it, is kind of like accessing
between a VMware host and client OS.)

> Hence, NT actually had fairly good compatibility with DOS programs
> because it was like an early, more tightly-integrated VMware.  I don't
> know if its DOS personality shared actual code with DOS, either, but
> that was only one face to it either way.

The "DOS" support was implemented along side the WOW subsystem.  I believe
it is now part of the NTVDM.  It was based upon MS-DOS 5 with some
improvements, but it never reached 6.x compatibility.  I just recall that
there were parts of "DOS" and NT's command.exe (not cmd.exe) that I wished
had made it back into the DOS 6 code base.

To this day if you run "command" on XP you get a window that identifies
itself as:

        Microsoft(R) Windows DOS
        (C)Copyright Microsoft Corp 1990-2001.

And "mem" reports:

    655360 bytes total conventional memory
    655360 bytes available to MS-DOS
    621328 largest executable program size

   1048576 bytes total contiguous extended memory
         0 bytes available contiguous extended memory
    941056 bytes available XMS memory
           MS-DOS resident in High Memory Area

I never really saw it as a VMware sort of thing.  NT has access to all of
the processor's protection levels, ring-0 through ring-3.  Although it only
uses 2.  VMware primarily runs in ring-3, user-mode and its ring-0 access is
limited to what is officially exposed and published in the Driver
Development Kit, DDK.   Drivers are not officially sanctioned to play with
the Global Descriptor Table, GDT, which controls virtual to physical memory
mappings and access modes.  They may only alter the Local Descriptor Table,
LDT, which is local to a process.  This prevents things like declaring a
code selector to be run in V86 mode and properly implementing copy-on-write,
COW, memory usage at the process level.  So, VMware has to (for the most
part) interpret 16-bit code that it is running because it has no access to
the GDT to use V86 mode.  AFAIK it may only be done at the undocumented
subsystem level.  V86 is the i386 protected mode that allows some processes
to run in 16-bit "real" mode while trapping out as needed for system
services.

VMware also runs the 32-bit code natively except for some instructions that
have to be specially handled because they are illegal in i386 protected
mode.  (Things like loading and altering the GDT.)  These too are emulated.
That is why there is a performance hit inside of VMware.  The NT kernel on
the other hand has complete control over the processors modes, memory
protection, etc. because it is the core of the native operating system and
therefore does not suffer a performance penalty where VMware does.

> And that's about where my (admittedly vague) knowledge trails off.

Ditto.

> -----Original Message-----
> From: Adrian Irving-Beer [mailto:address@hidden
> Sent: Tuesday, March 02, 2004 10:49 PM
> To: Tom Lord
> Cc: address@hidden
> Subject: Re: [Gnu-arch-users] tla1.2 on cygwin
> 
> 
> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnu-arch-users
> 
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/
>