ravi@eneevax.UUCP (Ravi Kulkarni) (09/16/85)
Lately, I have seen some nice desk accessories, games and even applications being posted to the net for the mac. I happen to have an atari 520ST and would like to have the source to these programs posted as well if possible. I am sure the amiga users would concur. I for one would rather see more interchange of information than barriers being raised by statements such as "My machine is the best". A lot of public domain software is available for the mac today, but I imagine that ST users will soon be contributing as well. I also feel that there is great learning value in seeing the source code for a program rather than just using it. -ravi -- ARPA: eneevax!ravi@maryland UUCP: [seismo,allegra]!umcp-cs!eneevax!ravi
rfb@h.cs.cmu.edu.ARPA (Rick Busdiecker) (09/16/85)
> Lately, I have seen some nice desk accessories, games and even > applications being posted to the net for the mac. I happen to > have an atari 520ST and would like to have the source to these > programs posted as well if possible. I am sure the amiga users > would concur. I for one would rather see more interchange of > information than barriers being raised by statements such as > "My machine is the best". A lot of public domain software is > available for the mac today, but I imagine that ST users will > soon be contributing as well. I also feel that there is great > learning value in seeing the source code for a program rather > than just using it. As soon as (if?) the cc68 cross-compiler can produce code for the Amiga, it should be very easy to move many of the programs that were developed for the Mac over to the Amiga. This is yet another good reason for writing good device-dependant c-code when developing for a micro. Rick Busdiecker rfb@h.cs.cmu.edu cmu-cs-pt!cmu-cs-h!rfb
guido@boring.UUCP (09/19/85)
In article <251@h.cs.cmu.edu.ARPA> Rick Busdiecker writes: >As soon as (if?) the cc68 cross-compiler can produce code for the Amiga, it >should be very easy to move many of the programs that were developed for the >Mac over to the Amiga. > >This is yet another good reason for writing good device-dependant c-code when >developing for a micro. Ha, ha, ha! device-dependent C for the Macintosh! Obviously you have not seen many of the C sources that were posted to net.sources.mac (admittedly, there weren't that many, but enoug to give one the taste). C code for the Macintosh consists of about 5 % algorithms and 95 % toolbox interface, unless you're writing HUGE applications. The typical demo program for instance has four or five lines to draw a specific curve and the rest of the program sets up windows, checks the keyboard and the mouse, and what-have-you. Given the complexity of the toolbox interface, it is unlikely that individuals who are writing one particular program would spend much time on separating the toolbox from the rest; I believe that currently MANY programs are actually study objects for their authors: they learned using the toolbox while they were writing it (and some even learned C at the same time :-). I have seen one demo for the ST and it was not different; I expect the Amiga to obey to the same rule. It is not that strange: libraries with the power of any of these machines' toolboxes are a new development in the microcomputer world and new developments are unlikely to start their life as regulated, standardized interfaces. Something like GKS on top of it would kill the system's performance and memory space; besides I doubt if GKS provides an adequate interface to a windowing system. -- Guido van Rossum, CWI, Amsterdam (guido@mcvax.UUCP)
peter@graffiti.UUCP (Peter da Silva) (09/21/85)
> Ha, ha, ha! device-dependent C for the Macintosh! Obviously you have not You mean device _in_dependant code, don'tcha? > seen many of the C sources that were posted to net.sources.mac (admittedly, > there weren't that many, but enoug to give one the taste). C code for the > Macintosh consists of about 5 % algorithms and 95 % toolbox interface, unless > you're writing HUGE applications. The typical demo program for instance > has four or five lines to draw a specific curve and the rest of the program > sets up windows, checks the keyboard and the mouse, and what-have-you. Which is really strange, since the dumb public-domain window package for the IBM-PC that I'm using just requires an openwin() and a couple of printwin() and plotwin()s to do the same thing. Maybe "everyone" should agree on a toolbox window environment & an interface for vanilla 'C' program usage. How many windows should you open to say "hello world"? Question on the Mac: is it possible to launch a program & hand it a window to do all it's text I/O in? Then you could just have a program that sets up the screen and so on & launches your hello-world program into it. I mean if the oh-so-terrible user-hostile AT&T PC7300 can do that, surely the super-friendly novice-chummy Mac can.