http://bugs.winehq.org/show_bug.cgi?id=4654
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #16 from Anastasius Focht focht@gmx.net 2008-11-01 09:28:08 --- Hello,
--- quote --- Download link is busted. Can someone retest? --- quote ---
Download link should be updated to: http://www.ebase.org/download Current version tested: http://www.ebase.org/files/ebase/ebasepro220-070714-winsetup.exe
Yes, correct $I10_OUTPUT prototype/stub is still missing. The app is based on FileMaker. Judging from how the app builds the stack frame before calling $I10_OUTPUT and extracts return data:
calling conv: cdecl return type: int/long (1 = ok, 0 = IEEE overflow?) arg1: long double value (real80, 10 byte) -> MSVCRT__LDOUBLE arg2: int max_digits (max. count of digits in following structure) arg3: int flags ? (not sure, the app has it hard coded to 0) arg4: ptr to caller supplied result structure, I call it "I10_OUTPUT_DATA"
struct I10_OUTPUT_DATA { short decimal_point_pos; /* decimal-point position */ char sign; /* sign indicator: "-", " " */ unsigned char digits; /* number of digits returned (excluding NULL term) */ char digit_buf[1]; /* storage to digits string (including NULL terminator) */ }
Example dumps of arg4/I10_OUTPUT_DATA data after app called $I10_OUTPUT:
--- snip for long double "0.0" (retval=1) --- 00 00 20 01 30 00 ... --- snip --- decpos = 0, sign = " ", digits = "0"
--- snip for long double "1.0" (retval=1) --- 01 00 20 01 31 00 [30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 39 33 00]... --- snip --- decpos = 1, sign = " ", digits = "1"
--- snip for long double "-1.23" (retval=1) --- 01 00 2D 01 03 31 32 33 00 [30 30 30 30 30 30 30 30 30 30 30 30 30 38] ... --- snip --- decpos = 1, sign = "-", digits = "123"
--- snip for long double "-NAN" (retval=0) --- 01 00 2D 06 31 23 51 4E 41 4E 00 ... --- snip --- decpos = 1, sign = "-", digits = "1#QNAN"
The remaining parts of digits buffer seems to get overwritten, but of no use for final result (digits taken until first NULL terminator).
If you fix the function signature and .spec file you get following output (only printing out args and returning 0, not touching arg4):
--- snip --- 001d:Call msvcrt.$I10_OUTPUT(00000000,80000000,00323fff,00000011,00000000,0032f55c) ret=10001035 001d:fixme:msvcrt:MSVCRT_I10_OUTPUT (1.000000, 17, 0, 0x32f55c) 001d:Ret msvcrt.$I10_OUTPUT() retval=00000000 ret=10001035 001d:Call msvcrt._controlfp(00000000,00000000) ret=100044ba 001d:trace:msvcrt:_control87 (00000000, 00000000): Called 001d:trace:msvcrt:_control87 Control word before : 00001372 001d:trace:msvcrt:_control87 Control word after : 00001332 001d:Ret msvcrt._controlfp() retval=000c0003 ret=100044ba 001d:Call KERNEL32.lstrlenA(10012370 "\xf5$\x02`9k\xc8{\x88\xf520000") ret=10004a9e 001d:Ret KERNEL32.lstrlenA() retval=0000000f ret=10004a9e 001d:Call ntdll.memmove(0032f63d,10012370,0000000f) ret=10007f3c 001d:Ret ntdll.memmove() retval=0032f63d ret=10007f3c 001d:Call ntdll.memmove(100124e4,0032f63d,0000000f) ret=10007eee 001d:Ret ntdll.memmove() retval=100124e4 ret=10007eee 001d:Call ntdll._itoa(fffff56d,100124f4,0000000a) ret=100049e3 001d:Ret ntdll._itoa() retval=100124f4 ret=100049e3 001d:Call msvcrt.atof(100124e4 "\xf5$\x02`9k\xc8{\x88\xf520000E-2707") ret=100049ee 001d:Ret msvcrt.atof() retval=000000f5 ret=100049ee --- snip ---
The arg types seem ok, but the output structure needs to get initialized, otherwise garbage might be taken for valid. Initializing it with plausible values seem to get the app further, though $I10_OUTPUT will need a real implementation, converting the long double to string representation.
Hope this helps for any takers.
Regards