Path: utzoo!mnetor!uunet!seismo!sundc!netxcom!rthralls
From: rthralls@netxcom.UUCP (Roberts Thralls)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Windows Anyone?
Message-ID: <798@netxcom.UUCP>
Date: 22 Apr 88 20:52:05 GMT
References: <4490012@hpcvca.HP.COM> <1097@neoucom.UUCP>
Reply-To: rthralls@netxcom.UUCP (Roberts Thralls)
Organization: NetExpress Communications, Inc., Vienna, VA
Lines: 94

In article <1097@neoucom.UUCP> wtm@neoucom.UUCP (Bill Mayhew) writes:
>
>
>The multitasking aspects of windows 386 do work.  Some nasty things
>like Lotus 1-2-3 or most any grphics program (windows paint
>excepted) must be run in "exclusive" mode that essentially puts
>everythig else away while they run.

Conventional applications (Non MS Windows) have complete control over
the screen, they do not cooperate with the Windows manager when displaying
graphics, so windows does not try to keep the screen clean, it simply 
allows the application to have the screen to itself, and when it is finished,
windows will allow well behaved programs to run.

>Windows multitasking is reasonably quick until an application
>starts doing disk I/O, then things rapidly fall apart.  I wrote
>some batch files that used a c program to generate ridiculous
>newspaper headlines.  The batch file was intentionally designed to
>use the disk a lot.  I could really only run three background task

Take Care in comparing apples to oranges - Window's provides window 
applications special file i/o routines that swap the File pointers
in DOS. Each application that has files open, must have windows 
swap file pointers before continuing file i/o. Applications that
were not written for the windows environment will need help doing 
file i/o from the windows manager ( a lot of help ). a DOS application
doing disk i/o in the windows environment is very, very, very different
from a windows application doing file i/o in the windows environment.

>
>Speed comparisons between the Unix PC rendering text and windows
>386 were nearly equivalent, if the program running didn't need to
>access the disk.  Obviouly the inefficient file system design of
>msdos shows itself quite nicely here.  I wonder if OS/2 is going to
>be dogged by similar crummy disk performance since it also uses the
>same old msdos file structure.

Again, watch out for those oranges when looking at file i/o under
windows -- Granted msdos file system S*CKS, but that isn't all that 
is bogging disk i/o here. Try writing a windows program to do the 
disk i/o.

>
>
>I think some of the Unix based DOS merge products may be the answer
>for people that want to run simultaneous msdos appplications, for
>these will be able to map the msdos file system onto the unix file
>system.  Since I haven't seen any of the Unix 386 DOS merge
>products I can't really honestly comment yet.

if DOS emulation is what you want, this is the better choice. Windows
was not meant to be an efficient multitasking environment. Its purpose
is for "intuitive and consistent interface to the user" and a reasonable
task communication and multitasking environment. Basically, form and
function over muscle.

>
>To sum up, windows 386 is probably worth the bucks, if one has an
>appropriately beefy 386 system.  I wouln't try to run it with less
>than 4 megabytes of memory aournd.  That is, presuming that you
>want to take advantage of the multitasking capabiltiies -- which at
>the current time are main reason for having windows 386 around.
>
>--Bill

As a windows application developer, Multitasking is much lower on the
list than say:

	+  an intutive and consistent interface

	+  Complex Graphics capabilities

	+  Device Independence

	+  Windowing functionality

	+  Interprocess Communication
		Several Alternatives to Data Sharing amoung applications
		 MicroSoft Canned:
		  - Clipboard Formats ( generally user controlled )
		  - Dynamic Data Exchange ( generally automated data sharing )
		 Mine:
		  - Proprietary Protocols ( have it your way )

	+  Last, but not least Multitasking

Bob.


-- 
Disclaimers: so it is written, so let it be disclaimed.
				uucp: uunet!netxcom!rthralls
Robert K. Thralls			
NetExpress Communications, Inc.