Thanks, Lutz. They are already plenty concerned about the jump to VFP 9.0, so one step at a time, I think. :)


Should not be a problem. I work at least on my DEV machine, with several versions. Each exe looks up it's own dll, so it should be fine. Only I would not instantiate the one inside the other. And not pick classes out of the other EXE.

If you consider to go to a "new" version from VFP 8, consider to skip VFP9 and use directly VFPA. It runs well and fixes some bugs.

Lutz

>Hi all -
>
>Doing some work for a client that runs under VFP 8.0 (both compiled EXEs and PRGs directly). They are facing some issues v. Windows 2016 / SMB (and others), and we're considering introducing VFP 9.0 (with SP2, etc.) to see if it helps eliminate or reduce random NETWORK READ WRITE errors, as well as giving us access to the latest-and-greatest development tools (e.g., Thor & company).
>
>A bit of a twist is that at least for one of the EXEs the source code may not be available, so we'd need to continue to be able to run that EXE--which I assume would not be an issue so long as the VFP8*.dlls runtime libraries are still around. I'm thinking something like a VFP 9.0 app loader EXE that calls the main VFP 8.0-built EXE, and it calls PRGs which would then run under 9.0 runtime libraries. (Hmmmm... not 100% sure what I just said is accurate.)
>
>I know we'll need a few SET ENGINEBEHAVIOR..., SET REPORTBEHAVIOR settings added, but other than that are there any "gotchas" trying to have both VFP 8.0 and 9.0 on the same box, potentially each running or compiling the same PRGs? I'm assuming once VFP 9.0 creates its FXP 8.0 cannot run it (but I don't remember for sure).
>
>Any suggestions and help is greatly appreciated.