Path: utzoo!mnetor!uunet!nuchat!peter From: peter@nuchat.UUCP (Peter da Silva) Newsgroups: comp.sys.amiga Subject: Re: Feeping Creaturism Message-ID: <775@nuchat.UUCP> Date: 12 Mar 88 02:10:00 GMT References: <8802181921.AA19069@cory.Berkeley.EDU> <682@sandino.quintus.UUCP> <7599@apple.Apple.Com> Organization: Public Access - Houston, Tx Lines: 118 In article <7599@apple.Apple.Com>, lsr@Apple.COM (Larry Rosenstein) writes: > Allow me to correct some errors. Ready when you are. > >two main reasons are that a program on the Mac has to be written essentially > >as a device driver, and that it's not even entirely examinable unless you > >have another Mac... because the resource fork contains information that is > >integral to dealing with the file but which is unintelligable even when > >it's available to people on other machines. > This is wrong. A program on the Mac is written much like a program on the > Amiga. It is not a device driver. Actually, it's written exactly like a device driver on the Amiga. Desk Accesories are even worse, they're written like UNIX device drivers. The Amiga supports, directly, quite a few programming models. (1) What the Mac people call the "Event Loop" model. Useful for completely interactive programs and device drivers. Even for highly interactive programs the similarity is only on the surface. The Amiga event loop is under the program's control... it can choose to get a particular set of events, and safely ignore all others. (2) The normal Amiga message loop, which is similar to the event loop but allows extensive forays out of that mode. For example, a paint program. Once you tell it that you want it to do some extensive process it's permitted to go away and do that. You still have control of the machine and can do whatever you want with other programs. (3) The normal UNIX filter model, where each program has one input and one output, both of which consist of a stream of ASCII characters. (4) The batch model, where the program just goes away and does its thing, control-Cs permitting. For example, a 'C' compiler. (5) The parallel model, where the program spawns off tasks to do jobs like user input and just sits back and spins its web. Like HaiCalc or SoundScape. (6) The server model, where the program is really a collection of seperate programs that talk to each other. SoundScape has aspects of this model, but the classic is Warrior Cycles. > Also, as people have mentioned, it is > possible to get a textual representation of the resources, which would look > much like the equivalent data definitions in an Amiga program. (The > difference is that the defns are not compiled in and can easily be changed.) Except that nobody ever distributes sources in this format. In fact very often sources code itself isdistributed in encoded form. Every program in comp.sources.mac is completely useless for anything but another Mac. > >It has to call the operating system at least once every 100 milliseconds to > >maintain desk accessories. > It is not essential to do this. It is courteous to keep DAs running, but > most applications do not do this while doing compute-intensive things. So while FooCalk is computing, you lose control of the machine. Great. > >It has to be built around an "event loop" that handles all events in the > >system, and passes down to other programs the ones it's not interested in. > This is not much different than what you have to do on the Amiga in response > to certain messages. If you use that model. > On the Mac, you can take advantage of frameworks such > as MacApp, which handle these things automatically. (A programmer using > MacApp has to do a lot less work than an Amiga programmer.) A lot more code, though. Can you even run modern programs on a Mac in less than 1 Meg? I've multitasked a terminal program and Deluxe Music in half that memory. Comes from every program carrying around a copy of stuff that should have been in the O/S. > >It has to allow for arbitrary relocation of large parts of its data as the > >system collects garbage. > The system does not collect garbage and it is not arbitrary. It coalesces > the memory blocks to prevent heap fragmentation. Beautiful example of DoubleTalk (a new Mac Application). It's arbitrary in the sense that this could occur at any time... the program has to assume it's happened every time through the loop. > >The idea of porting a Mac program to anything else, or porting anyone > >else's programs to the Mac, is pretty much a fantasy. Unless you write a > >badly-behaved Mac program or use A/UX. > People at Microsoft, Aldus, ... would disagree with you. They ported their > programs between the Mac and Windows. I have read where this was not a > major effort (provided you allow for this in the first place). I don't know about Aldus, but Microsoft is notorious in the Mac community for badly-behaved programs that bend the User Interface rules and have to be rewritten every time a new system comes out. Maybe they made their port real easy by doing a poor job. What this amounts to is that to port a program to the Mac you had to have written the program around the Mac event loop and emulated it in the O/S you did the original version in. > It seems to me that porting an Amiga program would be even more difficult, > unless that program was designed to be ported and didn't take advantage of > the unique Amiga features. You mean like an operating system? We'll see how hard it is to port programs when time comes to do ports for our video-game. Some models would be hard to port, to be sure. There aren't any other small real-time operating systems that come as standard equipment on a personal computer. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.