Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!rochester!ur-tut!ur-valhalla!micropen!dave
From: dave@micropen (David F. Carlson)
Newsgroups: comp.sys.ibm.pc
Subject: OS/2 programmer's model
Message-ID: <371@micropen>
Date: Fri, 4-Sep-87 12:21:27 EDT
Article-I.D.: micropen.371
Posted: Fri Sep  4 12:21:27 1987
Date-Received: Sat, 5-Sep-87 18:16:17 EDT
Organization: Micropen Direct Writing Systems, Pittsford, NY
Lines: 88
Keywords: OS/2 UNIX-like MSDOS

I have been waiting expectantly for details on the programmers model
of OS/2.  An article in Sept '87 Byte provides many of those details.
Below are my comments on OS/2 and the information in that article.
Factual errors may be due to the publishing delay as that article is
virtually my sole source of information (and this forum).

First, OS/2 has preserved the MS-DOS file system.  This is wise given
that IBM has never felt volume virtualization is a "good thing" and the
number of MS-DOS programmes that depend on the semantics of that file
system.  Xenix and UNIX on AT's typically use programs to read, write
and list directories to/from MS-DOS file systems.  The onus is on the user
to know when a file system is DOS or UNIX.  Initially OS/2 will not address
32meg file space limit or volume virtualization (but calls are spec'ed
for mountable volumes which would solve these problems.)

It seems that OS/2 has eliminated MS-DOS pseudo-pipes and replaced them with
system5 pipes (named and unnamed).  Shared memory, message queues and
semaphores also appear to be System5 clones.  System calls for non-blocking
IO (which with the necessity to use console screen memory directly is the
reason that MS-DOS was bypassed by most serious programs) are provided for
under OS/2.  Due to the fact that Microsoft C supports a very UNIX-like
call interface, it seems that OS/2 isn't much more that a UNIX with a DOS
file system.  It does provide some nice calls for realtime priorities
which make threads etc. possible.  Nice touch.

The multitasking is apparently done with one process per virtual console.
These virtual consoles are almost identical to XENIX/Microport virtual
consoles.  It is unclear if programs will know which console is active,
as from my own work it is very nice to disable scrolling important information
when the user is accessing a different console.  Since signals for stopping
jobs aren't available in system5, no user process knows which screen is active
and whether it has the active screen.  (A nice answer would be to have a 
SIGTSTP sent to the process group that uses the virtual console and then the
individual processes could decide whether to stop processing or not.  Of course,
this assumes Berkeley signals but ...)  It remains to be seen is OS/2 deals with
this better than current virtual console implementations.

The big fault I see with OS/2 is that it is intimately involved with the Intel
architecture.  The Microsoft additions to C to provide a limited control to
the programmer of the location of code and data with respect to the Intel memory
model the program was compiled with restricts the code to the Microsoft 
environment.  The Intel architecture and the fact that the programmer is 
responsible for knowing details of the memory scheme restricts the portability
of the code written.  A good compiler/operating system should present a device
virtualized, processor-independent programmers model.  It is clear thoughout
the programmers model of OS/2 that the hard disk is C:, that the processor is
a segmented one with a data segment, a code segment and a stack segment.  I 
argue often that a good programming environment one not need know anything(!!!)
about the target machine (except maybe bits per fundemental type) and should
never have to use the machine language to debug (a symbolic debugger should
provide the abstraction from the underlying architecture.)  Codeview (which is
the symbolic debugger under DOS and now OS/2) requires an intimate knowledge of
the processor and its machine language.  dbx(1) and sdb(1) and cc(1) under UNIX
typically divorce from the programmers model the underlying architecture of the
machine, and I feel that is a better way to write portable code.  This is not
a Microsoft proprietary pit:  many other OS's require such knowledge of the
programmer but the trend in programming toward portability acrossed machines
and even operating systems (C under VMS and MVS/TSO, and even MS-DOS) has more
model programming environments removing underlying detail from the programmers
model rather than adding more detail.  I had hopes that Microsoft would 
recognize this but it seems their proprietary interests in keeping programmers
in their fold won out over the industry's realization that non-portable coding
practice will restrict the market and (due to the rapid changes in computing)
the operational lifetime of the software.

The big win for OS/2 is that it provides a very machine efficient operating
system for Intel architectures.  Whereas UNIXs tend to be inefficient with
the limitations of segmentation, OS/2 was designed to be as efficient as
possible.  This gain is offset with the paragraph above in that user program
efficiency is in large part due to crafty coding and segment assigning by the
programmer.  And with the lifting of the 640k barrier, DOS programmers will
not have to do nasty overlays et al. any more.  A reasonably large win for
those afflicted.

A big loss for OS/2 and a testimony to its non-portability is the fact that
OS/2 supports 3 compilation environments:  OS/2 native, MS-DOS native, and 
"DOS-in-a-box"(C) compatibility modes.  System calls are incompatible and it
seems entirely possible that a company wanting to support both MS-DOS and
OS/2 would have a dog of a time doing it with one set of sources:  multiple
development costs would be high and the code still very non-portable to other
markets like the burgeoning XENIX/Microport user-base.

Comments?
-- 
David F. Carlson, Micropen, Inc.
...!{seismo}!rochester!ur-valhalla!micropen!dave

"The faster I go, the behinder I get." --Lewis Carroll