|
Post by psmart on Jul 10, 2021 7:59:37 GMT 1
I'm migrating a legacy Paradox 4.5 application to run under vDOS 2021.05.01 on Windows-10 64-bit. (I'm actually running the intermediate update provided to fix a command problem. Thanks Jos!) It's generally going very well, except that most math functions that should return zero are actually returning "blank", which is a unique Paradox value.
For example, all of these expressions return blank instead of the expected zero value:
int(0.5) = blank mod(30,10) = blank 0/1 = blank 1*0 = blank 1.0 * 0.0 = blank 5/5-1 = blank sin(0) = blank
These expressions work OK:
1-1 = 0 2-1 = 1
Basically, any expression involving multiplication or division seems to be afflicted. There are no applicable settings in Paradox that might control this behavior. All math operations involving non-blank numeric values should return a non-blank numeric result. Are there any options in vDOS pertaining to the math co-processor that might effect this behavior?
|
|
|
Post by Jos on Jul 10, 2021 8:52:23 GMT 1
No options to manipulate the emulated FPU. I don’t know the special meaning of blank results in computations, or how Paradox determines the result being ‘blank’ instead of zero.
Can you submit some sample to demonstrate this behavior, I don’t have Paradox 4.5.
Jos
|
|
|
Post by psmart on Jul 10, 2021 16:52:21 GMT 1
Numeric fields in a table can be blank, which is a distinct state from zero. All numeric fields in a table are initially blank. But numeric expressions should never return a blank value. If they succeed, they always produce a numeric result, as they do in other programming languages.
Unless you are able to run Paradox 4.5, I'm not sure what I can provide as far as a "sample". The problem occurs in many places in my scripts. For example, this is a simplified line:
A=0/1+2
This produces the error "Non-blank numerical value expected". If you break it down, 0/1 succeeds, but with an (incorrect) blank result. The error message occurs when it tries to add 2.
|
|
|
Post by Jos on Jul 10, 2021 18:26:55 GMT 1
So ‘blank’ would mean uninitialized/undefined?
I suspect Paradox uses some logic to test if the 0 result of a computation is actually 0. If it determines it isn’t, the result is set to blank. Perhaps that is some method to remedy an early FPU bug.
But I would need some test program, like "Hit a key" to execute a faulty computation…
Jos
|
|
|
Post by psmart on Jul 11, 2021 4:00:40 GMT 1
Undefined variables have no value at all and will generate an error if accessed before the first assignment. "Blank" is a specific state for a defined variable. Blank can be assigned explicitly e.g. A=BlankNum(), or assigned from a blank database field e.g. A=[Field]. But a numeric computation NEVER returns blank. If you attempt to operate on a blank value an error will occur. That's what I'm experiencing. Somehow a zero result is being mistaken for BlankNum().
Unfortunately, there is no documentation as to how BlankNum() is internally recorded/stored/coded. For a floating-point value I suspect they are using a unique bit pattern in the FP value, and this is somehow being confused with a zero result. If this is true, perhaps there is something in the vDOS emulated FPU that is setting or triggering the blank indicator.
Unless you can run Paradox 4.5, I'm not sure how I can provide a working example. If you have Paradox it's dead easy: 1) Press Alt-F10 to open the PAL menu 2) Select "Value" from the menu 3) When prompted for "Expression" enter 0/1 This should display 0 in the lower-right, but because of this bug it will display a blank result, so you won't actually see anything.
Also try the expression isblank(0/1), which will return True (it should be false) confirming that a blank result is being generated.
By comparison, isblank(1/1) returns false, since 1/1 is correctly evaluated with a result of 1, which is not blank.
I've done lots of other tests, all confirming the generation of a false blank result in place of zero.
As a work-around, is there a way to disable the 80387 FPU emulation in vDOS? If Paradox doesn't detect a co-processor I think it will revert to internal Floating Point operations, perhaps avoiding the problem.
|
|
|
Post by Jos on Jul 11, 2021 8:52:55 GMT 1
I also meant the value of a variable not being initialized/defined, not the variable itself.
I only have Paradox 3.5, and that gives correct results with for instance 0/1, isblank(0/1) and isblank(1/1).
FPU emulation can’t be turned off. Even if, you wouldn’t be pleased: FPU operations would be emulated by Paradox, while the whole lot of resulting X86 instructions would be emulated by vDos. The speed of FPU operations would drop by 99% or so.
I’ll look on the Internet if there’s a Paradox 4.5 copy around.
Jos
|
|
|
Post by psmart on Jul 11, 2021 16:45:40 GMT 1
"I also meant the value of a variable not being initialized/defined, not the variable itself."
Not sure I follow. Paradox variables are declared by their first assignment. So a variable cannot exist without a value.
I'll see if I can run Paradox 3.5 for testing. 4.5 has been better in all regards, so I've never had a reason to go back.
|
|
|
Post by Jos on Jul 11, 2021 23:11:13 GMT 1
My understanding was “blank” is a special condition of a variable, no value is assigned to it. So I guess A=0/1 will be the same as A=BlankNum() with Paradox 4.5/vDos.
Jos
|
|
|
Post by psmart on Jul 12, 2021 2:54:13 GMT 1
A=0/1 should be the same as A=0. Both should have the value zero.
BlankNum() is a separate value. The problem here is that an expected zero result from multiplication of division is returning BlankNum() instead of zero.
0 = 0 (obviously) but 0/1 is returning BlankNum() instead of zero. Interestingly, 1-1 returns zero (as it should), but 1.1-1.1 returns BlankNum(), so this seems to be floating point issue.
So 1-1 and 0/1 (which should both return zero) are actually returning different values. I'm hoping that's a clue as to the source of the problem.
|
|
|
Post by psmart on Jul 12, 2021 3:11:45 GMT 1
For background, BlankNum() is the default value for a numeric field in a table. This allows unused numeric entries to be blank instead of zero.
Numeric expressions, on the other hand, should never return BlankNum(). They should always return a numeric value, be it zero or non-zero, but never return BlankNum. So BlankNum doesn't generally occur in variables, unless it is assigned from a blank numeric field in a table.
|
|
|
Post by Jos on Jul 13, 2021 10:05:49 GMT 1
I found a Paradox 4.5 DOS version at vetusware.
Installed it, and could reproduce the FPU computation issue.
Noticed Paradox in vDos 2020.03.01 works correctly.
So I went over the changes to the FPU emulation between the two versions . Many changes to the FPU and how it’s called, but I couldn’t find a cause.
Decided to do a more thorough debug what is going on inside the FPU emulation of both versions. Surprise, surprise, with version 2020.03.01 Paradox doesn’t go into the vDos FPU emulation, but uses its own software FPU emulation!
The presence of a FPU can be detected in several ways. The simplest is to just check the BIOS equipment list flags. 2020.03.01 had the bit indicating a FPU is present off. So some programs (like Paradox) didn’t detect a FPU, 2021.05.01 has that bit set to on.
That explains why Paradox in 2020.03.01 works correctly. Not the ‘blank’ results in 2021.05.01. Will take some more time to track that down, so for now you could use 2020.03.01.
Jos
|
|
|
Post by psmart on Jul 13, 2021 16:43:34 GMT 1
Very interesting. Hopefully you can still find the problem in the FPU emulation, since it should match the results when paradox does it's internal FP code. Unfortunately I don't think I can use the earlier version, because I need the command /c fix that you recently provided.
FWIW, Paradox does seem to be detecting the FPU, at least that's what it reports in the "Machine Info" from the Custom Configuration Program, copied below.
Detailed Machine Information Copyright (c) 1990,1993 Borland International ---------------------------- DOS Version: 5.0 BIOS Version: Not Found BIOS ID String: CPU Type: 80386/80486 class Coprocessor: 80387 Paradox is currently running in protected mode Total Main Memory: 655,360 bytes Extended Memory: Used by Paradox in protected mode Expanded Memory: In use by Paradox as a swap device Display Adapter 1: VGA Monitor 1: PS/2-compatible color display Mouse Driver Version: 20.81 Configuration signature: Configuration signature not found Disk Drive Information ---------------------- Boot Drive: C: Drive Total Bytes Free Bytes Local? Type (Floppy Only) ----- -------------- ------------- ------ ------------------------- C: 134,213,632 125,829,120 Y N: 134,213,632 125,829,120 Y P: 134,213,632 125,829,120 Y Contents of CONFIG.SYS ---------------------- File not found Contents of AUTOEXEC.BAT ------------------------ rem vDOS AutoExecc File for paradox set user=%%user%% if (%user%)=() set user=undefined REM C: will be current folder (normally n:\pdox45), which must contain me\me.exe use p: c:\temp use n: n:\ n: cd \pdox45 paradox -user %user% \pdoxdata\mail -extk 16000 -emk 0 -bios -share -diag -nettrace -prtready -space exit
|
|
|
Post by Jos on Jul 13, 2021 18:17:29 GMT 1
I forgot about that /c fix. Paradox indeed detects a FPU with vDos 2021.05.01. In 2020.03.01 however not: Jos
|
|
|
Post by psmart on Jul 13, 2021 18:35:47 GMT 1
FYI, this same FPU issue also causes several parts of the Paradox CCP to fail with the error "Non-blank numerical value expected". I assume these routines are performing a FP operation that is returning blanknum instead of zero. I will try to re-test this with 2020.03.01
|
|
|
Post by Jos on Jul 13, 2021 21:18:15 GMT 1
I will have found the cause, but not all happy with that.
There’s a correction procedure in the FPU emulator for if a program stores a real number in a FPU register that comes extremely close to an integer. This was once added to circumvent a rounding bug in DataEase (DE). Removed in version 2018.05.01. But I had to reinstate it in 2020.03.01. I at least documented this, even the date (2020-01-06) I had to add it back in.
I have to figure out if it’s indeed exclusively related to DE. Then probably ‘fingerprint’ the three main DE versions, and only do this correction if one of these DE versions is running.
Could be I send you a provisional fixed vDos to do more thoroughly checking this is indeed the mishap with Paradox.
Jos
|
|