hal@world.std.com (Harry A Levinson) (05/10/91)
I am afraid to ask this because I don't want to start a roaring fire of flames but... I have been using both a Mac and a DOS machine for about 5 years. I have recently been trying to help some friends with their 386 machine running Windows 3/ W4W and XL4W (facelift is installed and enabled). The 386 is 16MHz with 2Mb. The printer is an Okidata 24 pin. My impression of Windows are: 1. It has tryed to impose a GUI environment where it does not quite fit. As a result computer novices take longer to learn how to use a Windows machine than a Mac. However once acquainted with Windows both environments provide similar capabilites. 2. Adding applications and peripherals is easier (for a novice) on the Mac. 3. It seems to take more Intel machine to get the same response as a Mac. Are these consistent with others? I would appreciate it if comments could be limited to those with working knowledge of both Windows and Mac. I am especially interested in comments from people who have seen reactions to both systems from complete computer illiterate types learning to use a computer for the first time. Thanks, harry levinson hal@world.std.com
akm@obelix.cs.uoregon.edu (Anant Kartik Mithal) (05/11/91)
In article <1991May10.135518.5538@world.std.com> hal@world.std.com (Harry A Levinson) writes: >My impression of Windows are: >1. It has tryed to impose a GUI environment where it does not quite fit. Could you clarify what you meant by that? I ask because it has a lot of bearing on your next sentence. > As a result computer novices take longer to learn how to use a Windows > machine than a Mac. -- Anant Kartik Mithal akm@cs.uoregon.edu Research Assistant, (503)346-4408 (msgs) Department of Computer Science, (503)346-3989 (direct) University of Oregon, Eugene, OR 97403-1202
jim@tortuga.SanDiego.NCR.COM (Jim (James) Ruehlin) (05/11/91)
In article <1991May10.135518.5538@world.std.com> hal@world.std.com (Harry A Levinson) writes: >My impression of Windows are: > >1. It has tryed to impose a GUI environment where it does not quite fit. > As a result computer novices take longer to learn how to use a Windows > machine than a Mac. However once acquainted with Windows both environments > provide similar capabilites. I've extensively used and programmed on both machines. I'm currently working on an application for Windows 3.0. I mostly agree with this statement, but I think the Mac is a bit smoother and easier to use, even for advanced users. However, Win 3.0 is a little more customizable. I think both of these are minor differences. >2. Adding applications and peripherals is easier (for a novice) on the Mac. No question about it. Easier for the pro too, if you ask me! >3. It seems to take more Intel machine to get the same response as a Mac. I agree, but I think part of the reason for this is the Mac mouse is controlled by hardware, while the poor intel chip has to handle everything. It's just a matter of one machine being built for the mouse and the other isn't. - Jim Ruehlin
gaynor@agvax2.ag.ohio-state.edu (05/11/91)
In article <1991May10.135518.5538@world.std.com>, hal@world.std.com (Harry A Levinson) writes: >I am afraid to ask this because I don't want to start a roaring >fire of flames but... >My impression of Windows are: > >1. It has tryed to impose a GUI environment where it does not quite fit. > As a result computer novices take longer to learn how to use a Windows > machine than a Mac. However once acquainted with Windows both environments > provide similar capabilites. I agree that Windows doesn't quite fit. After having used it on a day-to-day basis for the past 6 months, I'm convinced that it's a shell, not an OS. Now, granted, it's one hell of a shell, adding numerous new capabilities to the operating system, especially in the area of graphics. But it is still layered on top of DOS, and all its limitations. (memory, device handling, file names, ad nauseum) >2. Adding applications and peripherals is easier (for a novice) on the Mac. Adding an application still requires an often-lengthy "install" process (although more Mac applications need to be "installed" these days), and files such as CONFIG.SYS, AUTOEXEC.BAT, WINDOWS.INI, and the like often need to be modifies and tweaked by hand. Then you still have to install the icon in a Windows group. (One of my biggest complaints - the Program Manager has -no- relation to disk structure or even to real files. It's just a bunch of pointers.) >3. It seems to take more Intel machine to get the same response as a Mac. I've got an IBM PS/2 model 30 on my desk (10 Mhz 286, 16 color VGA, 2 MB RAM, 20 MB HD), and it runs Windows programs significantly slower than a Mac Plus (8 Mhz 68000, 9" b/w screen, 1 MB RAM, 20 MB HD) runs comparable programs. (Windows Write - MacWrite II, Terminal - Red Ryder, Windows Paint - Canvas). And here I thought that the '286 machines were supposed to be similar in response to '020s. (Gross oversimplification). In the end, IMHO, Windows doesn't compare to System 6.0x. System 7.0 will make the comparison even worse. However, Windows 3.0 is the best thing going for MS-DOS machines at the time being. --- Jim Gaynor - AgVAX System Manager - Academic Computing - Ohio State University VMS:<gaynor@agvax2.ag.ohio-state.edu> UNIX:<gaynor@magnus.acs.ohio-state.edu> Disclaimer : All opinions expressed here are mine and only mine. So there! Witty Quote: "Think, think, think, think..." - Winnie-the-Pooh, Taoist Bear.
aaron@jessica.stanford.edu (Aaron Wallace) (05/11/91)
In article <1991May10.183738.15661@zardoz.eng.ohio-state.edu> gaynor@agvax2.ag.ohio-state.edu writes: >I agree that Windows doesn't quite fit. After having used it on a >day-to-day basis for the past 6 months, I'm convinced that it's a >shell, not an OS. Now, granted, it's one hell of a shell, adding >numerous new capabilities to the operating system, especially in the >area of graphics. But it is still layered on top of DOS, and all its >limitations. (memory, device handling, file names, ad nauseum) The only thing DOS is used for (and thus imposes limits on) is the file system. Windows takes over memory management and device handling. Okay, this is a bit of a simplification, but the exceptions are few... >>2. Adding applications and peripherals is easier (for a novice) on the Mac. > >Adding an application still requires an often-lengthy "install" >process (although more Mac applications need to be "installed" these >days), and files such as CONFIG.SYS, AUTOEXEC.BAT, WINDOWS.INI, and >the like often need to be modifies and tweaked by hand. Then you >still have to install the icon in a Windows group. Funny. Most programs I install do it automatically. As for ease of use installing peripherals, is it easier to get a <name your favorite non-Apple printer> working on a Mac or with Windows, in general? >>3. It seems to take more Intel machine to get the same response as a Mac. > >I've got an IBM PS/2 model 30 on my desk (10 Mhz 286, 16 color VGA, 2 >MB RAM, 20 MB HD), and it runs Windows programs significantly slower than >a Mac Plus (8 Mhz 68000, 9" b/w screen, 1 MB RAM, 20 MB HD) runs >comparable programs. (Windows Write - MacWrite II, Terminal - Red >Ryder, Windows Paint - Canvas). And here I thought that the '286 >machines were supposed to be similar in response to '020s. (Gross >oversimplification). Note that you have VGA (4 bits/pixel) and the Mac is monochrome (1 bit/ pixel). Thus, in terms of raw graphics speed, you'd expect the PS/2 to be 1/4th the speed in screen-intensive stuff. Better comparison: a 10 MHz 286 with a Herc and a Classic. I think you'll find it to be much closer-- My 12 MHz machine is easily as fast as a classic (and probably faster, subjectively). Even then, the Herc shuffles around 50% more pixels than the tiny Classic screen. Comparing Apples and non-Apples is never easy :-) >In the end, IMHO, Windows doesn't compare to System 6.0x. System 7.0 >will make the comparison even worse. However, Windows 3.0 is the best >thing going for MS-DOS machines at the time being. The one problem I have with this kind of thread and the OS/2 vs. Windows one is that people tend to buy and use applications, not operating systems. OS/2 is much better than Windows, but Windows apps are in general better (or at least more plentiful) than OS/2 apps. There are some good Mac apps, but for what I do the Windows apps are better. For me, that is the final line... That and price, that is! Aaron Wallace
lester@bronze.ucs.indiana.edu (Jim Lester) (05/11/91)
aaron@jessica.stanford.edu (Aaron Wallace) writes: >In article <1991May10.183738.15661@zardoz.eng.ohio-state.edu> gaynor@agvax2.ag.ohio-state.edu writes: >>I agree that Windows doesn't quite fit. After having used it on a >>day-to-day basis for the past 6 months, I'm convinced that it's a >>shell, not an OS. Now, granted, it's one hell of a shell, adding >>numerous new capabilities to the operating system, especially in the >>area of graphics. But it is still layered on top of DOS, and all its >>limitations. (memory, device handling, file names, ad nauseum) >The only thing DOS is used for (and thus imposes limits on) is the file system. >Windows takes over memory management and device handling. Okay, this is >a bit of a simplification, but the exceptions are few... I'll buy that, however the file system is a BIG part of any computer >>>2. Adding applications and peripherals is easier (for a novice) on the Mac. >> >>Adding an application still requires an often-lengthy "install" >>process (although more Mac applications need to be "installed" these >>days), and files such as CONFIG.SYS, AUTOEXEC.BAT, WINDOWS.INI, and >>the like often need to be modifies and tweaked by hand. Then you >>still have to install the icon in a Windows group. >Funny. Most programs I install do it automatically. I have just finished installing both W4W and Word, PageMaker for Windows and PageMaker on the Mac etc... and Mac is easier hands down... >As for ease of use installing peripherals, is it easier to get a <name your >favorite non-Apple printer> working on a Mac or with Windows, in general? I have done a number of non-apple printers which are plug and play... My mother can do it (and has) >>>3. It seems to take more Intel machine to get the same response as a Mac. >> >>I've got an IBM PS/2 model 30 on my desk (10 Mhz 286, 16 color VGA, 2 >>MB RAM, 20 MB HD), and it runs Windows programs significantly slower than >>a Mac Plus (8 Mhz 68000, 9" b/w screen, 1 MB RAM, 20 MB HD) runs >>comparable programs. (Windows Write - MacWrite II, Terminal - Red >>Ryder, Windows Paint - Canvas). And here I thought that the '286 >>machines were supposed to be similar in response to '020s. (Gross >>oversimplification). >Note that you have VGA (4 bits/pixel) and the Mac is monochrome (1 bit/ >pixel). Thus, in terms of raw graphics speed, you'd expect the PS/2 to be >1/4th the speed in screen-intensive stuff. Better comparison: a 10 MHz >286 with a Herc and a Classic. I think you'll find it to be much closer-- >My 12 MHz machine is easily as fast as a classic (and probably faster, >subjectively). Even then, the Herc shuffles around 50% more pixels than the >tiny Classic screen. Comparing Apples and non-Apples is never easy :-) Sure compare same IBM PS/2 to Mac II and the Mac II will come out favorably >>In the end, IMHO, Windows doesn't compare to System 6.0x. System 7.0 >>will make the comparison even worse. However, Windows 3.0 is the best >>thing going for MS-DOS machines at the time being. >The one problem I have with this kind of thread and the OS/2 vs. Windows >one is that people tend to buy and use applications, not operating systems. >OS/2 is much better than Windows, but Windows apps are in general better (or >at least more plentiful) than OS/2 apps. There are some good Mac apps, but >for what I do the Windows apps are better. For me, that is the final line... I will agree that it is more a matter of personal preference >That and price, that is! as an amusing aside I was Window Shopping yesterday :-) Microsoft Office PcConnection Price $629 (ie windows version) MacConnection Price $525 (ie Mac version) >Aaron Wallace Jim Lester Guy who does neat MAC stuff who is now living in a Windows World Finicial Management Support Indiana University Disclaimer: IU didn't put this foot in my mouth (It barely puts food in my mouth :-) )
leoh@hardy.hdw.csd.harris.com (Leo Hinds) (05/11/91)
In article <1991May10.183738.15661@zardoz.eng.ohio-state.edu> gaynor@agvax2.ag.ohio-state.edu writes: >I agree that Windows doesn't quite fit. After having used it on a >day-to-day basis for the past 6 months, I'm convinced that it's a >shell, not an OS. Sorry, but I can't help be a little sarcastic when I say ... give Mr Gaynor a prize ... he has (finally) realized windows IS NOT AN OS !!! ... I wish uSoft had done the job right & made it an OS (starting to sound like os2 ?!?) ... but for the moment we will have to love with what (little) we have. > But it is still layered on top of DOS, and all its >limitations. (memory, device handling, file names, ad nauseum) But it tries to do the best it can. It has (amongst other things) "legitimalized" 386 extenders ... of course they had to do it differently than the already accepted ways) ... >I've got an IBM PS/2 model 30 on my desk (10 Mhz 286, 16 color VGA, 2 >MB RAM, 20 MB HD), and it runs Windows programs significantly slower than >a Mac Plus (8 Mhz 68000, 9" b/w screen, 1 MB RAM, 20 MB HD) runs >comparable programs. Far be it for me to say windows is not slow (the people at uSoft tech support were themselves surprised at how slowly my 20MHz DX w/2MB, 135MB disk system, running ATM with >150 fonts) would go through the basic steps of working with printers on the control panel. I would like however to point out that the Mac 9" b/w screen requires less video manipulations to redraw the entire screen (512*384*1=196,608 bits=24,576 bytes) than the 16 color vga (640*480*4=1,228,880 bits=153,600 bytes) ... 6.25 times as much to be exact ... at least compare apples with apples :-) ( I din't really say that, did I?!) leoh@hdw.csd.harris.com Leo Hinds (305)973-5229 Gfx ... gfx ... :-) whfg orpnhfr V "ebg"grq zl fvtangher svyr lbh guvax V nz n creireg ?!!!!!!? ... znlor arkg gvzr
glenn@gla-aux.uucp (Glenn L. Austin) (05/11/91)
In article <1991May10.135518.5538@world.std.com>, hal@world.std.com (Harry A Levinson) writes: > I am afraid to ask this because I don't want to start a roaring > fire of flames but... > > I have been using both a Mac and a DOS machine for about 5 years. I have > recently been trying to help some friends with their 386 machine > running Windows 3/ W4W and XL4W (facelift is installed and enabled). > The 386 is 16MHz with 2Mb. The printer is an Okidata 24 pin. > > My impression of Windows are: > > 1. It has tryed to impose a GUI environment where it does not quite fit. > As a result computer novices take longer to learn how to use a Windows > machine than a Mac. However once acquainted with Windows both environments > provide similar capabilites. That was my impression as well. I believe Windows ends up requiring a higher level of user as well, due to the many non-standard peripherals available for DOS machines. This makes it much more difficult to change the operating system, both for the users and the developers. > 2. Adding applications and peripherals is easier (for a novice) on the Mac. See comment above about peripherals. > 3. It seems to take more Intel machine to get the same response as a Mac. That is consistent with my evaluation as well. A few years ago (when the 386 was just announced), I put an 8088, an 80286 and an 80386 all running DOS on a logic analyzer. My results were surprising -- all three processors when executing code were doing byte fetches, in spite of the fact that the 286 and 386 had 32-bit buses. After doing some comparitive evaluations of the designs of the 680x0 and the x86, I came to the following conclusions: 1) Average instruction length for the Intel processors is approximately 5 bytes (using general-purpose code), and is fetched on a byte-by-byte basis. The fetch cycle is due to the limitations of the 86 architecture. By keeping relatively compatible with the 8080, additional instructions for newer processors must use a flag byte to denote an instruction for a newer processor. For example, all new 386 instructions start with $0F with no indication as to the actual instruction without reading this first byte. 2) Average instruction length for the Motorola processors is approximately 3.5 bytes (using general-purpose code), and is fetched on a long-word basis, if long-word aligned. By using long-word fetches, approximately 80% of the more common instructions are loaded with one memory access. This explains why fewer wait states on the Mac have a smaller affect than on the PC. 3) The Intel processors are designed more for use with higher-level languages. They provide easier string processing at the expense of more specialized registers and more complex setup. The Motorola processors are designed more for use with C and Assembly, and provide more register flexibility at the expense of specialized functions. 4) Windows is added to DOS, and is reliant upon DOS and BIOS for all of the peripheral access, except video and specialized drivers. The Mac O/S was designed in from the beginning, so there are no "levels" of OS to contend with. > Are these consistent with others? > > I would appreciate it if comments could be limited to those with working > knowledge of both Windows and Mac. I am especially interested in > comments from people who have seen reactions to both systems from > complete computer illiterate types learning to use a computer for the > first time. Just for the record, I've been programming for 15 years, including 13 on mainframes and minis, 9 on the PC, and 6 on the Macintosh. I've worked extensively with MS/DOS, UNIX and the Macintosh, and I've found that not only is the machine faster, but the time for developing products is significantly less, if the same care is given to the user interface to make the program easy to use. The Mac is my machine of choice for both use and development, if the comparison is limited to microcomputers. =============================================================================== | Glenn L. Austin | "Turn too soon, run out of room. | | Macintosh Wizard and | Turn too late, much better fate." | | Auto Racing Driver | -- Jim Russell Racing School Instructors | |-----------------------------------------------------------------------------| | Usenet: glenn@gla-aux.uucp | CI$: 76354,1434 | | GENie: G.AUSTIN3 | AOnline: GAustin | ===============================================================================
ted@cs.utexas.edu (Ted Woodward) (05/12/91)
In article <1991May10.203309.22163@leland.Stanford.EDU> aaron@jessica.stanford.edu (Aaron Wallace) writes: >In article <1991May10.183738.15661@zardoz.eng.ohio-state.edu> gaynor@agvax2.ag.ohio-state.edu writes: >>I agree that Windows doesn't quite fit. After having used it on a >>day-to-day basis for the past 6 months, I'm convinced that it's a >>shell, not an OS. Now, granted, it's one hell of a shell, adding >>numerous new capabilities to the operating system, especially in the >>area of graphics. But it is still layered on top of DOS, and all its >>limitations. (memory, device handling, file names, ad nauseum) >The only thing DOS is used for (and thus imposes limits on) is the file system. >Windows takes over memory management and device handling. Okay, this is >a bit of a simplification, but the exceptions are few... Then please explain why I can't use the CASE tool I need to (a piece of junk called excelerator) AND then network software I need to print with at the same time on the 286 clone I have to use at work, even WITH windows. On a 4 meg machine. I'll tell you why; 640K limit. Yes, even windows still must deal with this. And it sure is damn slow switching from a dos application to the program manager...The only thing I could do is put excelerator in one dos shell, and the network in another. But if I try to quit the network shell, windows dies because the network goofs up some memory stuff that windows needs in dos, but doesn't bother to save before starting the shell, and restore after exiting it. And why does windows drop me into it's directory when I invoke a dos shell instead of the directory I started window in? Sheesh, like I'm going to run dos applications from the windows directory... >>Adding an application still requires an often-lengthy "install" >>process (although more Mac applications need to be "installed" these >>days), and files such as CONFIG.SYS, AUTOEXEC.BAT, WINDOWS.INI, and >>the like often need to be modifies and tweaked by hand. Then you >>still have to install the icon in a Windows group. >Funny. Most programs I install do it automatically. Really? Hmm...perhaps I installed the disk cache I use incorrectly. Or the video driver, or the other stuff I use...but then the manuals told me to modify the autoexec.bat or config.sys; not an installer. And hell, when I let the windows installer modify the path setting, it created a path that was too long for dos to handle. And didn't even check...I had to go in and manually fix it; I'd have been is some serious shit if I had been a novice. >As for ease of use installing peripherals, is it easier to get a <name your >favorite non-Apple printer> working on a Mac or with Windows, in general? Easier on the mac. Lets see...do I have the printer attached to com 1, lpt 1, etc. Hmm...I'm not sure; I didn't install the printer... As opposed to putting the printer driver in the system folder and selecting it from the chooser. Hell, the top 3 megs on that 286 (out of 4) were sitting by USELESS until I added a 3 meg disk cache. Now, at least, I'm getting a little performance out of it (ond before anybody flames the size of my disk cache, you try searching an 8 meg database without it...) -- Ted Woodward (ted@cs.utexas.edu) "Mad scientists HATE shopping for shoes!" -- Peaches
cadsi@ccad.uiowa.edu (CADSI) (05/12/91)
From article <1991May11.235337.8359@daffy.cs.wisc.edu>, by carter@cat23.cs.wisc.edu (Gregory Carter): [lots of stuff deleted] > Your impression that it takes more Intel machine is correct, intel CPU's > are brain damaged. > > --Gregory > Well..., Actually DOS is the Brain-Dead part. The Intel processors are actually pretty good. Particurlarly the 386 and above. I suggest that the OS over the chips is usually the problem. BTW, I wonder what makes you think Intel's toys are Brain-Dead? BTW, the MAC operating system is just as Brain-Dead as DOS. I won't go into detail here, possibly by e-mail if you wish to rebut. IMHO there are two GREAT OS's available at this time: MACH and OS/2. |----------------------------------------------------------------------------| |Tom Hite | The views expressed by me | |Manager, Product development | are mine, not necessarily | |CADSI (Computer Aided Design Software Inc. | the views of CADSI. | |----------------------------------------------------------------------------|
russotto@eng.umd.edu (Matthew T. Russotto) (05/13/91)
In article <1991May12.023111.25863@ccad.uiowa.edu> cadsi@ccad.uiowa.edu (CADSI) writes: >at this time: MACH and OS/2. ^^^^ Uh huh. Yes, Mr. Napolean. Now just put your arms through this coat here.. No, it's not backwards, it is supposed to be that way... Elba? No, this isn't Elba... :-) -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.
gt7865a@prism.gatech.EDU (COMER,MATTHEW BRIAN) (05/13/91)
People keep mentioning that the Mac has to do a lot less screen work than
most PC's. Well, I work with both Mac's and PC's. My PC has a Paradise VGA
card, and my Mac has a radius full screen display. The Mac beats the PC
speed-wise any day. I am not jumping on the Mac bandwagon by saying this, but
I would like to know (from some of you experts out there) how the Mac-Radius
combo can perform so well.
--
Comer, Matthew Brian
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt7865a
Internet: gt7865a@prism.gatech.educadsi@ccad.uiowa.edu (CADSI) (05/13/91)
From article <1991May12.211518.24682@eng.umd.edu>, by russotto@eng.umd.edu (Matthew T. Russotto): > In article <1991May12.023111.25863@ccad.uiowa.edu> cadsi@ccad.uiowa.edu (CADSI) writes: > >>at this time: MACH and OS/2. > ^^^^ > Uh huh. Yes, Mr. Napolean. Now just put your arms through this coat here.. > No, it's not backwards, it is supposed to be that way... Elba? No, this isn't > Elba... This may sound nasty, it isn't meant to be, but... How long have you used either MACH and/or OS/2 (2.0 Beta that is). BTW, not a bad comeback. .9 points. |----------------------------------------------------------------------------| |Tom Hite | The views expressed by me | |Manager, Product development | are mine, not necessarily | |CADSI (Computer Aided Design Software Inc. | the views of CADSI. | |----------------------------------------------------------------------------|
gaynor@agvax2.ag.ohio-state.edu (05/13/91)
In article <3330@travis.csd.harris.com>, leoh@hardy.hdw.csd.harris.com (Leo Hinds) writes: >In article <1991May10.183738.15661@zardoz.eng.ohio-state.edu> gaynor@agvax2.ag.ohio-state.edu writes: >>I agree that Windows doesn't quite fit. After having used it on a >>day-to-day basis for the past 6 months, I'm convinced that it's a >>shell, not an OS. > >Sorry, but I can't help be a little sarcastic when I say ... give Mr Gaynor >a prize ... he has (finally) realized windows IS NOT AN OS !!! ... True, it -isn't- an operating system. But, my good Leo, please tell me how Windows is marketed. It is marketed as an operating system, although the marketing is intelligent enough never to actually claim that it is an OS. The ads would have you beleive that you never again need worry about "C:\>", or about tweaking CONFIG.SYS or editing AUTOEXEC.BAT. But they are wrong. That is, unless you never install a card or never install a program that might potentially conflict with another, or doesn't have a extensive INSTALL procedure. For those of you talking OS/2 or Mach, that's fine. I'd love to see one of the new OS/2 betas, and I have no experience with Mach, so I can't comment on it. We could also throw AmigaDOS 2.0 into the soup if you wish, which I have seen, in beta form. That beta was a year ago, and it impressed me then. I'd like to see it now. But the discussion was comparisons of Windows 3.0 and Macintosh (assume System 6.0x), by persons who have more-than-passing experience with both. The person who started this thread was searching for intelligent, informed opinions on that topic, not a quest for the ultimate OS (which is highly dependant on your needs and style). --- Jim Gaynor - AgVAX System Manager - Academic Computing - Ohio State University VMS:<gaynor@agvax2.ag.ohio-state.edu> UNIX:<gaynor@magnus.acs.ohio-state.edu> Disclaimer : All opinions expressed here are mine and only mine. So there! Witty Quote: "Think, think, think, think..." - Winnie-the-Pooh, Taoist Bear.
ajauch@bonnie.ics.uci.edu (Alexander Edwin Jauch) (05/17/91)
In <1991May10.183611.3392@donner.SanDiego.NCR.COM> jim@tortuga.SanDiego.NCR.COM (Jim (James) Ruehlin) writes: >>3. It seems to take more Intel machine to get the same response as a Mac. >I agree, but I think part of the reason for this is the Mac mouse is >controlled by hardware, while the poor intel chip has to handle everything. >It's just a matter of one machine being built for the mouse and the >other isn't. Well Jim, I don't agree with this one. I have used windows without a mouse (horrors!) and it is still much slower redrawing windows and such than a Mac. I would blame the speed differential in that Macs have much of there system calls in ROMs and they are specifically tailored to run a GUI. Windows is grafted onto a DOS machine and has two layers of crap to get through. I would say that considering it's inherent disadvantage it is quite speedy. -- Alex Jauch *ajauch@bonnie.ics.uci.edu |"If all you have is a hammer, then the whole* *ajauch@orion.oac.uci.edu |world looks like a nail" -- Stolen *
tneff@bfmny0.BFM.COM (Tom Neff) (05/18/91)
In article <1991May17.170732.13608@macc.wisc.edu> dsals@vms.macc.wisc.edu (David Sals) writes: >What this all comes down to, is that windows is a poor substitute >for a macintosh. Windows is a poor substitute for a Macintosh in just the same sense that a haircut is a poor substitute for new shoes. You're not comparing equivalent things. If a customer is faced with the choice of buying Windows or a Mac, he or she should ALWAYS buy Windows. Why? Because it's much less expensive than a Mac! If you're ready to buy Windows, this implies you ALREADY have a PC. Think about it. Now if you have NEITHER a PC nor a Mac, then the question is: should you buy a PC *and* Windows, or a Mac. Very different question. The *correct* approach is to start with what the customer actually wants to *DO* with their computer! Whoa, scary concept there huh? Jeez, what'll they think of next. If you can characterize the APPLICATION or applications the customer has in mind, you can select SOFTWARE that does what he or she wants; and in turn sell them HARDWARE to support it. This approach has actually been known to yield the unheard-of beast known as a "satisfied customer." Clearly a dangerous trend. :-) On the other hand, if the customer just wants a computer for some nebulous undefined bull**** reason, just to HAVE one or because they've been reading computer rags on the Trump shuttle and sort of think they must need one somehow, then sell them the most expensive computer in the shop, because they are stupid -- so you win all their money.
mariusk@Lise.Unit.NO (Marius Kjeldahl) (05/18/91)
In article <1991May18.050842.5732@cs.uoregon.edu>, akm@obelix.cs.uoregon.edu (Anant Kartik Mithal) writes: |> In article <1991May17.170732.13608@macc.wisc.edu> dsals@vms.macc.wisc.edu (David Sals) writes: |> >1) Windows runs slower on a comparatively powerful machine (of |> > course, you can't really compare mac and ibm power, but the |> > windows environment is a software "emulation" shell, whereas |> > the mac environment is built into the hardware. Of course it |> > is going to run faster on the mac. |> |> A number of people have talked about how the fact that much of the |> MacToolbox is in ROM makes it faster than Windows, where the code for |> all the graphics resides in RAM. Does this really make a difference? I |> have the following reasons for believing this doesn't make a |> difference: |> |> 1. Many PC clones allow for shadow ram, which copies the ROM |> routines to RAM, which substantially speeds the machines up. |> |> 2. The System distributed for the Mac contains patches to fix |> bugs in the ROM, so some Toolbox routines execute in RAM |> |> 3. There are a couple of applications that exist in both Windows |> as well as PM versions (e.g. Word for PM and Word for |> Windows), and the PM versions are faster (InfoWorld reported |> on this a while back. This is done by running the two versions |> of the program on the same machine, so they are using the same |> ROM (to whatever extent the ROM is used at all...) |> |> So, my question is: if the Mac is faster than a "comparable" pc in |> execution, what is the reason? Is it ROM? (I don't think so for the |> reasons listed above.) What other things can make a difference? |> |> cheers, |> |> kartik |> |> -- |> Anant Kartik Mithal akm@cs.uoregon.edu |> Research Assistant, (503)346-4408 (msgs) |> Department of Computer Science, (503)346-3989 (direct) |> University of Oregon, Eugene, OR 97403-1202 1. Usually RAM is faster than ROM, thats why they incorporate things like shadowram and so on. 2. That is one of the drawbacks with the operatingsystem in ROM - you'll usually need hardware to perform the upgrade. This kind of solution you are mentioning does not sound healthy. 3. This is difficult to measure.. Generally: Applications across hardware platform usually contains small, but quite a lot of different features so it is not always rights to test against time only. Anyway the actual speed of an application varies with what kind of hardware it is being run on. The critical points are the usual microprosessor type (speed, fpu's and so on), speed of RAM (and ROM if used), speed of harddisk and so on. But often _more_ important is the way that the application has been written! Well, I want try to judge what is more fair to judge by, but just wanted to say there are many ways to perform speed tests. Usually this speed is not so critical (often in terms of seconds), but ofcourse there are applications where speed is the only essential factor.. Well, probably did not make you a lot wiser, just keep these things in mind...
Charlie.Mingo@p4218.f421.n109.z1.FidoNet.Org (Charlie Mingo) (05/19/91)
mariusk@Lise.Unit.NO (Marius Kjeldahl) writes:
MK> 1. Usually RAM is faster than ROM, thats why they incorporate things like
MK> shadowram and so on.
RAM may be slightly faster than ROM in the MS-DOS world, but on Macs the
opposite is true. Also, the comparison of ROM to RAM is a bit off, as with RAM
the code has to be loaded from disk in the first place. If you had gobs of RAM
to spare, you could just preload the whole thing at boot-time, but the ROM on my
Mac IIci is 512K, which would consume most of MS-DOS's 640K address space. If
you don't preload, then ROM is thousands of times faster than any disk access.
MK> 2. That is one of the drawbacks with the operating system in ROM - you'll
MK> usually need hardware to perform the upgrade. This kind of solution you are
MK> mentioning does not sound healthy.
Some of the MacOS is in ROM, the rest is put in the "System" file on the HD.
ROM overrides are fairly rare, and simply consist of a tweak substituting a RAM-based code segment for a ROM-based one. Owing to the design of the 680x0
series, this is easily accomplished by changing a single low memory value in
the trap dispatch table. ROM overrides are a complete nonissue in the Mac world.
* Origin: mingo@well.sf.ca.us mingo@cup.portal.com (1:109/421.4218)wchang@qin.Berkeley.EDU (William Chang) (05/19/91)
I believe the Mac ROM exists in order to make the Mac legally unclonable, by copyright. The original Lisa was more powerful, but the Mac came out with 64K ROM, 128K RAM, and 400K floppies, and ran essentially the same interface we are now using. Obviously a great deal of genius and hard work went into it. (X windows is how many megs? How fast is it on 50 Mhz workstations?) The more compact the code, the faster it is (usually!). Think of the Mac ROM as a collection of device drivers--the hardest software to write-- with the GUI as one big device. Nobody else has done as well, for better or for worse. William Chang (wchang@ucbarpa.berkeley.edu)
Charlie.Mingo@p4218.f421.n109.z1.FidoNet.Org (Charlie Mingo) (05/19/91)
wchang@qin.Berkeley.EDU (William Chang) writes:
WC> I believe the Mac ROM exists in order to make the Mac legally unclonable,
WC> by copyright.
You don't need to put your s/w ito ROMs to get extra copyright protection.
I believe the ROM's were used (i) to make it mich more difficult to
*physically* copy the OS; and (ii) to spped up the original 1984 mac: in the
old days, macs had only 128K of RAM and had to frequently purge and retrieve much
of the OS from slooow floppys. The ROMs freed up RAM for applications to use
and speeded up things because they were "preloaded" with the OS.
* Origin: mingo@well.sf.ca.us mingo@cup.portal.com (1:109/421.4218)krk@cs.purdue.EDU (Kevin Kuehl) (05/20/91)
In article <1991May19.021620.22656@agate.berkeley.edu> wchang@qin.Berkeley.EDU (William Chang) writes: >we are now using. Obviously a great deal of genius and hard work went >into it. (X windows is how many megs? How fast is it on 50 Mhz workstations?) Comparing the Mac interface to X windows is like comparing Apples and oranges. How many different architectures does the Mac interface run on? Can it take advantage of a much faster machine on the net as easily? You pay the price for generality. -- Kevin Kuehl krk@cs.purdue.edu
arst@rwing.UUCP (Mike Arst) (05/22/91)
Regarding the idea that, given a choice, someone should always buy and use Windows, rather than a Mac, doesn't work for all of us. The reason? What *software* is it that you want to use? That's entirely dependent upon the situation. The cost of the equipment and software, in general, cannot always be the sole determining factor. I started out in this business operating conventional phototypesetting equipment, then switched to using pseudo-typesetting software for CP/M, then pseudo-typesetting software for DOS; then I began working with Ventura Publisher for GEM; then I began investigating Pagemaker for the Mac. Finally, after several years of using Pagemaker, I discovered QuarkXPress 3.0 and found it to have the best combination of features and typographic functions I need to get my work done the way I want it done. For my purposes, it is the best of the systems I have used so far - hands down. QuarkXPress is NOT available for Windows (yet). It will be, and I reckon that at first it isn't going to be as stable as one wishes it were. Another factor in this decision, for me, would be font handling. I see message after message in some of the conferences carried on DOS machines to the effect that people are having a lot of trouble dealing with fonts under Windows. That was my own experience in the past for the short time that I used Windows. One font hassle after another. We've had our share of font problems with the Mac, but nothing like what we experienced under Windows. The place where I work has to support every Adobe font, and a lot of others besides. That's a *TON* of fonts. No way could we do our work quickly and efficiently under Windows - not a bleedin' chance. Not until the whole business of font handling under Windows is much improved. There are also a variety of programs that manipulate fonts and graphics (including color photographs) that, it seems to us, simply are not available for Windows yet, or are not sophisticated enough or bug-free enough to be worth using under Windows. So the question is not whether it's chiseled in stone that the one system, versus the other, is "the best." It's: what do you need to get done with it? We could not get our work done economically under Windows. Period. I am not a MacBigot at all (fully half of what I do involves using Unix-ish text processing tools and batch files on a DOS machine, with which I'm quite comfortable). But I could not in conscience recommend Windows to anyone who has to do publishing work at the level at which we do it. I would not cavalierly suggest that someone waltz right out and spend a fortune on Mac equipment. But if they need to do certain kind of work that is problematic under Windows, they might well be shooting themselves in the foot to try getting what they want that way. It would be a penny-wise and pound-foolish decision. Mike Arst, Seattle, WA polari!arst@sumax.seattleu.edu -- Mike Arst rwing!arst
glenn@gla-aux.uucp (Glenn Austin) (05/24/91)
In article <1991May18.050842.5732@cs.uoregon.edu>, akm@obelix.cs.uoregon.edu (Anant Kartik Mithal) writes: > So, my question is: if the Mac is faster than a "comparable" pc in > execution, what is the reason? Is it ROM? (I don't think so for the > reasons listed above.) What other things can make a difference? Two things -- processor effeciency and levels of routines. 1) Windows sits on top of (and beside) DOS. This is the reason that PM is faster -- its part of the OS. 2) The Motorola (and for that matter, any linear-addressing processor) is faster than segmented memory. 3) The average instruction length of normal instructions on the 80x86 processors is 5 bytes, read a byte at a time (usually -- hook up a logic analyzer and see for yourself!), where the 680x0 average instruction length is 3-4 bytes, read a long-word at a time (at worst case, a word at a time). Less than half the accesses to memory (RAM OR ROM) is faster. This is also why zero-wait state 80x86s show better speed increases than their 680x0 counterparts. > Anant Kartik Mithal akm@cs.uoregon.edu > Research Assistant, (503)346-4408 (msgs) > Department of Computer Science, (503)346-3989 (direct) > University of Oregon, Eugene, OR 97403-1202 How about that -- someone else from Eugune! :-) =============================================================================== | Glenn L. Austin | "Turn too soon, run out of room. | | Macintosh Wizard and | Turn too late, much better fate." | | Auto Racing Driver | -- Jim Russell Racing School Instructors | |-----------------------------------------------------------------------------| | Usenet: glenn@gla-aux.uucp | CI$: 76354,1434 | | GENie: G.AUSTIN3 | AOnline: GAustin | ===============================================================================
strobl@gmdzi.gmd.de (Wolfgang Strobl) (05/29/91)
Charlie.Mingo@p4218.f421.n109.z1.FidoNet.Org (Charlie Mingo) writes: >mariusk@Lise.Unit.NO (Marius Kjeldahl) writes: >MK> 1. Usually RAM is faster than ROM, thats why they incorporate things like >MK> shadowram and so on. > RAM may be slightly faster than ROM in the MS-DOS world, but on Macs the >opposite is true. ... How that? What kind of ROMs are used in Macs? > ... Also, the comparison of ROM to RAM is a bit off, as with RAM >the code has to be loaded from disk in the first place. If you had gobs of RAM >to spare, you could just preload the whole thing at boot-time, but the ROM on my >Mac IIci is 512K, which would consume most of MS-DOS's 640K address space. If >you don't preload, then ROM is thousands of times faster than any disk access. True, but irrelevant. Windows uses the protected mode and is able to load and run code everywhere in the 16M address space of the 80286+ processors. Parts of the system are loaded into RAM during Windows startup, others are loaded only on demand. This occurs only once, if the machine has enough RAM. So the difference we are talking about here is the time to read 512K Bytes once - takes half a second, on my machine. No big deal. Wolfgang Strobl #include <std.disclaimer.hpp>
seiler@vlsisj.uucp (%) (05/30/91)
In article <4799@gmdzi.gmd.de>, strobl@gmdzi.gmd.de (Wolfgang Strobl) writes: |> Charlie.Mingo@p4218.f421.n109.z1.FidoNet.Org (Charlie Mingo) writes: |> |> >mariusk@Lise.Unit.NO (Marius Kjeldahl) writes: |> |> >MK> 1. Usually RAM is faster than ROM, thats why they incorporate things like |> >MK> shadowram and so on. |> |> > RAM may be slightly faster than ROM in the MS-DOS world, but on Macs the |> >opposite is true. ... |> |> How that? What kind of ROMs are used in Macs? I am surprised that RAM is faster than ROM in the IBM clone world. What type of ROM's do IBM clones use? The types are: Mask Programmed ROM - fastest and largest memory type for a given geometry. The data is frozen in by metal layers added to the chip at the last stage of processing. Only practical if a large number of identical ROM's are to be made. PROM - programmed by blowing internal fuses. Also fast but size is more limited. EPROM - These are programmed by zapping with pulses of the correct voltage and rise time. If the package has a quartz window, they can be erased with UV light. These are slow. EEPROM (electrically erasable read only memory) - currently with very limited size. Used mainly to store a small amount of status information while the power is turned off. Some interesting work in ferro-electric memorys may change this. I suppose that IBM clones may use EPROM's which benefit by copying into RAM. The Mac uses mask programmed type, which are faster than static RAM's, let alone dynamic RAM's. That assumes the same technology is used ( an ECL RAM will be faster than a p MOS mask programmed ROM ). The big disadvantage of the mask programmed type is a significant set up cost for a run. EPROM has essentially no set up cost. However, after the fixed cost, mask programmed ROM are cheaper. In addition, some Mac's have a built video display which uses the main RAM to hold the display buffer. This slows down RAM access when the CPU contends with the video display. ROM doesn't have to contend with the video so it is slightly faster. By the way, this does not apply to plug in video cards. Bruce Seiler seiler@compass-da.com Disclaimer: Just because my parent company sells ROM's amd other IC's to Apple and PC chip sets to IBM doesn't PROVE I know what I'm talking about.
dant@ryptyde.UUCP (Daniel Tracy) (06/05/91)
Responding to the following: "Correct me if I am wrong, but in small (or tiny) memory model apps, the 80x86 is essentially a linear-addressing processor. I would tend to think it would be faster shuffling 16-bit addresses (since the segment registers do not change) than a Motorola with (is it?) 32-bit addresses." Well, not really. I'm assuming that even though the segment "window" doesn't have to be moved, the accessing routine is still slower. The window doesn't change, but it's still there. In order to request a memory address, a segmented chip must do an extra multiply (at least) every time. That is, it multiplies the address location within any segment by the segment being used, so it doesn't act as linear-addressing at all. The 386+ DOES have a fairly good linear memory mode, but this isn't used by any OS's except for Unix. Also, there are many other factors in 680x0 vs 80x86. Intel's line doesn't even come close in most cases to MC's chip line. Also, because the 80x86 began as 16-bit chips internally, many kludges had to be performed in order to maintain compatibility across the line, and thus the 680x0 line is also accelerating past the 80x86 at a faster clip because it isn't being held back by mode up mode implimentation. Sorry is this letter isn't spaced properly.
jgs@home.merit.edu (John Scudder) (06/05/91)
In article <1991May29.200007.9448@vlsisj.uucp> seiler@vlsisj.uucp (%) writes: >In article <4799@gmdzi.gmd.de>, strobl@gmdzi.gmd.de (Wolfgang Strobl) writes: >|> Charlie.Mingo@p4218.f421.n109.z1.FidoNet.Org (Charlie Mingo) writes: >|> >|> >mariusk@Lise.Unit.NO (Marius Kjeldahl) writes: >|> >|> >MK> 1. Usually RAM is faster than ROM, thats why they incorporate things >like >|> >MK> shadowram and so on. >|> >|> > RAM may be slightly faster than ROM in the MS-DOS world, but on Macs >the >|> >opposite is true. ... >|> >|> How that? What kind of ROMs are used in Macs? > >I am surprised that RAM is faster than ROM in the IBM clone world. What type of >ROM's do IBM clones use? The types are: [ lots of good stuff about ROMs deleted ] >Bruce Seiler >seiler@compass-da.com >Disclaimer: Just because my parent company sells ROM's amd other IC's to Apple > and PC chip sets to IBM doesn't PROVE I know what I'm talking about. Perhaps a contributing factor to this "RAM is faster than ROM" myth is the practice of some Plus and SE accelerators of copying the ROMs into accelerator RAM. The RAM is presumably faster than the ROMs in this case since it sits on a 32-bit bus instead of a 16-bit bus as the ROMs do. --John -- ** John Scudder ** Merit/NSFNET ** jgs@merit.edu ** no amusing quote ** ** Disclaimer: I speak for myself, not Merit. **
glenn@gla-aux.uucp (Glenn Austin) (06/06/91)
In article <1991Jun4.154854.19649@dbase.A-T.COM>, tomr@dbase.A-T.COM (Tom Rombouts) writes: > In article <0E010021.e0mxxc@gla-aux.uucp> glenn%gla-aux.uucp@skinner.cs.uoregon.edu writes: > > > >In article <1991May18.050842.5732@cs.uoregon.edu>, akm@obelix.cs.uoregon.edu (Anant Kartik Mithal) writes: > >> So, my question is: if the Mac is faster than a "comparable" pc in > >> execution, what is the reason? Is it ROM? (I don't think so for the > >> reasons listed above.) What other things can make a difference? > > > >Two things -- processor effeciency and levels of routines. > > [ rest of post deleted ] > > >2) The Motorola (and for that matter, any linear-addressing processor) is > >faster than segmented memory. > > Correct me if I am wrong, but in small (or tiny) memory model apps, > the 80x86 is essentially a linear-addressing processor. I would tend > to think it would be faster shuffling 16-bit addresses (since the > segment registers do not change) than a Motorola with (is it?) 32-bit > addresses. It would be -- if they dealt with 16-bit (or wider) fetches, but because of the roots of the 80x86 in the 8080, and the fact that extensions beyond the 8086 generally have a single prefix byte (which must be fetched before it can determine that it IS an extension to the 8086 instruction set), the 80x86 tend to be inefficient in memory accesses. This is (once again) why zero-wait-state RAM has more benefits on the 80x86 than it does on the Motorola 680x0 processors (which do long word and word fetches). =============================================================================== | Glenn L. Austin | "Turn too soon, run out of room. | | Macintosh Wizard and | Turn too late, much better fate." | | Auto Racing Driver | -- Jim Russell Racing School Instructors | |-----------------------------------------------------------------------------| | Don't take me too seriously -- I never do! :-) | |-----------------------------------------------------------------------------| | Usenet: glenn@gla-aux.uucp or glenn%gla-aux.uucp@skinner.cs.uoregon.edu | ===============================================================================
mikel@dosbears.UUCP (Mike Lipsie) (06/06/91)
In article <20@ryptyde.UUCP> dant@ryptyde.UUCP (Daniel Tracy) writes: > >Well, not really. I'm assuming that even though the segment "window" doesn't >have to be moved, the accessing routine is still slower. The window doesn't >change, but it's still there. In order to request a memory address, a segmented >chip must do an extra multiply (at least) every time. That is, it multiplies >the address location within any segment by the segment being used, so it doesn't >act as linear-addressing at all. Er. This explanation makes me worry about the rest of your logic. It does NOT do a multiply; it does an ADD. The segment register multiplied by 16 is added to the offset register. In 8086 mode this means the _equivalent_ of a four bit shift to the segment register. > The 386+ DOES have a fairly good linear >memory mode, but this isn't used by any OS's except for Unix. Also, there are >many other factors in 680x0 vs 80x86. Intel's line doesn't even come close >in most cases to MC's chip line. Also, because the 80x86 began as 16-bit chips >internally, many kludges had to be performed in order to maintain compatibility >across the line, and thus the 680x0 line is also accelerating past the 80x86 >at a faster clip because it isn't being held back by mode up mode implimentation. You can't be "better" and then "pass the competition". Make up your mind. -- Mike Lipsie dosbears!mikel@pyramid.com mikel%dosbears.uucp@ingres.com
f85-bli@byse.nada.kth.se (Bengt Lidgard) (06/06/91)
I heard this funny rumour that Apple is planning to release System 6 for Intel chips. To use on former DOS machines! Is this total nonsense ?!!! Is it possible???! Wondering, Bengt
kls30@duts.ccc.amdahl.com (Kent L Shephard) (06/11/91)
In article <1991Jun4.154854.19649@dbase.A-T.COM> tomr@dbase.UUCP (Tom Rombouts) writes: >In article <0E010021.e0mxxc@gla-aux.uucp> glenn%gla-aux.uucp@skinner.cs.uoregon.edu writes: >> >>In article <1991May18.050842.5732@cs.uoregon.edu>, akm@obelix.cs.uoregon.edu (Anant Kartik Mithal) writes: >>> So, my question is: if the Mac is faster than a "comparable" pc in >>> execution, what is the reason? Is it ROM? (I don't think so for the >>> reasons listed above.) What other things can make a difference? >> >>Two things -- processor effeciency and levels of routines. > >[ rest of post deleted ] > >>2) The Motorola (and for that matter, any linear-addressing processor) is >>faster than segmented memory. Excuse me but this is not the case. If you have an OS like Unix, System 7 or any OS that provide virtual memory you are back to -(drum roll please) a segmented OS. Pages are just large segments. But honestly it depends entirely on how efficient the architecture to to begin with. An efficiently designed segmented arch. can be faster than a non-segmented one. Also the entire system will design will effect performance. >Correct me if I am wrong, but in small (or tiny) memory model apps, >the 80x86 is essentially a linear-addressing processor. I would tend >to think it would be faster shuffling 16-bit addresses (since the >segment registers do not change) than a Motorola with (is it?) 32-bit >addresses. > >Of course, this is straying from discussion of Win3.... > >Tom Rombouts Torrance 'Tater tomr@ashtate.A-T.com -- /* -The opinions expressed are my own, not my employers. */ /* For I can only express my own opinions. */ /* */ /* Kent L. Shephard : email - kls30@DUTS.ccc.amdahl.com */
bitting-douglas@cs.yale.edu (Douglas Bitting) (06/12/91)
In article <56nD02AQ08cd01@JUTS.ccc.amdahl.com> kls30@DUTS.ccc.amdahl.com (Kent L. Shephard) writes: >>In article Something'er'other, someone wrote: >>>2) The Motorola (and for that matter, any linear-addressing processor) is >>>faster than segmented memory. > >Excuse me but this is not the case. If you have an OS like Unix, System 7 >or any OS that provide virtual memory you are back to -(drum roll please) >a segmented OS. Pages are just large segments. Paged != Segmented. Pages are, by definition, fixed in size. Segments are, by definition, variable in size. To have fixed page segments defeats the purpose of the hardware support given to segmentation. This aside, a paged system is much more efficient than a segmented system. This is because there is not nearly the amount of overhead to keep track of on a paged System. For example, if one had a "demand segmenting" system vs a "demand paging" system (two possible ways to implement VM given different hardware support), the complexity of the OS would be vastly different. In the demand segmenting system, not only owuld the OS have to worry about swapping in a segment, but it would also have to worry about "creating" the right amount of space tin order to fit the segment in. Most of the time, a perfect fit cannot be made so space is wasted in memory and overall performance dips. On a demand paging system, if a page needs to be swapped in, it is just a matter of swapping out a page to create the necessary space... much simpler and more efficient. Also, (this is in reply to the quote of the quote of the...) not all Macintosh Models are linearly addressed (this is especially true with the introduction of VM in System 7). On some models with the PMMU (the IIci comes to mind), memory is not linear even *WITHOUT* virtual memory. The PMMU makes it look that way to software, but it really isn't the case... > >-- >/* -The opinions expressed are my own, not my employers. */ >/* For I can only express my own opinions. */ >/* */ >/* Kent L. Shephard : email - kls30@DUTS.ccc.amdahl.com */ --Doug -- Doug Bitting | "And we know that in all things God works PO Box 3043 Yale Station | for the good of those who love him..." New Haven, CT 06520 | --Romans 8:28 bitting@cs.yale.edu +------------------------------------------
aaron@jessica.stanford.edu (Aaron Wallace) (06/12/91)
In article <1991Jun12.055711.21457@cs.yale.edu> bitting-douglas@cs.yale.edu (Douglas Bitting) writes: >In article <56nD02AQ08cd01@JUTS.ccc.amdahl.com> kls30@DUTS.ccc.amdahl.com (Kent L. Shephard) writes: >>>In article Something'er'other, someone wrote: >>>>2) The Motorola (and for that matter, any linear-addressing processor) is >>>>faster than segmented memory. >> >>Excuse me but this is not the case. If you have an OS like Unix, System 7 >>or any OS that provide virtual memory you are back to -(drum roll please) >>a segmented OS. Pages are just large segments. > >Paged != Segmented. Pages are, by definition, fixed in size. Segments are, by >definition, variable in size. To have fixed page segments defeats the purpose > [etc...] >Also, (this is in reply to the quote of the quote of the...) not all Macintosh >Models are linearly addressed (this is especially true with the introduction of >VM in System 7). On some models with the PMMU (the IIci comes to mind), memory >is not linear even *WITHOUT* virtual memory. The PMMU makes it look that way >to software, but it really isn't the case... > I've never actually programmed a Mac (life does have it's small blessings!), but I remember that my girlfriend once had do for a Pascal class. I remember her having to worry about arranging static data into segments and getting segment too large errors. I've read elsewhere that, lovely as the linear address space is, Apple went through all kinds of hoops and backflips to simulate a segmented memory system on the Mac. Personally, I think segments are great. 64K segments, that's a different matter... Aaron Wallace
doner@Aero.org (John Doner) (06/12/91)
In article <1991Jun12.152813.20074@leland.Stanford.EDU>, aaron@jessica.stanford.edu (Aaron Wallace) writes: |> |> I've never actually programmed a Mac (life does have it's small blessings!), |> but I remember that my girlfriend once had do for a Pascal class. I remember |> her having to worry about arranging static data into segments and getting |> segment too large errors. I've read elsewhere that, lovely as the linear |> address space is, Apple went through all kinds of hoops and backflips to |> simulate a segmented memory system on the Mac. What looks like a segmented memory system to some is mainly just a compiler limitation. They use 16-bit integers as array subscripts, so arrays get limited to 2^16. They always generate branches using the 16-bit offset instructions, instead of the 32-bit ones, so CODE segments get limited to 32K. None of this is Apple's doing, or intrinsic to the hardware or the Mac OS. One limitation that is in the OS is the jump table size of 32K. This limits the number of external (i.e., inter-CODE-resource) references accordingly. Not much of a problem, except with MacApp. (Does System 7 fix this?) Actually, it's hard to fault the compiler writers. It seemed so reasonable at the time. But with today's cheap memory, it's a bad idea to build those limitations into the compilers. John Doner
tom@mims-iris.waterloo.edu (Tom Haapanen) (06/13/91)
John Doner <doner@Aero.org> writes: > aaron@jessica.stanford.edu (Aaron Wallace) writes: >|> I've never actually programmed a Mac [...] I remember >|> having to worry about arranging static data into segments and getting >|> segment too large errors. I've read elsewhere that, lovely as the linear >|> address space is, Apple went through all kinds of hoops and backflips to >|> simulate a segmented memory system on the Mac. > What looks like a segmented memory system to some is mainly just a compiler > limitation. They use 16-bit integers as array subscripts, so arrays get > limited to 2^16. They always generate branches using the 16-bit offset > instructions, instead of the 32-bit ones, so CODE segments get limited to > 32K. None of this is Apple's doing, or intrinsic to the hardware or the > Mac OS. Having done development work on a Mac since early January, 1984 (although admittedly not recently), I can confirm that it is *NOT* a MC68000 or Mac hardware limitation. It is, however, a limitation built into the Mac OS, designed to make it possible to run reasonable apps on a machine with just 128K or RAM. by swapping segments in and out of main memory. That, of course, is just like Windows' segment-swapping. > Actually, it's hard to fault the compiler writers. It seemed so reasonable at > the time. But with today's cheap memory, it's a bad idea to build those > limitations into the compilers. Compiler writers? Heck, we were using a cross-assembler to do this, and we had the same limitation! There weren't a lot of development tools available before January 24... [ \tom haapanen --- university of waterloo --- tom@mims-iris.waterloo.edu ] [ "i don't even know what street canada is on" -- al capone ]
ccimino@athena.mit.edu (c cimino) (06/13/91)
It seems likely that the difference in speed is largely based on the underlying system software. Windows is less efficient because it is built on top of DOS instead of DOS being redesigned for Windows. -chris cimino my thoughts are my own.