From: brian%jaguar.cs.utah.edu@cs.utah.edu (Brian Sturgill)
Newsgroups: comp.os.os2.advocacy
Subject: Re: OS/2 vs NT features list, Revision 1.3
Date: 2 Sep 92 16:18:11 GMT
Article-I.D.: hellgate.1992Sep2.101812.16584
Organization: University of Utah CS Dept

In article <1992Sep2.135826.27225@njitgw.njit.edu> dic5340@hertz.njit.edu (David Charlap) writes:
>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.

NTFS is fully secured... has to be... you need that to meet C2. or does
secured have an unusual meaning 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. 

Good point, I'll add it to OS/2's list.


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

The advantage is you get a large piece of memory which is broken up
and managed as is done by malloc.  When you're finished with the large
piece of memory, you can free once the big piece, which can be more
efficient depending on the nature of your allocation.
DosAllocMem is only good to give you the big piece of memory, it does
not manage it.
Multiple growable heaps is a standard feature of other system too, for
example Macs have had this feature for years.

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

I would not have put that there if I did not have faith in the person
that told me.  This person should definitely know.  I'd say who it
was, but don't know if they want it known.


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

There is a lot wrong with 16-bit thunked calls.  First of all it's extra
over-head in translation.  Secondly the underlying code runs in 16-bit mode
which is slower.  IBM currently only brings them in via the migration
package which is supposedly there only while migration from 1.X is being
supported (though IBM supports such things quite a while).
Though I agree, I don't think it likely they'll take it away.
My guess is they ran out of time... yet I've not seen announcements that
the "June" CSD will fix it. Anybody know?

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

All I can say is that it is nice to use.

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

Sigh... it has both a long name and a short one.
I.E. the file has two names as a part of its attributes.
This is not the same as a Unix link.
The directory entry contains two names.
I promise... Microsoft isn't stupid; NTFS is a very modern file system.

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

If you can find that announcement I'd be greatly interested.
(I'd also like to know if other things are promised.)

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

This is a good point, I'm not sure if you need LAN Manager of NT as a server
for this or not... maybe the Microsoft people out there can help?

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


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