From: dic5340@hertz.njit.edu (David Charlap)
Newsgroups: comp.os.os2.advocacy
Subject: Re: OS/2 vs NT features list, Revision 1.3
Date: 2 Sep 92 13:58:26 GMT
Organization: New Jersey Institute of Technology, Newark, N.J.

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

The list is getting better.  I'll ignore things that haven't changed
since they've already been argued to death, and I've made my comments
on them already.

>Windows NT's networking features (beyond TCP/IP) are roughly equivalent
>to the OS/2 LAN Server 2.0 "Entry Package".  Here I only have access to
>a press release, so if you have experience with both please
>jump in.

LAN Server will also provide your "secured file system", via the
HPFS386 that it ships with.  While this should be sold separately, or
be included, it is one feature that you wouldn't normally expect to
find in a LAN server, so I'm mentioning it here.

>Features currently in OS/2 2.0 but not in Windows NT
>  
>	Object Oriented Shell (WorkPlace Shell)
>	
>	Great DOS support
>	
>	Mediocre Windows 3.0 support (NT's is currently poor).
>	
>	Is actually released.
>
>@	Runs without a GUI.

How about VDM's.  This goes beyond just "Great DOS support", since you
can boot any XT-based OS (like Minix - did someone finally get this
working?) and many older video games that you have to boot into to
run. 

>Features currently in Windows NT but not in OS/2 2.0
>		
>#	Multiple growable heaps.
>		DosAllocMem is not equivalent, it merely allocates memory
>		blocks.  This API is roughly equivalent to doing malloc's
>		from multiple heaps.

I fail to see why the difference is anything other than semantics.
It seems to me that an app would work just as well with either method.
What's the advantage?

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

This is still being argued.  One person posted a Makefile which (using
some stack-killing apps that was posted) got the app to compile and
run fine under icc.  The problem may be a compiler not using
OS-features in its malloc() functions.  Wait for the final verdict
when the heat dies down.

>	Global VM/File Buffer Cache.
>		This is a common feature in most modern operating
>		systems.  It apparently makes disk consistency
>		easier to manage.
>
>#	All but 60K kernel is pageable. (Microkernel design)
>		All means All... everything but a small piece
>		is pageable.

Neat.  But, again, I question its value.  Performance must slow to a
crawl if something critical, like the file system, gets swapped out.
Of course, these things would never get swapped, since they'd always
be active.

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

There's nothing wrong with 16-bit "thunked" calls.  The fact is, no
functionality was added to those calls.  A program which works in text
mode may as well be a 16-bit app.  I think IBM wants to keep the text
apps compatible with 1.x boxes.  They still should have placed them in
some headers, though.

The calls are being supported, since many IBM apps use them.

>@	DOS, (later POSIX), OS/2 1.X and NT console apps use the same window.
>		If you bring up an NT command prompt and run a DOS program
>		the output occurs in the same window.  Contrast this
>		with OS/2 2.0... if you run the DOS "ls" command in an
>		OS/2 window a DOS window appears... the output flys by and
>		the window closes; often before the output can be read.

Cosmetics, although very nice ones.  DOS apps run in different kind of
sessions.  OS/2's design was to give every session a separate window.
NT will still be running DOS and POSIX apps in separate sessions -
they'll just transfer the data between sessions to have it all appear
in the same window.

Considering the low-level of DOS apps' I/O, it would be difficult to
do this with all DOS apps.  Since OS/2 text apps and POSIX apps
generally use stdio (or OS calls) for their i/o, it would be much
easier to do.  DOS apps often directly-write the video buffer.  I
wonder how MS will get this data into another session's window.
Especially if the app goes into graphics mode.

All I can think of would be to run it in a hidden session window and
bit-blt the image on top of the NT window.  Not a very elegant
solution. 

But then NT doesn't promise full DOS compatibility.  This may be one
of the restrictions.  

>	NTFS
>#		Automatic 8.3 names
>			NTFS supports both long names and short ones.
>			The short one is generated automatically
>			if the long one it does not fit the 8.3 pattern.
>			This is done so that DOS apps can see long-named
>			files too.

What happens when a DOS apps edits the file?  These apps typically
make backups.  They do it by renaming the original file and then
create a new file to save data into.

What happens to the long name when this happens?

>OS/2 2.0 will add the following in September/October
>#	Rumored to slim-down such that it might properly fit in 4 megs.
>		I use the word rumored as I've not seen an announcement
>		from IBM that this will happen at this time.  People
>		believe it will... if you know for certain... tell
>		me and I'll take "rumored" off.  Other rumors I've left
>		off the list, but this one is quite important to OS/2's
>		positioning against NT.

According to an IBM announcement on comp.os.os2.misc (which may be
archived to ftp-os2 by now), the Fall csd will be bringing great
performance improvements, especially to those with minimal (4MB)
hardware platforms.

I usually don't call it a rumor if IBM actually said it.

But I'm content to leave this along until the CSD arrives.  Then we
can just add "works in 4MB" to OS/2's features.

>Windows NT will add the following in September/October
>#	Remote booting (Diskless/dataless workstations)
>		(Some say OS/2 has this now... is this in the base package?)

OS/2 can be booted remotely.  The server that performs the boot,
however, is in the LAN server package.

What about the server that remote boots the NT system?  I know NT has
built in networking, but I thought that was just client software.
They're not shipping the server for free as well, are they?

I think this is an equivalent level of support.
-- 
   |)  David Charlap           "TELEPHONE, n.  An Invention of the devil which
  /|_  dic5340@hertz.njit.edu   abrogates some of the advantages of making a
 ((|,)                          disagreeable person keep his distance."
  ~|~                              --- Ambrose Bierce, The Devil's Dictionary
Newsgroups: comp.os.os2.advocacy