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
carter@cat23.cs.wisc.edu (Gregory Carter) (05/12/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. > >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 Your impression that it takes more Intel machine is correct, intel CPU's are brain damaged. --Gregory
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.
cadsi@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. | |----------------------------------------------------------------------------|
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 *
dsals@vms.macc.wisc.edu (David Sals) (05/17/91)
I worked at ComputerLand for a while, and was asked to compare
window and the mac quite often. The main differences I have seen
with regard to new users are as follows:
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.
2) Windows is a little more awkward, a little less intuitive.
When Microsoft wrote windows, they had to make it look and
function significantly differently from the mac system so that
they wouldn't get sued (they got sued anyway). While the
differences are just fine for most DOS users, people who
haven't used computers before usually seemed much more confused
with windows. They would try to do things the way they did
them on the macintosh, and it just doesn't work. Note: even
though you are using a graphical interface, you are still
using the DOS filing system. Whenever you want to add a new
program to your windows library, you have to locate it in the
normal DOS mode of access.
3) This is the most important difference, in my oppinion. When
programs are written for the macintosh, they are all (with a
very few exceptions) written to use the same menu structure,
the same mouse functions, often even the same commands (cut,
copy, paste, print, all show up in the same place in most
programs). What this means to a new user, is that, once they
learn how to use ONE program on the mac, it is very easy to
transfer that knowledge to other software. The learning curve
goes way up.
Now let's talk about windows. Many programs that the user
might want to use, aren't even available for windows. Yes,
you might be able to start Wordperfect from windows, but you
won't be able to take advantage of the cut/paste or linking
features which make windows worth having. More importantly,
since there has been no standard set for DOS programs, the
interfaces are all over the place. Every time a user wants
to learn a new program, they are going to have to start from
scratch (at least as far as memorizing the commands, if not
learning the functions of the program). The learning curve
is much lower.
What this all comes down to, is that windows is a poor substitute
for a macintosh. I have nothing against DOS systems, and in fact
use one often, but I almost never use windows. It's not a lot
more than a toy to me. I would rather use batch commands to start
my programs.
If you want to take advantage of specific DOS software, get a DOS
system, and if you like, get windows too. If you want to get a
graphically based, intuitive machine, get a macintosh. Windows is
a poor substitute at best.
:-D ave
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.
>
>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.comtneff@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.
akm@obelix.cs.uoregon.edu (Anant Kartik Mithal) (05/18/91)
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
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...
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)
plim@hpsgwp.sgp.hp.com (Peter Lim) (05/20/91)
/ akm@obelix.cs.uoregon.edu (Anant Kartik Mithal) / 1:08 pm May 18, 1991 / 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? $ Is it really so ? First off, it is hard to determine what is a "comparable" pc to a mac. Secondly, I tend to find that Windows has a greater minimum requirement for things to start rolling. From my experience, for "properly" configured system vs. "in-properly" configured system, a proper 25 MHz non-cached 386 can run (say PowerPoint) up to 5 times faster that a 33 Mhz cached 386. This was clocked with printing to a PaintJet printer. If you have been trying to get Windows to fly with 2 MB RAM, then you WILL be disappointed even with a 33 Mhz 386. I would say, a minimum of 4 MB RAM is preferred; with proper disk cache configuration --- then, Windows will run very nicely. It is not fair for me to say how it compares with the Mac (heck, I only have a lowly Mac/SE original with 4 MB RAM). But, like I said above, Windows need a lot more before it starts to fly. So, I would tend to say it is not fair comparison for a mac and pc both equiped with 2 MB RAM. Regards, ___o``\________________________________________________ ___ __ _ _ Peter Lim. V````\ @ @ . .. ... .- -> 76 MIPS at under US$20K !! --- -- - - /.------------------------------------------------ === == = = >--_// . .. ... .- -> 57 MIPS at under US$12K !! `' . If you guessed SUN, IBM or DEC, you are wrong ! E-mail: plim@hpsgwg.HP.COM Snail-mail: Hewlett Packard Singapore, Tel: (065)-279-2289 (ICDS, ICS) Telnet: 520-2289 1150 Depot Road, Singapore 0410. #include <standard_disclaimer.hpp>
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 | ===============================================================================
tomr@dbase.A-T.COM (Tom Rombouts) (06/04/91)
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. Of course, this is straying from discussion of Win3.... Tom Rombouts Torrance 'Tater tomr@ashtate.A-T.com
s902113@minyos.xx.rmit.oz.au (Luke Mewburn) (06/05/91)
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. Not really. apps for the 680x0 chips can use a 'short' addressing, which is 32K either side of 00000000 (ie bottom & top 32K of address space). which is really fast. >Of course, this is straying from discussion of Win3.... Yeah, I think the mac groups need a '.advocacy', like the amiga groups, for all sorts of mac vs {ibm|amiga|next|unix|other gui}. >Tom Rombouts Torrance 'Tater tomr@ashtate.A-T.com -- ____________________________________________________________________________ | Luke Mewburn [Zak] | #disclaimer: I _own_ these opinions, | | s902113@minyos.xx.rmit.oz.au | No-one else deserves them :-) | ----------------------------------------------------------------------------
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.
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 | ===============================================================================
risto@tuura.UUCP (Risto Lankinen) (06/06/91)
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: >[ 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. >Of course, this is straying from discussion of Win3.... Hi! To stray back, a small model program for Windows doesn't necessarily gain as much as it would in DOS, where the library calls and indirect references to data really are near/short. In Windows, all calls to external modules will inavoidably be far, most of which also require pointers to be long. The (static) library calls still are near, but there is an option of not using them at all, in which case you'll get 99% identical executables in both small and medium model for many source codes. (This is *not* to say, that programs made for Windows are inefficient in one way or other, nor am I doing any comparison between Windows and Mac!) Terveisin: Risto Lankinen -- Risto Lankinen / product specialist *************************************** Nokia Data Systems, Technology Dept * 2 3 * THIS SPACE INTENTIONALLY LEFT BLANK * 2 +1 is PRIME! Now working on 2 -1 * replies: risto@yj.data.nokia.fi ***************************************
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
c60c-1jo@e260-1e.berkeley.edu (Payam Mirrashidi) (06/11/91)
Could any tell me what the actual number of MIPS and FLOPS the various Motorola have. I guess that the numbers for FLOPS are going to drastically different if a floating point co-processor is included, so those numbers would be great too. Payam
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.