|
Post by foxpropgmr on Jun 7, 2021 3:14:42 GMT 1
Jos ... vDos very reproducably fails at this point ... as soon as the "V" in variables is hit. Walt
|
|
|
Post by Jos on Jun 7, 2021 10:46:45 GMT 1
vDos 2021 introduced FoxProX optimizations by identifying certain core routines and executing that functionality directly, instead of processing those routines one instruction at a time by the emulated CPU. I suspect one of those core routine replacements to blame. Can you send me some test to replicate that exception?
Jos
|
|
|
Post by foxpropgmr on Jun 7, 2021 14:16:10 GMT 1
Do you have a copy of foxprox.exe?
|
|
|
Post by Jos on Jun 7, 2021 14:39:31 GMT 1
Yes, I have that.
Jos
|
|
|
Post by foxpropgmr on Jun 22, 2021 4:46:29 GMT 1
Jos ....
Open foxprox and get to a Command box
Type in "modi repo test" <enter>
Type Alt+O, then "v" (for Variables)
Then <enter> (for Add)
Fill Variable Name with "X", Value to Store with 1
Then press Ctrl+Enter. It should error out at this point.
|
|
|
Post by Jos on Jun 22, 2021 14:24:00 GMT 1
Found the mishap.
vDos optimizes FoxProX performance by executing some frequent used core functions directly, instead of putting those thru the emulated CPU. At first the start of the functions are marked so the CPU turns over control to the corresponding native code. To get a slight additional speed gain, the instruction that called the function is also replaced by a marker. That then saves an emulated CALL and RET instruction.
Instead of a CALL function_address, FoxProX in your example uses at the end CALL [ECX+0x116] to call the strlen() function. Putting the marker over that code messes up the CALL instruction.
I removed placing that second marker for all functions to be on the safe side.
I’ll send you a modified vDos.exe.
Jos
|
|
|
Post by foxpropgmr on Jun 22, 2021 21:42:11 GMT 1
Thanks!! Works fine.
Walt
|
|
|
Post by Jos on Jun 22, 2021 21:52:55 GMT 1
Thanks for the feedback.
Jos
|
|
|
Post by foxpropgmr on Jun 22, 2021 22:07:59 GMT 1
Jos ...
Something else happened. With the newest version of vDos, FoxproX displays and processes (Count, Sum, etc) only the first record of any database it opens.
|
|
|
Post by foxpropgmr on Jun 22, 2021 22:13:52 GMT 1
It may have to do with existing indexes. It opens non-indexed files ok. And if I remove an index from a file that didn't display properly, then it displays properly.
|
|
|
Post by foxpropgmr on Jun 22, 2021 22:19:30 GMT 1
It may have something to do with multiple indexes. I put one index on a file and it displayed properly. Then I put all the indexes it should have and only the first record appeared.
|
|
|
Post by foxpropgmr on Jun 22, 2021 22:24:20 GMT 1
I think it has something to do with the Deleted() function. Things are ok until I index with the deleted function.
Here's the Foxpro command >>> Index on Deleted() tag Deleted
|
|
|
Post by Jos on Jun 22, 2021 22:30:34 GMT 1
Some FoxProX core functions substitutions are kind of optimistic. And the vDos I sent comes with more than 2021.05.01.
I for instance didn’t detect virtual page ‘crossovers’ in those functions, so left out (a bit of needless time consuming) checking for such.
Could you produce some test to demonstrate/replicate that indexing issue?
Jos
|
|
|
Post by foxpropgmr on Jun 23, 2021 0:38:34 GMT 1
do you have a .dbf style database?
If so, open it exclusively Use (database name) excl
Run this command on it >> Index on Deleted() tag Deleted
Then "Browse" it.
If you know it has 50 records, but you see only one; that's it.
Let me know if you need a sample database.
Walt
|
|
|
Post by Jos on Jun 23, 2021 8:52:29 GMT 1
I tested with vDos 2021.05.01 and the one I sent you:
Use WALT.DBF excl Index on Deleted() tag Deleted
WALT.DBF contains 615 records, FoxProX reports “615 records indexed”, and all 615 are shown with “Browse”.
I’m missing something?
Jos
|
|