>>High resolution screen display + lots of controls is one frequent answer - you used up the GDI memory, which can't exceed a total of 64K.
>>
>>You may find that limiting VFP's use of memory will actiually speed things up - VFP will eat your page file until there isn't anything left and then some, and when the virtual memory space exceeds the phsycial memory space by lots, you may well find that your end up hurting performance by thrashing out the system swapping pages between disk and RAM worse than if VFP didn't think it had a GB to play with...
>
>Interesting. I checked my task manager and it reported ~140mb being used, so I thought I was OK in general. I also never heard of NT having a GDI limit like WFWG/95, although I am running at 1024x768x64k res.... I'm not running any ActiveX controls at present.
>
I believe that NT allows 64K per Win32 session, as opposed to a total of 64K in Win3.x and Win9x. There is a real limit to the GDI under NT, but not as bad as what Win9x imposes. The GDi gets used up by the Windows virtual console, so it's not an ActiveX issue as much as a number of virtual Windows, complexity of each virtual Window in use, and obviously the size as determined by screen size and pixel depth.
>Reading through the Hacker's Guide "CDROM" and the MSDN help on VFP, there was mention of Remote Views using up memory "invisibly" and my app is all remote views on VFP data. However, I haven't gotten very far with tweaking the memory usage on my remote views or VFP in total. Do you have any hints, oh Win32 master?
I'd fire up Task Manager and watch how memory usage went on the Performance tab p or System Monitor - at the moment, with VFP6 up on one session not doing much of anything, RegEdit, an MSDN help session, a VFP6 help session, a file find and VFP6 help under NT Server, I'm using about 90MB of virtual memory, mapped into about 75MB of RAM on 256MB. Each help session uses 6-7MB, and VFP idling along eats ~2Mb.
For grins, I just started up a data gen app I wrote for a client that creates the rates and allpoints tables for a trucking company (the all zip code to all zip code mapping, about 850K records in the primary table), and VFP's memory usage jumped from 2MB to 62MB in less than 4 minutes (this is a big LTL trucking data gen app, using several hundred MB of data), and I've limited VFP to no more than 128MB of memory in the application using SYS(3050). VFP immediately pegs out the CPU usage at 100 on the first processor. Swap file activity isn't all that high.
If I were running a web browser on the same machine, it'd be well into the swap file by now, with twice the base RAM that you're running and a smaller swap file...and that's with VFP not doing any significant screen I/O and the NT server set to give a good chunk of system resources over to being a server. VFP6 has managed to keep memory usage above 150MB now for several minutes and CPU usage at 100% on one processor, and 68% on the other, even limiting VFP's memory appetite.
As a comparison, I'm running a similar (single processor) system with Win98 right now on-line - with a couple of web browser sessions, Outlook and a Folio session, I have only 14% of system resources free. Adding a VFP session in the background, I'm showing Win98 using 388MB of memory allocation (IOW, more than the NT box doing some real work), also pegged at 100% CPU utilization (I'm watching via System Monitor.) Gawd help me if I ever needed to get VFP to actually do some work on here now...
The data gen app finished on the NT box - even idling along, after doing a CLOSE ALL, memory usage is still at nearly 92MB. Clearly, VFP is retaining a good chunk of the system memory. Closing down VFP immediately frees up another 25MB, and restarting it only uses 2MB or so until it starts doing something.
The lesson - exit periodically and restart VFP to get back some resources. Limit VFP's use of memory using SYS(3050) on NT systems especially. And the low memory warning probably doesn't indicate that you're out of system memory here, or you'd be able to hear the system thrashing out moving back and forth between the swap file and memory.
