duncanb@ibmpcug.co.uk (D G Booth) (11/11/89)
========================================================================= This is a brief summary of a hitherto unknown (at least to me) windows `feature'. It is distributed as is and without guarantee as to accuracy or relevance. Comments are welcome, especially if anyone already knew about this problem, or if I have got it totally wrong. Enjoy! ========================================================================== Microsoft windows running in fully paged EMS mode has to track the relocatable entry points for dynalink libraries whenever it does a task switch. This is because library code segments will be in a different place in each application, and it is obviously undesirable to patch all the calls on each task switch. To acheive this a block of memory is allocated to hold all the relocatable library entry points. i.e. the usual SAR + int 3f or SAR + jump. There is one copy of this block for each memory bank, and the copy is held in another EMS bank allocated just for it. The task switch procedure is: bank out the application memory bank bank in the relevant entry point block copy the new entry points into the master table bank in the new application bank. Now the problem: the entry point block occupies a single EMS page. This limits it to a maximum size of 16k. Apparently the entry points in KERNEL, USER, and GDI already use about 40% of the available space. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! If you try to load a library when this block is full, the library load will fail `out of memory' even though there is apparently lots of free memory available. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Each application task switch involves not only 3 bank switches, but also a block move of up to 16k (and at least 6k). No wonder Windows 386 tasking is SLOW! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! How to recognise when this problem has occurred: Unexpected out of memory errors, or libraries (such as PRINTER DRIVERS) go wrong inexplicably. Note that the 16k limit is a total for the system. If you are running something like Designer (which has BIG libraries) then other applications that normally work fine may start to have problems. This is not a limit on EXPORTS (there is a separate limit of 2000 exports from libraries), it a limit on inter-segment entry points. A FAR function in a library will generate an inter segment call if it is called from outside its own segment, even if it is declared static. On the other hand, if it is not called from outside its own segment it will not generate an entry point even though it is FAR. The linker flag /PACKCODE may help a lot in this respect. Avoid hundreds of small 100 byte segments. -------------------------------------------------------------------------- Unrelated problem (from the same informant): DONT YIELD THE PROCESSOR WHEN PROCESSING WM_SYSCOMMAND/SC_CLOSE MESSAGES. An application that took some time to close down the database it was accessing had a PEEK/DISPATCH message loop that it entered after it received a WM_SYSCOMMAND/SC_CLOSE. When it terminated, the application code/data was left in memory even though it had supposedly terminated. When SC_CLOSE is generated, the windows menu handling code clears the menu from the screen, sets a *STATIC* flag to indicate that it is shutting down the window, sends the SC_CLOSE and posts the WM_QUIT. By yielding the processor, the user was able to make another menu selection - in a different application, clearing the flag (because the other app wasnt shutting down.) On return to the closing app, the flag was clear so the rest of the shutdown code was not executed. MORAL: If you must close down slowly, post yourself a message to force the shutdown. -------------------------------------------------------------------------- (The above information was supplied by Kevin Reader of LBMS). Duncan Booth -- Automatic Disclaimer: The views expressed above are those of the author alone and may not represent the views of the IBM PC User Group.