oster@lapis.berkeley.edu (David Phillip Oster) (09/14/86)
I am not a great amiga expert, but the mac has some definate advantages for the programmer in certain areas: Text handling - when the mac was released, they gave me a one page pascal program that implemented a mouse based text editor with cut, copy, and paste. I sincerely doubt you could do as much on the amiga as concisely. Sound - recently net.micro.amiga had a note from R.J.Micah, one of the designers of the Amiga's software, giving three pages of C code to do what a mac programmer does as "SysBeep(1)" Most amiga programmers use the equivalent of MacInTalk to make their machine say "Beep" because it is too hard to get a tone out of it. Debugging - for $25 you can get an Apple software supplement that includes the debugger MacsBug. MacsBug remains in memory application after application, can dissasemble any code, can give a symbolic trace of the calling tree, knows the name of each operating system call, and, with its ES command, lets you exit back to the Mac's shell from a crashed application. It is not even the best debugger for the Mac. Nothing even as good as it exists for the Amiga. Most amiga programmers have to reboot their whole machine if even one task crashes. Resources - The Mac has a what-you-see-is-what-you-get editor called the resource editor that allows you to change menus, fonts, icons, and every detail of alerts and dialogs (requestors on the Amiga) without ever recompiling. An amiga programmer must laborously speel out these things in C code that does not look at all like the finished product. Fast dynamic linking, the Mac's control definition procedures, menu definition procedures, window definition procedures, and packages allow programmers to substantially change the behavior of compiled code without recompiling it. I myself have taken Apple's finder, pasted a new window definition procedure into it using the resource editor, and made all the windows apple shaped. Apple replaced the standard file interface recently, and all the old programs suddenly became able to cope with a hierarchical directory structure, something no other machine has done without requiring all the software developers to come out with new releases of their programs. (Unix recently when through a change in its directory structure, and everybody had to recompile.) The standard amiga linker is so slow it is known as "Deep Thought" High level printing - Since mac applications comminucate with printers as if they accepted high level graphics calls, most applications did not need to be recompiled to accept laser printers, even though the applications had not been designed with laser printers in mind. Amiga applications have to have special code for each kind of printer. safety - the amiga crashes if you draw a line that extends outside the screen. (According to a friend who regularly crashes his amiga this way.) The mac graphics system calls, although they aren't very safe, are safer than this! Disk Operating system interface - The mac's operating system takes a Pascal view of the world. this is not great for a C programmer, but most Mac compilers have a pascal keyword that handles the details. The system itself is pretty decent. The Amiga's operating system is written in BCPL. BCPL is a ancient British language that was directly responsible for the birth of C. The designers of C started out in BCPL and concluded that it was not possible to make a BCPL compiler that generated decent code for a byte addressable machine. programming environments - LightSpeed C, with its integrated compiling, linking, multi-window editor, make, grep, and profiling is so good and so fast, that I've known users of 8MegaByte, 16MegaHertz, Sun3 68020 systems to prefer to develop on the mac and port their code to the sun, because the 1MegaByte 8MegaHertz 68000 mac has a faster edit, compile test cycle. Conclusion - both machines have their strengths and weaknesses as programming machines. I would probably choose an amiga if I were going to write "Pong". I would certainly choose the mac if I were doing anything involving fonted text manipulation or object oriented graphics. Although the hardware of the Amiga should be faster than a Macintosh, the superior software of the Mac consistantly makes it easier to use, faster, and more powerful at the kinds of tasks that I like to do. --- David Phillip Oster -- "The goal of Computer Science is to Arpa: oster@lapis.berkeley.edu -- build something that will last at Uucp: ucbvax!ucblapis!oster -- least until we've finished building it."
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/16/86)
>From: (David Phillip Oster) >I am not a great amiga expert, but the mac has some definate advantages >for the programmer in certain areas: > Text handling - when the mac was released, they gave me a one page > pascal program that implemented a mouse based text editor with cut, > copy, and paste. I sincerely doubt you could do as much on the amiga as > concisely. If it's only one page I'd like to see it. > Sound - recently net.micro.amiga had a note from R.J.Micah, one of the > designers of the Amiga's software, giving three pages of C code to do > what a mac programmer does as "SysBeep(1)" Most amiga programmers use > the equivalent of MacInTalk to make their machine say "Beep" because it > is too hard to get a tone out of it. For simple BEEPS, the MAC wins. One thing I'd like to see as an addition to one of the run-time libraries for the amiga is a simple BEEP call. It isn't dificult to make the Amiga BEEP, just long winded because the run-time library was set up to utilize the full capability of the amiga's sound and you have to set-up a lot of junk. Taking another point of view, I can make the amiga say something to me with a very simple program (maybe even less than a page). Try doing that on a MAC. > Debugging - for $25 you can get an Apple software supplement that > includes the debugger MacsBug. MacsBug remains in memory application > after application, can dissasemble any code, can give a symbolic trace > of the calling tree, knows the name of each operating system call, and, > with its ES command, lets you exit back to the Mac's shell from a > crashed application. It is not even the best debugger for the Mac. > Nothing even as good as it exists for the Amiga. Most amiga programmers > have to reboot their whole machine if even one task crashes. Nothing quite as good exists for the amiga, but there is a program called 'wack' that does almost as much (everything except the OS call names and symbolic trace). Additionaly, there is a version in ROM that allows you to do post-mortem debugging. There are several versions of Wack. One allows you to delve into the task-structures, system modules, run-time libraries, resource lists, system modules, and other things. And, of course, it disassembles code. If a single task crashes and doesn't upset the rest of the machine, it is frozen (and an alert comes up), but the machine still continues to run other tasks. If a task destroys something very important, the machine comes up with a dead-end alert and you must reboot. If even one task on the MAC crashes (oh! I'm sorry, there is only one task!), you have to reboot your MAC too. Also, when you reboot the amiga you almost never have to reboot from scratch, since the OS is in write-protected RAM. > Resources - The Mac has a what-you-see-is-what-you-get editor called > the resource editor that allows you to change menus, fonts, icons, and > every detail of alerts and dialogs (requestors on the Amiga) without > ever recompiling. An amiga programmer must laborously speel out these > things in C code that does not look at all like the finished product. HA! this is a major difference between the Amiga and the MAC. On the MAC all your requestes and such form a kind-of 'secondary' file, and thus you can easily edit it without recompiling your program. I agree that we don't have anything like a resource editor for the Amiga yet, but there will be one soon. Of course, since the Amiga has a normal file-system and a completely different method of handling menu's and such, the editor would generate C global structures that would then be compiled rather than modify the resource file directory ('cause there ain't to resource file). > Fast dynamic linking, the Mac's control definition procedures, menu > definition procedures, window definition procedures, and packages allow > programmers to substantially change the behavior of compiled code > without recompiling it. I myself have taken Apple's finder, pasted a > new window definition procedure into it using the resource editor, and > made all the windows apple shaped. Apple replaced the standard file > interface recently, and all the old programs suddenly became able to > cope with a hierarchical directory structure, something no other > machine has done without requiring all the software developers to come > out with new releases of their programs. (Unix recently when through a > change in its directory structure, and everybody had to recompile.) The > standard amiga linker is so slow it is known as "Deep Thought" IBM changed from flat to hierarchical without any problems. Since the Amiga employs run-time libraries, and there are system calls to modify library vectors, one could easily modify whichever call he wanted to do something else. In this case, I think the Amiga is more flexible. It means you can change any call in Exec, Intuition, etc... even completely replace system 'rom' modules with your own. (All sounds, window handling, system calls, DOS calls, and most other things are accessed through run-time run-modifiable libraries.) As for the file-system, the Amiga has always had a hierarchical directory structure. It's only slow getting directories. It's speed lies in reading/writing/finding. (but here I believe the MAC+ has a faster filesystem; the amiga only beats out the older MACs). > High level printing - Since mac applications comminucate with printers > as if they accepted high level graphics calls, most applications did not > need to be recompiled to accept laser printers, even though the > applications had not been designed with laser printers in mind. Amiga > applications have to have special code for each kind of printer. The code is part of the system. A particular application program doesn't need to know or care what kind of printer is on the other end, it just uses a standard set of escape codes through AmigaDos's printer device (just another file). I think the Amiga's printer interface wins here. > safety - the amiga crashes if you draw a line that extends outside the > screen. (According to a friend who regularly crashes his amiga this > way.) The mac graphics system calls, although they aren't very safe, > are safer than this! This only happens if you are not using intuition. If you are using Intuition, OOB lines are clipped properly. In fact, one uses the same graphics calls whether using a custom window or one with cliprects. In fact, anything you do via cliprects is clipped properly. In fact, you can have X processes in overlapping windows and completely oblivious to fact as the graphics are clipped properly and saved in alternate buffers so when you move the window nothing is lost. Most people use cliprects, at least during development. > Disk Operating system interface - The mac's operating system takes a Pascal > view of the world. this is not great for a C programmer, but most Mac > compilers have a pascal keyword that handles the details. The system > itself is pretty decent. The Amiga's operating system is written in > BCPL. BCPL is a ancient British language that was directly responsible > for the birth of C. The designers of C started out in BCPL and > concluded that it was not possible to make a BCPL compiler that > generated decent code for a byte addressable machine. Here you are incorrectly assuming that the entire OS is written in BCPL. This is not true. ONLY AMIGADOS is written in BCPL. All the other stuff (Intuition, layers, graphics, devices, the system exec.,...) was written by Amiga in C. I hate pascal. > programming environments - LightSpeed C, with its integrated > compiling, linking, multi-window editor, make, grep, and profiling > is so good and so fast, that I've known users of 8MegaByte, 16MegaHertz, > Sun3 68020 systems to prefer to develop on the mac and port their code > to the sun, because the 1MegaByte 8MegaHertz 68000 mac has a faster > edit, compile test cycle. Currently, and I know of nobody on a 68020 Sun3 who uses a MAC to compile. Remember that the Amiga is multi-tasking. You can EDIT and COMPILE at the same time, leaving your edit active, etc... However, LightSpeedC currently beats the shewabs out of Lattice and Manx on a 512K Amiga, which does make a big difference. With a 1Meg Amiga, you could keep the entire compiler and editor ram-resident, have the editor running continuously (ala multi-tasking), and I think the Amiga just may beat LightSpeedC. As for programming ease, the multi-tasking does all the integrations you need. Add a shell and your set. >Conclusion - both machines have their strengths and weaknesses as >programming machines. I would probably choose an amiga if I were going to >write "Pong". I would certainly choose the mac if I were doing anything >involving fonted text manipulation or object oriented graphics. Although >the hardware of the Amiga should be faster than a Macintosh, the superior >software of the Mac consistantly makes it easier to use, faster, and more >powerful at the kinds of tasks that I like to do. >--- David Phillip Oster -- "The goal of Computer Science is to And the hardware on the Amiga IS faster than a MAC+. The MACs software may be superior now, but then again the MAC's been out a couple years longer than the Amiga. Lets see what happens in another year, you may be in for some surprises. -Matt
dorner@uiucuxc.CSO.UIUC.EDU (09/16/86)
dillon@CORY.BERKELEY.EDU writes: > IBM changed from flat to hierarchical without any problems. Since Gack! Last I knew, WordStar STILL won't accept pathnames. IBM certainly did NOT change from flat to hierarchical without any problems. In general, you had to be in the same directory as your files to use them. And that has persisted in many programs, even popular ones. Steve Dorner University of Illinois Computing Services Office dorner@uiucuxc.CSO.UIUC.EDU, ihnp4!cbosgd!uiucdcs!uxc!dorner I am the OFFICIAL SPOKESMAN not only of UIUC, but of the State of Illinois, The President of the United States, and the EMPEROR of the WORLD. All my decisions are final.
sdh@joevax.UUCP (The Doctor) (09/16/86)
> > For simple BEEPS, the MAC wins. One thing I'd like to see as an > addition to one of the run-time libraries for the amiga is a simple > BEEP call. > > It isn't dificult to make the Amiga BEEP, just long winded because the > run-time library was set up to utilize the full capability of the > amiga's sound and you have to set-up a lot of junk. > > Taking another point of view, I can make the amiga say something to me > with a very simple program (maybe even less than a page). Try doing > that on a MAC. > If you like, I will post 2 programs, one that takes input from the keyboard and converts it to speech. It takes up roughly 24 lines of code. The other program will play 4 voice music. In this, the largest portion of the code is data for the music (I was too lazy to put it in an external file). > > with its ES command, lets you exit back to the Mac's shell from a > > crashed application. > If even one task on the MAC crashes (oh! I'm sorry, there is only one > task!), you have to reboot your MAC too. > Flame on. Excuse me, but can you read? Flame off. The 2 lines listed here say that you do not have to reboot your mac after a crash. It is true for MacsBug and more powerful debuggers like db, from Manx. > > Resources - The Mac has a what-you-see-is-what-you-get editor called > > the resource editor that allows you to change menus, fonts, icons, and > > every detail of alerts and dialogs (requestors on the Amiga) without > > ever recompiling. An amiga programmer must laborously speel out these > > things in C code that does not look at all like the finished product. > > HA! this is a major difference between the Amiga and the MAC. On > the MAC all your requestes and such form a kind-of 'secondary' file, > and thus you can easily edit it without recompiling your program. > Just a side note here. You don't have to put all the resources in resource files. they can be generated on the fly, or in a way similar to that of the Amiga. Resource files were designed so that the mac software cold easily be translated into foreign languages. As an example of this, I have a version of Macpaint in French. The code is all the same. Only the resources were changed to accomodate language differences. It would be a Herculean task to have to translate a all the strings, menus, etc, in a program the size and complexity of MacPaint without the resources. > lies in reading/writing/finding. (but here I believe the MAC+ has > a faster filesystem; the amiga only beats out the older MACs). > > > High level printing - Since mac applications comminucate with printers > > as if they accepted high level graphics calls, most applications did not > > need to be recompiled to accept laser printers, even though the > > applications had not been designed with laser printers in mind. Amiga > > applications have to have special code for each kind of printer. > > The code is part of the system. A particular application > program doesn't need to know or care what kind of printer is on > the other end, it just uses a standard set of escape codes through > AmigaDos's printer device (just another file). I think the Amiga's > printer interface wins here. > I disagree with you here. The process of printing a bitmap is the same as drawing it to the screen. No escape codes. You just open the printer driver and draw the bitmap. All the graphics calls to the screen can be done to the printer, rectangles, ovals, polygons, complex regions --all in any combination of framing or painting with control over the line width and patterns. Consider this: you draw a Ploygon and the drawing routines know enough to give you better resolution for a laser printer than a dot-matrix --transparent to the programmer! (actually, I think its the printer driver that does this, not the drawing routines). Think about how easy it would be to do the printing for a Macdraw document. Its just a screen refresh with the printer driver open. > This only happens if you are not using intuition. If you are using > Intuition, OOB lines are clipped properly. In fact, one uses the > same graphics calls whether using a custom window or one with > cliprects. In fact, anything you do via cliprects is clipped > properly. In fact, you can have X processes in overlapping windows > and completely oblivious to fact as the graphics are clipped properly > and saved in alternate buffers so when you move the window nothing > is lost. > > Most people use cliprects, at least during development. > Rectangles? you can only clip with Rectangles :-) Sorry, I can't help a little unfair prodding here. I just finished a program that had to make a telephone look like it was ringing, so I just used the shape of the phone as a clipping region, and drew circles "underneath" it, producing concentric sections of cricles that were clipped by the phone. It would have taken much longer to do that if it wasn't in ROM. The code would have been substanstial instead of trivial. > And the hardware on the Amiga IS faster than a MAC+. The MACs software > may be superior now, but then again the MAC's been out a couple years longer > than the Amiga. Lets see what happens in another year, you may be in for > some surprises. > No argument here. After seeing, using and programming the Amiga, my conclusion was that it seemed to be developped in a hurry. It seemed to lack refinement in spite of all its power. I can't wait to see the programs when the machine has been more refined, but at the same time, I can't wait to see the Mac programs then. Steve Hawley joevax!sdh
phil@sivax.UUCP (Phil Hunt) (09/16/86)
I currently own BOTH machines, a Mac-Plus with AT-20 hard disk and an Amiga with 512k/ext disk drive. I have been using both for a couple of weeks now (The mac for 1 1/2 years) and thought I would give a comparision of sorts from a real users point of view: 1) The Amiga is full COLOR! I do not care what anyone says, color is great ...but...For any application, the MAC display is much better. I even connected a 9" b/w monitor to the Amiga (There is a video out as well as RF out and RGB out), the resolution is not at the Mac level. The display on the Mac 'feels' better. This is the best way to put it. 2) The AMIGA has special graphics processing chips as well as custom voice synthesis and 4 voice circuits requiring very little processor time to use. It even comes out of the machine in STEREO (yes, right and left RCA jacks!). There is no doubt that this allows the machine to do more. The graphics and voice stuff is offloaded from the 68000. But...Even with all its sophisticated H/W, I think the Mac Studio Session sounds better than the Amiga stuff (I used Instant Music for Amiga). 3) The Amiga is better at programmer interface things, such as, cleaning up windows. On the Mac, you must redraw sections overlaid by other windows. This is automatic (but overridable) on the Amiga. 4) AmigaDOS is very powerful. You get tired of window environment?, use AmigaDOS! The Amiga has the best of both worlds there. A workbench (Desktop) as well as a full DOS, complete with batch, MULTITASKING (with priorities, interjob communication, message mailboxes etc). You can spawn a job on the Amiga, and BOTH keep running. An example, you run Deluxe Paint (Macpaint-type program), it loads and is running, you take the mouse and click on the top menu bar and DRAG the mouse down. The screen moves down and the Workbench is right behind it! (Ala like servant) But the difference is everything can still be d running, a DOS window, Deluxe paint etc. 5) Mac disk management is better, keeping track of mounted but unloaded disks alot cleaner. The Amiga does too, but windows for disk mounts sometimes come up for disks in the drive. As well as requests for disks with GREEK names (Garbage names) 6) Mac disk drives are faster than the Amiga, I do not know why this is. The Amiga disks use a DMA xfer technique, so they should be faster. 7) Amiga comes with 1 serial port and 1 parrallel port standard as well as a memory expansion port and a BUS EXPANSION PORT (ie for Sidecar, a FULL PC clone complete with IBM PC -type card slots and other devices) 8) When a pgm finishes on the Amiga, the desktop does not have to be rebuilt as it runs as a process also, the forward windows are just removed. This is nice. I hope this capsule comparision can help with any questions you might have. Phil Hunt ..calma!sivax!phil (408)942-1212 running (A DOS window
daveh@cbmvax.cbm.UUCP (Dave Haynie) (09/16/86)
> Xref: cbmvax net.micro.mac:2661 net.micro.amiga:2575 > > I am not a great amiga expert, Obviously... > Resources - The Mac has a what-you-see-is-what-you-get editor called > the resource editor that allows you to change menus, fonts, icons, and > every detail of alerts and dialogs (requestors on the Amiga) without > ever recompiling. An amiga programmer must laborously speel out these > things in C code that does not look at all like the finished product. The Amiga has a Font Editor and an Icon editor shipped with it (the Font Editor is officially new for release 1.2). I've got a public domain Menu editor which lets me define menus, graphically, then produce C code to create them. And a full featured gadget editor is just around the corner (can you edit MAC gadgets as easily as all the other stuff?). > Fast dynamic linking, the Mac's control definition procedures, menu > definition procedures, window definition procedures, and packages allow > programmers to substantially change the behavior of compiled code > without recompiling it ... Amiga resident/disk libraries and device handlers do the same thing. All previously compiled programs on the Amiga immediately take advantage of any modified libraries. For instance, the various math libraries could be modified to support the 68881 coprocessor. Once done, every program run on the machine that does floating point math will use the 68881 for its floating point. Also, no matter how many tasks use it, a library exists only once in memory, loaded as needed, discarded if unnecessary. > The standard amiga linker is so slow it is known as "Deep Thought" True. I use BLink, a free, ALink compatible linker that MUCH faster. > High level printing - Since mac applications comminucate with printers > as if they accepted high level graphics calls, most applications did not > need to be recompiled to accept laser printers, even though the > applications had not been designed with laser printers in mind. Amiga > applications have to have special code for each kind of printer. FALSE, LIES, UNTRUE! For each different style of printer, there is a configuration file, run by the printer device, that translates all printer specific functions into generic Amiga functions. This is more powerful that the MAC's printer interface. The Amiga can support any printer via any I/O port in a program transparent fashion. This includes graphic dumps (which may be scaled in various ways) as well as a generic text interface that the MAC doesn't have. I can switch from Epson printer to HP Laserjet or Apple ImageWriter just by selecting the printer option through the Amiga's Preferences program. How many type of printers will the MAC support, anyway (other than Apple, of course). > Disk Operating system interface - The mac's operating system takes a Pascal > view of the world. this is not great for a C programmer, but most Mac > compilers have a pascal keyword that handles the details. The system > itself is pretty decent. The Amiga's operating system is written in > BCPL [etc.] The Amiga's disk interface is far faster than the MAC's. That should say it all. There's very little in the DOS that requires byte boundary access anyway. > ... Although > the hardware of the Amiga should be faster than a Macintosh, the superior > software of the Mac consistantly makes it easier to use, faster, and more > powerful at the kinds of tasks that I like to do. Can't comment on ease of use, that's a personal preference, though I like the option of not having to use a mouse all the time, only when I want to. With a few minor exceptions (circle/ellipse drawing, I believe), BYTE found the Amiga to be consistantly faster than the MAC, in graphics, disk, sound, etc. I like to do my tasks a few at a time, thank you. > --- David Phillip Oster -- "The goal of Computer Science is to > Arpa: oster@lapis.berkeley.edu -- build something that will last at > Uucp: ucbvax!ucblapis!oster -- least until we've finished building it." -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh "I gained nothing at all from Supreme Enlightenment, and for that very reason it is called Supreme Enlightenment." -Gotama Buddha These opinions are my own, though for a small fee they be yours too. \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
c160-aw@zooey.Berkeley.EDU (Christian Wiedmann) (09/16/86)
My opinion in this already belabored subject is that the key issue is not the interface to the programmer, but the interface to the user. Both the Amiga and the Mac support a mouse and windowing. What the Amiga lacks is a clearly defined User Interface. When I sit down with a Mac program, I expect to be able to use it without reading the manual. From what I've seen and heard about Amiga software, this is less true for the Amiga. The reason the Mac is hard to program is because of all the requirements made by Apple. There is no question, though, that the Amiga hardware is better than the Mac's. Now if only Commodore were Apple... -Christian These views are the definitive views of this Universe.
jimb@amdcad.UUCP (Jim Budler) (09/16/86)
In article <8609152222.AA23166@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: +--------------- | I agree that we don't have anything like a resource editor for the | Amiga yet, but there will be one soon. Of course, since the Amiga | has a normal file-system and a completely different method of | handling menu's and such, the editor would generate C global | structures that would then be compiled rather than modify the | resource file directory ('cause there ain't to resource file). +--------------- Normal file system? Did you ever notice that in unix applications there are two 'forks' called text and data. The difference is that the address of the two 'forks' is contained in the file itself, and on the mac the addresses are in the directory. +--------------- | IBM changed from flat to hierarchical without any problems. Since | the Amiga employs run-time libraries, and there are system calls to | modify library vectors, one could easily modify whichever call he +--------------- They did? I remember a LOT of problems with commercial applications during the switchover. Some of them involving costly updates to the commercial applications. I remember having to run Lotus under DOS 1.0, and use complicated methods to move data to and from hard disks during the time it took the upgrade of Lotus to become available (I know, some of that delay time was introduced by my companies purchasing, processing purchase requests, but that's still time). +--------------- | As for the file-system, the Amiga has always had a hierarchical | directory structure. It's only slow getting directories. It's speed | lies in reading/writing/finding. (but here I believe the MAC+ has | a faster filesystem; the amiga only beats out the older MACs). +--------------- I'm glad you said something nice. +--------------- | > Disk Operating system interface - The mac's operating system takes a Pascal | > view of the world. this is not great for a C programmer, but most Mac | > compilers have a pascal keyword that handles the details. The system | > itself is pretty decent. The Amiga's operating system is written in | > BCPL. BCPL is a ancient British language that was directly responsible | > for the birth of C. The designers of C started out in BCPL and | > concluded that it was not possible to make a BCPL compiler that | > generated decent code for a byte addressable machine. | | Here you are incorrectly assuming that the entire OS is written in | BCPL. This is not true. ONLY AMIGADOS is written in BCPL. All | the other stuff (Intuition, layers, graphics, devices, the system | exec.,...) was written by Amiga in C. | | I hate pascal. +--------------- I hate pascal, too, but don't consider the difficulty converting the calls to be any more than an extra bit of knowledge. Once you know it, you know it. It takes two minutes to code the interface. +--------------- | >Conclusion - both machines have their strengths and weaknesses as | >programming machines. I would probably choose an amiga if I were going to | >write "Pong". I would certainly choose the mac if I were doing anything | >involving fonted text manipulation or object oriented graphics. Although | >the hardware of the Amiga should be faster than a Macintosh, the superior | >software of the Mac consistantly makes it easier to use, faster, and more | >powerful at the kinds of tasks that I like to do. | >--- David Phillip Oster -- "The goal of Computer Science is to | | And the hardware on the Amiga IS faster than a MAC+. The MACs software | may be superior now, but then again the MAC's been out a couple years longer | than the Amiga. Lets see what happens in another year, you may be in for | some surprises. +--------------- And by the time the Amiga catches up with Mac on software, the Mac will catch up with the Amiga on hardware, retaining a lead in software. So in another year you may be in for some surprises. -- Jim Budler Advanced Micro Devices, Inc. (408) 749-5806 Usenet: {ucbvax,decwrl,ihnp4,allegra,intelca}!amdcad!jimb Compuserve: 72415,1200 I got tired of my old signature.
graifer@net1.UCSD.EDU (Dan Graifer) (09/16/86)
In article <8609152222.AA23166@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >>From: (David Phillip Oster) ... >> Fast dynamic linking, the Mac's control definition procedures, menu >> definition procedures, window definition procedures, and packages allow >> programmers to substantially change the behavior of compiled code >> without recompiling it.... >> Apple replaced the standard file >> interface recently, and all the old programs suddenly became able to >> cope with a hierarchical directory structure, something no other >> machine has done without requiring all the software developers to come >> out with new releases of their programs. (Unix recently when through a >> change in its directory structure, and everybody had to recompile.) ... > > IBM changed from flat to hierarchical without any problems. ... I was working on IBM PCs (unfortunately) when IBM came out with directories. Most software continued to work in the sense that it didn't crash, but it certainly wasn't "without problems". The nicer programs could deal with exactly two directories at a time: the current directories for drives a: and b: If the auxilliary files for the software where in some other directory (even if in the path) the program was unable to find them. Some software would only talk to the root directory of a: and b:. A hard drive labelled C:? forget it! Eventually, they had to add commands to DOS to make directories look like separate physical drives so brain damaged software would talk to them. Dan Graifer (Sorry, but the claim above re-awakened some old anger and frustration)
c160-aw@zooey.Berkeley.EDU (Christian Wiedmann) (09/17/86)
In article <193@zen.BERKELEY.EDU> c160-aw@zooey.Berkeley.EDU.UUCP (Christian Wiedmann) writes: >My opinion in this already belabored subject is that the key issue is not >the interface to the programmer, but the interface to the user. Both the >Amiga and the Mac support a mouse and windowing. What the Amiga lacks is >a clearly defined User Interface. What I really wanted to say is that IN MY OPINION, the Amiga lacks a clearly defined user interface. I also have to admit that I've hardly used the Amiga. Therefore my views are suspect, and I admit it, biased. From what I've heard about programming the Amiga, I would say that either argument is nitpicking. On the whole, programming both machines is roughly the same complexity. Nevertheless, I don't see why both machines couldn't use the skeleton program idea. This would get rid of the problems for both machines. -Christian Wiedmann Disclaimer: The above view is totally unsubstantiated and therefore is worthy of eternal bewonderment.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/17/86)
>jimb@amdcad.UUCP (Jim Budler) Writes: >Normal file system? Did you ever notice that in unix applications there >are two 'forks' called text and data. The difference is that the >address of the two 'forks' is contained in the file itself, and on the mac >the addresses are in the directory. What are you talking about? -Matt
edusoft@utecfa.UUCP (Educational Software) (09/18/86)
Christian Wiedmann muses:
> Now if only Commodore were Apple...
If Commodore were Apple, then they would have given us great software on
an overloaded processor (with no multi-tasking).
I guess though, that if Commodore were Apple, then Apple would be IBM,
but the big question is ... who would IBM be ? :-)
bill idsardi
espjimb@amdcad.UUCP (Jim Budler) (09/18/86)
In article <8609170125.AA12047@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > >>jimb@amdcad.UUCP (Jim Budler) Writes: >>Normal file system? Did you ever notice that in unix applications there >>are two 'forks' called text and data. The difference is that the >>address of the two 'forks' is contained in the file itself, and on the mac >>the addresses are in the directory. > > What are you talking about? > > -Matt Try the command `size /bin/*sh' sometime. This will display something like: text data bss dec hex 65536 2048 19836 87420 1557c /bin/csh 18432 3072 16844 38348 95cc /bin/sh The command `ls -l /bin/sh' gives: -rwxr-xr-x 1 root 68608 Jul 10 1983 /bin/csh -rwxr-xr-x 1 root 22528 Jul 10 1983 /bin/sh As you'll note, text + data is approx. file size. bss is `buffered storage space'. This is preallocated space. The program will take a minimum of text + data + bss memory to run (although paging on a vmunix system can allow programs totaling more than physical memory, echh!) My point is that Unix systems store the file with one directory entry, then within an application, the first portion of the file ( the a.out header) defines where the text and data portions begin. On a mac there are two directory entries, one for the data fork, one for the resource fork. The application `size' gets the information above from the file, using the structure defined in <a.out.h> or <nlist.h> (depending on your version of UNIX). Diskinfo, on a Mac, gets the some of the same information from the directory. The Mac extended the concept a bit by having the two sections (forks) for non-applications. Is one or the other `normal'? Is one or the other `antiquated'? Is one or the other `better'? Is one or the other `newer'? The adjective `normal' as applied to the Unix file structure was what I was trying to oppose. I was not trying to say that they were exactly similar. The advantage of the Unix system? A simpler directory structure? I doubt it. The Unix directory structure is far more complex than the Macintosh directory structure. It contains a pointer to the inode describing the physical location of the beginning of the file. It contains information about modification date of the file, access date of the file, and size of the file. The inode structure is the real heart of the Unix file structure, and nothing the Mac has approaches it. The advantage of the Macintosh system? The directory structure contains two things the Unix structure does not: The creation date of a file. The starting address of TWO sections. Roughly, and I mean roughly, equivalent to the text and data segments of a Unix application. It lacks: The inode structure, which can tell you when a particular physical segment of a file is modified (I believe dump uses this rather than the directory entry to determine what needs to be backed up). File tags on a Mac don't approach this, especially since they are relatively unsupported. It gains: The ability to modify one portion of the file (i.e. Redit and Resedit) without disturbing the other. You cannot expand any portion of a Unix application without recompiling. With `adb'(sdb,dbx) you can shorten some things (strings) and modify others, but not expand, without recompiling. The creation date. The finder copies a file, maintaining this date. The newer versions of binhex and related terminal programs maintain this date. It is useful. As to the actual comparison between the Unix text+data and Mac rsrc+data? Depends on the programmer. If he programs entirely Unix style, all information in the code, no resources, then his CODE resource is equal to Unix text + data. And his resource fork may contain nothing but CODE ID=0 and CODE ID=1. His data fork will be empty. If he programs Mac style, with resources, then his CODE resources are approx. equal to Unix text + part of the data, and the rest of the resources + the data fork may equal the rest of the Unix data. Most Mac applications do not use their own data fork, but some store static data there. Unix applications store all of their static data in their data segment. I think a comparison should be on the merits, not on the appearance, and certainly not on the state of `normallcy'. I'm certain I will receive much mail/posting/flames telling me how wrong my view of file structures, both Mac and Unix, are. I welcome mail and corrective information. Flames I can do without. -- Jim Budler X X Advanced Micro Devices, Inc. X X (408) 749-5806 X Usenet: {ucbvax,decwrl,ihnp4}!amdcad!jimb X X Compuserve: 72415,1200 X X Signature, what signature? I'll make my mark!!
jat@blnt1.UUCP (09/18/86)
In article <1274@jade.BERKELEY.EDU> oster@lapis.berkeley.edu.UUCP (David Phillip Oster) writes: >I am not a great amiga expert, but the mac has some definate advantages ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I would have never guessed. >for the programmer in certain areas: > Text handling - when the mac was released, they gave me a one page > pascal program that implemented a mouse based text editor with cut, > copy, and paste. I sincerely doubt you could do as much on the amiga as > concisely. Agreed. > Sound - recently net.micro.amiga had a note from R.J.Micah, one of the > designers of the Amiga's software, giving three pages of C code to do > what a mac programmer does as "SysBeep(1)" Most amiga programmers use > the equivalent of MacInTalk to make their machine say "Beep" because it > is too hard to get a tone out of it. Try and get 4 voice stereo sound out of a Mac, in N pages of code! Then worry about stopping everything to produce the sound -- the Amiga does the waveform table in hardware in the background. > Debugging - for $25 you can get an Apple software supplement that > includes the debugger MacsBug. MacsBug remains in memory application > after application, can dissasemble any code, can give a symbolic trace > of the calling tree, knows the name of each operating system call, and, > with its ES command, lets you exit back to the Mac's shell from a > crashed application. It is not even the best debugger for the Mac. > Nothing even as good as it exists for the Amiga. Most amiga programmers > have to reboot their whole machine if even one task crashes. MacsBug doesn't use windows and has nowhere near the power of Metascope for the Amiga. And it doesn't have to deal with a multitasking machine. > Resources - The Mac has a what-you-see-is-what-you-get editor called > the resource editor that allows you to change menus, fonts, icons, and > every detail of alerts and dialogs (requestors on the Amiga) without > ever recompiling. An amiga programmer must laborously speel out these > things in C code that does not look at all like the finished product. Fonts and Icons have editors available from the operating system. Sure, you can change a Mac program's resources without recompiling, but for the most part only cosmetic changes. Try swapping the first two entries of a menu without recompiling. Besides, there is nothing to keep you from doing the same thing on the Amiga -- just that the O/S doesn't provide tools to do it. > Fast dynamic linking, the Mac's control definition procedures, menu > definition procedures, window definition procedures, and packages allow > programmers to substantially change the behavior of compiled code > without recompiling it. I myself have taken Apple's finder, pasted a > new window definition procedure into it using the resource editor, and > made all the windows apple shaped. Apple replaced the standard file > interface recently, and all the old programs suddenly became able to > cope with a hierarchical directory structure, something no other > machine has done without requiring all the software developers to come > out with new releases of their programs. (Unix recently when through a > change in its directory structure, and everybody had to recompile.) The > standard amiga linker is so slow it is known as "Deep Thought" I haven't worked on a Mac since the new finder was released, so I don't know about this one. The linker is slow, but the Mac was no speed demon, either. > High level printing - Since mac applications comminucate with printers > as if they accepted high level graphics calls, most applications did not > need to be recompiled to accept laser printers, even though the > applications had not been designed with laser printers in mind. Amiga > applications have to have special code for each kind of printer. Wrong! The Amiga has a printer independent control character set. That is why all you have to do is select which printer you have in Preferences and all of the programs use it. (They can talk directly to the device if they want to with no control code translation). Since the Mac treats the printer like it is a big bit-mapped screen, it is difficult to do anything that can't easily be represented on a fixed page size. > safety - the amiga crashes if you draw a line that extends outside the > screen. (According to a friend who regularly crashes his amiga this > way.) The mac graphics system calls, although they aren't very safe, > are safer than this! I haven't had any exprience with that problem. I do know that supplying really wierd parameters to some of the gadget routines will crash the system. > Disk Operating system interface - The mac's operating system takes a Pascal > view of the world. this is not great for a C programmer, but most Mac > compilers have a pascal keyword that handles the details. The system > itself is pretty decent. The Amiga's operating system is written in > BCPL. BCPL is a ancient British language that was directly responsible > for the birth of C. The designers of C started out in BCPL and > concluded that it was not possible to make a BCPL compiler that > generated decent code for a byte addressable machine. Gee, last time I checked the 68000 can only access words on a word boundary. If you are started to compare the technical merits of the two operating systems, look out. The Mac has some very tight code in its operating system that does a lot of nice things, but it does it by putting a lot of the work on the programmer. Anytime the O/S requires me to call a function "as often as possible" so that desk accessories can run, its time to get a real O/S. The Amiga's operating system is multitasking from the ground up, with message passing and event waiting. On the Mac I would have to continually check to see if something was selected. Think of what that wasted CPU time could be used for. In the Amiga, I can set up event handlers which will be invoked only when there is something for them to do. This lets other programs use the time which is wasted on the Mac. > programming environments - LightSpeed C, with its integrated > compiling, linking, multi-window editor, make, grep, and profiling > is so good and so fast, that I've known users of 8MegaByte, 16MegaHertz, > Sun3 68020 systems to prefer to develop on the mac and port their code > to the sun, because the 1MegaByte 8MegaHertz 68000 mac has a faster > edit, compile test cycle. I never used LightSpeed C, but I would be VERY surprised people using a Mac over a Sun3 (unless there are 50 users on the Sun :-). The Mac has got to have the slowest disk drives available on any computer besides the C64. I like my development environment on the Amiga running a custom version of emacs with the Lattice compiler. Granted, the compiler could produce better code and the linker could be faster, but it's pretty good anyway. >Conclusion - both machines have their strengths and weaknesses as >programming machines. I would probably choose an amiga if I were going to >write "Pong". I would certainly choose the mac if I were doing anything >involving fonted text manipulation or object oriented graphics. Although >the hardware of the Amiga should be faster than a Macintosh, the superior >software of the Mac consistantly makes it easier to use, faster, and more >powerful at the kinds of tasks that I like to do. I guess everyone is entitled to their opinion. I will stick to my Amiga, even though I am not writing Pong. Having the ability to run multiple programs far outweighs what little advantage the Mac has in rendering text. Also, I noticed you don't mention the Amiga's custom hardware. Even if you aren't writing games, the hardware can be very useful. The public domain life program on the fish disks uses the blitter for calculating the next generation and gets an incredible 19.8 generations/sec for about 32k cells. Clearing an area of memory (I bet you don't do that, since you aren't writing Pong) is a nice way to speed up your programs using the blitter. John Tamplin Blount Brothers Corporation akgua!blnt1!jat 2511 Fairlane Drive 205/244-6231 Montgomery, AL 36116
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/18/86)
> What are you talking about? > > -Matt HE REPLIES: > Jim Budler X X > >Try the command `size /bin/*sh' sometime. This will display something like: >text data bss dec hex >65536 2048 19836 87420 1557c /bin/csh >18432 3072 16844 38348 95cc /bin/sh >The command `ls -l /bin/sh' gives: >-rwxr-xr-x 1 root 68608 Jul 10 1983 /bin/csh >-rwxr-xr-x 1 root 22528 Jul 10 1983 /bin/sh > >As you'll note, text + data is approx. file size. >bss is `buffered storage space'. This is preallocated space. The program >will take a minimum of text + data + bss memory to run (although paging >on a vmunix system can allow programs totaling more than physical >memory, echh!) > >My point is that Unix systems store the file with one directory entry, >then within an application, the first portion of the file ( the a.out >header) defines where the text and data portions begin. On a mac >there are two directory entries, one for the data fork, one for the >resource fork. Foolish person, that is simply the executable format that someone made up. Object files have the same sort of format. Fonts have different formats. Some backup programs use a vitual hierarchy format. That has nothing to do with the MAC's filesystem. Try applying my last example to the MAC's file format (NOT directory structure... single-file format). You can't. Unix Files are exactly ONE contiguous stream, period. Certainly the executable format is similar, in a remote way, to the macs file format, but the difference is that you are BOUND by the mac's file format for the entire system, not just the executable. -Matt
daveh@cbmvax.cbm.UUCP (Dave Haynie) (09/19/86)
> 2) The AMIGA has special graphics processing chips as well as custom voice > synthesis and 4 voice circuits requiring very little processor time to use. It > even comes out of the machine in STEREO (yes, right and left RCA jacks!). There > is no doubt that this allows the machine to do more. The graphics and voice > stuff is offloaded from the 68000. But...Even with all its sophisticated H/W, > I think the Mac Studio Session sounds better than the Amiga stuff (I used > Instant Music for Amiga). I think the MAC uses 8 bit D-A coversion for its sound, too. The sound quality depends alot on the program, since at least on the Amiga a programmer can greatly vary the sampling rate. The Amiga's advantage in this area is four D-As to the MACs one, and the fact that a sound waveform is fetched by the custom chips and played automatically, without processor intervention. However, to create better sounds, the processor will have to work harder than just sitting there. The Amiga is CAPABLE of sounding better; whether it does or not depends alot on the software. And make sure you hook it up to a real stereo; the monitor speaker is lousy. > 6) Mac disk drives are faster than the Amiga, I do not know why this is. The > Amiga disks use a DMA xfer technique, so they should be faster. I've never timed a MAC drive, but I'd expect the Amiga to LOAD or SAVE a program faster than the MAC (floppies, right?). But the AmigaDOS file structure is very bad for anything like directory searching or wildcard matching, as the file names aren't included in the directory headers, but in the file headers. This is the same reason that specific file access is very fast; the directory headers on disk contain hash tables that find the files very quickly. I don't know the internals of the MAC file structure, but its gotta be faster than this. > I hope this capsule comparision can help with any questions you might have. > > Phil Hunt > ..calma!sivax!phil > (408)942-1212 > running (A DOS window -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh "I gained nothing at all from Supreme Enlightenment, and for that very reason it is called Supreme Enlightenment." -Gotama Buddha These opinions are my own, though for a small fee they be yours too. \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
lsr@apple.UUCP (Larry Rosenstein) (09/19/86)
In article <741@cbmvax.cbmvax.cbm.UUCP> daveh@cbmvax.cbm.UUCP (Dave Haynie) wri es: >The Amiga has a Font Editor and an Icon editor shipped with it (the Font >Editor is officially new for release 1.2). I've got a public domain >Menu editor which lets me define menus, graphically, then produce C code to >create them. And a full featured gadget editor is just around the corner >(can you edit MAC gadgets as easily as all the other stuff?). For the most part, yes. The Resource Editor has graphical icon, font, and dialog editors. Plus you can write custom graphical editors and plug them into the Resource Editor. There are also public domain editors for menus, etc. A significant point about these editors and resources in general is that resources can be plugged into an application or document without recompiling. You can plug new editors into the Resource Editor framework and start editing new kinds of data structures. You can change the command key equivalents for menus. You can change the keyboard mapping in MacTerminal. >... >FALSE, LIES, UNTRUE! For each different style of printer, there is a >configuration file, run by the printer device, that translates all printer >specific functions into generic Amiga functions. This is more powerful >that the MAC's printer interface. The Amiga can support any printer via >any I/O port in a program transparent fashion. This includes graphic >dumps (which may be scaled in various ways) as well as a generic text >interface that the MAC doesn't have. I can switch from Epson printer to >HP Laserjet or Apple ImageWriter just by selecting the printer option >through the Amiga's Preferences program. How many type of printers will >the MAC support, anyway (other than Apple, of course). This was one of the mistakes in the original BYTE article. The Macintosh Print Manager supports printers in a device independent way, via printer resource files. You can also stream text and bitmaps to printers. Is is true that Apple itself does not support anything other than its own printers, but 3rd parties have developed alternate printer drivers for the Mac and Apple does license the source code of the ImageWriter driver to developers. >... >The Amiga's disk interface is far faster than the MAC's. >... >With >a few minor exceptions (circle/ellipse drawing, I believe), BYTE found the >Amiga to be consistantly faster than the MAC, in graphics, disk, sound, etc. I think if you go back a couple of months in BYTE you will find Bruce Webster's column comparing the Mac, Amiga, and Atari ST in a few informal benchmarks. I seem to recall that the Macintosh disks were faster than either the Amiga's or Atari's and that the Amiga graphics were faster for things that could be done in hardware (lines or rectangles) but that other things (such as text) were slower. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.CSNET
jimm@amiga.UUCP (James D. Mackraz) (09/20/86)
In article <193@zen.BERKELEY.EDU> c160-aw@zooey.Berkeley.EDU.UUCP (Christian Wiedmann) writes: >My opinion in this already belabored subject is that the key issue is not >the interface to the programmer, but the interface to the user. Both the >Amiga and the Mac support a mouse and windowing. What the Amiga lacks is >a clearly defined User Interface. When I sit down with a Mac program, I >expect to be able to use it without reading the manual. From what I've seen >and heard about Amiga software, this is less true for the Amiga. The reason >the Mac is hard to program is because of all the requirements made by Apple. >There is no question, though, that the Amiga hardware is better than the >Mac's. Now if only Commodore were Apple... > > -Christian > >These views are the definitive views of this Universe. If an application ascribes to the suggested guidelines (e.g., Project and Edit menus, and so on) for standard Amiga user-interfaces, a simple application (or simple functions of a complicated application) can be operated by an untrained user. What a system designer has to avoid, while providing this commonality, is a "user-interface funnel," through which all applications have to operate the same. On the Amiga, there are, for example, system standard dialog boxes (yes/no) called AutoRequests. They operated identically, and when they were enhanced in the system to respond to keystrokes, all programs using them benefited. But you can get in at a much lower level than that and do much more with the concept. Likewise, you needn't handle window sizing as simple as the Byte article describes. There are other examples where Intuition provides simple, standard methods as the default (menu operations) but provides great flexibility, at the discretion of the programmer. Try out the controls to the public-domain Triclops Invasion, or use the "fast menu" of Aegis Images or Animator, and see how one can slightly enhance the interaction suitable to the application, or toss it out completely and do things that no Amiga (or Mac) designer had dreamed of. It seems more and more that mac-lovers flaming the amiga have heard more than they have seen, or perhaps never written a desk accessory and had to live with bs quasi-tasking and a single threaded dos. There is more to application programmer power than windows and scroll bars. Try it, you'll like it. jimm
jimb@amdcad.UUCP (Jim Budler) (09/23/86)
In article <8609182058.AA24864@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: +--------------- | Foolish person, that is simply the executable format that someone | made up. Object files have the same sort of format. Fonts have different | formats. Some backup programs use a vitual hierarchy format. That has | nothing to do with the MAC's filesystem. Try applying my last example to | the MAC's file format (NOT directory structure... single-file format). You | can't. Unix Files are exactly ONE contiguous stream, period. Certainly the | executable format is similar, in a remote way, to the macs file format, but | the difference is that you are BOUND by the mac's file format for the entire | system, not just the executable. +--------------- Name calling yet. My article did state that the file stucture under Unix appeared as a contiguous bytes. I consider that a limitation, and said so. As I said, a programmer can program entirely in CODE resources, so that no other resources are used. If I can emulate the Unix stdio library, and Unix applications on a Mac by ignoring the dual nature of the file system, except for one bit in my file open calls, how can it be that I am limited by the Mac's file structure? I can have shell interface, place all my data in a contiguous stream in a file, and access my applications internals as contiguous bytes if I chose to. +--------------- | made up. Object files have the same sort of format. +--------------- Yes. Exactly the same. The difference between an executable and an object file is the contents, not the structure. I hope you don't think that a Unix file is all physically contiguous. I was attempting to refute the argument previously stated by someone that the Unix file structure was more normal. The file structures differ only in having two directory entries, pointing to two different starting locations. The *directory* structures differ considerably, but I was trying to point out, provide much similar information. I chose the executable because it is a common file type (not structure) roughly comparable to the macintosh. I could have chosen any pure data file on either, and pointed out their similarities also. They differ only in that the Macintosh pure data file has an extra *entry* in the directory for the resource fork. It may be empty and may be ignored. That data file can be accessed in exactly the same way as an Unix data file, namely fopen(), fget(), fput(), lseek(), fread(), fwrite(). A common programming trick on the mac is to put data in the data fork of an application. This would be like placing /usr/lib/dict/words inside spell(1) on Unix. On unix this cannot be done unless you consider all the data in /usr/lib/dict/words to be static. The program spell would not have to be rewritten for the Mac (except legally) except for the change of the pathname from /usr/lib/dict/words to the program name itself (assuming I'm operating under a shell with in/out redirection). How can something like this be considered a limitation? It enables me to do something that cannot be done under Unix. I could do it the same way as Unix, namely place words in a seperate file in a known location, but then when I copy spell to another disk, I have to copy both of the files. Barring the obvious: multitaking, memory requirements, there are few tasks which can be written for Unix, that cannot be ported as Unix style tasks to the Mac. If you ignore the resource structure of the Mac, do not use multiple fonts, do not use bit mapped graphics (that isn't Unix anyway), treat the tty port as an ascii device driver, treat the printer and modem ports as ascii device drivers, use the default window size the compiler provides, you will get very unixlike applications which will perform like tasks. This, as I said in the other article, is the programmer's CHOICE. It has nothing to do with the file structure. -- Jim Budler X X Advanced Micro Devices, Inc. X X (408) 749-5806 X Usenet: {ucbvax,decwrl,ihnp4}!amdcad!jimb X X Compuserve: 72415,1200 X X Signature, what signature? I'll make my mark!!
daveh@cbmvax.cbm.UUCP (Dave Haynie) (09/23/86)
> A significant point about these editors and resources in general is that > resources can be plugged into an application or document without > recompiling. You can plug new editors into the Resource Editor framework > and start editing new kinds of data structures. You can change the command > key equivalents for menus. You can change the keyboard mapping in > MacTerminal. That's a good feature; its more difficult to change some things on the Amiga, like menus, etc., after compiling. There's nothing that does that automatically, yet. Of course, I can change the keymaps from the CLI via the SetMap command; we have several US maps, including Dvoark, along with various European maps, with support for dead keys. The mapping is done automatically from any open console, and that includes ANSI style output to support more than the normal 256 logical keys. Or I can instead pass raw key codes to the key mapping function, allowing my program to intercept key combinations that wouldn't otherwise appear in a key map. > Larry Rosenstein > > Object Specialist > Apple Computer > > AppleLink: Rosenstein1 > UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr > CSNET: lsr@Apple.CSNET -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh "I gained nothing at all from Supreme Enlightenment, and for that very reason it is called Supreme Enlightenment." -Gotama Buddha These opinions are my own, though for a small fee they be yours too. \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
cc1@locus.ucla.edu (Michael Gersten) (09/24/86)
:> the resource editor that allows you to change menus, fonts, icons, and :> every detail of alerts and dialogs (requestors on the Amiga) without :> ever recompiling. >The Amiga has a Font Editor and an Icon editor shipped with it ... >Menu editor which lets me define menus, graphically, then produce C code to >create them. You missed a point of the original. The mac can do all that without recompiling. You cannot change topaz fonts (not under 1.1, anyways). You cannot change the requesters themselves automatically at all. Also, I don't know about Lettice, but Manx has a m.lib math library that is compiled in; changing it to use the 68881 would mean re-compiling, not just changing mathieee.library Michael Gersten Views expressed here may not be those of the Computer Club, UCLA, or anyone in their left OR right mind. And that's the name o' that tune.
bezanson@gumby.WISC.EDU (Brian Bezanson) (09/24/86)
>> I am not a great amiga expert, >Obviously... Obviously you have never used a Mac... >> Resources - The Mac has a what-you-see-is-what-you-get editor called >> the resource editor that allows you to change menus, fonts, icons, and >> every detail of alerts and dialogs (requestors on the Amiga) without >> ever recompiling. An amiga programmer must laborously speel out these >> things in C code that does not look at all like the finished product. >The Amiga has a Font Editor and an Icon editor shipped with it (the Font >Editor is officially new for release 1.2). I've got a public domain >Menu editor which lets me define menus, graphically, then produce C code to >create them. And a full featured gadget editor is just around the corner >(can you edit MAC gadgets as easily as all the other stuff?). You missed the point here, you can graphically edit ALL the Macs resources (windows, dialogs, menus, icons, strings, etc...) without having to change any of the original programs code or need for any recompiling. If I want to change/modify a Mac Menu, all I have to do is use a resource editor. You have to recompile with the new code AND ORIGINAL SOURCE [Flame On: No wonder you need Multitasking, you have to do many things to make one change: Flame off] >> Disk Operating system interface - The mac's operating system takes a Pascal >> view of the world. this is not great for a C programmer, but most Mac >> compilers have a pascal keyword that handles the details. The system >> itself is pretty decent. The Amiga's operating system is written in >> BCPL [etc.] >The Amiga's disk interface is far faster than the MAC's. That should say it >all. There's very little in the DOS that requires byte boundary access anyway. WRONG!!! Though the Amiga may be faster from a hardware DESIGN point, in practical use, I could always go to sleep waiting for it to read in a disk, and I could watch ROOTS in the time it took to open up it's 'folders'. The Amiga OS, at least from Intuition/Finder Section was defintely slower than on the Mac 512E or Plus. >> ... Although >> the hardware of the Amiga should be faster than a Macintosh, the superior >> software of the Mac consistantly makes it easier to use, faster, and more >> powerful at the kinds of tasks that I like to do. >Can't comment on ease of use, that's a personal preference, though I like the >option of not having to use a mouse all the time, only when I want to. With >a few minor exceptions (circle/ellipse drawing, I believe), BYTE found the >Amiga to be consistantly faster than the MAC, in graphics, disk, sound, etc. >I like to do my tasks a few at a time, thank you. The Mac is far easier to use, because Apple created a standard interface that 99% of all Mac programs follow. You can use nearly any mac program, to some basic extent, without ever having read the documentation. I hate the 2 button mouse on the Amiga. One minute you use the right button to open a window, the next you have to use another button. It has less functionality than the Mac Mouse. The Amiga is a great piece of hardware, but it was brought out by an ailing firm that is still on the edges of financial disaster, and the Amiga is not helping Commodore out a lot. The Atari ST for it's price and software has the Amiga beat out, and the Mac edges out the Atari in the higher end market. The Amiga has probably seen it's last days as a viable computer, due to price drops in Atari and Apple lines, and the introduction of Apples //GS. Time is a telling factor. Let's have a net re-union next year and see if the Amiga is still sold by Commodore (or anyone else). Commodores low-end market is falling to the big boys. Brian Bezanson bezanson@gumby.wisc.edu ----------------------------- 'Here today, gone tomorrow...' ----------------------------- -- Brian Bezanson {seismo,ihnp4,allegra,topaz,harvard}!uwvax!puff!bezanson Manta Software Corp. " " " " " !gumby!bezanson bezanson@gumby.wisc.edu bezanson@puff.wisc.edu
tecot@apple.UUCP (Ed Tecot) (09/24/86)
In article <1896@utecfa.UUCP> edusoft@utecfa.UUCP (Educational Software) writes: > >Christian Wiedmann muses: >> Now if only Commodore were Apple... > >If Commodore were Apple, then they would have given us great software on >an overloaded processor (with no multi-tasking). > >I guess though, that if Commodore were Apple, then Apple would be IBM, >but the big question is ... who would IBM be ? :-) > AT&T! Of course, now you may ask: who would AT&T be? RAMJAC, of course! _emt ________ All my opinions have been distorted by a chocolate chip cookie high.
chiu@princeton.UUCP (Kenneth Chiu) (09/24/86)
In article <397@gumby.WISC.EDU> bezanson@gumby.WISC.EDU (Brian Bezanson) writes: >You missed the point here, you can graphically edit ALL the Macs resources >(windows, dialogs, menus, icons, strings, etc...) without having to change >any of the original programs code or need for any recompiling. If I want to >change/modify a Mac Menu, all I have to do is use a resource editor. You >have to recompile with the new code AND ORIGINAL SOURCE Why is this necessarily a good thing? I'm sure it makes the system routines more complex, and it seems that the only changes you can make to a program's menus, etc., without recompiling are only cosmetic. For example, can you add a new menu item to a terminal emulator that turns handshaking on/off without recompiling? >The Mac is far easier to use, because Apple created a standard interface that >99% of all Mac programs follow. You can use nearly any mac program, to some >basic extent, without ever having read the documentation. There is a trade-off here between having all programs use the same interface, and having more flexibility. Perhaps Apple leaned toward the standardization side, and perhaps Commodore leaned toward the flexibility side. Regardless, the issue is endlessly debatable, and certainly not so simple. >I hate the 2 button >mouse on the Amiga. One minute you use the right button to open a window, the >next you have to use another button. It has less functionality than the Mac >Mouse. Have you ever used a Xerox Star, a Sun, or an Apollo? Deciding how many buttons to put on a mouse is another design issue that involves compromise, and no one choice is obviously better. If you have only few buttons, you are limited to what actions can be initiated with only a button press. This means that you must necessarily have more mouse activity to perform a given action. If you have many buttons, it can be difficult to remember what button does what. BTW, the right button is almost universal for pulling down, or popping up a menu, and the left button is almost universal for making some kind of selection. >Time is a telling factor. Let's have a net re-union next year and see if >the Amiga is still sold by Commodore (or anyone else). Commodores low-end >market is falling to the big boys. Taking any bets? :-) I have not done any programming on the Mac, so I have refrained from making any specific comments about Amiga vs. Mac. I believe that such discussions can be useful and informative, but not if you are going to just say the Amiga is better because of blah, blah, blah, or the Mac is better because blah, blah, blah. The people who designed these things are not stupid, they certainly must have had a lot of considerations in mind. -- Kenneth Chiu UUCP: princeton!chiu Princeton University Computer Science Department BITNET: 6031801@PUCC
mdw@cec2.UUCP (09/24/86)
In article <1896@utecfa.UUCP>, edusoft@utecfa.UUCP (Educational Software) writes: > > Christian Wiedmann muses: > > Now if only Commodore were Apple... > I guess though, that if Commodore were Apple, then Apple would be IBM, > but the big question is ... who would IBM be ? :-) > IBM would have to be shifted up to HAL... 'open the pod doors Hal...' 'I'm sorry David but we can't allow the competition' I have no connection with IBM, APPLE, or A.C. Clarke so there
dwb@well.UUCP (David W. Berry) (09/25/86)
In article <172@apple.UUCP> lsr@apple.UUCP (Larry Rosenstein) writes: >I think if you go back a couple of months in BYTE you will find Bruce >Webster's column comparing the Mac, Amiga, and Atari ST in a few informal >benchmarks. I seem to recall that the Macintosh disks were faster than >either the Amiga's or Atari's and that the Amiga graphics were faster for >things that could be done in hardware (lines or rectangles) but that other >things (such as text) were slower. Or must be done by hand, as is the case with rounded rectangles, ellipses, arcs, or polylines... all things which the Mac ROM's handle, but the Amiga user must figure out for himself. To me it seems relatively clear that this discussion has degenerated from a technically informative one into a religious war. No offense, Larry, you were getting the thing back onto technical footing, the general drift has just been downward. From all indications I would have to say that both machines have their advantages, both from a user and a programmer standpoint. Each machine has features built into it's primitives that are advantageous and those that are badly misimplemented or not implemented at all. Apple certainly should have done something more about multi-tasking. Amiga should have more Graphics primitives. Apple seems to have thought out the process of internationalization and customization much more thoroughly than Amiga did. Resources can be used to drastically change the appearance of an application without needing to recompile the program or take a debugger to it. At one time their was a set of resources floating around which would give an application apple shaped windows. Could the Amiga do that without patching the operating system? Amiga has come up with what seems to be a cleaner interface for the programmer to use, primarily because there is much less to learn to use it. In short, both machines have their advantages and disadvantages and further presentation of fact and misfact and arguments til we're blue in the face aren't really going to change anybody's minds. I still think the Mac is a great machine and would rather be developing software for it than for the Amiga. I have good friends that feel the same way about the Amiga. I respect that. In the future can we move the discussion from one of "My machine can do this and yours can't. So there. Nyah, Nyah, Nyah." To a more constructive one of "Hey, I really like this about the my machine. How can I do it on yours too? Flames to /dev/nsa, they need all the mail they can get... David W. Berry (701 Menker Ave, #1 ; San Jose, CA. 95128-2876).USNail dwb@well.uucp dwb@Delphi dwb@GEnie 293-0752@408.MaBell -- David W. Berry dwb@well.uucp dwb@Delphi dwb@GEnie 293-0752@408.MaBell
daveh@cbmvax.cbm.UUCP (Dave Haynie) (09/25/86)
> Xref: cbmvax net.micro.mac:2815 net.micro.amiga:2714 > You missed a point of the original. The mac can do all that without > recompiling. You cannot change topaz fonts (not under 1.1, anyways). > You cannot change the requesters themselves automatically at all. Only the Amiga Menu Editor (producing C code) requires it output to be compiled; everything else happens at any time. The Topaz fonts in 1.1 and 1.2 are "ROM" fonts, so you can't of course change them. But you can load a ROM font into FontEd and save it as a disk font. > Also, I don't know about Lettice, but Manx has a m.lib math library that > is compiled in; changing it to use the 68881 would mean re-compiling, > not just changing mathieee.library I'm not sure about Manx, but I imagine that the m.lib is merely a shell into which the math library routines are moved. The idea being that I want C convention mathematic calls, not Amiga convention, so that I get portability. Of course, any language can open the math libraries directly and get most of their benefits (these math libs contain a large variety of floating point routines, including routines that a language can use for its intrinsic *, /, +, -, ^, etc. operators. If your language doesn't support these, blame the language implementors, not the Amiga, when you add your 68881). > Michael Gersten > Views expressed here may not be those of the Computer Club, UCLA, or > anyone in their left OR right mind. And that's the name o' that tune. -- ============================================================================ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh These opinions are my own, though if you try them out, and decide that you really like them, a small donation would be appreciated.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/26/86)
>> > Now if only Commodore were Apple... >> I guess though, that if Commodore were Apple, then Apple would be IBM, >> but the big question is ... who would IBM be ? :-) >> >IBM would have to be shifted up to HAL... I - 1 = H B - 1 = A M - 1 = L Hmm.. looks like subtract one rather than shift up. (couldn't resist) -Matt
bezanson@gumby.WISC.EDU (Brian Bezanson) (09/27/86)
In article <1666@princeton.UUCP>, chiu@princeton.UUCP (Kenneth Chiu) writes: > >You missed the point here, you can graphically edit ALL the Macs resources > >(windows, dialogs, menus, icons, strings, etc...) without having to change > >any of the original programs code or need for any recompiling. If I want to > >change/modify a Mac Menu, all I have to do is use a resource editor. You > >have to recompile with the new code AND ORIGINAL SOURCE > > Why is this necessarily a good thing? I'm sure it makes the system routines more > complex, and it seems that the only changes you can make to a program's menus, etc., > without recompiling are only cosmetic. For example, can you add a new menu item > to a terminal emulator that turns handshaking on/off without recompiling? No, you can't add menu items (because the program can't respond to them because it doesn't know what they mean, in this case recompiling would be needed). What editing the resources are good for are: 1) Adding command-keys (Control characters) to menu items to save time, 2) Changing the wording of menus or strings to other languages or to suit your own personal needs, and 3) modifying window size, cinfiguration, etc... the resources can be edited in any way the user sees fit. Also, there are LAYOout resources that programmers can use to let you customize how the program handles certain actions (the finder allows you to grid icons for neater movement, turn off the warning system for discarding files, and more.) In summation, the beauty of Mac resources are that the user can modify the look and feel to suit his/her needs and if the programmer allows, LAYOut resources can be used to customize the program. -- Brian Bezanson {seismo,ihnp4,allegra,topaz,harvard}!uwvax!gumby!bezanson Manta Software Corp. bezanson@gumby.wisc.edu
elg@usl.UUCP (Eric Lee Green) (10/03/86)
In article <397@gumby.WISC.EDU> bezanson@gumby.WISC.EDU (Brian Bezanson) writes: > >>> Resources - The Mac has a what-you-see-is-what-you-get editor called >>The Amiga has a Font Editor and an Icon editor shipped with it (the Font >>Editor is officially new for release 1.2). I've got a public domain >>Menu editor which lets me define menus, graphically, then produce C code to >>create them. And a full featured gadget editor is just around the corner >>(can you edit MAC gadgets as easily as all the other stuff?). >You missed the point here, you can graphically edit ALL the Macs resources >(windows, dialogs, menus, icons, strings, etc...) without having to change >any of the original programs code or need for any recompiling. Well whoopeedo to you, too, Mr. Computer Bigot. Just what we need, another flaming Mactribesman cluttering up the net with his diatribes about how his computer is better than every other computer in the world (to hear some of the Mactribesmen speak, their Mac is better than a Sun!). Frankly, who gives a #$%@#$% about whether you have to recompile your code after changing the gadgets? Doesn't exactly sound earth-shattering to me... >WRONG!!! Though the Amiga may be faster from a hardware DESIGN point, in >practical use, I could always go to sleep waiting for it to read in a disk, and >I could watch ROOTS in the time it took to open up it's 'folders'. The Amiga >OS, at least from Intuition/Finder Section was defintely slower than on the >Mac 512E or Plus. Oh so true. Intuition has some definite problems with speed in that area, mainly because it is sitting on top of a real operating system. The Mac stores disk directory entries with both their corresponding icons, and the filenames/locations/etc. Tripos/Amigados doesn't, since if you are operating in the CLI environment, there are no associated icons. The Amiga has to go looking for ".info" files due to the implementation chosen (I personally think they should have stored all the icons in a single ".info" file in each directory, instead of having to go chasing around looking for them). >>> ... Although >>> the hardware of the Amiga should be faster than a Macintosh, the superior >>> software of the Mac consistantly makes it easier to use, faster, and more >>> powerful at the kinds of tasks that I like to do. You must not be very demanding! I do alot of programming. One thing I like to do on Unix is to call up a shell window in GNU Emacs, compile my program, run it, and as the errors pop up, edit my program and do it all over again. I also suspend the editor alot to pull up dc or go brouse thru /usr/src/local looking for likely solutions, etc. I can see where, if you just use your Mac as a terminal or a word processor, you could prefer the Mac to an Amiga (that tiny monitor shure has nice looking characters!)... but while I can use my preferred work style on both Unix and the Amiga, I wouldn't be able to use it on the Mac due to the lack of multitasking. Programming the Mac sounds an aweful lot like programming my C-64 -- I HATE single-tasking computers, they're so awefully limited. >The Mac is far easier to use, because Apple created a standard interface that >99% of all Mac programs follow. You can use nearly any mac program, to some >basic extent, without ever having read the documentation. I hate the 2 button >mouse on the Amiga. One minute you use the right button to open a window, the >next you have to use another button. It has less functionality than the Mac >Mouse. Obviously, you've never used an Amiga. The right button is used ONLY pull down menus, in all the Amiga software that I have used, and the left button is used ONLY to move windows around, tweak gadgets, etc. >The Amiga is a great piece of hardware, but it was brought out by an ailing >firm that is still on the edges of financial disaster, and the Amiga is not >helping Commodore out a lot. The Atari ST for it's price and software has the >Amiga beat out, and the Mac edges out the Atari in the higher end market. >The Amiga has probably seen it's last days as a viable computer, due to price >drops in Atari and Apple lines, and the introduction of Apples //GS. > >Time is a telling factor. Let's have a net re-union next year and see if >the Amiga is still sold by Commodore (or anyone else). Commodores low-end >market is falling to the big boys. > >Brian Bezanson bezanson@gumby.wisc.edu Talk about your LIES!!!! The Amiga is right now reaching the point of takeoff. Within the last month, several pieces of hardware have been release for a suitable price that make the Amiga competitive with any computer on the market today. For example, if I had an Amiga (just lusting after one, thank you), I could add 4 megabytes of RAM to it for under $1200... try that with your Mac! See ya, Mr. Computer Bigot! By the way, I think the Mac Plus is a nice machine... the Computing Center here has several Macs used by the secretaries (the techies generally have PC-Drones or other such machines, since they enjoy playing with soldering irons and you need a hacksaw to open a Mac). -- Eric Green {akgua,ut-sally}!usl!elg (Snail Mail P.O. Box 92191, Lafayette, LA 70509) " In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move."
zrm@mit-eddie.MIT.EDU (Zigurd R. Mednieks) (10/04/86)
There are a few key points the discussion of Mac programming vs. Amiga programming has missed. Most important, since the discussion hinges on the Byte article by an implementor of True Basic, is that his main gripe is rooted in the job he had to do, not the Mac. He had to port a system designed to be "portable" to an environment that loathes "ported" software. Of course it would be unpleasant! True Basic's goal of making all True Basic implementations the same is in direct conflict with Apple's goal of making all Mac applications behave the same. The Amiga makes far fewer demands on its applications to look alike. As for the Mac being difficult to program, I can say from experience that it is loads easier to bang out a quick program for a Unix machine than a Mac. Since the Amiga is sort of like a Unix system with a window system layered on top, it would be about as easy to program as a Unix system. Unless you need advanced features, you can ignore them. Makes sense. But what do we mean by "easy?" What do we mean by "program?" If we mean something that strips the high bit off every third character in a file, the Amiga wins. If we mean writing something like DBase Mac or More or LightspeedC, I think the Mac wins hands down. It is much EASIER to produce software that is very impressive on the Mac. And that it what sells. But enough talk! What did I actually DO about the fact that the Mac is hard to program? Two things: First, I wrote a book called "C Programming Techniques for the Macintosh" with Terry M. Schilke. Howard W. Sams & Co., Inc. publishes it. Second, I started a consulting firm for those folks without the time to read the book. The book is what I wish I had when I, a real Unix Wizard, was helplessly cussing and flailing through my first Mac program. There are many other good books. Knaster's book should really be called "How to REALLY Write Macintosh Software" since it points out all the pitfalls that snag the first-time effort at bigger applications. His book should take a big load off Apple's developer support people. And what do I actually feel about programming, now that I have done a lot of it on several machines? I don't hack Unix much anymore, unless somebody pulls a big wallet on me. Mac programming is just more fun, more intellectually stimulating, and it produces more gratifying results. Lastly, Apple is doing something about programmer productivity on the Macintosh. MacApp will make the Mac not only the most featureful machine around, but it will also make it the fastest to program for medium to large applications. And it will infuriate people porting software to the Mac, because it will make Mac programming still more "different." I think Apple has stumbled upon something unique in the computer industry with the Macintosh. It has produced a machine with a higher-quality "feel" to it. Programming a Mac is like working with really good tools, or playing a really good instrument. You have the confidence that the people who wrote the underlying software are at least your intellectual peers and, in many cases, have something to teach you about computer systems. There are few other machines that seem to win this kind of respect from programmers, and most other micros don't even come close. Well now that I have made everybody without a Mac or some avant garde Lisp or Smalltalk workstation feel inadequate, flame off. -Zigurd
wetter@tybalt.caltech.edu.Caltech.Edu (Pierce T. Wetter) (10/05/86)
>Well whoopeedo to you, too, Mr. Computer Bigot. Just what we need, >another flaming Mactribesman cluttering up the net with his diatribes >about how his computer is better than every other computer in the >world (to hear some of the Mactribesmen speak, their Mac is better Oh great now all we need is another Amigatribesman cluttering up the net with his diatrabes about how his postings are better than every other then all ther other postings... signal/noise ratio = - infinity Pierce Wetter
davec@mhuxl.UUCP (Dave Caswell) (10/06/86)
> world (to hear some of the Mactribesmen speak, their Mac is better > than a Sun!). Frankly, who gives a #$%@#$% about whether you have to > recompile your code after changing the gadgets? Doesn't exactly sound > earth-shattering to me... > > Eric Green {akgua,ut-sally}!usl!elg > (Snail Mail P.O. Box 92191, Lafayette, LA 70509) > Well, I for one give a "#$%@#$%". With modifiable resources I can significantly modify the behaviour of programs that I don't have source code for. The LAYO resource in the Finder comes to mind. I figure resources are one of the niftyer ideas that the mac folks came up with. Dave Caswell {allegra|ihnp4|...}!mhuxl!davec It is only with the heart that one sees rightly, what is essential is invisible to the eye. Antoine de Saint-Exupery
B5U@PSUVMB.BITNET (10/07/86)
In article <954@usl.UUCP>, elg@usl.UUCP (Eric Lee Green) says: >You must not be very demanding! I do alot of programming. One thing I >like to do on Unix is to call up a shell window in GNU Emacs, compile >my program, run it, and as the errors pop up, edit my program and do >it all over again. I also suspend the editor alot to pull up dc or go >brouse thru /usr/src/local looking for likely solutions, etc. I can >see where, if you just use your Mac as a terminal or a word processor, >you could prefer the Mac to an Amiga (that tiny monitor shure has nice >looking characters!)... but while I can use my preferred work style on >both Unix and the Amiga, I wouldn't be able to use it on the Mac due >to the lack of multitasking. Programming the Mac sounds an aweful lot >like programming my C-64 -- I HATE single-tasking computers, they're >so awefully limited. > > >Talk about your LIES!!!! The Amiga is right now reaching the point of >takeoff. Within the last month, several pieces of hardware have been >release for a suitable price that make the Amiga competitive with any >computer on the market today. For example, if I had an Amiga (just >lusting after one, thank you), I could add 4 megabytes of RAM to it >for under $1200... try that with your Mac! See ya, Mr. Computer Bigot! > >By the way, I think the Mac Plus is a nice machine... the Computing >Center here has several Macs used by the secretaries (the techies >generally have PC-Drones or other such machines, since they enjoy >playing with soldering irons and you need a hacksaw to open a Mac). >-- > > Eric Green {akgua,ut-sally}!usl!elg > (Snail Mail P.O. Box 92191, Lafayette, LA 70509) > >" In the beginning the Universe was created. This has made a lot of > people very angry and been widely regarded as a bad move." First of all, learn to spell correctly. No one can respect your opinions if your posting looks like crap because of misspelling. Even as an Engineering major, I try to spell correctly. Second, LET'S CAN THIS @#$% & $ DISCUSSION ALREADY ! The relative merits of both machines are high, but the final answer will come down to YOUR OWN OPINION ! Let's try to help people out with this newsgroup instead of filling it up with garbage (this can also be said of the current 80x86 vs. 680x0 discussion). Third, Mr. Green, you are as big a computer bigot as the person you criticized! You are bitching about the Mac's problems even louder than he attacked the Amiga's. Let's just say that they are both excellent machines, and one might be bought over the other, depending on the person and hi
bezanson@gumby.WISC.EDU (Brian Bezanson) (10/08/86)
In article <954@usl.UUCP>, elg@usl.UUCP (Eric Lee Green) writes: > >You missed the point here, you can graphically edit ALL the Macs resources > >(windows, dialogs, menus, icons, strings, etc...) without having to change > >any of the original programs code or need for any recompiling. > > Well whoopeedo to you, too, Mr. Computer Bigot. Just what we need, > another flaming Mactribesman cluttering up the net with his diatribes > about how his computer is better than every other computer in the > world Just what we need, another flaming Amigatribesman cluttering up the net with his diatribes about how his computer is better than any other computer in the world. > (to hear some of the Mactribesmen speak, their Mac is better > than a Sun!). Frankly, who gives a #$%@#$% about whether you have to > recompile your code after changing the gadgets? Doesn't exactly sound > earth-shattering to me... What if you want to modify a commercial program that you don't have the sources to? Tonight, I was looking at some modifications that people have made to the Finder to allow different icon spacing, dating conventions, etc. Try that with Intuition. Also, try to produce a foreign language version of an application without the sources. I think it's a big deal (and obviously you never even considered these advantages). > Oh so true. Intuition has some definite problems with speed in that > area, mainly because it is sitting on top of a real operating system. > The Mac stores disk directory entries with both their corresponding > icons, and the filenames/locations/etc. This is WRONG! The Mac operating system does not store icons/folder locations in the directory entry for that file. Rather, the Finder creates a file called the DeskTop, which contains the icons and their locations, comments, etc...Many people tend to believe that the Finder and the operating system are one and the same. They are not; the Finder is merely an application program. > Tripos/Amigados doesn't, since > if you are operating in the CLI environment, there are no associated > icons. The Amiga has to go looking for ".info" files due to the > implementation chosen (I personally think they should have stored all > the icons in a single ".info" file in each directory, instead of > having to go chasing around looking for them). Amazing. This is more or less what the Mac Finder does. Could Apple have done something right in the eyes of this person? My biggest pet peeve about the Amiga is that it is possible to have applications that have no icon, because there is no .info file. This is very confusing to novices, who, when given a disk that they are told has something on it, get horribly confused when no icons appear. They should have had a default, generic icon. Not everyone uses the CLI, you know. > >>> ... Although > >>> the hardware of the Amiga should be faster than a Macintosh, the superior > >>> software of the Mac consistantly makes it easier to use, faster, and more > >>> powerful at the kinds of tasks that I like to do. **** The below comments you are about to make, are based on the above text, which I did not even type! > You must not be very demanding! I do alot of programming. One thing I > like to do on Unix is to call up a shell window in GNU Emacs, compile > my program, run it, and as the errors pop up, edit my program and do > it all over again. I also suspend the editor alot to pull up dc or go > brouse thru /usr/src/local looking for likely solutions, etc. I can > see where, if you just use your Mac as a terminal or a word processor, > you could prefer the Mac to an Amiga (that tiny monitor shure has nice > looking characters!)... My mac that I am typing this on has a 12" (720x364) screen, it's called a MacXL (Lisa for the diehards). If you want to really see true multitasking, see a Lisa running Lisa 7/7 software, still the best multi-tasking micro to date. > but while I can use my preferred work style on > both Unix and the Amiga, I wouldn't be able to use it on the Mac due > to the lack of multitasking. Programming the Mac sounds an aweful lot > like programming my C-64 -- I HATE single-tasking computers, they're > so awefully limited. I have used multi-tasking in program design on a Burroughs B25, it was nice but there was no super advantage in it. With design systems like Lightspeed C & Pascal, where compile times are less than 10 seconds, I'll be done and in my application before you have switched over to your compiler. The biggest fault in Amiga multitasking (at least on the ones I used at the local amiga dealer), is that they kept on crashing at regular intervals. I'd rather have a one task system that works, than a multitasking that bombs. If you really want nice multi-tasking (and since you have made the jump to the amiga), why not wait and look at the new open mac, it will have what you want and more. > >The Mac is far easier to use, because Apple created a standard interface that > >99% of all Mac programs follow. You can use nearly any mac program, to some > >basic extent, without ever having read the documentation. I hate the 2 button > >mouse on the Amiga. One minute you use the right button to open a window, the > >next you have to use another button. It has less functionality than the Mac > >Mouse. > Obviously, you've never used an Amiga. The right button is used ONLY > pull down menus, in all the Amiga software that I have used, and the > left button is used ONLY to move windows around, tweak gadgets, etc. Yes, I have used the amiga, but the two-button mouse is not straight forward as to it's meaning. I can take a complete computer novice (like yourself?) and have them working faster & better on a mac than an Amiga. Also, I hate the word 'gadget', makes me think of a cheap toy construction kit where you slap together gadgets to make something. > >Time is a telling factor. Let's have a net re-union next year and see if > >the Amiga is still sold by Commodore (or anyone else). Commodores low-end > >market is falling to the big boys. > Talk about your LIES!!!! The Amiga is right now reaching the point of > takeoff. Within the last month, several pieces of hardware have been > release for a suitable price that make the Amiga competitive with any > computer on the market today. Just try to add a cheap 20 meg hard disk. I can get 20 meg SCSI drives for $595 LIST. > For example, if I had an Amiga (just > lusting after one, thank you), I could add 4 megabytes of RAM to it > for under $1200... try that with your Mac! See ya, Mr. Computer Bigot! Yeah I can add 2 megabytes now for $220, that's only a tad more expensive than Amiga 256K upgrades isn't it (retail price?) When the 1 megabit chips are out, I'll be able to have 4 megs internally w/o an expansion box (that is twice as big as the Amiga.) > By the way, I think the Mac Plus is a nice machine... the Computing > Center here has several Macs used by the secretaries (the techies > generally have PC-Drones or other such machines, since they enjoy > playing with soldering irons and you need a hacksaw to open a Mac). A Hacksaw? I have seen internal hard drives, fans, 4 meg memory upgrades w/ 68020 & 68881 boards. How is it so hard to open, don't you know how to use a screw driver (w/star tip)? -- Brian Bezanson {seismo,ihnp4,allegra,topaz,harvard}!uwvax!gumby!bezanson Manta Software Corp. bezanson@gumby.wisc.edu
mwm@eris.berkeley.edu (Mike Meyer) (10/10/86)
In article <7761B5U@PSUVMB> B5U@PSUVMB.BITNET writes: > the $1200 figure quoted; but for what purpose other than perhaps a BBS can I > find a reason, unless you want a virtual micro :-) ), available software, Because I want the LISP program I'm working on, the visual editor (written in LISP, of course), the LISP help system, the LISP compiler, and the LISP debugging/windowing system in memory. Of course, a terminal emulator so I can monitor mail on the mainframe at work would be nice, also. I'm just afraid that 4Meg won't be enough.... On the more serious side, Sun 3's with less than 4Meg are slow (but they're running Unix), and a Slime running release 7 needs 4MegaWords (36 bit words) to get good response out of it. And these systems *HAVE* virtual memory. "Given the choice between more memory and faster disk, always take more memory." <mike