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.
rick@uwmacc.UUCP (the absurdist) (12/07/85)
[ dropped from the net.lang.c distribution, since this is not a specifically C language issue ] In article <284@yetti.UUCP> oz@yetti.UUCP (Ozan Yigit) writes: > 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*. Almost any source I have seen has function mixed w/interface all over it. Not just on the Mac -- look at Unix sources. It's possible to call a separate module everytime you need to handle an exception, do i/o, or whatever -- but very few people bother. (Quick, what was the last major C program you wrote where every call to a routine from section III of the manual was separate? No forks, etc.?) Sure, portability is desirable. But most people are aiming at a specific target, and why should they make their code more complex and fragile to support a machine they are not interested in? Something that escapes most mainframe-oriented people is that it is often nearly impossible to get tech support (even manuals!) w/o buying software to go with it. Even IF someone wanted to write for Apple's Toolbox, Atari's Gem, and Amiga's Intuition interfaces, they'd face major problems in finding out how to write/support software on a second and third machine. This discussion is about what people do for *FREE*, after all. -- Rick Keir -- right next to the Oyster Tank -- UWisc - Madison {allegra, ihnp4, seismo}!uwvax!uwmacc!rick