Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!tut.cis.ohio-state.edu!purdue!mentor.cc.purdue.edu!noose.ecn.purdue.edu!newton.physics.purdue.edu!maxwell.physics.purdue.edu!sho
From: sho@maxwell.physics.purdue.edu (Sho Kuwamoto)
Newsgroups: comp.sys.mac.misc
Subject: Re: Rumor -> Loss of Mac's 20% advantage over Windows 3.0
Message-ID: <3881@newton.physics.purdue.edu>
Date: 9 Jul 90 21:42:38 GMT
References: <1915@runxtsa.runx.oz.au> <3871@newton.physics.purdue.edu> <3053@gmdzi.UUCP>
Sender: news@newton.physics.purdue.edu
Organization: Purdue Univ. Physics Dept, W.Lafayette, IN
Lines: 63

In article <3053@gmdzi.UUCP> strobl@gmdzi.UUCP (Wolfgang Strobl) writes:

>Sorry, I don't know what cdev's are. "TSR" is of course the (in)famous 
>Terminate and Stay Resident routine. What does a cdev do, and what 
>is it used for?

A cdev is a control panel device.  The control panel is used by the
user to control aspects of the mac's behavior.  Key repeat time, mouse
speed, etc.  For a number of years now, the control panel has been
modular.  It is relatively simple to write a module for the control
panel when appropriate.  It is common to use the control panel to
control the functionality of an init.  For example, my screen blanker
can be set through my control panel.  I can tell it how long to wait
until blanking the screen, etc.  This is a minor point, but it's just
one thing I happened to find annoying on PCs running DOS.  If I wanted
to change the behavior of a TSR, I had to remember what key sequence
would pop up the menu for that TSR.

>Bigger applications and Windows itself
>consist of many small code segments, which are loaded and discarded
>on demand. 

This sounds very similar to how it's done on the mac.

>An application does not hold pointers to memory for a long
>time, they use handles, instead, which have to be locked in order
>to get to the pointer. A memory block can be marked as "discardable",
>if the application can reconstruct its content. Windows does
>not normally preserve the content of a window, because this
>may need to much memory, and an application has to be
>able to reconstruct the window content anyway.

This does as well.

>The important point here is that the code of a DLL is shared
>by all running applications which use it. Windows itself is a
>collection of such DLL's. Printer drivers are DLL's
>with a known set of entry points. Many major applications
>consist of a set of DLL's and one ore more programs using
>these DLL's. 

We don't have any sort of dynamic linking on the mac, but then again,
all the windowing routines are in ROM, so it's not real important.

>>Does Windows require you to write your own event loop, does it use
>>callbacks, or does it use some sort of object oriented design?  
>
>Yes, yes and yes (-:
>
>You have to write your own event loop, but it normally does
>not contain any special code, i.e. the standard Windows message loop
>  while(GetMessage(&msg,NULL,0,0)) 
>  {   TransLateMessage(&msg);
>      DispatchMessage(&msg);
>  }

Much simpler than the code for mac applications.  In some ways, I'd
like to see a complete revamping of the entire mac ROM.  Then again,
I think of the headaches that would cause...

-Sho
-- 
sho@risc.com