Cross Platform API
- Posted by David Cuny <dcuny at DSS.CA.GOV> Apr 08, 1998
- 719 views
I did a bit of research on the Mac and X Windows APIs this weekend; here = are some findings, in case people are interested: [Web Information] My primary source for X Windows information is a great tutorial at: http://www.ee.cityu.edu.hk/~edap053/xtut00.html My primary source for Mac programming is an on-line book on coding the = Macintosh for hobbyists, at: http://cafe.ambrosiasw.com/alt.sources.mac/macintosh-c/ The are both excellent. [Terminologies] X Windows calls attributes 'resources', and controls 'widgets'. This can = be a bit confusing. [Similarity to Win32 API] Both the Mac and X Windows are based around the same kind of event-based = model. They both support the same basic set of controls. They both use = callbacks to handle interaction with controls. There seems to be more similarity than differences - but the differences = can be a real pain. [Calling the Mac API from Euphoria] The Mac API is fairly simple to call. Although most calls look something = like this in C: createWindow( ... ) they can also be coded like this: toolbox( _CreateWindow, ... ) using a Pascal calling convention. Since the Mac toolkit is part of the = OS, the calls don't need to be resolved until runtime. This means that = you could provide a mininal version of a Mac port that knew very little = of the tookit, and have it extended by users - much the same as Win32. [Calling the X Windows API from Euphoria] The X Windows API is fairly low-level, and typically one would code to a = higher-level interface, such as Motif or AfterStep. In either instance, = the calls are to a library that is linked at compile time (as opposed to = the run time DLLs of Win32). This means that Euphoria would need = explicitly have to define what X Windows/Motif calls are to be = supported. [Possible Mac Issues] In Mac programming, it seems that you have to define *all* your = resources ahead of time, using a tool like ResEdit (resource editor). = What's a resource? Just about anything: a window, a control, a menu = item, a cursor. In theory, the resource file can be bypassed by creating the controls on = the fly (or resource files on the fly). In practice, this doesn't seem = to be the direction that people take. For example, Sun's Tcl/Tk code = simulates Mac controls by creating a set of each type of control in a = hidden window. When that control needs to be displayed in a window, it = copies a bitmap of that hidden control into the window that has that = control. With a new OS "just around the corner" (Rhapsody), it's not clear how = portable the Mac code will be to the new OS. It seems that Apple is = encouraging people to use the NextStep libraries (which are also = available under the GNU license in the form of OpenStep). [Cross Platform Issues] Certain basic things, like bitmaps and fonts, are not easily transported = between the platforms. Unless you are using a geometry manager (such as Tk's), a window = formatted for one OS will not look right for another. The Mac is based on a Pascal model, not a C model. One example of this = is the strings - they are size prefixed, not zero delimited.=20 I don't know if there is an -endian issue with the Mac. [Cost of Compilers] The X Windows libraries and compilers are typically free. The Mac = compilers can range from about $100 (non-Power PC version of MetroWork's = C Compiler or Apple's MPW compiler) to $450 (MetroWork's Power PC = compiler). [Is There A Market?] There seems to be a large number of people using different tools on the = Unix platform who would be willing to look at a Linux port of Euphoria, = with or without a GUI. Problematically, most Unix users (as Robert has = pointed out before) are used to not having to pay for their tools. While there is less of a base for Mac users, there also seems to be less = programming tools available. I just thought people might be interested. -- David Cuny