September 2002 - Wine-Devel

Re: InitThreadInput16

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > True, but InitThreadInput16 is not such a function, InitThreadInput is. > So we had to invent a new name that does not exist in Windows. > And I thought the policy for new names which are wine specific was > to prefix them with wine_*. But in a way I see a point in this naming > convention, as it keeps the name close to an official function. However, > it is a departure from our naming policy, right? No, the naming policy has always been that 16-bit functions have a "16" suffix. That's necessary because most of the time there is a 32-bit one with the same name, and in our code they are in the same namespace. Usually they are only called from inside the same dll so you don't need to add the extra 32-bit export, but the naming convention is the same in both cases. > Also, there is a small problem with this 16-bit stuff: it is usually > called from 32-bit code, and this code has to do a 32->16 bit conversion > on handles, coordinates, etc, which are lossy. So I think it would make > more sense to export InitThreadInput32 (if we have to export a new name > anyway), and have InitThreadInput16 call it. This way we will have no > deps on 16bit code, and we can compile it out (just for kicks, winelib, > and to check that there are no 32->16 transitions). I disagree. The right fix to avoid calling 16-bit functions is to change the whole logic to not depend on them; simply hiding them behind a 32-bit export that doesn't exist on Windows is not a good fix. At least with the 16 suffix it's clear that something is wrong. -- Alexandre Julliard julliard(a)winehq.com

Sept. 27, 2002

Re: InitThreadInput16

by Dimitrie O. Paun

On September 27, 2002 01:57 pm, you wrote: > No, it's better to always use official functions. True, but InitThreadInput16 is not such a function, InitThreadInput is. So we had to invent a new name that does not exist in Windows. And I thought the policy for new names which are wine specific was to prefix them with wine_*. But in a way I see a point in this naming convention, as it keeps the name close to an official function. However, it is a departure from our naming policy, right? Also, there is a small problem with this 16-bit stuff: it is usually called from 32-bit code, and this code has to do a 32->16 bit conversion on handles, coordinates, etc, which are lossy. So I think it would make more sense to export InitThreadInput32 (if we have to export a new name anyway), and have InitThreadInput16 call it. This way we will have no deps on 16bit code, and we can compile it out (just for kicks, winelib, and to check that there are no 32->16 transitions). -- Dimi.

Sept. 27, 2002

Re: InitThreadInput16

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > But it seems that InitThreadInput is an undocumented API. Why export an > (and depend on) undocumented 16-bit function. If we need the functionality, > shouldn't we rather export a 32-bit API, with a name like > wine_init_thread_input > or what have you, and with a well defined, and understood semantics? No, it's better to always use official functions. It doesn't matter if it's not documented, we have to understand it and implement it correctly anyway. So it's better to use it internally too than to invent a different one to do the same thing. -- Alexandre Julliard julliard(a)winehq.com

Sept. 27, 2002

Re: WM_STYLECHANG{ING/ED}

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > So my question to you: do you know for sure of any case when we change > some of those bits, and we should not emit a notification? No, I haven't looked into it. That doesn't mean we should start sending notifications everywhere without checking what Windows does... -- Alexandre Julliard julliard(a)winehq.com

Sept. 27, 2002

Re: WM_STYLECHANG{ING/ED}

by Dimitrie O. Paun

On September 27, 2002 12:59 pm, Alexandre Julliard wrote: > "Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > > Shouldn't we send such a message, when we touch *any* WS_[EX_]* bits? > > Sometimes yes, sometimes no. The only way to know is to test that > specific situation under Windows. [Note to self: I should find a way to test stuff on Windows] So my question to you: do you know for sure of any case when we change some of those bits, and we should not emit a notification? -- Dimi.

Sept. 27, 2002

Re: InitThreadInput16

by Dimitrie O. Paun

On September 27, 2002 01:06 pm, Alexandre Julliard wrote: > It should, but to work around it we have added an InitThreadInput16 > export in user32.spec; this time it's a normal 32-bit export so it can > be used from other dlls. This is really a hack because Windows doesn't > do it like this of course. But it seems that InitThreadInput is an undocumented API. Why export an (and depend on) undocumented 16-bit function. If we need the functionality, shouldn't we rather export a 32-bit API, with a name like wine_init_thread_input or what have you, and with a well defined, and understood semantics? -- Dimi.

