Re: Naive question about system dependencies

[Bob Crispen <crispen@EIGHT-BALL.HV.BOEING.COM>]

Howard Holm <hholm@clark.net> sez:

> I was considering how
>I would go about writing a program that was intended to be used in several
>different operating system environments (e.g. OS/2 and UNIX).
[snip]
>So, my question is how
>do you go about accounting for differences in GUI's and the like?

For the past several years the folks in my group have put all our
OS dependent functions into one package called OS_Services.  We've
got different package bodies for each OS.  Pretty vanilla Ada approach,
actually -- keep your PRAGMA INTERFACEs in one place, handle
variability with different package bodies, group similar functions
together in a package.  No rocket science here, and it works pretty
well.

The only question, of course, is what do the subprograms in the
specs look like?  Our two main OSes are Unix (IRIX and SunOS) and
VxWorks, so we've got a lot of commonality to begin with.  That
leaves us with two odd cases: (a) functions in the OSes that are
similar, but not quite identical and (b) functions that are unique
to a given OS.

In the first case, standardization efforts (e.g., Posix, OpenGL)
often let us decide what the "correct" function call looks like.
We then do what's necessary in the subprogram body to call the
OS function(s) that most closely approximate the function.
Sometimes that's not possible; e.g., the "incorrect" version
requires the caller to supply an argument which would be a pain
to get in the subprogram body.  Only then do we have two versions
side by side in the package spec.

When there's a wonderfully useful little function in one operating
system that isn't present in another (e.g., sysBusIntGen() in
VxWorks but not Unix) and we don't expect ever to use it on the
Unix side, we implement the body of that function on the Unix side
so it gives a warning message, raises an exception, etc.  Of course,
if it becomes necessary, we'd expend the effort to write a subprogram
body that performed that function.  But there's no reason to spend
effort on writing the body for a subprogram you'll never call.

Note that some people write packages for the ages, rather than to
solve the problems of a particular family of products.  Or they
write packages that will go out of their control.  Those folks
would disagree violently with my last statement, and with good
reason.

If I had to cope with GUIs, I think I'd probably have a separate
package for them rather than cluttering up my OS_Services package.
I do know that I prefer to use OS_Services rather than the
large number of OS bindings packages provided by the vendor wherever
I can.  Vendors change their package specs whenever they want, and
don't always provide the same functions or even bindings across
platforms.

Note that where there aren't any applicable standards or emerging
standards (and is there a domain where that isn't true any more?)
you've got to do the systems engineering to determine what the call
ought to look like to (e.g.) place a character on the screen at a
particular position, and then make the bodies do what they have to
for your particular system.

Note also that this approach doesn't require you to be stupid.  If
you're going to sell 1,000 copies of the Microsoft Windows version
to every 1 you sell on other OSes, it ought to be pretty clear what
the "correct" forms of each function are, and never mind all that
business about standards.

Finally, let me say that I've yielded to temptation to write elegant
and user-friendly calls to put in the same package alongside the
"straight" OS bindings (where the functions have the same name and
arguments as the OS function).  In my desire to be helpful, where a
socket package requires you to call socket(), then bind(), then
whatever, I provided an elegant Set_Up_Connection subprogram.

Every time I've done this, I've regretted it.  I've had to fool with
the "user-friendly" bodies to make them meet the needs of the current
program.  Lesson learned: put the user-friendly stuff in a different
package, and always supply the straight OS calls.
+-------------------------------+--------------------------------------+
| Bob Crispen                   |   Who will babysit the babysitters?  |
| crispen@foxy.hv.boeing.com    +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+