Portability of Mac Source

[Peter da Silva]

> >
> >Unportable, yes... by definition. Mac-specific? No longer. See net.micro.amiga
> >and net.micro.atari for more info. It is no longer acceptable to assume that
> >windows==macintosh (actually it never was, but you slobs got away with it).
> >-- 
> >Name: Peter da Silva
> 
> Slobs ... *moi*?

Yeh, you... (rolls up sleeves and spits on hands) wanna step outside & make
somethin' of it?

> Sorry, but it's not just the fact that the system uses
> windows - it's also the way they're used. There are over 400 (aren't there?)
> toolbox routines that do all that stuff for you, so your code ends up looking
> like a lot of calls to the toolbox with some (or whatever language) thrown
> in.

Ahh, then why not isolate the Mac-specific stuff in a seperate module.

> Ahh, you say, then why not isolate the parts that are mac-specific and
> provide a high level interface that mimics the mac?

What are you, a telepath?

No, that's not quite what I say. I say write the Macintosh software with the
intention of porting it to other machines. You may lose some efficiency, but
you'll gain at least one huge new market for your stuff. Maybe two.

Pseudo-code. Let's use the UNIX model.

main {
	signal(CLOSE_WINDOW_BUTTON, close_routine);
	signal(RESIZE_WINDOW_BUTTON, repaint_window_routine);
	signal(...other_stuff..., ...other_routines...);

	main_loop {
		do_some_stuff...
#if !defined(MULTITASKING) && !defined(MOUSE_INTERRUPTS)
		poll_mouse(); /* this will call all the other signals */
#endif
		some_more_stuff...
	}
}

If the program is written in a manner that supports porting, then porting will
be easy. This will require a certain amount of LCD coding (on 4.2UNIX, frex,
CLOSE_WINDOW_BUTTON is INTERRUPT, and RESIZE_WINDOW_BUTTON is TSTOP), but
the gain is portable code.
-- 
Name: Peter da Silva
Graphic: `-_-'
UUCP: ...!shell!{graffiti,baylor}!peter
IAEF: ...!kitty!baylor!peter