Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
'Hacking' Visual FoxPro
Message
From
26/01/2013 12:38:11
 
 
To
All
General information
Forum:
Visual FoxPro
Category:
Other
Title:
'Hacking' Visual FoxPro
Miscellaneous
Thread ID:
01564249
Message ID:
01564249
Views:
144
Mostly this message is to Doug Hennig, but I wanted it to be part of a public record discussion. I invite others to participate as well.

Doug,

In a recent post here and on Foxite, I mentioned using SAVE TO in your ON ERROR routine instead of LIST MEMORY. You pointed out that SAVE TO is limited to variables in scope, whereas LIST MEMORY does all variables, and is therefore not appropriate for an ON ERROR handler.

Since Microsoft no longer supports VFP ... I was wondering what your thoughts would be on the ethics of "hacking" the VFP9 libraries to remove that shortcoming? Or to re-purpose older, often unused attributes and settings for new flags which would enable the "enhanced SAVE TO" feature to be turned on or off programmatically in code?

A person skilled in x86 assembly could create a "patch" (like the one issued by Microsoft which fixed the startup error seen when running VFP on fast CPUs) which would allow the SAVE TO algorithm to use the same memory variable retrieval mechanism as LIST MEMORY does, allowing it, therefore, to save ALL memory variables to disk, rather than just those in scope.

I recognize the EULA mandates that we do not reverse engineer the product, or decompile the binaries, etc. If it's possible to set that aside, then I'm asking what would be your opinion on the ethics of doing so now that Microsoft has abandoned Visual FoxPro and will likely never again contribute anything to it.

I'm mostly looking for people's input. I won't argue with anyone, but I will point things out to get a response.
Next
Reply
Map
View

Click here to load this message in the networking platform