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.
mike@smu (12/04/85)
I strongly disagree that Mac-like programs can easily be made
portable. It seems to me that only someone who has never really tried
to do that could make such a claim. The are MAJOR differences between
GEM and the Macintosh ROM. Ever tried to use windows under GEM?
Scrollbars are great fun, let me tell you. In fact, have you ever
tried to deal with event processing under GEM? MUCH MUCH different
than the Macintosh. These differences aren't things like changing
ints to longs.
Claiming that all one must do is sacrifice a little bit of efficiency
(supposedly gained by exploiting some system-specific feature) in
order to create programs that move easily between "similar"
environments is silly. UNIX and VMS are similar; both are multi-user,
multi-tasking minicomputer operating systems. Think of the
difficulties involved in porting a heavily UNIX-oriented software
system to as different an environment as VMS. It is unlikely that
anyone would try and make the software use features found only in the
intersection of the two OS's. A more likely solution would be to use
something like EUNICE (I think that's what it's called) to provide a
UNIX environment within VMS (or vice-versa). Unfortunately, nobody
has created MacGEM (and I doubt anybody will).
Mike McNally SMU -----------------------------------------
mike@smu "Is there Christmas in the hippie world?"
...{convex|texsun}!smu!mike -----------------------------------------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
matt@srs.UUCP (Matt Goheen) (12/09/85)
One last point on this topic that I haven't seen mentioned. Writing
portable code assumes you have access to multiple computers/compilers.
I ONLY have Aztec C. I can't write code portable to any other C
compiler because I don't have any other C compiler. If someone with
another brand of compiler wants to port my code to their brand that's
fine with me (thus the advantage of posting source), but generally that
can be a non-trivial task - especially with Mac sources (thus the
advantage of posting binaries).
Matt Goheen
S.R. Systems
..!{seismo,allegra}!rochester!srs!matt
"Everything that rises must converge."ralphw@ius2.cs.cmu.edu (Ralph Hyre) (12/10/85)
In article <186@srs.UUCP> matt@srs.UUCP (Matt Goheen) writes: >Writing portable code assumes you have access to multiple computers/compilers. Not always, especially if you have good documentation on your versions portability with respect to a standard version, say K&R (assuming you have a 'C' compiler). For example, I can write code that implements, say the Christiansen MODEM protocol, and distribute source. All that would need to be done for a specific machine is re-implement the following routines: write_char_to_modem(c : char); c : char := read_char_from_modem(); write_char_to_file(f : file_des, c : char); c : char := read_char_from_file(f : file_des); f : file_des := open_file; close_file(f : file_des); and perhaps an init_modem(); With the Mac case you will also need information on OS, ToolBox, and other 'standard software' (appletalk, packages, etc.) calling conventions. Apple should get the C compiler companies together and have them work on standard calling conventions so that this area is portable... The Mac is troublesome because Apple hasn't provided a 'standard' development environment with the machine, [not even BASIC :-)] Perhaps Apple should give away a C compilers with the machine, so that people won't have an excuse to not include source, (at least on USENET)
spector@acf4.UUCP (David HM Spector) (12/11/85)
Thats really not fair. Apple did suppy a "Standard" development environment,
its called Lisa Pascal. I'll admit that its not my favourite, but then a dozen
or so companies came out with other environments. Apple did give us some thing
much more important, a standard user interface and a standard way to achieve it.
As for toolbox calling conventions, any maker of a "developement" environment
who doesn't respect the calling conventions set down in Inside Macintosh isn't
worth buying from. As far as I know, every language for the mac uses the
standard calling sequence, or in some instances a slight modification (e.g.,
Forth, and NEON) to account for quirks in the language. I happen to use Mac C
from Consuliar, and I use all of the tooltraps the same way I would from Pascal....
Dave Spector
NYU/acf Systems Group
SPECTOR@NYU
...!{siesmo,allegra,inhp4}!cmcl2!spector
^--That's an L, not a one.guest@ccivax.UUCP (What's in a name ?) (12/20/85)
> In article <186@srs.UUCP> matt@srs.UUCP (Matt Goheen) writes: > >Writing portable code assumes you have access to multiple computers/compilers. > Not always, especially if you have good documentation on your versions > portability with respect to a standard version, say K&R (assuming you have > a 'C' compiler). > > For example, I can write code that implements, say the Christiansen > MODEM protocol, and distribute source. All that would need to be > done for a specific machine is re-implement the following routines: Who the &*()%^ cares whether mac code is portable? Why should the power of the machine be decreased by several orders of magnitude just so the program will run on stone-age machines? I for one do not want to turn my mac into a generic "computer". The power of the mac will never be realized if we try and make our mac s/w so it can run on a you-know-who pc (yech and double yech). PLEASE get off this port. crud. Yours in Test, Sam Mantel - Rochester, NY (guest@ccivax)
lewis@axiom.UUCP (Lewis Gordon Pringle Jr.) (12/23/85)
>Who the &*()%^ cares whether mac code is portable? Why should the power of >the machine be decreased by several orders of magnitude just so the program >will run on stone-age machines? I for one do not want to turn my mac into Well, I think that many people care if mac code is portable. I happen to be good friends with a Lisa owner who REALLY wishes more mac code was portable. Well written programs need not work on only one configuration of one machine, in order to take advantage of 'the power of the machine' that you are running on. I think the attidute that writing mac software is a Holy experience, and mac programs shouldn't be desecrated with hints of portability is a crock. I applaude the macs user-interface, and I think that all mac programs should maintain it, but I am convinced that they can do so and still give thought to the future. What of future genaration macs (the Mac+++^3), and other existing machines (like the Amiga, etc ..). Writting protable code doesn't necessarily mean that you make sure that the program works perfectly on all machines it might ever be run on, but a well designed and implemented program should not be too difficult to port to a simmilar architecture (like Mac to Amiga). I think that most people can deal with not counting on the number of pixels wide the screen is. Merry Christmas, Lewis. -- ---------- The facts expressed herein are subject to change without notice ... UUCP: {humming,linus,harvard,security}!lewis@axiom.UUCP
berger@datacube.UUCP (12/24/85)
[]
Port CRUD!!!!????
The Mac is not what I call, advanced enough, to be the last machine
ever worth writting code for. I think your the one who needs the
growing up!
There are many reasons for writting portable code. Even if you plan
to only use it on one machine. You never know what the future may
hod especially when dealing with technology. Portablilty does not
necessaryily mean lower performance either.
Bob Berger
Datacube Inc. 4 Dearborn Rd. Peabody, Ma 01960 617-535-6644
ihnp4!datacube!berger
decvax!cca!mirror!datacube!berger
{mit-eddie,cyb0vax}!mirror!datacube!berger