|
Post by psmart on Jul 13, 2021 23:47:43 GMT 1
Glad to help in any way I can. Perhaps a config.txt option to control FPU emulation?
FYI, our goal is to get a large Paradox application running under Windows-10, and will be purchasing a network license for that purpose. In the mean time, if you have a donation mechanism, I'm glad to support your efforts. (Found it!)
|
|
|
Post by Jos on Jul 14, 2021 9:12:58 GMT 1
Although that rounding correction could be controlled by a config.txt option, I dislike adding options to it. My experience is the more options and documentation is provided, the less is actually read and understood.
With only some 10 options (not counting those of printing), there are already too many questions due to not reading or understanding those few. In the past there was for instance an option to control what and how much memory vDos would make available to DOS programs. Resulting in many questions how to optimize that setting for a particular program. Now it’s just fixed at 16MB EMS and XMS (or extended) and ‘straight’ conventional memory, no more questions about memory settings, or users endlessly experimenting…
Thanks for your generous donation.
Jos
|
|
|
Post by psmart on Jul 14, 2021 17:35:47 GMT 1
Fully understand. It just seemed that something like "fixing a bug in DataEase" that required a deviation from 100% FPU emulation, would justify a specific setting, so as to avoid any possibility of problems in other environments, such as Paradox. This would allow you to implement application-specific features without any risk of impacting other applications.
BTW, do you have a full list of changes in each release? All I could find was the summary on the download page.
FYI, I've gone back and done some testing on the earlier versions, and found that 2020.03.01 seems to be free of the issues we've discussed. (1) It avoids FPU emulation and forces Paradox to handle FP internally, which avoids ALL the errors I was getting with blank values, including multiple errors in the custom configuration program. (2) The "command /c" option appears to work without the following space. I can see it in the log. So it looks like the dependency on a space is something that was (inadvertently?) added in 2021.05.01. Mind you, it looks like there are still plenty of enhancements in 2021.05.01 that would be useful, so I do look forward to a new release, but in the mean time I can continue work on my application with the old version.
|
|
|
Post by Jos on Jul 14, 2021 19:12:09 GMT 1
You’re probably right with “fixing a bug in DataEase”. Then again, programs mostly (always?) use common FPU libraries, using the real FPU if not present, or emulating one. So that bug could be very well be in several other programs.
I however (for now?) opted for another strategy: The very first call to store a 64 bit floating point in a FPU register is inspected for the specific value Paradox 3.5 and 4.5 (but also dBase V) uses, probably to determine if it needs adjustments. The rounding correcting of vDos is then disabled.
I’ll send you a modified vDos.exe. I verified your examples in Paradox 3.5 and 4.5. And some formulas in dBase V.
I only save the lists of “Major/noticeable” changes for later references. A full list wouldn’t be very useful. For instance the CPU emulation undergoes a vast amount of (mostly small individual) changes each vDos release. So the vDos CPU got over 100% faster the past years.
The need for a leading space would be due to, probably not directly related, changes to command line handling.
Jos
|
|
|
Post by psmart on Jul 15, 2021 6:47:53 GMT 1
Got the update. Thanks. Unfortunately none of the LEFT Alt key combinations are working in Paradox. For example, pressing Alt-e generates just the letter e. This seems to affect all Alt keys when using the LEFT Alt key. The right Alt key works as expected! Ctrl keys are OK.
|
|
|
Post by herman on Jul 15, 2021 6:48:43 GMT 1
In dBase 5 is no problem and gives 0 for
int(0.5) mod(30,10) 0/1 1*0 1.0 * 0.0 5/5-1 sin(0)
Herman
|
|
|
Post by Jos on Jul 15, 2021 9:36:22 GMT 1
An issue was reported with the right Alt key and US keyboards (only). Windows then reports for Alt+character the Unicode of that character, causing vDos to report that character key was pressed.
The fix for that oddity was incorrect, I’ll send you a new vDos.exe later this day.
Jos
|
|