Newsgroups: comp.sys.mac.misc
Path: utzoo!utgpu!watserv1!sunee!gpsteffl
From: gpsteffl@sunee.waterloo.edu (Glenn Steffler)
Subject: Windows vs. MAC - programming reasons
Message-ID: <1991Apr3.194824.16965@sunee.waterloo.edu>
Organization: Gold Disk Inc.
References: <1991Mar27.061300.7636@nntp-server.caltech.edu> <ROBERTK.91Apr1171818@lotatg.lotus.com> <19990@imag.imag.fr>
Date: Wed, 3 Apr 1991 19:48:24 GMT
Lines: 64

Subject was something like: messy Dos vs Mac gimme real reasons.

Background:
I have been working in Windows 3.0 since September 88, and have
ported a Macintosh animation editor to Windows.  The Port consisted
of rewriting the user interface, yet keeping the underlying structures
and object manipulation code.

In article <19990@imag.imag.fr> gourdol@imag.imag.fr (Gourdol Arnaud) writes:
>in which way is the Memory management better on Windows. I find
>the Mac model quite clean and powerful (except for this stupid story
>of MultiFinder partitions maybe).

Windows memory management has handles like the MAC.  Fortunately tho, the
handles are not in some fixed area like the Mac handle table that has to
be initialized etc.  The Windows handles are handled internally by Windows,
and as such, the current limitation on amounts of available system handle
resources are only operating system version dependent.  The next logical
step is for the use of a local discriptor table for a task, which would
allow a seriously large number of handles per task.  Currently Windows
uses a single global discriptor table for all system tasks etc.

I have written a small DLL which allocates, compacts and deallocates 
32 (long/far pointers) memory for use in linked lists and such.  The
application which required these services could easily allocate upwards
of 10,000 separate memory blocks.  Windows has a limit of approximately
8000 (yes 8000) global handles (meaning the number of separate
blocks of memory that can be allocated in global shared memory space.)
Obviously that limit would cripple large projects (animations) and
would slow Windows down considerably, as the segment/selector cache
would be busy matching different address mappings as different
handles/selectors were being used to link through a list.

[
If you don't understand any of this selector/handle stuff just
look up any good 386 assemblers reference and the Windows SDK.
]

The DLL allocates large blocks of global memory, and then does local
memory management within.  The global blocks can grow/shrink depending
on the requirements (ie. # of small individual blocks needed within).
Thus, memory management is the same as any other system, once this DLL
was written.  Except, Windows can page the memory to disk in enhanced
mode or move it around in memory in standard mode.  Nice that the OS
can deal with the memory anyway it wants for optimizing usage,
yet it still appears as logically fixed memory.
(I find that useful in low-mem situations.)

>As for the dialog boxes, I can imagine quite easily how they can
>be better on Windows :-) Could you however elaborate...

Fully direct manipulatable resource creation applications.  Dialog
boxes are just a few mouse strokes away.  The dialog procedures which
handle most of the complexity needed for drop down combo boxes,
list boxes, radio buttons and other controls are included as default
handler functions provided by the Windows ui.

>Arnaud.

-- 
Windows Sumo Wrestler                "Bo doesn't know software" - George Brett
  --(Windows 3.0, a combination of modern moodring technology and voodoo)--
"I guess she had a way, of making every night seem bright as day"
`I Don't Believe In Love`   -Queensryche (Oper. Mindcrime)     Glenn Steffler
