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> <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