From: conrad@actrix.gen.nz (Conrad Bullock)
Subject: Re: OS/2 vs NT features list, Revision 1.4
Organization: Actrix Information Exchange
Date: Sat, 5 Sep 1992 03:24:10 GMT

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

OK, in this case, this is a meaningless feature. You are starting to
compare minor implementation details, instead of features.

Please give me an example of where this 'feature' would be used, and why
DosWaitMuxWaitSem is not good enough?

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

Well, in that case we might as well start coming up with tiny little
differences, start calling them features, and be done with it. By your 
argument, we're not allowed to refute them, right?

NT is better than OS/2 2.0 because it comes in a nicer box?

OS/2 2.0 is better because it comes with free stickers?

NT is better because this API has 4 parameters and OS/2's equiv has 3?

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

Signals are subsumed by the exception management system in 2.0, where
thread 1 is no longer special

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

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

All this stuff was given to attendees at IBM's recent Developer's seminar
in Australia (along with the DDK stuff). It has also been publicly
demonstrated in New Zealand, and there are a couple of sites outside of
IBM which are beta testing it.

Xref: sparky comp.os.os2.advocacy:5266 comp.os.os2.apps:6066