VFP9 app runs in VFP7

[foxmuldr3]

I have an app.exe created in VFP9. If I go to VFP7's command window and go to that directory type "do app.exe" it runs There is no "app.prg", but instead a "start.prg" that is compiled into "app.exe".

I get a few error messages here and there with properties that didn't exist in 7, such as "frmName.Themes", etc., but it runs.

Does anybody have experience with this?

Best regards,
Rick C. Hodgin

 

[foxmuldr3]

It would be a nice hybrid. I can't see it being beneficial for most applications though. Only a niche. And in those niche cases the developer could augment the xbase code with C/C++ based DLLs anyway.

Seems like a lot of work for virtually no improvement on 99% of applications, and a marginal improvement on 1% of applications, the latter of which could be better handled by the hybrid xbase for quick GUI and data processing design, with the C/C++ DLL handling hard compute.

I think the future of compute is heterogeneous anyway. We'll have the CPU handling some, but off-loading big tasks to the GPU or some other dedicated compute hardware. That would be even more difficult to code for.

Not impossible by any stretch ... I think it's just wholly impractical for any reasonable design. I could be wrong about that though.

Best regards,
Rick C. Hodgin

 

[Olaf Doschke]

Yes, GPUs have become HPC engines, I just saw a Keppler Video on youtube doing real time raytracing even with fluid simulation... Thats surely a job for a seperate toolset.

Bye, Olaf.

 

[foxmuldr3]

Server farms are moving to massively parallel low-power compute CPUs. Having dozens of much slower, much lower-powered CPUs operating in parallel, processing data in blocks ... makes far more sense than a high-end engine.

I believe this will be the future of computing in general. Apps will have to be designed to run in massively parallel threaded models to be able to utilize future machine resources where dozens if not hundreds of CPUs are present.

I believe also this is why Microsoft is devoting so many resources into .NET and Windows Azure. You write for the virtual machine, which then scales as technology evolves underneath. And in that way, behind-the-scenes, out-of-sight, without regards to original design, all of your explicit coding needs are handled however the .NET designers wish to deliver it -- and that necessarily includes data mining. So long as you're receiving what you paid for (software works, users see no delays), then who cares if on the other side of the (perfectly named) cloud, which masks what is happening from outside prying eyes, that they move data however they want, research against your data and code whenever and however they want, examine your customer's buying habits and usage, along with every other company using the Azure platform and remote .NET servers, to create a type of global eye on all commerce everywhere?

There's pretty much everything scary about such a prospect. :-(

Best regards,
Rick C. Hodgin