From: brian@jaguar.cs.utah.edu (Brian Sturgill)
Subject: Re: Windows, OS/2 and Mac APIs
Organization: University of Utah CS Dept
Date: Sat, 14 Nov 92 02:05:59 GMT

In article <1992Nov13.151438.19436@emr1.emr.ca> jagrant@emr1.emr.ca (John Grant) writes:
>I have not used or programmed for OS/2 or Mac, however I have just spent 3
>months on my first Windows app.  Wow! What a learning curve (I'm comfortable
>with it now, though).  So my question is directed at those who have programmed
>for any combination of 2 or 3 of these environments.  How do they compare at
>the API level?
>
>Note: this is not a question about either:
>	(a) linear/segmented address spaces
>   or   (b) 16/32 bit mode
>I really don't care about those 2 topics for this discussion.  All I am
>interested in is the API (system function calls, structure of programs,
>callback functions etc).  Which system is more intuitive, easer etc?
>
>-- 
>John A. Grant						jagrant@emr1.emr.ca
>Airborne Geophysics
>Geological Survey of Canada, Ottawa


I've programmed in all of the above, though with OS/2 I have extensive
experience with the API but not with the Presentation Manager (graphics)
portion.  I'll also throw in Motif and X11 in the graphics portion and
Unix in the non-graphics portion.

Here's what I think (easiest to hardest):

Graphics:
	PM (OS/2)  (I really only know this from a "feature" standpoint.)
	Win32
		Win32's graphics API is messy relative to PM.
	Windows 3.X (but with Win32s, this is no longer necessary)
	Motif
		In truth programming for Windows and Motif are about the
		same level of difficulty. The difference is that in Motif
		you spend all your time overriding the ill-thoughtout
		defaults of the widgets, and you must occassionally
		resort to X11.  In Windows you spend all your time
		building the primatives into generic widget-like gadgets.
		It takes about the same time between Windows and Motif,
		but Motif has a lot larger overhead, so I rank it lower.
		Motif also has the same limitations as X11.
	X11
		Well X11 is primative... it was designed that way.
		It has not printer support, and is lacking other things
		that one is accostomed to like sound, multi-media, etc.
	Macintosh

Non-Graphics:
	Win32
	Unix
		Unix has less features than Win32, but what it does have,
		is usually accessible through very clean, time-tested
		calls.  However, unless you're doing character-mode
		sorts of I/O (e.g. to ascii terminals), it is missing
		too many things.  Various vendors have added many
		of the missing things, but there are no standard interfaces
		to those things.
	OS/2
		OS/2's non-graphics API is messy and weak in many areas.
		Currently it does not define a console API, but you
		can still use the 16-bit calls from OS/2 1.X.
	Windows 3.X (but with Win32s, this is no longer necessary)
		The reason I rate it below OS/2 is that you often
		have to resort to DOS calls, and the C to Asm
		issues (or the use of a call that fakes the asm)
		is messy.  There is no console API.
	Macintosh

Macintoshes are by far the hardest platform to program for.
This is mainly due to Apple's insistance that you must follow all the
rules, but then not really codifing the rules.
For example to do sound on a Mac, you need to look through 3 of the
6 Inside Mac volumes, then search the Tech notes.
To do file I/O you need to look in 2 volumes plus all the Tech notes.
You need to know to ignore the information in Volume II.
They recently have redone Inside Mac, but the description did
little to reassure me.

Some people will tell you that the Mac is easy to program for... I
invariably find that people that say this did not realize that the
code they were producing violated many of the guidelines.
Another problem with the Macintosh API is that it consists of calls
that take HUGE data structures, and you have to understand every
item in the data structure to initialize it properly.  The large number
of initializations also makes all code look very cluttered.
Also most of the extensions to the API were ill-planned, often leaving
two or three distinct sets that will almost work together.
Most of the Macintosh API calls do not check for valid data.  For example
it is possible under most versions of MacOS to create a filename that
contains an ASCII null character, even though this is supposedly not
a legal character in the file name.

Brian
-- 
C. Brian Sturgill                   I strongly encourage you to mail your copy
University of Utah                     of Ross Perot's:  "United We Stand
Center for Software Science            How we can take back our country",
brian@cs.utah.edu; CIS: 70363,1373        to President-elect Clinton.