Newsgroups: comp.os.os2.advocacy,comp.os.ms-windows.advocacy
Subject: Re: OS/2 vs NT features list, Revision 1.4
From: conrad@actrix.gen.nz (Conrad Bullock)
Date: Fri, 4 Sep 1992 07:17:34 GMT
Organization: Actrix Information Exchange

In article <1992Sep2.170400.10092@hellgate.utah.edu> brian%jaguar.cs.utah.edu@cs.utah.edu (Brian Sturgill) writes:

> OS/2 vs NT features list, Revision 1.4

> Features currently in Windows NT but not in OS/2 2.0

> 	Generic wait on multiple events/semaphores of different types.
> 		This is helps prevent deadlocks.  Consider the classic
> 		deadlock example: Two processes, P1 and P2, both want
> 		to access tape drives A and B.  P1 locks A and waits for
> 		B, P2 locks B and waits for A. Deadlock.
> 		With the generic wait facility you say wake me when
> 		I have both A and B.  This mechanism prevents many
> 		deadlock problems.

I think you're being slightly mischievous here - added an extra
qualification without making it clear. OS/2 2.0 has DosWaitMuxWaitSem
which allows you to wait on multiple semaphores - it does have the
restriction that you can't mix event and mutex semaphores, but I don't
know that that's a big problem. certainly in your example, both processes
would use mutex semaphores, and OS/2 2.0 can use DosWaitMuxWaitSem.

Removing the 'of different types' above would make OS/2 2.0 and NT
equivalent.

> 	Automatic stack expansion.
> 		OS/2 2.0 does not (in the general case) have dynamic stack
> 		extension. Someone inside IBM (and others) sent me this story.
> 		Thread 1's stack is statically sized according to the value
> 		you set in the executable at compile time.  Worse, all pages
> 		of this stack are committed as the process starts, so you
> 		don't want to grossly oversize the stack.  All other threads
> 		do have dynamic stack extension.  Doing this somehow made
> 		compatibility with older API's easier.

Well, I think this is a bit picky. Surely this is a compiler/application
dependant thing. What is to stop a compiler using a runtime library which
has startup code to run main() (Or the mainline/etc) in its own thread,
with automatic stack expansion (as all new threads have).

In either case, all my major applications have a simple mainline which
starts multiple threads, and then stops.

> 	All but 60K kernel is pageable. (Microkernel design)
> 		All means All... everything but a small piece
> 		is pageable.

Out of interest, how much of OS/2 is non-pageable? Are device drivers
pageable?

> 	Asynchronous I/O
> 		OS/2 1.X had this feature but for unexplained
> 		reasons dropped it in 2.0.  While you can do it
> 		with threads, you can also multi-task in DOS...
> 		all you have to do is write the code that intercepts
> 		the timer interrupt and swaps the processes.
> 		Apparently the 16-bit API DosReadAsynch, DosWriteAsynch
> 		still exist in thunked form.
> 		Deitel and Kogan don't mention them... anybody
> 		know why they're being phased out?

I'm not sure about this, but Deitel & Kogan refers to new Asynchronous 
I/O systems in 2.0: (Page 255 & 256):

"   The device driver architecture has also been enhanced to provide a
new 'extended strategy interface'. It provides an alternative I/O
model for FSDs that support intelligent I/O devices, command chaining,
scatter-gather I/O, and a better asynchronous I/O model.
  [ ... ]
    The extended strategy interface queues incoming requests on per-
device service queues, and then immediately returns to the caller
without blocking. This allows the requester, usually an FSD, to
determine when the thread should be blocked. Consequently, a single
thread can initiate multiple chained I/O requests before blocking.
[ ... ] The extended strategy interface provides FSDs with a faster
and more flexible I/O model for performing asynchronous I/O."

> !	Console API
> 		Please remain calm on this one... I am just hoping for
> 		some information.  OS/2 2.0 only supports the
> 		Console API via 16-bit thunked-calls.  In theory
> 		the 16-bit calls are there only for backwards compatibility.
> 		Anybody know what the future plans are?

I would doubt there would ever be any problem with stdin/stdout. At the
very least, the 32-bit API will still work on 'CON'.
By 'Console API', do you mean the Vio subsystem?

> 	GUI

> 		Designed to help accellerators.
> 			The internal routines have been changes so that
> 			drawing commands are buffered and sent to the
> 			underlying graphics drivers in a manner that
> 			can take advantage of graphics accellerator cards.

Isn't that really a device driver issue - how does the GUI know whether a
device is dumb/smart, and how best to order the commands?

> 	Developers provided with a common installation program.

OS/2's INSTAID (Little used, except by IBM) ships with OS/2's base package.
(As is device driver install, for device drivers)

> @	An NT user can change their environment (e.g.) PATH without
> 		having to reboot for it to take effect.

So can OS/2 - SET PATH or PATH from the command line (as with any
environment variable). You can't change the _global_ settings - ie
the path doesn't change in other sessions, but then I wouldn't want
it to. Different sessions have a path related to what I'm doing.

> @	NT can generically use more than 16 megs of memory.
> 		OS/2 only uses the memory above 16 megs as
> 		a form of fast cache.

This is only an issue on some ISA machines - EISA and MCA have unrestricted
use of all memory.
On ISA machines, normally DMA only works up to 16MB - What does NT do? Not
do any paging above 16MB? Move pages below 16MB before paging? Not use DMA?

In fact, I'm not sure what OS/2 2.0 does, but I thought it was smarter
than using it as a cache.

> @	Has seemless support for 16-bit Windows apps on XGA and 8514 displays.

> OS/2 2.0 will add the following in the Fall.

> 	Catch up to NT by adding a 32-bit GUI.
> 
> 	Catch up to NT by allowing 32-bit drivers.
> 
> @	Catch up to NT by having seemless support of 16-bit Windows
> 		apps with XGA and 8514 displays.

This is in beta test for OS/2 2.0 now - does that count? (since NT is in
beta test).