>>>Two obvious ones - first change the MEMLIMIT to a maximum of 15500, and >second, adjust the .PIF of the FPW app to run in its own address space >rather than the shared Win16 address space.
>>
>>Co-incidentally, I have a similar problem just cropped up with a client upgrading to XP and a fast machine.
>>
>>I already have emailed him the patch for that and that is OK. However they are now getting low memory errors which causes my error trapping to restart the app (with a prior warning about low memory) in the middle of trying to enter data into a text box.
>>
>>I will try to get them to edit the Config.fpw, but I don't know about a Program Information File for FPW2.6a, or is that a "local" Config.FPW you are referring to?
>
>A PIF is just a desktop shortcut. Take a look at
>
>Re: Insufficient Memory in Windows Server 2000 Thread #681492 Message #681907

FWIW, a .PIF is a heck of a lot more than just a shortcut (.LNK or .URL) file - the .PIF (Program Information File) for an executable describes the virtual machine conditions for running the app, rather than just the name of the executable. It can describe a number of operating system characteristics surfaced to the application such as available memory, processor preferences, and OS service presense.

In most cases, you will find a .PIF file associated with a DOS or Win16 application; the .PIF describes the virtual machine characteristics of the system resources that the executable thinks are available to it. The specific limit in the CONFIG.FPW to avoid FPW 'wrapping around' its memory pointers - the Win16 environment made a 24 bit address space available to all Win16 apps, with limited protection of the shared memory resource; an error in the memory handling of any Win16 app in the shared address space affected all Win16 apps in the shared address space; if a Win16 app runs in its own protected area of memory, it is far less affected (and is far less likely to fatally terminate other Win16 apps as a result of it failing) by other Win16 apps screwing up the shared Win16 address space. The cost paid is a somewhat larger memory footprint for each Win16 app running at one time (this is a frequent issue under Terminal Server and various Citrix enhancements to WTS) and slower communication between Win16 apps running on a given machine because of higher overhead to communicate between process address spaces.

The real solution is to get rid of DOS/Win16 apps, particularly in the thin client arena (where potentially lots of Win16 apps that should be executing isolated from one another are granted the ability to crunch each other through the shared address space) and large dataset scenarios (again, the Win16 memory address space is 24 bit rather than 32 bit, and pointer handling (gawd do I hate segment registers) is a whole lot more complex especially with very large data structures that can cross other memory borders with consequences for Win16, where a segment is 64KB rather than 4GB...)

BTW, I have a suicidal user who wants to run an FPDOS app over W2K WTS; there's no equivalent of TameDOS available AFAIK for W2K WTS SP3, and while there are registry hacks to handle DOS apps idling at a READ, they are not dynamic. All this after making the commitment to a completely native AD environment, forcing the upgrade of their sole remaining NT 4.0 WTS to Win2K, where their Canadian distributor uis running a kludged-up SBT Series 6 under FPDOS 2.6, interfaced to CrippleShip...erm...ClipperShip, which lacks good tools for integration (even compared to the ODBC Hell of products like UPS WorldShip; the US distributor uses Ascent with ODBC file integration and both custom scripting and DCOM interfaces and are very happy campers.) Other than allocating the app to a specific terminal server and limiting the number of sessions to avoid bogging down everything (or forcing them into MetaFrame) I'd appreciate any ideas, even just the address of a good hit man in Vancouver...