Portability of Mac Source

[Ozan Yigit]

>
>> 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.
>
	That is indeed very doable. I have a version of the Ancient
	Clisp (by Thomas Duff) that runs on 512 MAC, VMS, and on my
	PRO-350 (VENIX). [No.. it is not yet distributable. I have to
	clear it with Thomas first - and more work is needed.]
	It is the SAME CODE, except under MAC, the routines
	for the user-interface and memory management are replaced with
	those more suitable for MAC. (like windows, menus, mouse poll etc.)

	Surely, the porting of MAC programs may leave lot to be desired
	in terms of interface, but the question is exacly what we are
	porting ?? The windows and menus or the *functionality*.

	Perhaps it is safe to say that some MAC programmers worry more
	about how the program *looks* rather than what it *does*. SIGH.
	And I thought the advancement of systems like MAC would clear
	away all the interface blues, and let people concentrate more on
	the *functionality*.

	Btw: there is another side to the coin. SUN has facilities to
	build interfaces to programs that are originally written to run
	on ordinary terminals. Check out the ancient UN*X chess running with
	such an interface. Does any MAChack need a better hint ???

OZ
-- 
Usenet: [decvax|allegra|linus|ihnp4]!utzoo!yetti!oz
Bitnet: oz@[yusol|yuyetti]
		In the beginning, there was Word all right, except
		it wasn't fixed number of bits.