Xref: news-dnh.mv.net comp.os.msdos.djgpp:4126 Path: news-dnh.mv.net!mv!news.sprintlink.net!cs.utexas.edu!academ!news.sesqui.net!rice!news!sandmann From: Charles Sandmann Newsgroups: comp.os.msdos.djgpp Subject: Re: 2beta4 probs Date: Thu, 04 Jan 1996 21:48:19 CST Organization: Rice University, Houston, Texas Lines: 16 Message-ID: <30ec9f83.sandmann@clio.rice.edu> References: Reply-To: sandmann AT clio DOT rice DOT edu NNTP-Posting-Host: clio.rice.edu To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp > [It's slow] > I get the "virtual memory exhausted" message from cc1plus, even > though my temp dir's got 38 megs free, and the drive the source is on > I'm using CWSDMPI beta6, if that matters - someone on the list *DON'T* use anything but CWSDPMI beta9 with V2 beta 4. The sbrk() algorithm was changed to use multiple memory zones. CWSDPMI beta 7 and before put each zone into a separate area of memory, and limited them to 15 max. The 15 max causes the VM exhausted messages; the different zones exhausts the page directory entries which then page like crazy (so it seems like the program is running in 1/2Mb of memory). So the problems you are seeing are a CWSDPMI bug/limitation. Upgrade to beta9, the zip file is only 37Kb for crying out loud! Oh, and unless you CWSPARAM edit your CWSDPMI image, it will always page onto C:\CWSDPMI.SWP (It doesn't look at TEMP). a 4, set LFN=N was introduced so you could make projects expecting truncation (like GCC). But due to an incomplete opendir implementation (still discussing details) all file names are lowercased even when LFNs are enabled. This isn't a problem on VFAT drives, but it CAN be on network drives if case sensitive. If someone wants to work with me on the details of the LFN libc stuff under SAMBA, I would be willing to help find and fix the bugs.