>>Secondly, will there be a way to fire up a VFP component, have it run to completion, and then retain the VFP runtime environment (not so much the state as the runtime engine itself, as IL would offer) between instances of VFP services, where for some period in the life of the .NET application, there may not be anything crying for VFP's runtime to be retained in the working set? I see this as an issue, since VFP's engine is not necessarily svelte and trim - it's big, and imposing, and sucks up RAM with very little consideration of others playing in the sandbox with it - I'm thinking in terms of the less than optimal behavior I've seen with VFP running with it's default best guess for how to allocate RAM - it can get ugly very quickly if you don't use SYS(3050), especially if you tend to overallocate swap file space (I confess, I tend to add swap files to each physical drive on NT and 2K boxes, and rarely trim back the inevitable overallocation.) VFP then uses the virtual RAM address space size, not the physical RAM size, to guesstimate how much it should snatch up and squirrel away, in case it gets hungry a little later. The result is heavy swap file activity, in extreme cases with little UI activity, VFP can cause the OS to thrash out. Will we see some better protection from our own misconfigurations in VFP7 (hint, hint, beg, beg)?


Ed, after rereading this carefully, we're not sure what you're asking for. Do you want the VFPEnv to be retained in memory or not? What is the issue exactly? Can you send some repro code?