gsm@gsm001.uucp (Geoffrey S. Mendelson) (02/09/91)
There is a package for the IBM pc called Ventura Publisher. It is marketed
by Xerox. Ventura has a "good" GUI interface. As a desktop publisher,
it IMHO beats the pants of of both Quark Xpress, and Pagemaker.
It is now available for the Mac. We should see some sparks fly soon.
Ventura release 1.1 runs on a PC/XT with 640K, a hercules card (resolution
very close to a Mac) in B&W, and about 5 meg of disk space. I have been
using r1.1 for almost 3 years. I have never bothered to upgrade, as I can
do just about anything I need with it. And to top it off, it runs under
GEM, which has got to be the worlds worst GUI manager.
My point? Good GUI's, good software, etc, are NOT HARDWARE DEPENDENT.
The Mac's system makes it easier to code one, as most of it comes in rom.
The AMIGA's GUI has some good points over the MAC, Next Step has some
good points over the MAC, WINDOWS has some (but not many) good points over
the MAC MVS (IBM Mainframe) has some good points over the MAC. If you look for
good points over the MAC you will find them everywhere.
WHAT REALY MATTERS IS AVAILABLE APPLICATION SOFTWARE.
The MAC application software has a good point that no other system has:
They all have a similar look and feel. Not only can't you get sued for
copying it, You are encoraged, if not forced, to use it.
This is worth far more than anyone gives it credit. Or maybe they do, that's
why they buy MACs.
Anyone who has a substancial software investment in the Mac will not go out
and buy an IBM, or vice versa, or a NexT or an Amiaga. Why? No-one wants to
through it all out and start over. I have a PC, an AMIGA, a UNIX system and
a MAC. I can show you stuff on the MAC the blows away the pc, stuff on the
pc that blows away the MAC, stuff on the amiga that will knock your socks off,
etc. Who cares? Each is a tool. I use each for what it can do best. Is any
one better than the other? No.
What it comes down to is which machine/software combination is the easiest
to use for the job at hand. If I could only buy one machine what would I buy?
I don't know. Probably an Amiga, with a MAC emulator, an ATARI ST emulator,
a PC emulator etc.......... Or to quote an earlier posting:
"Buy an IBM, buy an Amiga, buy a dishwasher......"
I would rather have dishwasher than a computer.
--
----------------------------------------------------------------------------
| Geoffrey S. Mendelson | Computer Software Consulting | Dr. |
| (215) 242-8712 | IBM Mainframes, Unix, PCs, Macs | Who |
| uunet!gsm001!gsm | | Fan too!| berger@iboga (Mike Berger) (02/10/91)
gsm@gsm001.uucp (Geoffrey S. Mendelson) writes: >My point? Good GUI's, good software, etc, are NOT HARDWARE DEPENDENT. >The Mac's system makes it easier to code one, as most of it comes in rom. *---- I agree with some of the points you've made in your posting, but I couldn't let this pass. What's the difference whether your GUI support library is in ROM or RAM? In fact, most of the complaints I hear about programming the Mac involve the complexity of the ROM calls. Fortunately, the better compilers isolate the programmer from that... just like in the PC family. -- Mike Berger Department of Statistics, University of Illinois AT&TNET 217-244-6067 Internet berger@atropa.stat.uiuc.edu
derek@coco2.albany.edu (Cinderella Man) (02/10/91)
In article <1991Feb9.035631.15285@gsm001.uucp> gsm@gsm001.uucp (Geoffrey S. Mendelson) writes: >There is a package for the IBM pc called Ventura Publisher. It is marketed >by Xerox. Ventura has a "good" GUI interface. As a desktop publisher, >it IMHO beats the pants of of both Quark Xpress, and Pagemaker. >It is now available for the Mac. We should see some sparks fly soon. I've used Ventura Publisher on a 33MHz '386, and while it does have its good points, I'd take Mac PageMaker or XPress over it any day. I don't like its treatment of "frames" or its graphic and text handling. However, it IS better at doing standardized layouts than those programs, and I love the way it treats document files, imports and exports. I haven't seen the Mac version yet, but I assume its text and graphics capabilities are improved over the PC. It should also be MUCH faster on the Mac. You're right, we might see sparks... >| Geoffrey S. Mendelson | Computer Software Consulting | Dr. | Derek L. -- baby, life's what you make it...can't escape it.
gsm@gsm001.uucp (Geoffrey S. Mendelson) (02/10/91)
>What's the difference whether your GUI support >library is in ROM or RAM? ROMs don't change much. Either intentionaly such as bug fixes or unitentionaly due to wild stores. A stable base to develop code on is very useful, especially on a machine without memory protect. Lets say, for sake of argument, our GUI support routines take up 128k. Any module that uses the GUI is by default 128k bigger. That is 128k more disk to store it, 128k more ram to run it, and 128k more disk transfer time to load it. If you are running 4 programs under a multitasking O.S. such as multifinder, that 128k becomes 512k. Programers, being an efficency based bunch, would try to short cut, or limit the size of the GUI. Less size means less function. Something gets lost in the process. The complexity of the MAC rom calls is due to the amount of function behind them. The equivalent calls in UNIX (X-windows), ms-dos (Windows) AMIGA (the native O.S) are just as obscure and hard to use. For efficency, I would hope that the ROMS are copied into RAM on machines with MMUs. This is because the access time of ram is much faster than the roms currently in use. On the other hand using a rom chip is much cheaper than an mmu. It's sort of a poor man's memory protect. When the AMIGA 1000 was released the operating system code was rushed out the door. Unable to produce code stable enough for ROMs, Commodore made a section of the RAM read only. When you you booted the machine, you had to boot with a "KICKSTART" disk, then boot with the operating system. If you were one of the lucky ones who had a hard disk, you had to boot with the "KICKSTART" disk, then you could boot from the floppy to use the hard disk. To add injury to insult, the "KICKSTART" process probably added $100 to the price of the machine. If the original MAC had this feature, GUI or not, it would have never taken off. The "rest of us" don't want to have to boot our computers twice. Also at the time of the first MAC another 64k of ram for the rom images would have added several hundred dollars to the price. Memory did not become cheap until IBM and its clones started the incessant demand for it. Remember that Steve and Steve did not see any need for more than 128k on the MAC. They knew about expansion slots. They just could not conceive that "the rest of us" would want them. -- ---------------------------------------------------------------------------- | Geoffrey S. Mendelson | Computer Software Consulting | Dr. | | (215) 242-8712 | IBM Mainframes, Unix, PCs, Macs | Who | | uunet!gsm001!gsm | | Fan too!|
fry@zariski.harvard.edu (David Fry) (02/10/91)
Most of the arguments about having the Mac GUI functions in ROM or RAM is irrelevant because many (most?) of the functions are patched with routines from the System file (and are stored in RAM, of course) at runtime. The effects of the toolbox code getting munged by a rogue program are no more severe than several other parts of memory getting stepped on, e.g. low memory globals, stack, etc. David Fry fry@math.harvard.EDU Department of Mathematics fry@huma1.bitnet Harvard University ...!harvard!huma1!fry Cambridge, MA 02138
gourdol@imag.imag.fr (Arnaud Gourdol) (02/12/91)
In article <1991Feb9.212956.12871@ux1.cso.uiuc.edu> berger@iboga (Mike Berger) writes: >gsm@gsm001.uucp (Geoffrey S. Mendelson) writes: >>My point? Good GUI's, good software, etc, are NOT HARDWARE DEPENDENT. >>The Mac's system makes it easier to code one, as most of it comes in rom. >*---- >I agree with some of the points you've made in your posting, but I >couldn't let this pass. What's the difference whether your GUI support >library is in ROM or RAM? In fact, most of the complaints I hear about >programming the Mac involve the complexity of the ROM calls. Fortunately, >the better compilers isolate the programmer from that... just like in the >PC family. What?!!?? What's in the Macintosh ROM is like a library. You would link it with the object code of your program if using a "compiler" approach, but the calls available will be the same and the complexity will be the same. The complexity surely DON'T come from the fact it's in ROM or RAM. I am not ver well informed about the PC world, but I think that Windows works very much like the Macintosh toolbox, that is, it is not linked your program. The difference of course is that the Macintosh Toolbox is in ROM and Windows is in RAM. Arnaud.
gourdol@imag.imag.fr (Arnaud Gourdol) (02/12/91)
In article <1991Feb10.023034.858@gsm001.uucp> gsm@gsm001.uucp (Geoffrey S. Mendelson) writes: >>What's the difference whether your GUI support >>library is in ROM or RAM? > > ROMs don't change much. Either intentionaly such as bug fixes or >unitentionaly due to wild stores. > > A stable base to develop code on is very useful, especially on a >machine without memory protect. The Macintosh toolbox IS in ROM. But this does not mean that there can't be bug fixes, new features added, etc. (The same is true for the Amiga). The Macintosh system allows you to alter the comportement of system calls by defining "Trap Patches". This features is used to write zillions of Inits AND by Apple to correct the bugs found in the ROM. The system automaticall installs those patches at boot time, and of course they reside in RAM. New features can be added, such as 32 bit Color Quickdraw, sound compression (MACE) and even System 7 which do not requires that you change the ROMs, but however adds thousands of features. [Comments about the fact that a library in RAM would have to be duplicated several times] This is not necesarily true. One could imagine shared libraries in RAM. In fact, this is the way it works with the Amiga and the way it was supposed to work with the NeXT (the feature was not implemented in OS 0.9, I presume it is now?). > For efficency, I would hope that the ROMS are copied into RAM on >machines with MMUs. This is because the access time of ram is much faster >than the roms currently in use. On the other hand using a rom chip is >much cheaper than an mmu. It's sort of a poor man's memory protect. On the original Mac, and I think still on the Mac Classic, the ROM is in fact faster than the RAM. This is because the RAM is used as a video memory and that the video chip steals one cycle every four cycles to the processor. Of course, the video memory don't steal cycles for the ROM, so the code in ROM executes faster. This is no more true with the Mac II line, because the video RAM is distinct from the "real" RAM, so there is no cycle stealing. However, this might be the case for Macintosh with built-in video, such as the Mac II ci, Mac II si and Mac LC. Besides, I am not sure that ROM chips on the Mac IIs are slower than RAM chips, but even if that was the case, this would not matter much, as Mac IIs are equiped with processors with a cache built-in. >---------------------------------------------------------------------------- >| Geoffrey S. Mendelson | Computer Software Consulting | Dr. | >| (215) 242-8712 | IBM Mainframes, Unix, PCs, Macs | Who | >| uunet!gsm001!gsm | | Fan too!| > IMHO, the main advantage to have the code in ROM is that it's readily available. Say you want to display some text in a window. If your system has standard libraries call that can do this reasonably well, what will you do? You'll use them, of course. Benefit for you: few line of codes to write. Benefit for your user: consistency with other application he uses that display text in a window (they will both do it the same way). If your system has not standard library, what will you do? Just write all yourself, or use one of the libraries made by other and link it with your code. This was the case of the PC-world, not so long ago. Nowadays, things are changing since Windows is slowly getting standard on PC, so you can now assume your user will have Windows. So, what's important is to have a standard library with the system, either in ROM or RAM. And this library must be well written, ie provide adequate services to you the programmer and have a consistent look and feel for the user. BTW, note that all the Macintosh sold now have ROM Simms. This means it's easy (OK, possible) to change the ROM where the size of the various patches will go beyond 1 or 2 Megs. Arnaud.
francis@uchicago.edu (Francis Stracke) (02/12/91)
If you want to reply, use the address francis@zaphod.uchicago.edu. Don't know why zaphod is getting left off, but it is. In article <17981@imag.imag.fr> gourdol@imag.imag.fr (Arnaud Gourdol) writes: In article <1991Feb10.023034.858@gsm001.uucp> gsm@gsm001.uucp (Geoffrey S. Mendelson) writes: [Comments about the fact that a library in RAM would have to be duplicated several times] This is not necesarily true. One could imagine shared libraries in RAM. In fact, this is the way it works with the Amiga and the way it was supposed to work with the NeXT (the feature was not implemented in OS 0.9, I presume it is now?). For that matter, the IBM has always had what amounted to a RAM-based library: the calls accessed through INT $21. Mac just has more of it. -- /=============================================================================\ | Francis Stracke | My opinions are my own. I don't steal them.| | Department of Mathematics |=============================================| | University of Chicago | Until you stalk and overrun, | | francis@zaphod.uchicago.edu | you can't devour anyone. -- Hobbes | \=============================================================================/
Jim.Spencer@p510.f22.n282.z1.mmug.edgar.mn.org (Jim Spencer) (02/14/91)
Mike Berger writes in a message to All MB> I agree with some of the points you've made in your posting, MB> but I couldn't let this pass. What's the difference whether your MB> GUI support library is in ROM or RAM? In fact, most of the complaints MB> I hear about programming the Mac involve the complexity of the MB> ROM calls. Fortunately, the better compilers isolate the programmer MB> from that... just like in the PC family. The difference is that it runs faster and is absolutely uniform. Also, because every machine has it, a programmer is nuts if he or she doesn't use it. No compiler can isolate the programmer from what is considered complicated about the Mac ROM calls (they are called just like any other procedure and in fact parts of the Toolbox are in RAM, not ROM; the difference is largely transparent to the programmer.) The only thing complicated about the Toolbox is that it is large which puts a burden on the programmer to know a lot going in. As I said, no compiler can take care of that for you. -- Jim Spencer - via The Minnesota Macintosh Users Group UUCP-Fido Gateway UUCP: ...uunet!tcnet!kksys!edgar!mmug!22.510!Jim.Spencer INET: Jim.Spencer@p510.f22.n282.z1.mmug.edgar.mn.org
berger@iboga (Mike Berger) (02/16/91)
gsm@gsm001.uucp (Geoffrey S. Mendelson) writes: >Remember that Steve and Steve did not see any need for more than 128k on the >MAC. They knew about expansion slots. They just could not conceive that >"the rest of us" would want them. >-- *---- What I fail to understand is why you feel compelled to defend this short-sightedness. Every other computer expert in the world understood the need. -- Mike Berger Department of Statistics, University of Illinois AT&TNET 217-244-6067 Internet berger@atropa.stat.uiuc.edu
ds4a@dalton.acc.Virginia.EDU (Dale Southard) (02/16/91)
From aritcle <1991Feb15.220523.24037@ux1.cso.uiuc.edu> +----------------- |gsm@gsm001.uucp (Geoffrey S. Mendelson) writes: |>Remember that Steve and Steve did not see any need for more than 128k on the |>MAC. They knew about expansion slots. They just could not conceive that |>"the rest of us" would want them. |>-- |*---- | |What I fail to understand is why you feel compelled to defend this |short-sightedness. Every other computer expert in the world understood |the need. |-- | Mike Berger +----------------- Mike, with all due respect, I really doubt that "Every other computer expert in the world" would agree with that. Let's remember the time frame of which we are speaking: My Apple ][+ was still relativly state of the art (48 K with a floppy). Fact is, the off the shelf mac had just about everything that 95% of the computer hobbists were putting in the slots of their S-100 systems (which DID still exist, I have proof). But we all have our gremlins to live with. The ][gs was an attempt to bring the apple ][ design into the 90s (maybe into the 80s). MS-DOS is STILL trying to get around the 640K limit (before we laugh, mac users will probably be in the same boat with the 13 Meg limit in a few years). The Mac II line addressed the slot (no pun intended) problem. Windows 3 is addressing the IBMs interface problems. etc etc Nothing is perfect and most operating systems will be FOREVER chained to their min. configurations or first incarnations. I have no problems with the "limitations" of my SE/30 and its one slot -- If I did I would buy somthing with slots. As it is, I haveplenty of unused ports & SCSI addresses left. --> --> Dale UVa (ds4a@virginia.edu)
gsm@gsm001.uucp (Geoffrey S. Mendelson) (02/16/91)
> >gsm@gsm001.uucp (Geoffrey S. Mendelson) writes: >>Remember that Steve and Steve did not see any need for more than 128k on the >>MAC. They knew about expansion slots. They just could not conceive that >>"the rest of us" would want them. >>-- >*---- > >What I fail to understand is why you feel compelled to defend this >short-sightedness. Every other computer expert in the world understood >the need. I did not defend it. I no longer have the original post, would you please email it to me if you have it. I believe that you are taking me out of context. What I meant, and obviously I was not completely clear, is that they were shortsighted. They knew about slots (having put them in apple II's). My point was that when the MAC was first designed, the designers were so shortsighted as to feel that 128k was all anyone would ever need. They cannot claim ignorance as an excuse. Geoff. -- ---------------------------------------------------------------------------- | Geoffrey S. Mendelson | Computer Software Consulting | Dr. | | (215) 242-8712 | IBM Mainframes, Unix, PCs, Macs | Who | | uunet!gsm001!gsm | | Fan too!| ---------------------------------------------------------------------------- | WANTED: PAL VIDEO TAPES (VHS or BETA) inquire within. | | Especialy "missing" Dr Who Episodes. | ---------------------------------------------------------------------------
russotto@eng.umd.edu (Matthew T. Russotto) (02/18/91)
In article <1991Feb15.235111.9859@murdoch.acc.Virginia.EDU> ds4a@dalton.acc.Virginia.EDU (Dale Southard) writes: >bring the apple ][ design into the 90s (maybe into the 80s). MS-DOS is >STILL trying to get around the 640K limit (before we laugh, mac users will >probably be in the same boat with the 13 Meg limit in a few years). Too late. Optima apparentley allows 128 continuous megabytes, and the newer macs include a 32-bit memory manager which will allow 4 Gig under VaporWare 7.0 -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.
john@newave.UUCP (John A. Weeks III) (02/18/91)
In article <1991Feb15.220523.24037@ux1.cso.uiuc.edu> berger@iboga (Mike Berger) writes: > gsm@gsm001.uucp (Geoffrey S. Mendelson) writes: > > Remember that Steve and Steve did not see any need for more than 128k on > > the MAC. They knew about expansion slots. They just could not conceive > > that "the rest of us" would want them. > What I fail to understand is why you feel compelled to defend this short- > sightedness. Every other computer expert in the world understood the need. The memory size was a problem, but there is no need for "expansion" slots in a Macintosh. With three different external network plugs plus a variety of other connectors, any device that you could want can easily be added. Why should the toaster buyers pay for the slots, power supply, and space that they will never use? The only thing that expansion slots have done for the PC world is create a large number of compatibilty problems. -john- -- =============================================================================== John A. Weeks III (612) 942-6969 john@newave.mn.org NeWave Communications ...uunet!rosevax!tcnet!wd0gol!newave!john ===============================================================================
awessels@ccwf.cc.utexas.edu (Allen Wessels) (02/18/91)
In article <1991Feb17.195352.28702@eng.umd.edu> russotto@eng.umd.edu (Matthew T. Russotto) writes: >In article <1991Feb15.235111.9859@murdoch.acc.Virginia.EDU> ds4a@dalton.acc.Virginia.EDU (Dale Southard) writes: >>bring the apple ][ design into the 90s (maybe into the 80s). MS-DOS is >>STILL trying to get around the 640K limit (before we laugh, mac users will >>probably be in the same boat with the 13 Meg limit in a few years). > >Too late. Optima apparentley allows 128 continuous megabytes, and the newer >macs include a 32-bit memory manager which will allow 4 Gig under VaporWare >7.0 I'm guessing that Optima/128 allows 128 meg RAM with the 32-bit clean machines. For reasons I've never manage to understand, ROM upgrades would be required for the IIx, cx, and SE/30s out there to use more than 14 or so meg as System memory. While the 32 bit memory manager allows a 4 Gig address space, I bet we're only allocated 1/2 of it.
russotto@eng.umd.edu (Matthew T. Russotto) (02/19/91)
In article <44352@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: > >I'm guessing that Optima/128 allows 128 meg RAM with the 32-bit clean machines. >For reasons I've never manage to understand, ROM upgrades would be required for >the IIx, cx, and SE/30s out there to use more than 14 or so meg as System >memory. Well, actually, not so-- 'All' you would have to do is place an entirely new version of the memory manager and bootstrap code (patched to load the new memory manager) into high memory, and essentially restart the system. Somehow I doubt Apple is going to do that. -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.
mmcnew@pro-odyssey.cts.com (Monty McNew) (02/20/91)
> gsm@gsm001.uucp (Geoffrey S. Mendelson) writes: In-Reply-To: message from john@newave.UUCP > > Remember that Steve and Steve did not see any need for more than > > 128k on the MAC. There was only one Steve connected with the short sightedness of 128k on the original Mac. Let us just say that his last initial was not a 'W'. ---- ProLine: mmcnew@pro-odyssey Monty S. McNew Internet: mmcnew@pro-odyssey.cts.com @ Pro-Odyssey UUCP: crash!pro-odyssey!mmcnew 707/437-4734 ARPA: crash!pro-odyssey!mmcnew@nosc.mil Fairfield, CA