mrgofor@mmm.UUCP (Michael Ross) (11/22/85)
> >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*? 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, you say, then why not isolate the parts that are mac-specific and provide a high level interface that mimics the mac? Well that's a good question, but unfortunately the answer is best understood by people who have actually programmed the mac. The use of the toolbox is integral to all parts of a mac program. The workings of the toolbox reflect a philosophy that I would doubt is duplicated in either the Amiga or ST (not because it's a bad philosophy, but simply because the extremely complex problems that are tackled by the toolbox can be solved in any number of ways, and I would be surprised if three or more independent development teams would have solve those problems in the same way). -MKR
peter@graffiti.UUCP (Peter da Silva) (11/24/85)
> > > >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
oz@yetti.UUCP (Ozan Yigit) (12/03/85)
> >> 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.