>>(you can stop laughing at my rant now)
>
>Actually you are both right, in your own ways. In comparable conditions, sure VFP will be 25% because it does tree times more work. But there are no comparable conditions... because the current speed of FPW is zero, it won't run on 64 bit.

Yupp, another valid POV. In theory recompiling FPW as 32bit with some changes in C compiler constants would probably be cheapest if done by an old hand who compiled FPW back in the early nineties.
We all know that wom't happen. and even a 32 bit FPW would lag 16 bit FPW on 32 bit OS 2-5% due to pointers nedeng more space, some structs overflowing cache lines and so on. Tiny, but measurable.

So either run it in fastest vfp (as Martina mentioned, vfp5 -quite possible, 3 was a dog forme, 5 was fun to experiment / code few screens for myself, earnest vfp work started with 6) or find a general translation layer for 16 bit code - no idea, if DosBox or a guest VM running NT, W2K or XP or a wine-enhanced Linux is supported on TS.

And yes, new HW will run rings around perf experienced decades ago even through VM layers.

>Okay, here's a comparable thing. Same code running over the years: my solitaire game. Apart from some minor cosmetic issues, the code is mostly the same as it was in 2003. Shortened it by a third when adding jQuery in 2008, which actually made it slower, but looked better.
>
>And guess what, it's now blazingly fast. I can't even notice when it reshuffled the cards and laid them down again. And back then I could just about see when that happened, or when it had to do a double loop to check whether the game was over after the last move. Even on my clumsy Pine64 phone...