dave@micropen (David F. Carlson) (09/04/87)
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 Carrolltb@laura.UUCP (Tb) (09/07/87)
Hi out there, Generally i agree with what David writes in his article. Considering all the similarities between OS/2 and *IX i wonder "why OS/2 at all". I do not see REAL advantages over *IXes. As far as i know Microport offers a package which allows one MS-DOS task under their UNIX. So this offers all OS/2 does. Any comments ?? -Torsten ..mcvax!unido!tb ( don't try the above adress) D
eric@snark.UUCP (Eric S. Raymond) (09/08/87)
In article <109@laura.UUCP>, tb@laura.UUCP (Tb) writes: > Considering all the > similarities between OS/2 and *IX i wonder "why OS/2 at all". I do not see > REAL advantages over *IXes. As far as i know Microport offers a package which > allows one MS-DOS task under their UNIX. So this offers all OS/2 does. > Any comments ?? The strategic purpose of OS/2 is to wed Fortune 500 companies to 1) IBM's way of doing things, 2) anything that's not a UNIX. It has *no* advantages over a UNIX + DOS-bridge combination. None. Maybe it will someday if somebody writes an application for it with the ground-breaking quality of a VisiCalc, but don't hold your breath waiting. Any such application will almost certainly a) be written in a portable HLL (most likely C), and b) be available under UNIX. I believe OS/2 is going to become the Edsel of the operating systems market. -- Eric S. Raymond UUCP: {{seismo,ihnp4,rutgers}!cbmvax,sdcrdcf!burdvax,vu-vlsi}!snark!eric Post: 22 South Warren Avenue, Malvern, PA 19355 Phone: (215)-296-5718
rkh@mtune.ATT.COM (Robert Halloran) (09/09/87)
In article <109@laura.UUCP> tb@laura.UUCP (Tb) writes: >Generally i agree with what David writes in his article. Considering all the >similarities between OS/2 and *IX i wonder "why OS/2 at all". I do not see >REAL advantages over *IXes. As far as i know Microport offers a package which >allows one MS-DOS task under their UNIX. So this offers all OS/2 does. >Any comments ?? And the '386 Unixes (sp?) now being announced have add-ons allowing for MULTIPLE DOS windows, which OS/2 has no stated intention of doing. Said multi-DOS packages were announced for Microport '386 Unix this summer, and this week in AT&T's '386 announcement. If the OS/2 model looks so much like Unix, and isn't available yet, and purportedly takes up a half-megabyte of RAM, and only runs one DOS window even on a '386, WHY oh WHY would anyone in their right mind bother with it when Unix can be had NOW for the '386, with all the development tools thereof? Bob Halloran ========================================================================= UUCP: {ATT-ACC, rutgers}!mtune!rkh home ph: (201)251-7514 Internet: rkh@mtune.ATT.COM evenings ET USPS: 19 Culver Ct, Old Bridge NJ 08857 Disclaimer: I am a contractor. Any opinions stated or implied are solely MINE, NOT my agency's, NOT my client's. Got it?! Quote: "When the going gets weird, the weird turn pro." - Hunter Thompson
jpn@teddy.UUCP (John P. Nelson) (09/10/87)
>> "why OS/2 at all". > >It has *no* advantages over a UNIX + DOS-bridge combination. None. I'm not convinced of this. The OS/2+presentation manager (windows) provides a nice, standard, window/graphics programming environment. Of course, this version of OS/2 is not supposed to arrive for a long time. If the 386 UNIX vendors would get together and support X-windows and a common object file format, then OS/2 would begin to look pretty silly. I did notice that OS/2 supports "lightweight processes" (my own terminology, not Microsoft's). I wish UNIX could do that sometimes. fork/exec is not always the best multitasking model. Oh well.
mcdonald@uxe.cso.uiuc.edu.UUCP (09/11/87)
>Generally i agree with what David writes in his article. Considering all the >similarities between OS/2 and *IX i wonder "why OS/2 at all". I do not see >REAL advantages over *IXes. As far as i know Microport offers a package which >allows one MS-DOS task under their UNIX. So this offers all OS/2 does. >Any comments ?? Yes indeed! The REAL reason for OS/2 is that IBM is trying to grab CONTROL over the PC world and YOUR COMPUTER. A properly written protected operating system makes it MUCH harder for the user to wrest control from the writer of a proprietary program! HOWEVER: If the user of a single-user system (such as OS/2) has physical control of the machine, he is going to be able, eventually, to get around any barrier. IBM and Microsoft seem to realize this, and aren't going out of their way to make it hard (like VMS seems to be doing). Actually, according to what I have been reading on the BIX (tm) OS/2 conference, there are going to be lots of differences between OS/2 and **ix. Unix is a very different philosophy from MS-DOS; one is multi-user, the other single user. I think that Microsoft is trying to write a SINGLE-USER multitasking system that incorporates as many of the feature of MS-DOS as possible. Among other things, MS-DOS allows a user to set up his own operating environment with terminate-and-stay-resident utilities like Sidekick and Pro-Key. This is very un-Unixy. One thing OS/2 is trying to do is to organize these things to reduce the chaos that results from "TSR conflict". Whether they succeed is a big question. Another thing that I hope they do is to provide a mechanism for seamless transfer of text and graphics between applications, as the Macintosh already does. I have not read about whether or not they are trying to do this. The Unix kernal is really a primitive operating system. I'll bet that OS/2 will be much more complicated. Let's wait until we see the whole thing before deciding. (I use Unix, VMS, MS-DOS, and RT-11(pdp-11) every day and I find that I frequently have temper tantrums over all but RT-11. I think that that says something. I'll admit that Unix gives me fewer than VMS or MS-DOS.) Doug McDonald (this note written on a Micro-term VT-100 clone connected to a PDP-11/73 running RT-11 connected to a VAX11/780 running VMS connected over a Sytek Localnet to a Pyramid 90 running Unix.)
mickey@axis.fr (Michael Dance) (09/12/87)
It has been said that OS/2 message queues are the same (functionally) as UNIX message queues but (according to Byte) OS/2 queues are only readable by the process that created them (or perhaps the user who created them - maybe someone can clarify this) which is not the same as UNIX that allows message queues to be read and written by many processes and many users (the UNIX queues have read and write bits set at creation time in the same way as files). Arbitration between such prcesses can be random (first come first serve) or by the use of message types. For example UNIX message queues can be used as bidirectional 'pipes' by the processes at both ends of the 'pipe' by judicious use of message types, this is not possible with OS/2 (as described by Byte) This is not an terrible problem in the sense it can be worked around but if it exists in UNIX people will use it (I already have) so moving UNIX code to OS/2 may not be very simple - especially as UNIX has virtually no multi-process debugging tools, whether OS/2 will have such tools is yet to be seen (they are difficult to conceive in a non-deterministic system let alone implement). PS /2 is an IBM trademark 3/2 is an arithmetic expression yielding 1 in integer arithmetic surely used by someone in a programming book as such an example Can IBM copyright something already published?