Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!mandrill!neoucom!wtm
From: wtm@neoucom.UUCP
Newsgroups: comp.sys.ibm.pc
Subject: Re: MS WORD/EGA/MOUSE problem
Message-ID: <706@neoucom.UUCP>
Date: Fri, 25-Sep-87 09:12:58 EDT
Article-I.D.: neoucom.706
Posted: Fri Sep 25 09:12:58 1987
Date-Received: Tue, 29-Sep-87 01:09:54 EDT
References: <3864@ecsvax.UUCP>
Organization: Northeastern Ohio Universities College of Medicine
Lines: 51
Keywords: Mouse, EGA, Paradise, Microsoft Word, HELP
Summary: Microslush Word 3.0 mouse / vid-ega problems


The lastest version of "Word" that I have to play with here is ver
3.0.  Up though this version, the performance of Word on mixed
manufacturer hardware is pretty unpredictable.

It is curious that the Michael (the orginal poster) had troubles
with the Mouse Systems PC-mouse.  So far, that is the only 3rd
party mouse driver that I've been able to get to talk to Word.  My
suggestion is that you ingore the stuff that the MS-Word
installation disk says about the mouse driver.  Use the driver that
came with the PC-mouse instead.   One time under circumstances I
haven't been able to duplicate, MS-Word said something to the
effect of "you must have a Microsoft brand mouse to use this
product" when booting up.  I think that was with a Summa Graphics
mouse.

By Microsoft's admission, up to ver 3.0 doesn't support EGA cards
very nicely.  They fiddle around in the chips directly, rather than
using the EGA BIOS.  They claim to only support IBM Branded EGA
cards.  On an AST EGA-plus, Word will occasionally hang the system
when the cursor is at the end of a line when justified paragraphs
are specified.  On an STB EGA Multires, Word turns the entire
screen a pathetic lime green-- similar to the Codeview EGA bug.

Unfortunately, abberant behavior as above also carries over into
Windows, ver 1.03, but not so extrmeme.  I wish they'd get their
act together and put out a product that doesn't sneak past BIOSes
and poke around in dark undocumented corners of their operating
system.

On the other hand, D-R's GEM is a much more behaved product,
seemingly much more conservatively written-- not using undocumented
interrupts or bypassing video BIOS.  GEM doesn't seem to sufffer
from lack of speed by behaving itself.  Thus, I think Microsoft
can't shield itself from user complaints with charges of equipment
incompatiblity and/or claims of the need for sneaky programming to
get adequate :-) performance.  The :-) re: Windows' performance.

To illustrate:  GEM and run Windows as a task and return back to
GEM when Windows exits.  If you run Windows, and then try to run
GEM as a task under windows, the system crashes.  I haven't been
able to cure that by messing with PIF files.  (This is really an
academic argument, since it would normally be pretty silly to run
one window environment as a task in another window environment.
That is unless you want a decent paint program for Windows.)

I sure hope they do a better job with OS/2 and Presentation
Manager!

--Bill
(wtm@neoucom.UUCP)