gillies@p.cs.uiuc.edu (08/19/88)
I heard that Microsoft had a "pseudo language" interpreter they used
to write their software (e.g. Excel). This was something like a
pascal P-code interpreter. The interpreter supposedly saved a lot of
memory (hence MS-Word runs in 220K). But to do this, they had to use
the upper bits of each 32-bit pointer for extra data. This is fine on
an MS-DOS machine, which is physically incapable of accessing more
than 1Mb of memory, but kills you on a macintosh.
So the Excel problem wasn't actually sloppiness -- Microsoft was
trying to write innovative software that used very little memory, and
got bit by 1 Mb+ machines. Wasn't Excel released for 128K machines?
Then the software DID last for 2 generations of hardware..... pretty
good...
Don Gillies, Dept. of Computer Science, University of Illinois
1304 W. Springfield, Urbana, Ill 61801
ARPA: gillies@cs.uiuc.edu UUCP: {uunet,ihnp4,harvard}!uiucdcs!gilliesmcdonald@uxe.cso.uiuc.edu (08/22/88)
>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). This is worthless drivel. 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. Microsoft's compiler products for the PC are excellent - don't flame them about those. Besides - you think Microsoft is interested in helping Apple in any way? Why should they, considering Apple's attitude toward them?
mcdonald@uxe.cso.uiuc.edu (08/22/88)
>Thanks Oliver - The very first thing I should have criticized in my post last week >was Microsoft Fortran for the Mac. >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. >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. Well, the Microsoft compiler has lots more wrong than that. First, all the programs I wrote with it refused to run on Mac II's (their bugs). Second, the code generation was abysmal. For example, a simple statement IF(i.lt.j)goto 100 should compile to a test and a branch on condition. How do they do it? They test, they load the flag into a register as a byte, extend the byte to a word, then the word to a long. Then they test the long, and branch on that. That kind of code is INEXCUSABLY bad! Third, and worst of all, this dumb compiler generates CODE for data statements! Instead of just compiling the data into a static data section, they store it as literals in the instruction stream. For example character*1 x(5) data x(1)/'a'/,x(2)/'a'/,x(3)/'r'/,x(4)/'g'/,x(5)/'h'/ generates 7 bytes of code for each character , 35 bytes total. Interestingly enough, Microsoft's product for the IBM-PC is excellent. Guess which computer I use now (hint: it has a very nice batch file processing system right in the operating system).
postmaster@mailcom.UUCP (Bernard Aboba) (08/23/88)
I believe that the Language Systems Fortran Compiler, which works with MPW, is now the preferred compiler. MS's other competitor, DCM, never really got off the ground with MacTran '77, although it wasn't a bad product. Has anyone used the Language Systems Compiler, and is ready to venture an opinion on it? --- * Origin: MailCom -- EchoMac Info Here, Palo Alto (415) 855-9548 (Opus 1:204/444) SEEN-BY: 161/444 204/444 -- ------------------------------------------------------------------------------ FidoNet: 1:204/444 UUCP: ...!sun!sunncal!mailcom!bernard INTERNET: sunncal!mailcom!bernard@Sun.COM US MAIL: Bernard Aboba, FaAA, 2225 East Bayshore Rd., Palo Alto, CA 94303
rob@uokmax.UUCP (Robert K Shull) (08/24/88)
In article <46100204@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >Guess which computer I use now (hint: it has a very nice batch file >processing system right in the operating system). I couldn't guess, there are LOTS of machines that run Unix. You couldn't mean MS-DOS. NOTHING is "very nice" about that. "Tolerable" maybe, but not "very nice." -- Robert K. Shull University of Oklahoma, Engineering Computer Network att!occrsh!uokmax!rob or sun!texsun!uokmax!rob
rob@uokmax.UUCP (Robert K Shull) (08/24/88)
In article <46100203@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >Besides - you think Microsoft is interested in helping Apple in any way? >Why should they, considering Apple's attitude toward them? Now that's what I call good business practice! Use the resources of your company to make a bunch of buggy programs. That'll sure make Apple's equipment look bad! Wouldn't affect the software company's reputation at all, I'm sure. EVERYBODY would know that Apple's to blame. Robert -- Robert K. Shull University of Oklahoma, Engineering Computer Network att!occrsh!uokmax!rob or sun!texsun!uokmax!rob
gillies@p.cs.uiuc.edu (08/24/88)
It is really too bad that Apple doesn't support printer drivers that
well, since the Mac O/S architecture supports device-independent
printing. I would think this is one way Apple could make their
otherwise "closed" architecture more open, and *widen the technology
gap* between Macintosh software and PC software
Don Gillies, Dept. of Computer Science, University of Illinois
1304 W. Springfield, Urbana, Ill 61801
ARPA: gillies@cs.uiuc.edu UUCP: {uunet,ihnp4,harvard}!uiucdcs!gilliespostmaster@mailcom.UUCP (Bernard Aboba) (08/25/88)
I think that Apple's lack of support for device drivers may be quite damaging in the long run. For example, at work we've put in the usual array of Apple DTP equipment, but the Art department refuses to use it: it can't support large Calcomp and HP plotters as well as an IBM PS/2 with MicroDesigner, and the plotters are needed for 80% of their output. I have tried several plotting packages such as Plot-It and MacPlot (which I couldn't get to work at all), and have not come up with a good alternative. There are several nice printers, such as the HP PaintJet, that might have caught on had drivers been available. Perhaps the best plotter drivers available now are those that come with applications such as Mac Draw II and Cricket Graph. However, Cricket seems to have WITHDRAWN support for several devices in revision 1.2. Unfortunately, I have an Apple plotter which seems to no longer be supported. I have heard a lot about the Cricket Drivers which are going to be released. Does anyone know what devices are to be supported by these? --- * Origin: MailCom -- EchoMac Info Here, Palo Alto (415) 855-9548 (Opus 1:204/444) SEEN-BY: 161/444 204/444 -- ------------------------------------------------------------------------------ FidoNet: 1:204/444 UUCP: ...!sun!sunncal!mailcom!bernard INTERNET: sunncal!mailcom!bernard@Sun.COM US MAIL: Bernard Aboba, FaAA, 2225 East Bayshore Rd., Palo Alto, CA 94303
casseres@Apple.COM (David Casseres) (08/26/88)
In article <76000279@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: > >It is really too bad that Apple doesn't support printer drivers that >well, since the Mac O/S architecture supports device-independent >printing. Actually, the OS doesn't do anything in particular for device-independent printing. The part of the Printing Manager that's in the system is just a little bit of glue that knows how to pass Printing Manager calls to the current printer driver. _Everything_ else is in the driver itself: the entire user interface (not counting the Chooser but counting the interaction that appears in the Chooser window), the entire implementation of the Printing Manager calls, and the entire QuickDraw interception system (bottlenecks) that causes QuickDraw calls to produce printed images. It's all in the driver because it's all different for each type of printer; that's how device independence is achieved, and that's why it's so hard to develop a driver, and that's why it's so hard to support third parties who are trying to develop printer drivers. David Casseres
fmodwyer@cs.tcd.ie (Frank O'Dwyer , ext. 1695) (08/26/88)
[REPOST - earlier messages were chewed - sorry if you get this twice] In article <46100203@uxe.cso.uiuc.edu>, mcdonald@uxe.cso.uiuc.edu writes: > 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. Good thinking. If *almost all* compilers do it, then presumably there are those which do not. Hardly *necessary* then, is it? > Besides - you think Microsoft is interested in helping Apple in any way? > Why should they, considering Apple's attitude toward them? This is worthless drivel. What's more, it is completely off the point. The original message referred to a microsoft product for the *PC*. Who said anything about helping Apple? (mind you, I see your point. Microsoft did a great service to Apple in developing MS-DOS :-)). Disclaimer: I have never used any microsoft product, other than MS-DOS and Word for the mac. The latter is streets ahead of the former. But then, that wouldn't be hard :-)
kaufman@polya.Stanford.EDU (Marc T. Kaufman) (08/27/88)
As a beta-tester for 32 bit Quickdraw, I can tell you all (in advance) that MS Word (3.02) hangs the machine when 32 bit Quickdraw is running. Evidently Word tries to read some bits from (or put bits to) the display memory directly. Under 32 bit QD, this happens in 32-bit address mode. As a developer who ported the ORIGINAL MS Basic (the Albaquerque one, written in PDP-10 assembler, with each 8080 instruction being a MACRO...), I can tell you that MicroSoft's claim to fame is that they were there first... not that thay did a better job. [how long did it take to fix the syntactic ambiguities in the original BASIC? Why were they there in the first place?]. Marc Kaufman (kaufman@polya.stanford.edu)
gillies@p.cs.uiuc.edu (08/28/88)
Already we have Imagewriter II (72dpi) printing, Imagewriter LQ
(216dpi) printing, 300 dpi Quickdraw laser printing, and Postscript
printing for the macintosh.
Now Cricket has decided to do their own drivers, probably because
Apple is so reluctant to support "real" drivers. History will
probably say that Apple's reluctance was a tactical error. Apple is
causing a proliferation of non-standard printing drivers and printers.
Thus, the macintosh is becoming more & more like a MS-DOS machine
every day, with lots of non-standard software that won't work together.
Don Gillies, Dept. of Computer Science, University of Illinois
1304 W. Springfield, Urbana, Ill 61801
ARPA: gillies@cs.uiuc.edu UUCP: {uunet,ihnp4,harvard}!uiucdcs!gillies