Windows 95 to Mac

Date: Fri Jul 10 08:26:36 MST 1998
From: Warren \"The Howdy Man\" Ockrassa <hotsgl19-2@IDT.NET>
Subject: Windows 95 to Mac

> All the graphics are in BMPs, sounds in WAVs and a few Xtras (Smacker,
> XtraDraw, FileXtra) and lots of smacked video clips done with smacker.
> Total CD size is about 250 MB.

If the smacker clips are .mov again you should be fine. However there might be a MacSmacker -- frankly I have no idea.

For the most part if the xtras you are using on Wintel exist on Mac as well, you should be fine as long as you adjust your references a little, as and if needed.

The toughest part will probably be in filename convention. Macs of course do not use the *.* format and, if you are developing for Win32, do not allow more than about 27 characters in any file or directory name. If you have kept pretty much everything 8.3 compliant, only relatively minor adjustments re such items as the directoryDelimiter will probably be needed.

Oh: Menus. Win menus exist in the active window; Mac menus are defined across the top of the screen. Mac menus include the "@" item, which is the Apple menu, and which, if it's missing, will result in your Mac users squealing about how "your program screwed up my menus". In general you can put the "About this program" stuff in the Apple menu, to wit:

menu:@
About this program... | AboutBox()

on StartMovie

  if the machineType = 256 then
    installMenu cast "MyMenuWin"
  else installMenu cast "MyMenuMac"

END StartMovie

  "MyMenuWin" text contents:

      menu:File
     Exit/X | QUIT
     menu:Help
     Help for MyApp... | HelpMenu()
     About MyApp... | AboutBox()

  "MyMenuMac" text contents:

     menu:@
     About MyApp... | AboutBox
     menu:File
     Quit/Q | QUIT
     menu:Help for MyApp
     Help for MyApp... | HelpMenu()

[apple menu]  File  Edit  Help  Help

So renaming your own "Help" menu, if it's present, to something like "Help for this program" might be advisable:

[apple menu]  File  Edit  Help for MyApp...  Help

Fonts in Rich Text fields -- text castmebers, not field castmembers -- retain their font characteristics across platforms *as long as you do not select them for editing on the other platform*. That is if you use, say, a special Windows font called "handwriting" in a text castmember, that text will appear correctly formatted on Mac *uhtil you click on it*, in which case it will revert to (as I recall) Geneva.

Fonts in ASCII fields -- editable stuff -- are generally displayed on Mac 2 points smaller. This includes button text if you use generic Tool Palette buttons. So you might have a perfectly-aligned and -framed "exit" button in Windows which will appear a little small on Mac (it will be the correct width, but not tall enough). If precision spacing is an issue for such items onscreen consider using scripted bitmaps rather than Tool Palette items.

Long and short: Even if you manage to really streamline the process, your file ports will probably still need a little hand-tweaking in order for the ports to be really decent.

It is extremely advisable to avoid, as much as you can, platform-specific compiles. It can get very hard to synchronize release versions if you use two different sets of code. I've gotten around this for the most part by putting up a splash screen on app launch which locks out all the other system stuff -- and which covers nicely palette shifts and other unpleasantness. Besides it keeps the user focused -- for the moment at least -- on the running program. I also use machineType tests where they are applicable.

For a practical example of this kind of xplat work, link to http://www.hots.org/hots-wired.htm, select the "Software update" link and download the Crossword-O-Rama app for your favorite Win system and for Mac as well, as applicable.

I designed the program with complete -- as complete as possible -- xplat transparency in mind. The onscreen displays in either Mac or Win look virtually identical and even the saved crossword puzzles are platform-independent. That is a PC crossword puzzle can in fact be opened and played on Mac, will display onscreen correctly, and will print properly. You can even email the puzzles.

(I used Macromedia's Fontographer for WinNT to create the Crossword-O-Rama font; that is one reason I was able to make the program work so well across platforms. Happily Fontog for NT includes a DragNDrop utility for Macs which converts Win .ttf to Mac fonts.)

Note that all versions of Crossword-O-Rama lock the user out of the system unless the Taskbar is set to be on top at all times, and every version uses the Mac palette exclusively.

Hope this was worthwhile. All the best! --