Xref: utzoo comp.sys.mac.misc:10279 comp.windows.ms:10931
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!samsung!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!gg2
From: gg2@cunixf.cc.columbia.edu (Guy Gallo)
Newsgroups: comp.sys.mac.misc,comp.windows.ms
Subject: Re: give me solid facts: Word for Windows
Message-ID: <1991Mar29.061014.10477@cunixf.cc.columbia.edu>
Date: 29 Mar 91 06:10:14 GMT
Organization: Columbia University
Lines: 29


>This is strictly a Word for Windows problem.  Applications that do not
>support multiple active instances are supposed to check for one already
>running, and if one is found, activate that running copy and bring its
>window to the top (see Microsoft Systems Journal, Dec/90 for details).

>>I find it *terribly* ironic that a major Microsoft product fails to
>>conform to the guidelines specified *by Microsoft* for Windows
>>applications.

-------
Christopher

It isn't so much ironic as an example of what happens when your do a bit
of magic to bring a product out for a platform it isn't quite right for.
The reason WinWord won't allow multiple instances of itset lies in the fact
that it was a Windows 3.0 program shoe-horned into Windows 2.x in its 1.x
incarnations.

This, by the way, is a subtle reflection of the fact that the applications
division *doesn't* always co-ordinate with the applications division (as the
FTC is investigating).

It is my bet that WinWord 2.0 will behave more like Excel in this regard.

(BTW - I firmly believe that most of the shortcoming of WinWord -- such as
the long save time for a large template, lack of compiled macros, the need
to do FilePrinterSetup when you add a font to update WINWORD.INI -- the very
existence of WINWORD.INI -- are consequences of this shoe-horning.