Re: Generate unicode CHAR messages
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >On Thu, 16 Nov 2000, Dmitry Timoshkov wrote: > >> Hello. >> >> Changelog: >> Dmitry Timoshkov <[EMAIL PROTECTED]> >> Always generate unicode CHAR messages. >> >Good day! > >This broke my mail app. I have been running with it 'til now, so I >guess you could say it isn't very broke, but if I have to change my >phone number I am SOL. It won't accept input in one text-entry item >(?) of a dailog. I have before and after +message,+key,+text logs, but >even after removing the beginning stuff and grepping out the >GetTextExtentPoint they are still to big to mail, unless you don't mind >gzipped and split. > >If I have missed a correction or some later patch that sets it right, >please point it out. I just pick from wine-patches and hope for the >best. Probably this is a case where ANSI <-> Unicode message conversions don't work correctly. I already mailed to Alexandre my preliminary patch (which doesn't work) for suggestions. CreateWindowExA/W should always allocate new window proc and subclass window in the case if class was registered with a not compatible function type (A instead of W and vice versa). IsWindowUnicode should return TRUE for windows created by CreateWindowExW without reference to by which version of RegisterClass (A or W) base class was registered. Currently in Wine winproc handling does something wrong. Right now I'm investigating it further. Until it will be fixed, switching to unicode of the internal USER classes risks break too many applications. But perhaps it is completely unrelated problem. Could you send me both traces: before and after my patch was applied (+relay,+key,+message)?
Re: DLL functions returning structs
from mingw32(gcc with CRTDLL): /* * div_t and ldiv_t are structures used to return the results of div and * ldiv. * * NOTE: div and ldiv appear not to work correctly unless * -fno-pcc-struct-return is specified. This is included in the * mingw32 specs file. */ So we should implement div and ldiv for i386 platform. (If we specify -fno-pcc-struct-return, some library functions may not work correctly.) An implementation of div(and ldiv) is: (please rewrite this code for inline assembler) _div: _ldiv: mov eax,[esp+4] cdq idiv [esp+8] ret -- Hidenori Takeshima
Re: DLL functions returning structs-Info+Suggestions
OK, I've been investigating (couldn't wait), heres what I've got so
far:
Recap: Using GetProcAddress to get a pointer (p_ldiv)to CRTDLL's
"ldiv" function, and calling through that pointer produces
errors in some cases. This is because ldiv returns a struct.
The problem occurs for any dll function that returns a struct when
one side (the process or the dll) is not the same as the other.
There are four situations to consider:
1. unix application calls unix .so
2. unix application calls win32 .dll
3. win32 application calls unix .so
4. win32 application calls win32 .dll
Case 1. unix calls unix (winelib apps)
This works fine. function pointer is defined as:
ldiv_t (__cdecl *p_ldiv)() = 0;
and the returned struct is assigned without problem:
ldiv_t ldt = p_ldiv(20L,3L);
Case 2. unix calls win32 (winelib, wine)
Doesn't work using the above code. ldiv_t is filled with crap.
The following works however:
void (__cdecl *p_ldiv2)() = 0; /* Note void return! */
ldiv_t ldt;
p_ldiv2(20L,3L);
__asm__ __volatile__( "movl %%eax, %0;" : "=m" (ldt.quot) : );
__asm__ __volatile__( "movl %%edx, %0;" : "=m" (ldt.rem) : );
Because in this case VC returns structs < 8 bytes in registers.
Note that this code will crash in case 1 (i.e. if unix .so is
called).
Case 3. win32 calls unix (wine)
Crashes into debugger (see last post for trace). I can fix this by
modifying the .so, so the .spec calls my function:
@ cdecl ldiv(long long) CRTDLL_ldiv
which I implement as:
void __cdecl CRTDLL_ldiv(long x, long y)
{
ldiv_t ldt = ldiv(x,y);
__asm__ __volatile__( "movl %0, %%eax;" : "=m" (ldt.quot) : );
__asm__ __volatile__( "movl %0, %%edx;" : "=m" (ldt.rem) : );
}
i.e. I load the struct into registers before returning. Of course,
this wont work with a unix caller.
Case 4. win32 calls win32 (wine)
This works fine, as you'd expect. The pointer and call
are exactly as in case 1.
Summary/Suggestions:
struct return conventions are different between gcc on linux and
win32 (and probably solaris etc as well). The method of gcc's returns
hasn't been investigated, but we cant change it anyway, unless we
want the Wine installation to require a recompile of every binary
on the box (including kernel), i.e *no way*.
The problem is that we must dynamically decide how to return
structs from .so based dlls based on whether the calling process
is a native or win32 binary. I'll start the ball rolling with
3 suggested solutions:
1. Allow .spec files to specify struct return values.
(I am not convinced this is a good idea anymore).
.spec files could be enhanced as per my previous mail.
The generated .spec.c file could hold a table of extra
info about structs being returned and generate two stubs,
one for host o/s calling programs, one for win32. The win32
stub would call the native version, load the returned value
into registers, and return. winelib progs would just link
direct to the native stub. GetProcAddress would determine
the callers type and return the appropriate stub.
Alternately, the base function could return its values in
registers, and a stub would be generated for native calls.
Theres a few possibilities around this area.
PROS: DLLs dont have to know about the mechanism.
CONS: Lots of work/overhead for a rarely used feature.
More work to implement structs > 8 bytes.
2. Make the DLL's do it.
Do something like:
.h :
#if defined(__GNUC__) && defined(__i386__)
void __cdecl CRTDLL_ldiv(long x, long y)
#else
ldiv_t __cdecl CRTDLL_ldiv(long x, long y)
#endif
.c:
#if defined(__GNUC__) && defined(__i386__)
void __cdecl CRTDLL_ldiv(long x, long y)
{
ldiv_t ldt = ldiv(x,y);
if (win32_caller())
{
__asm__ __volatile__( "movl %0, %%eax;" : "=m" (ldt.quot) : );
__asm__ __volatile__( "movl %0, %%edx;" : "=m" (ldt.rem) :
return;
}
_some_asm_here_to_push_the_return_value_the_way_gcc_does_
);
#else
/* All other callers/platforms must be native (winelib) */
ldiv_t __cdecl CRTDLL_ldiv(long x, long y)
{
return ldiv(x,y);
}
#endif
PROS: Dont have to touch spec files for this rare occurence
Can handle returning structs > 8 bytes when (if) they come up.
CONS: Must expose internal call to get process type for linux/x86
dlls
Note: I have to make sure this works!
3. Add a new function attribute to gcc
No Thanks. This would take forever...
So there you have it. If someone knows how to determine whether the
current process is native or win32, please let me know so I can test
#2 out. Other than that, feedback please!!
Cheers,
Jon
=
"May their negative actions ripen upon me. And may all my virtues ripen upon
them."-Nagarjuna, on Compassion
"If it could be talked about, everybody would have told their brother."-Chuang Tzu, on
Tao
[EMAIL PROTECTED] , [EMAIL PROTECTED]
__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/
DLL functions returning structs
Hi all,
While updating my crt test harness, I found a call returning strange
values using the native DLL. The call is "ldiv", which returns an
ldiv_t struct _by value_. ldiv_t is defined the same under linux and
windows. The spec entry is:
@ cdecl ldiv(long long) ldiv
i.e it uses the libc version.
My (linux) test harness uses LoadLibrary to load the DLL, and
GetProcAddress to get the function pointer. Problem is, the code:
ldiv_t ldt = p_ldiv(20L,3L);
fprintf(stderr,"%ld, %ld\n",ldt.quot,ldt.rem);
Gives with the wine .so:
6, 2
And with the real DLL:
1079733392, 1073782154
The .so is behaving 'correctly'. The win32 DLL results look like
addresses to me.
Compiling the program under vc and running the .exe under wine
generates:
with the wine .so
Call kernel32.372: GetProcAddress(40886000,00420028 "ldiv")
ret=00401050 fs=008f
trace:win32:MODULE_GetProcAddress (40886000,ldiv)
trace:win32:PE_FindExportedFunction (ldiv)
Ret kernel32.372: GetProcAddress() retval=4088f4f4 ret=00401050
fs=008f
Call crtdll.421: ldiv(0014,0003) ret=00401063 fs=008f
trace:seh:EXC_RtlRaiseException code=c005 flags=0
0807e690: exception_event( first=1,
record={context={flags=,eax=,ebx=400ff528,ecx=0014,edx=0003,esi=0003,edi=008f,ebp=405a6d34,eip=4027dada,esp=405a6d1c,eflags=00010206,cs=0023,ds=002b,es=002b,fs=008f,gs=,dr0=,dr1=,dr2=,dr3=,dr6=,dr7=,float={,,,,,,,,,,,,,,,,,,,,,,,,,,,}},rec={code=c005,flags=0,rec=(nil),addr=0x4027dada,params={1,14}}
)
0807e690: exception_event() = 0 { status=0,
context={flags=,eax=,ebx=400ff528,ecx=0014,edx=0003,esi=0003,edi=008f,ebp=405a6d34,eip=4027dada,esp=405a6d1c,eflags=00010206,cs=0023,ds=002b,es=002b,fs=008f,gs=,dr0=,dr1=,dr2=,dr3=,dr6=,dr7=,float={,,,,,,,,,,,,,,,,,,,,,,,,,,,}}
}
nasty, eh?
With the win32 .exe and win32 DLL i get the correct answer once
again.
So it appears that returning structs only works when the dll and
caller are built with the same compiler (or return convention).
Before I start checking further, I'd like to check whether anyone has
any info on this. Presumably what is happening is that vc++ and gcc
have different conventions for returning structs by value. If this is
true then we may need support in the .spec file for generating some
fixup asm to get around this, something like:
@ cdecl struct(8) ldiv(long long) ldiv
Which could mangle the return value into something gcc expects.
This begs the question of how this should be handled though - In
theory the stub must determine what convention the caller expects, so
it can return structs the way the elf or pe program expects. Or maybe
gcc has a flag for returning structs in an MS compatable way (Im off
to look now)?
So, has anyone come across this before, got more info, or am I
barking up the wrong tree?
Cheers,
Jon
=
"May their negative actions ripen upon me. And may all my virtues ripen upon
them."-Nagarjuna, on Compassion
"If it could be talked about, everybody would have told their brother."-Chuang Tzu, on
Tao
[EMAIL PROTECTED] , [EMAIL PROTECTED]
__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/
Re: Borland Database Engine and Delphi 4
--- cn <[EMAIL PROTECTED]> wrote: > George Saich wrote: > > < machine (Win98) and was > able to get the debugger working (Its a little > flakey,but seems to be > working). Additionally, I had to copy a RPCRT4.DLL > to the > C:\windows\system folder. With Kylix on the way I'm > not sure if anyone > besides me is interested in this, but if anyone is > interested let me know and I'll post what I did. > Anyone know what > RPCRT4.DLL does?>> > > As a novice, I failed to complete the installation, > without Windows > installed, at very early installation stage by > running d:\install.exe. > Would it be convenient for you to post the > step-by-step installation > procedure for Delphi/C++Builder? I had a (mostly) BCB v4 working from an existing install, awhile back. i.e. Windows already installed, using mostly Wine dlls, using Windows dlls for the rest, using an BCB v4 installed under windows and registiry keys 'ported' over to wine's registry file(s). BCB v4's only problem back then was that it locked-up when linking. Another Wine-Developer (I'll let him step in if he feels compelled to) sent me a patch that fixed that problem and I was a compiling fool. Compiling the testing nearly all of my favorite Example programs... I kinda stopped after I got to Swat!, that's gotta be my all-time favorite... HTH, George P.S. RPCRT4.DLL appears to be an important part of M$'s Remote Procedure Call routines. __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
Corel and Wine
does it explain the very low commits rate on Corel's CVS Wine tree ? http://news.cnet.com/news/0-1003-200-3785993.html A+ --- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle
