[Bug 4654] ebasePro 2.12 doesn't start properly--missing plugin

wine-bugs at winehq.org wine-bugs at winehq.org
Sat Nov 1 09:28:12 CDT 2008


http://bugs.winehq.org/show_bug.cgi?id=4654


Anastasius Focht <focht at gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |focht at gmx.net




--- Comment #16 from Anastasius Focht <focht at 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


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.



More information about the wine-bugs mailing list