You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xerces.apache.org by cr...@goingware.com on 2000/02/29 11:41:38 UTC

MacOS port starting to work

I have the MacOS port of Xerces updated and starting to work fine.

There were two main issues, the transcoding service and the platform utilities.

The original instructions recommended using the ICU transcoding service on the 
Mac, and I worked on building them on the Mac, at first by working to build them 
on Windows with Metrowerks Codewarrior (you can build for either platform on 
either platform with codewarrior).

But I've been in something of a hurry to get my client something that works 
quickly so she could do a demo and although it was starting to build OK I gave up 
for now.  I will return to ICU later.  I did get ICU's libraries themselves to build ok in 
metrowerks for windows but didn't do the work required to build the data files.  I 
saw the stuff about loading a memory mapped file through a DLL and just started 
feeling deep-seated cross-platform dread.  I expect it can be gotten to work 
though.

What I did was to make a simple transcoder based on the Win32Transcoder 
service that uses the widechar ANSI library functions.  It has to be a separate 
transcoder service because, although corresponding functions are available on the 
Mac, they have slightly different names, some are missing, etc.

So began the MacOSTranscodingService.

But I didn't really mean this for production use except to get the port working.  
What I'm really going to do is write a MacOS transcoder that makes use of the 
Unicode API's that are available now in the MacOS system, so you'll have a 
choice of those or the ICU, or my "poor man's" transcoder.

The other issue was the MacOSPlatformUtils file.  This was written for a much 
earlier version of XML4C.  The most frequent changes were the different 
constructor API's for exceptions (using a code for the reason instead of an explicit 
string, so the text can be retrieved with the message loader).  There were a few 
functions added to the API that I implemented.

There seemed to be just one actual bug that prevented me from just having it work 
the first time I used it!  That was that the platform read function would throw an 
exception if it reached the end of file.  I changed that to test if the error code to 
the Mac FSRead call was eofErr and not throw an exception in that case.

What was really cool was that I'd written code on Windows that generated a UI 
based on what was found in an XML file.  The ui was pretty complicated and you 
could navigate around in it and stuff.

I built this UI using a cross platform GUI library that supports MacOS, Windows, 
BeOS, and XWindows, and initially wrote it all on windows.

I also use the Independent JPEG Group's JPEG format library.  That worked right 
out of the box on the mac, right on the first try.

So to move my application from Windows to the Macintosh, including a 
complicated GUI that is dynamically generated from XML, that also displays (and 
will later edit) JPEG files, the whole port took less than a week - two days of 
which was trying to get CVS working between my NT PC and my Macintosh (I 
gave up and just FTP'ed a zip file of the sources).

More on the reading XML from mac resources in my next email.

Mike Crawford
GoingWare - Expert Software Development and Consulting
http://www.goingware.com
crawford@goingware.com
Michael D. Crawford
GoingWare - Expert Software Development and Consulting
http://www.goingware.com
crawford@goingware.com

     Tilting at Windmills for a Better Tomorrow