>>>>On the embolded part: IMO such architecture is beneficial if you are on a server and try to work under a stateful paradigma as devs are/were used to on desktop apps - ASP.NET anybody?.
>>
>>Compelling VFP proposition # 121 was the ability to spool large local temporary datasets to disk rather than flooding memory. Back in the day, testers confirmed little real-life benefit from increasing FP's foreground memory beyond about 32-64mb.
>
>You are preaching to the converted - but MS does not see "client" as relevamt in ther dev effort as a few handful of years before.
>>
>>But of course things change- after all, the devices in our pockets are more powerful than those computers runing FP and there's no hard disk just memory, so the concept of spooling of local datasets is long gone from mainstream imagination.
>
>Yuck. Embolded: where is the sledge hammer needed to teach a lesson well remembered....
>"Memory" # RAM! On newer phones internal flash got a boost, if you can believe benchmarks, but the "Disc" analogue IMO is mSDxc "memory".
>It really is convenient (2x 200GB in wallet for non-sensitive things I might have to load on a moments notice) but the speed is not really good.
>In laptop for serious "fixme" like replacing a botched .vhd. Simple USB3 disc ist 3-5 times faster, as access is nearly sequential in restore.
>
>For quick saves of up to 1 GB it is ok: 1/3 to 1/2 of GB Lan speed.
>But: on mobile you are faster (with less latency as well...) AND you could employ space vs. time optimizations like having structured data and precompiled intermediate code, relieving CPU of a lot of drudgery.
>
>Any chance Chen can port the non GUI part of Vfp C++ to ARM compiler infrastructure ? I realize that OS-bound things like getenv() and other stuff will need work. Had something either a good idea or a brain fart this weekend, trying to decide which , as Lianja seems still to mirror MS in the disdain for client side persistable structured storage...

But from what I understand of the VFP C++ compiler, it only replaces the p-code portion with C++ code --- the resulting binary still has dependency on the VFP runtime DLLs (which is used as-is). I presume that what you're asking for is to have Chen extend this to allow re-building the runtime DLLs as well? (the VFP C++ compiler product probably slips under the radar as it's marketed as an "enhancement" -- but by extending the functionality to include runtime library he'd probably end up straying too far into area that could land him into hot water with Microsoft)