Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!apple!well!brent From: brent@well.UUCP (Brent Southard) Newsgroups: comp.windows.ms Subject: Re: Has anyone seen this problem..... Summary: Don't use Large model; don't lock memory permanently. Message-ID: <10731@well.UUCP> Date: 16 Feb 89 01:37:18 GMT References: <4517@umd5.umd.edu> Reply-To: brent@well.UUCP (Brent Southard) Distribution: usa Organization: Whole Earth 'Lectronic Link, Sausalito, CA Lines: 45 In article <4517@umd5.umd.edu> jonnyg@umd5.umd.edu (Jon Greenblatt) writes: > I am stumped! I am porting a lisp interpreter (xlisp2.0) to >MS Windows. I am using an internal memory allocation routine that breaks >memory off of large blocks of GLOBAL FIXED memory. The program is >compiled under the LARGE model and the data segment is FIXED and NOT SHARED. >Once a global memory block is allocated I lock it and never unlock it! Bad move. I'm sure you've been told this before, but I reiterate: don't keep global memory locked in Windows. Windows is CONSTANTLY moving code and data segments around. Even a few small locked segments can bring the machine to a virtual standstill if conditions are right. I realize this means a total rethinking of your memory management routines. We had the same problem with an application my company developed. After keeping data unlocked (except, of course, when using it) and switching to medium model, our memory problems disappeared. In fact, Microsoft acknowledged to us that large model programs are vulnerable to crashing, and their only advice was not to use large model. >The code segment is SHARED MOVEABLE DISCARDABLE. The program EXE is about The SDK Programming Tools Guide, page 74, says that SHARED is used only for 80286 protected-mode programs only. Try using LOADONCALL MOVEABLE DISCARDABLE. >180k and takes up 100k of windows memory when loaded, leaving me with 300k >memory free. Running small lisp programs it works ok. Running large ones >is where the problem is. When I lock about 100k of global fixed memory >the environment becomes unstable. I keep all memory locked and fixed. Please don't do this. Sorry, I already said that... >....The lisp dynamic memory is stored in about 17 blocks of global data >the biggest of which is 0x9024 bytes. Heapwalker reports the global blocks >to be of type TASK. I have the equivalent code running on a unix machine Your data blocks should be of type DATA, not TASK. Something is wrong here. Good luck! brent -- Brent Southard, ImageTech Corp. | Everybody's trying to be a friend of mine, Usenet: ...well!brent | Even a dog can shake hands. - W. Zevon CIS: 76657,415 | We fell into love, love's a very deep hole. GEnie: b.southard | - Loudon Wainwright III