Sept. 27, 2002

Re: InitThreadInput16

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > This DLL stuff is a bit confusing. In dlls/user/user32.spec we have > > 409 pascal16 InitThreadInput(word word) InitThreadInput16 > > so the exported name is InitThreadInput, right? No, that line is not in user32.spec, it's in user.exe.spec which is the 16-bit one. 16-bit functions cannot be imported from other dlls since this would require calling down to 16-bit which we want to avoid. So that InitThreadInput export is only available for 16-bit binaries, not for Winelib dlls. > Then how come in ./dlls/x11drv/desktop.c we call it like so: > > win->hmemTaskQ = InitThreadInput16( 0, 0 ); > > Shouldn't this yield an error? It should, but to work around it we have added an InitThreadInput16 export in user32.spec; this time it's a normal 32-bit export so it can be used from other dlls. This is really a hack because Windows doesn't do it like this of course. -- Alexandre Julliard julliard(a)winehq.com

Sept. 27, 2002

Re: WM_STYLECHANG{ING/ED}

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > In my relentless quest for speed :), I discovered that we don't send > a WM_STYLECHANGED message when we flip the WS_VISIBLE, or WS_VSCROLL, > and maybe a bunch of others, I haven't checked. > > Shouldn't we send such a message, when we touch *any* WS_[EX_]* bits? Sometimes yes, sometimes no. The only way to know is to test that specific situation under Windows. -- Alexandre Julliard julliard(a)winehq.com

Sept. 27, 2002

Re: How to tell winemaker and winebuild what I want to tell it

by Alexandre Julliard

"Bill Medland" <billmedland(a)look.ca> writes: > So I guess I am doing something dangerous in adding -lntdll.dll to the link > (which does the trick very nicely). Yes, this is asking for trouble. It happens to work now but this will likely change in the near future. -- Alexandre Julliard julliard(a)winehq.com

Sept. 27, 2002

-gstabs and '#warning "8 as alignment is not supported"'

by Greg Turner

OK, I did this: Index: configure =================================================================== RCS file: /home/wine/wine/configure,v retrieving revision 1.341 diff -u -r1.341 configure --- configure 25 Sep 2002 03:29:55 -0000 1.341 +++ configure 27 Sep 2002 15:20:40 -0000 @@ -1998,7 +1998,7 @@ CFLAGS=$ac_save_CFLAGS elif test $ac_cv_prog_cc_g = yes; then if test "$GCC" = yes; then - CFLAGS="-g -O2" + CFLAGS="-gstabs -O2" else CFLAGS="-g" fi and sure enough, debug symbols loaded for me. The only remaining annoyance: winedbg doesn't automagically find the sources like gdb. Presumably, I can fix this by issuing "dir" commands to winedbg. So I'm happy (although it'd be nice to not have to issue those "dir" commands). Thanks! Can anyone think of a reason not to submit this as a patch? I tried -gstabs in gcc 2.96 (the only other gcc readily available to me) and it was happy, so presumably its pretty portable, and it looks like the configure change above would only apply to gcc, which seems like precisely the right thing to me. Now one other question for y'all wine gurus out there: I was looking for the alignment issue I mentioned before, and it turns out not to be an "-malign=" problem like I was suspecting. Instead, I was seeing "8 as alignment is not supported" warnings from include/pshpack8.h: # if defined(__GNUC__) || defined(__SUNPRO_C) || defined(__SUNPRO_CC) || defined(_MSC_VER) # pragma pack(8) # warning "8 as alignment is not supported" # elif !defined(RC_INVOKED) # error "Adjusting the alignment is not supported with this compiler" # endif I don't understand, if the alignment isn't supported, why the #pragma pack(8) is there...? Anyhow, since it looks like everybody using gcc gets the same warning, it's probably not a gcc3.2 bug... but I was wondering if anyone could clarify what's going on, and whether this indicates a problem in crypt32.dll.so (the affected wine dll). Thanks for your patience and help, -gmt -- "Waiting periods are only a step. Registration is only a step. The prohibition of private firearms is the goal." -U.S. Attorney General Janet Reno, December 1993

Sept. 27, 2002