From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d694b5818a5102b1 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-09-20 14:32:07 PST Path: bga.com!news.sprintlink.net!redstone.interpath.net!ddsw1!panix!MathWorks.Com!zombie.ncsc.mil!paladin.american.edu!auvm!EIGHT-BALL.HV.BOEING.COM!crispen Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: comp.lang.ada Message-ID: <9409191448.AA03903@eight-ball.hv.boeing.com.hv.boeing.com> Date: Mon, 19 Sep 1994 09:48:18 CDT Sender: Ada programming language From: Bob Crispen Subject: Re: Naive question about system dependencies Comments: To: INFO-ADA@VM1.NoDak.EDU Date: 1994-09-19T09:48:18-05:00 List-Id: Howard Holm 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| +-------------------------------+--------------------------------------+