merlyn@rose3.rosemount.com (Brian Westley) (08/15/88)
Earle R. Horton writes: [description of microsoft software crashes] > How do they (Apple) do this? You either have to believe that >MicroSoft delibrately takes shortcuts which they know will compromise >the future integrity of their software, or that Apple Computer Company >does not fully document their operating system, perhaps even >internally. I know what I believe... Well, MicroSoft deliberately takes shortcuts. Really. Excel needs to be loaded in the first 1 meg of RAM to run (last I heard). Their free MacroMaker was evaluated as "not worth it" by many netters because it screws up. There is PLENTY of software written LONG AGO that runs under multifinder, on wider screens (or under SteppingOut), on Apple's weird multi-screen arrangement, etc. Microsoft really DOES write crappy software, which is why I refuse to buy any of their junk. They have said they want to be the IBM of software, and they are well on their way... Merlyn LeRoy
pff@thumper.bellcore.com (Peter Ferris) (08/17/88)
Merlyn, It's my understanding that Excel has been fixed so it no longer requires "the first MB of RAM". I think you're really throwing the baby out with the bathwater on this one. To say Microsoft is writes "crappy" software is a pretty hard statement. On what do you base such a statement? I want to see something other than "... Excel needs to be loaded in the first 1 meg of RAM to run (last I heard). Their free MacroMaker was evaluated as "not worth it" by many netters because it screws up. ". Listen to yourself! "... I heard", "...screws up". This is supposed to be a technical forum. I'd welcome hearing your FIRST HAND experience with Microsoft, not "a friend told me", or "I read this somewhere". Further, I'd like to know what Microsoft did or DIDN'T do to help you. I have found them to have one of the better product support groups in the industry. Not perfect. But very good. If you think you can do better, then have at it! Maybe you're Bill Gates' successor in the industry. Competition makes this country what it is. Merlyn, I don't want to dump on you, as an individual. I don't know you. I can appreciate a person wanting to collect user feedback before forking over hundreds for a "pig-in-a-poke" piece of software, but to come out of the woodwork and say "MICROSOFT TAKE SHORTCUTS" and begin character assasination on a MAJOR vendor of software really isn't too cool (or factual or...). Then again, Apple hasn't always perfectly documented every nuance of their work either... I, too, have my suspicions. Suffice it to repeat two funde- mental laws of computing: "Fallible men write fallible software..." (Are YOU Perfect?!) "If carpenters built house like programmers write software, the first wood-pecker that comes along would destroy civilization." Nothing personal, Merlyn... just can't let you squeak by on that blanket statement about Microsoft! Later... Pete Ferris pff@thumper.bellcore.com
tedj@hpcilzb.HP.COM (Ted Johnson) (08/17/88)
>Well, MicroSoft deliberately takes shortcuts. Really. Excel needs >to be loaded in the first 1 meg of RAM to run (last I heard). >Their free MacroMaker was evaluated as "not worth it" by many netters >because it screws up. > >There is PLENTY of software written LONG AGO that runs under >multifinder, on wider screens (or under SteppingOut), on Apple's >weird multi-screen arrangement, etc. > >Microsoft really DOES write crappy software, which is why I refuse to >buy any of their junk. They have said they want to be the IBM of >software, and they are well on their way... I agree! I read "Programmers at Work" a while ago (it is a book of a bunch of interviews with famous programmers), and one of the things that Bill Gates (CEO of MicroSoft) kept talking about (and considered as the sign of a good programmer) was doing wierd things to squeeze every bit of performance out of the hardware. -Ted
imp@crayview.msi.umn.edu (Chuck Lukaszewski) (08/19/88)
In article <1289@thumper.bellcore.com>, pff@thumper.bellcore.com (Peter Ferris) writes: > Merlyn, > It's my understanding that Excel has been fixed so it no longer requires "the first MB of RAM". I think you're really throwing the baby out with the bathwater > on this one. To say Microsoft is writes "crappy" software is a pretty hard > statement. On what do you base such a statement? I want to see something I'm sure that not everyone has had bad experiences with Microsoft. Well, I would like to add my two cents worth. The following is my *opinion* based on working with Microsoft products: First, Microsoft has acquired a deserved reputation in the last two years that they rush products to the market. Corallary: the users get to debug the pro- duct. This was certainly true with two major software releases: Word 3.0 and Microsoft Mail. I personally have crashed both software releases in SEVERAL different ways. Both products are sound in concept--but were rushed to market. In the case of Word 3.0, Microsoft had apparently cashed everyone's checks and was legally in the position of having to ship. In fairness, most of those bugs have been corrected, but we're talking major bugs here, things that should never have been in a release. Also in fairness to Microsoft, this reputation is recent and can be fixed, I think. I was terribly disappointed by being able to crash Microsoft Mail so easily. Second, and this is a question of programming philosophy, Microsoft has standardized on an in-house version of the C language, and they have trans- lators so that they don't have to rewrite lots of code for multi-machine packages. This is nice from an administrative standpoint (i.e. cost) but you pay the price in performance. For example, and this is a *technical* problem I have with Microsoft, they do many things on the Mac in non-inside-mac-fashion. Specifically, they do strange things in checking their environment (i.e. testing addresses greater than $400000 and $800000 for wraparound). Try looking in Excel 1.5 for this. This kind of hardware dependence is not a good idea. BTW, I dislike Practical Computer Applications programs for the same reason -- the games are GREAT, but they have largely thrown out the toolbox altogether. When the Mac II came out, none of their stuff ran. I guess I'll leave it at that for now. I have other problems with Micro- soft, but I'll save them for rebuttals. ---===---===---===---===--/* Chuck Lukaszewski */--===---===---===---===--- ARPAnet/NSFnet/MRnet: AppleLink: SnailMail: Ma Bell: imp@crayview.msi.umn.edu UG0138 Minneapolis MN 55418 612/789-0931 ---===---===---===---===--/* Chuck Lukaszewski */--===---===---===---===--- ARPAnet/NSFnet/MRnet: AppleLink: SnailMail: Ma Bell: imp@crayview.msi.umn.edu UG0138 Minneapolis MN 55418 612/789-0931
jnp@calmasd.GE.COM (John Pantone) (08/19/88)
(Peter Ferris) writes: >It's my understanding that Excel has been fixed so it no longer >requires "the first MB of RAM". I think you're really throwing the >baby out with the bathwater on this one. To say Microsoft is writes >"crappy" software is a pretty hard statement. On what do you base >such a statement? I want to see something other than... >...omissions... >... just can't let you squeak by on that blanket statement about >Microsoft! Later... Peter, I can only guess that you haven't had to deal with Microsoft's MSDOS/OS-2 stuff. There have been - for many years - outrageous bugs in the MSDOS assembler (MASM) with regard to arithmetic, masking and logical operations. There are enough things which are frustrating about MSDOS and OS/2 to make me wish I had never even entered the field. An early version (1 or 2) of MS-C used to hang up, from time to time, for no apparent reason, and issue the error message: "Sucking Mud". I swear to GOD, this is true! I will grant that MS's Macintosh stuff is CURRENTLY rather nice - except we can't forget MSWORD's abortive introduction (should have been called MSBUG - NO SMILEY's HERE :-( and how about the bizarre implementation of the interface - no menu resources, etc.? I agree that blanket statements such as XXX's stuff stinks, aren't particularly useful, nor productive; but you have to cut people a little slack - some of the software vendors in MICRO-LAND are so frustrating that it can drive you bats... Microsoft is on my list of "crazy makers". -- These opinions are solely mine and in no way reflect those of my employer. John M. Pantone @ GE/Calma R&D, 9805 Scranton Rd., San Diego, CA 92121 ...{ucbvax|decvax}!sdcsvax!calmasd!jnp jnp@calmasd.GE.COM GEnie: J.PANTONE
merchant@eleazar.dartmouth.edu (Peter Merchant) (08/19/88)
In article <870217@hpcilzb.HP.COM> Ted Johnson writes: >I agree! I read "Programmers at Work" a while ago (it is a book of >a bunch of interviews with famous programmers), and one of the >things that Bill Gates (CEO of MicroSoft) kept talking about >(and considered as the sign of a good programmer) was doing wierd >things to squeeze every bit of performance out of the hardware. On the other hand, I get rather psyched when, under MultiFinder on my one meg Mac Plus, I can run MS-Word and my terminal program at the same time and switch between the two. My terminal program takes up 300K and Word seems to run fine in <300K. Compare that with, say, FullWrite. I'm not saying that Word is better than FullWrite, I don't want to start that war up. I'm merely pointing out that most of Microsoft's software seems to run very nicely in small amounts of memory and this might be a feature of "doing weird things". --- "Wise guys realize Peter Merchant (merchant@eleazar.UUCP) There's danger in emotional ties..." (merchant@eleazar.dartmouth.edu) (Peter.G.Merchant@dartmouth.edu)
dtw@f.gp.cs.cmu.edu (Duane Williams) (08/19/88)
In <6766@umn-cs.cs.umn.edu>, Chuck Lukaszewski writes: | First, Microsoft has acquired a deserved reputation in the last two years | that they rush products to the market. Corallary: the users get to debug | the product. This was certainly true with two major software releases: | Word 3.0 and Microsoft Mail.... | | Also in fairness to Microsoft, this reputation is recent and can be fixed, I | think. The reputation may be recent, but the misbehavior at Microsoft is not. The initial version of Microsoft Multiplan for the Mac in 1984 was recalled from dealers' shelves very soon after release. -- uucp: ...!seismo!cmucspt!me.ri.cmu.edu!dtw arpa: dtw@cs.cmu.edu
kmw@ardent.UUCP (Ken Wallich) (08/20/88)
In article <6766@umn-cs.cs.umn.edu> imp@crayview.msi.umn.edu (Chuck Lukaszewski) writes: > >First, Microsoft has acquired a deserved reputation in the last two years that >they rush products to the market. [...] > >Also in fairness to Microsoft, this reputation is recent and can be fixed, I >think. CAN be fixed, yes, WILL be fixed? I doubt it. Recent? Geesh, one gets the impression that you haven't been using Microsoft products very much. I have NEVER liked Microsofts' software. The company started by writing hacked code that sorta worked, and has continued with this as a business plan. On the Mac side, lets take Microsoft BASIC. This was the first "language" available for my 128k mac, so I bought it. The documentation was mediocre, but then so was Apples, so I can't really complain about that. It was trivial to crash your mac running Microsoft BASIC. Within 6 months or so of it's release (I think I have the timing right), they released an update that cost 1/2 of the cost of the original package (sound familiar?). In this case, however, you didn't get an entire new system, with new manuals and MAJOR upgrades. This was suppose to be a significant performance improvement because what they did was replace the serially scanned symbol table with a hashed one. This company had been writing BASIC interpreters for a few YEARS before the Mac one, and they hadn't learned to HASH THE SYMBOL TABLE? Geesh, I used hashing in my "mock" interpreter several years earlier in college. Anyway, it sped up the interpreter about 5%, which wasn't worth the cost. By then I had a C compiler, so I put away this package forever. Of course, when the new versions of the MacOS came out, Microsofts products all broke. If they haven't learned how to follow the programming guidelines YET, then I doubt they ever will. I figured out then that Microsoft hadn't grown up, just out. They made more products for more machines, but the quality hadn't improved over the years. I haven't bought a Microsoft package since. -- Ken Wallich Ardent Computer Corp uunet!ardent!kmw Sunnyvale, California, USA "Slimey? Mud hole? My HOME this is!"
earleh@eleazar.dartmouth.edu (Earle R. Horton) (08/20/88)
In article <9867@dartvax.Dartmouth.EDU> Peter.G.Merchant@dartmouth.edu (Peter Merchant) writes: >... I'm merely pointing out that most of Microsoft's software seems to >run very nicely in small amounts of memory and this might be a feature of >"doing weird things". This hits the nail right on the head. Generally, "high performance" software on most any system has to do "weird" stuff. With the Macintosh, the documentation for programmers does not really specify just how weird you can get. Or if it does, it states things in an ambiguous fashion. When Apple changes things, it is very hard to determine from the documentation whether they are merely changing a "reserved" part of the operating system, or whether they are encroaching into areas that actually have belonged to application programmers. I don't know really whose fault this is, but I sure wish there was some way to determine when programming the Mac exactly what is and what is not allowed. I would like to be able to get this information from a single source, too. Now, you have to read Inside Macintosh and four or five Technical Notes to find out how some things work. I wonder if MS-DOS gives programmers and users the same problems as Apple system software does? Mr. Spock! This disk is damaged! Do you want to initialize it? Earle R. Horton. H.B. 8000, Dartmouth College, Hanover, NH 03755
jherr@umbio.MIAMI.EDU (Jack Herrington) (08/20/88)
in article <9867@dartvax.Dartmouth.EDU>, merchant@eleazar.dartmouth.edu (Peter Merchant) says: > > .... I'm merely pointing out that most of Microsoft's software seems to > run very nicely in small amounts of memory and this might be a feature of > "doing weird things". .... > But with larger memory, programs like Excel won't take advantage of that. Weird, but I have to admit, all around I really like WORD, it is fast, dependable (in most cases), has RTF, refreshes the screen really quickly. Has good keyboard commands for programmer types like me. Definitely cool. So I can live with the little quirks of Excel and Word. Jack Herrington
erics@eleazar.dartmouth.edu (Eric Schlegel) (08/20/88)
In article <9872@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: >When Apple changes things, it is very hard to determine from the >documentation whether they are merely changing a "reserved" part of >the operating system, or whether they are encroaching into areas that >actually have belonged to application programmers. For example? It's always seemed to me that Apple is fairly good about documenting what an application programmer can do and what he or she shouldn't touch. What specific instances have you seen to the contrary? eric ------ Eric Schlegel | DISCLAIMER: I'm just a poor college student, eric.schlegel@dartmouth.edu | which means I'm not responsible for what I | say and I can't pay you if you sue me anyway.
earleh@eleazar.dartmouth.edu (Earle R. Horton) (08/20/88)
In article <9874@dartvax.Dartmouth.EDU> erics@eleazar.dartmouth.edu (Eric Schlegel) writes: >In article <9872@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: >>When Apple changes things, it is very hard to determine from the >>documentation... >For example? It's always seemed to me that Apple is fairly good about >documenting what an application programmer can do and what he or she shouldn't >touch. What specific instances have you seen to the contrary? Popup menus. SCSI interface changed. *PRINTING* Who outside of Apple (or inside) has any idea how printing works? I have written a printer driver for the Mac, and sold an article to MacTutor about it (which they were very happy to buy). I don't have the foggiest if half the code in my driver is "compatible" or not, and no way to find out except by waiting for the System release that breaks it. (That's why it's free.) Required documentation for writing the driver was the PHONEBOOK edition of IM, and two Tech Notes. They ain't sayin' nuthin' about printing. I have read thousands of pages of computer documentation, and the Apple stuff is on nice slick paper, but it doesn't have half the informational content of, say, VMS documentation. I am not blaming Apple for this because if they were to raise the quality of the documentation to an acceptable level, I know I couldn't afford it. At 20 bucks or whatever I paid for IM V, it was definitely a bargain, but I just wish I could have paid 40 bucks and got twice as much. Maybe I'll buy Joel West's book... Mr. Spock! This disk is damaged! Do you want to initialize it? Earle R. Horton. H.B. 8000, Dartmouth College, Hanover, NH 03755
omullarney@cs.tcd.ie (omullarney@csvax1.cs.tcd.ie) (08/21/88)
In article <1289@thumper.bellcore.com>, pff@thumper.bellcore.com (Peter Ferris) writes: > To say Microsoft is writes "crappy" software is a pretty hard > statement. On what do you base such a statement? I want to see something > other than "... Excel needs > [Wooly claims deleted] > ". Listen to yourself! "... I heard", "...screws up". This is supposed to > be a technical forum. I'd welcome hearing your FIRST HAND experience with > Microsoft, not "a friend told me", or "I read this somewhere". Further, I'd > like to know what Microsoft did or DIDN'T do to help you. We bought a MicroSoft Fortran compiler some time ago ($400-500) for the (gasp - wait for it) IBM PC (no, really, I use Mac's now). We were working on a graphics project in Alsys Ada and wanted to write an interface to code developed in MS-Fortran. We never did - after months of working on it and going nowhere fast, we shelved it, and got in touch with MS technical support to see if they could help us. A very brief reply told us that the memory model used by MS on the PC "makes assumptions about the relationship between the styack segement register and the data segment register, it always assumes they are the same, SS=DS". (For those unfamiliar with the PC, all EXEcutable files deal with four segements of memory - stack, data, code and extra, using different ones at different times if the requirements for any climb above 64K). Now, if that isn't cutting corners, what is? Everybody else uses all four segements (or at least the main three) - that's what they are there for, but good old MS follow their usual line in plain old fashioned bloody mindedness in what seems to be a concerted effort to ensure that their stuff is incompatible with everything else (apart from their own stuff). Addmittedly, they do not guarantee that their compilers will work with any other than those in their product line, but then again, nor do Alsys, and their compiler does; it is well designed - no corners cut. Cost us several months to duplicate work, but we ended up with a better system :-) Now - Word: that is a lovely piece of work! Oliver
imp@crayview.msi.umn.edu (Chuck Lukaszewski) (08/22/88)
In article <9250@cs.tcd.ie>, omullarney@cs.tcd.ie (omullarney@csvax1.cs.tcd.ie) writes: > We bought a MicroSoft Fortran compiler some time ago ($400-500) for the > (gasp - wait for it) IBM PC (no, really, I use Mac's now). We were working Thanks Oliver - The very first thing I should have criticized in my post last week was Microsoft Fortran for the Mac. We purchased Microsoft Fortran for one of the professors at the Minnesota Super- Computer Institute, and I was given the task of converting to the Mac a couple of pieces of Fortran courseware that ran on Sun workstations. I sat down and got to work and ran into problem after problem after problem. To begin with, the documentation was terrible. By that I mean that basic things like execution environment weren't even discussed, and the documentation on the linker, compiler, etc was missing crucial details. Then I discovered that, contrary to Microsoft's advertising, many toolbox calls WERE NOT supported. The first ones I ran into were in QUICKDRAW of all places. I ended up having to hack some 68000 trap invoc- ations into the generated code in order to complete the project. Well, I haven't had to touch Microsoft Fortran since then (I usually work in 680x0 or C), but I did hear something very relevant and very curious. It seems that Microsoft didn't actually do the compiler. It was really a company called Absoft, which makes Fortran compilers. Fine. Well, they have THREE versions of a Fortran compiler for the Mac. It is the low-end one that they sold to Micro- soft. Absoft sells on its own a product called Fortran/020 for the Mac which uses the IDENTICAL manual, but at least has all of the trap calls in it. Looks like Microsoft was shortchanged in addition to all of Microsoft's customers. Perhaps better homework on Microsoft's part would have changed the situation, but then again, they don't seem to be into checking products for bugs before they get shipped. Heh - we still haven't heard from the Microsoft boys yet on this particular discussion. I hope they're either planning a revolution or looking for new jobs. ---===---===---===---===--/* Chuck Lukaszewski */--===---===---===---===--- ARPAnet/NSFnet/MRnet: AppleLink: SnailMail: Ma Bell: imp@crayview.msi.umn.edu UG0138 Minneapolis MN 55418 612/789-0931
dlw@hpsmtc1.HP.COM (David Williams) (08/23/88)
> Wasn't Excel released for 128K machines? Nope! Try the Macintosh Plus a 1 megabyte machine. >Then the software DID last for 2 generations of hardware..... pretty >good... Nope, pretty bad, Apple's engineers had to keep adding patches to the SYSTEM software to ensure that Microsofts code would run! Apparently someone finally got tired of catering to their sloppy programming and stopped putting patches in to allow Excel to reside in the first 1 meg of a multi meg machine and MicroSoft had to actually fix their code. Virtually every Microsoft product for the Mac has been released with serious bugs and this is since the 128k days and now it continues into the MacII timeframe. --David MS-DOS, just say NO!
casseres@Apple.COM (David Casseres) (08/23/88)
In article <9877@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: > *PRINTING* Who outside of Apple >(or inside) has any idea how printing works? I have written a printer >driver for the Mac, and sold an article to MacTutor about it (which >they were very happy to buy). I don't have the foggiest if half the >code in my driver is "compatible" or not, and no way to find out >except by waiting for the System release that breaks it. (That's why >it's free.) Required documentation for writing the driver was the >PHONEBOOK edition of IM, and two Tech Notes. They ain't sayin' >nuthin' about printing. Your last sentence says it all: Apple has never claimed to be offering any support to people who want to write printer drivers. Printer drivers that fully support our standards, are backward-compatible with existing applications, fully support the device-independent printing model, and have a good chance of being forward-compatible are very hard to write. About half a dozen people inside Apple know how to do it, and even the best of them couldn't do it without inside access to the System programmers and to the other people writing Apple printer drivers. A document that really explained how to do the job would be very large, everybody would REALLY hate what it told you to do, and it would probably be obsolete by the time it became available. David Casseres
anson@spray.CalComp.COM (Ed Anson) (08/23/88)
In article <15952@apple.Apple.COM> casseres@apple.com.UUCP (David Casseres) writes: > > Apple has never claimed to be offering >any support to people who want to write printer drivers. Not quite true. At the spring developers conference, last April, an Apple representative publicly offered support to printer developers who wanted to develop drivers for their products. That offer was followed up by phone calls and links promising specific support. Then there was a sudden change of policy. NOW apple expressly does not support driver development. The stated reason is that they don't know how to do it. > A document that really >explained how to do the job would be very large, everybody would REALLY >hate what it told you to do, and it would probably be obsolete by the >time it became available. Instead, we now just get to guess, and rely on old documentation (the phone book) which was never complete and is ALREADY obsolete. NOTE: The opinions expressed above are MY OWN. Don't blame my employer! -- ===================================================================== Ed Anson, Calcomp Display Products Division, Hudson NH 03051 (603) 885-8712, anson@elrond.CalComp.COM
omullarney@cs.tcd.ie (omullarney@csvax1.cs.tcd.ie) (08/25/88)
In article <46100203@uxe.cso.uiuc.edu>, mcdonald@uxe.cso.uiuc.edu writes: > > This is worthless drivel. > This is supposed to be an forum for technical discussion. That kind of comment belongs in alt.flame, and is not very helpful in any case. > If you wish to have a small memory model program on the 80x86, and > to support recursion using a stack, it is essentially NECESSARY to > have SS==DS. Almost all compilers do assume this. All C compilers do, > at least all I know of. The Microsoft fortran compiler is simply > a different front end for their C compiler. There are products that > don't assume DS==SS, but they either don't support recursion or > are intrinsically large model. My reading of the MS Fortran manual indicates that it is not intrinsically a small memory model compiler, so why does it enforce this condition wrt segment referencing? Why does it enforce these 'essentially NECESSARY' conditions when dealing with a large memory model, when my Alsys compiler copes just dandy - *and* it supports recursion ( along with a host of other things, like tasking ...). I'll tell you why - MS cut corners. > Microsoft's compiler products for > the PC are excellent - don't flame them about those. > Ahem! I had some very interesting experiences with the MS MASM, like the bug that cropped up as I developed the replacement software to that we had in Fortran. The MOVSW command ehibited a dislike to being used twice within a subroutine, and would pass junk around between segments on the second call. I ended up having to bundle all the data I wanted to transfer into single blocks and use MOVSW once only to avoid this 'feature'. Perhaps you think this is excellent - promotes more compact coding - but I found it a distinct pain in the ass. > Besides - you think Microsoft is interested in helping Apple in any way? > Why should they, considering Apple's attitude toward them? > Since when has *any* company responded to a rival's lawsuit by taking it out on their own customers? The Lawsuit is not the issue, the issue is MS attitude to software development. Stick to the point.