>Has anyone seen this error?
>Phar Lap fatal err 10049: Ran out of stack buffers
>
>It started today on this program I'm working on. It doesn't happen all the time to it's to track down. The error is displayed out on the dos level.
>
>The only thing I'm doing different than any other program I write is that in the prg I have a function defined rather than procedure. Is there some limit on open files and the number of calls to other procedures that I can do from within that function? Any arrays and variables I'm using are released as soon as I'm done with them. So I can't see where this memory issue is coming from.

Phar Lap was Watcom's memory manager, which was what Fox used for memory handling in those days. The error is impossible to track, but at least you can figure out where it happens. Usually (didn't have that too often) it sufficed to do some minor change in the code - swap the order of two commands, add a space to some unimportant string, insert a "select select()" line or something equally pointless, recompile all, build a new app/exe and it would run.

Also, in DOS days it happened a lot when emm386 was set to use expanded memory (which was a must in fox 2.0, but a burden in 2.6) - in today's terms, check the memory settings for your exe (in its shortcut, pif or whatever you use to run it) and make sure it doesn't try to emulate EMS (I think the setting was /Frame=OFF). Furthermore, this happened a lot when we had early SMC network cards, which used some block of upper memory to communicate with the driver, and this block overlapped with the 16K window EMS protocol used for communicating with its own blocks above the 1M boundary. This range had to be excluded. I suppose this wouldn't be happening on a W9x or higher OS.

I'm not really sure how much of this may still apply.