gpsteffl@sunee.waterloo.edu (Glenn Steffler) (04/04/91)
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
russotto@eng.umd.edu (Matthew T. Russotto) (04/05/91)
In article <1991Apr3.194824.16965@sunee.waterloo.edu> gpsteffl@sunee.waterloo.edu (Glenn Steffler) writes: >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. There is no such thing on the Mac either-- you can have as many handles as memory permits, though allocating space at the beginning reduces memory fragmentation (because master pointers must obviously be nonrelocatable!) -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.
gourdol@imag.imag.fr (Gourdol Arnaud) (04/05/91)
In article <1991Apr3.194824.16965@sunee.waterloo.edu> gpsteffl@sunee.waterloo.edu (Glenn Steffler) writes: >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. Wait a minute. On the Mac, handles are not "in some fixed area". They area allocated dynamically for each process. You can have as many handles as you want in each hep. The only reason you are advised to call MoreMaster at the beginning of your programm is to avoid heap fragmentation (having non relocatable blocks in the middle of your heap). But if you don't, it works anyway! The main difference I see with the Windows and Mac memory models are: - Windows share its memory pool with all the running processes. The Mac allocates a fixed size zone to each application. However, applications can request memory in a common pool (with MultiFinder or System 7). - Windows manage its handles with some kind of table, which does that thre is an upper limit on the number of handles you can allocate. The Mac gives application as many handles as they request, as they are allocated dynamically. I think I'd like to have the best of both worlds: - Common memory pool (altough this may lead to problems with unsafe applications). - Dynamically allocated handles. >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. Yeah. Sure, that's what I'd like to have with the Dialog Manager. Arno. -- /======================//==========================================/ / Arnaud Gourdol. // On the Netland: Gourdol@imag.fr / / // Via AppleLink: Gourdol@imag.fr@INTERNET# / /======================//==========================================/
n67786@cc.tut.fi (Tero Nieminen) (04/05/91)
In article <1991Apr3.194824.16965@sunee.waterloo.edu> gpsteffl@sunee.waterloo.edu (Glenn Steffler) writes: 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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Hmm.. If you a referring to master pointer blocks, I really dont understand how they have to be in some fixed area like you say. Every application has it's own master pointer blocks allocated inside it's own heap, but they do not need to be initialized. The system will allocate new master pointer blocks if the program runs out of free ones, automatically. Another issue is , tho, that it may not be wize to leave it all up to the system to do. Also ahndles are not limited in number by any other means than physical memory (which currently could be a significant factor). 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. The macintosh sustem heap has a set of it's own handles and master pointer blocks, likewise. -- Tero Nieminen Tampere University of Technology n67786@cc.tut.fi Tampere, Finland, Europe