From: brian%jaguar.cs.utah.edu@cs.utah.edu (Brian Sturgill)
Subject: Re: OS/2 vs NT features list, Revision 1.4
Date: 4 Sep 92 10:53:52 MDT
Organization: University of Utah CS Dept

In article <1992Sep4.071734.3972@actrix.gen.nz> conrad@actrix.gen.nz (Conrad Bullock) writes:
>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.

This is just a feature list, and the item involved clearly and simply
says "of different types".... how is this michevious?
Personally I think it is a great feature.  And I did not specify
two semaphores above... you read that in, not me.  For sake of simplicity
in the example I left the locking method unspecified.

It says "feature list", not "feature list that contains things
only of life and death importance", or "feature list designed to be
nice to OS X".  Every OS/2 person that responds to these things has a terrible
tendency to want to justify/refute THE VALUE of a feature.  I'm perfectly
willing to deal with whether or not a feature is valid, and to claify
what that feature means, but I don't see the point in debating the
VALUE of that feature.  Features are features... I give you a list, you
can weigh which OS's feature list you like best for yourself.

>
>> 	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.

Well may you do it that way, but thread 1 is special for other reasons
(for example signals) under OS/2 and is hard to avoid.  If you come from
a Unix background this facility is normal.
It is definitely not "picky" to point out the fact.  If you port Unix code
to OS/2 life can be hell because of this misfeature.
Besides why should every program waste a thread?

>
>> 	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?

Not enough information anywhere.  It is clear that considerably more than
that isn't though.

>
>> 	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."

Dietal and Kogan are talking about asyn I/O in the device driver.
I'm talking about a standard OS feature at the file handle level.

>
>> !	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?

Yes, the Vio subsystem.  (Which, by the way, is inferior to NT's anyway.)
I (and many others) want to know why these calls are still thunked.

>
>> 	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?

The graphics engine of course doesn't.  It buffers up the commands
in a generic manner that drivers for existing cards are comfortable with.
Microsoft got together we many of the leading card makers and asked
what they could do to make things easier/better for them.

>
>> 	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)

Please send me more information about this.  I've never heard of it.
Where is it documented?  I'm talking about a program that developers
can use to send out their own products... can INSTAID be used for this?

>
>> @	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.

See my latest revision.  I'm talking about doing the equivalent of a change
in config.sys.  Being able to change the PATH in the command line sure
doesn't help make the WPS know about the change now does it?

...
>> @	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).
>

1) the comparision is between OS/2 2.0 GA and the pre-beta Windows NT SDK.
	I've corrected this in rev 1.5, otherwise I'll have to keep updating
	both as moving targets.

2) Since when is the current beta generally available (i.e. the public
	can participate)... if it is how
	did IBM (once again) fail to tell me about it?

Brian
-- 
C. Brian Sturgill                       *** OS/2 2.0 is for YOU! ***
University of Utah                  Microsoft needs some competition, but
Center for Software Science        -I- want to be one of the many using NT.
brian@cs.utah.edu; CIS: 70363,1373           :-) :-) :-)
Newsgroups: comp.os.os2.advocacy