January 2002 - Wine-Devel - list.winehq.org

C++ Winelib problems

by Peter Hunnisett

Hello all, I've been tooling around with building a C++ application using Winelib and I've come across a couple of problems resulting from the use of global constructors. The problems can be reproduced with a simple C++ application which from a constructor calls a method which is resolved through a dll import. 1) If this program is the main program, wine_dll_set_callback has not yet been invoked so the __wine_dll_register call doesn't resolve the import list. The problem is that the constructors of the program are run immediately after the dll is registered which results in calling a non resolved import. This can be worked around by simply creating a non C++ stub which does a LoadLibrary/GetProcAddress on the real main exe. However I'm wondering if there is a good reason for needing to wait until after the main exe is loaded before being able to resolve imports? I must be missing something from my quick view of the code. 2) The order of running constructor execution and DLL entry point is incorrect. To show the problem assume you have foo.dll which imports bar.dll Present order for builtins: Load foo.dll Start to resolve foo.dll dependencies Start to resolve bar.dll dependencies Finsh resolving bar.dll dependencies Run bar.dll C++ constructors Finish resolving foo.dll dependencies Run foo.dll C++ constructors Run bar.dll DLL entry point Run foo.dll DLL entry point I actually haven't checked if PE images presently have the same problem since I don't know what triggers the ctor execution for a PE image. I assume that it's the running of the DLL entry point, but I don't know for sure. Hopefully I'll find the time at some point this week to whip up a test. The correct order: Load foo.dll Start to resolve foo.dll dependencies Start to resolve bar.dll dependencies Finsh resolving bar.dll dependencies Run bar.dll C++ constructors Run bar.dll DLL entry point Finish resolving foo.dll dependencies Run foo.dll C++ constructors Run foo.dll DLL entry point The problem seems reasonably simple enough to resolve but I'm sure that I'm missing something since my patch doesn't work for the present version of wine :(. I think that the problem is that there's an issue with inter DLL dependencies somewhere as it dies in SYSMETRICS_Init with a bad hdc. I've attached a patch which removes the recursive dep search from MODULE_DllProcessAttach and moves MODULE_DllProcessAttach from LoadLibraryExA into MODULE_LoadLibraryExA. Does this seem like a reasonable approach to take? Any problems with the patch? Ciao, Peter

Jan. 22, 2002

Re: C testing framework. ASCII/Unicode portable version

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > If you look even more carefully you'll find that my > test does not have a single real ASCII character :-P > Indeed, I do not test text processing there at all. I > use text strings there for: > a) identifying registry keys > b) testing system settings broadcast behaviour > (comparison against empty string) > c) tests description But none of them needs Unicode at all, you would test exactly the same thing by doing an ASCII only version (ok except maybe the empty string stuff). And how do you test for instance SystemParametersInfoA sending a message to a Unicode window proc? You can't do that with TCHAR. > b) multibyte, not one-byte characters are the common > lowest denominator. Converting the test to TCHAR.h I > had to remember that I'm using multi-byte characters. > E.g. in some places I needed to replace sizeof(buf) to > sizeof(buf)/sizeof(_TCHAR). That's not multi-byte charset support. Multibyte is where you can have two ASCII bytes represent one character in MBCS codepages. This is another example where ASCII and Unicode behave differently; so if you put a multi-byte char in one of the _T("") strings the test will break for any API that returns a character count. > We don't use TCHAR in Wine because it does not give us > any advantages. W and A Wine functions can't exist in > parallel universes, they must interact, probably > factor out common behaviour. > > But I can see which advantages we'll have with using > TCHAR with wine tests. Yes of course there are a few advantages. There are also large inconvenients, which more than offset the small gain IMHO. If your tests for A and W are identical it's not big deal to write both; and if they are different at least you can write them without having to resort to ugly #ifdefs and other hacks. -- Alexandre Julliard julliard(a)winehq.com

Jan. 22, 2002

Re: C testing framework. ASCII/Unicode portable version

by Andriy Palamarchuk

--- Alexandre Julliard <julliard(a)winehq.com> wrote: > If all you want is to call the function with some > random string, then > you don't really need to call both A and W since > they usually use the > same code anyway. So just call the A function and > you will have tested > as much (or as little) of the W function that you > would have by > recompiling the TCHAR code as Unicode, while > avoiding the whole macro > mess. Alexandre, one time you were saying than W and A functions can't be tested by the same code because they are completely different. Now you are saying that we don't need to test W function because they are no more than conversion to ASCII, calling A function, converting results back to Unicode and it is sufficient to test A function and check the conversions. Using TCHAR insures that A and W functions have the same behaviour. Why you are against using the same code for this and using encoding-specific code to check the differences? Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 22, 2002

Re: C testing framework. ASCII/Unicode portable version

by Andriy Palamarchuk

Alexandre, while I'm not pushing using TCHAR.h here, can't agree with some your arguments. --- Alexandre Julliard <julliard(a)winehq.com> wrote: > Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > > Here I don't agree with you. Programming with > TCHAR is > > *exactly* the same as programming with WCHAR, but > with > > different names. You think once - in WCHAR terms > and > > get as a bonus ANSII version! > > You don't think in WCHAR terms. There isn't a single > real Unicode > character in your test, it's all purely ASCII. If you look even more carefully you'll find that my test does not have a single real ASCII character :-P Indeed, I do not test text processing there at all. I use text strings there for: a) identifying registry keys b) testing system settings broadcast behaviour (comparison against empty string) c) tests description In *my* test application W and A versions of functions have exactly the same behaviour and I'm very glad I don't need to write the same code twice. > That's the main problem > with TCHAR, you have to stick to the lower common > denominator, which > means no Unicode chars, no multi-byte support, etc. a) in places where you need unicode characters or Unicode-specific checks you can use them with #ifdef _UNICODE. Test strings generator even will help to eliminate some of such conditionals. b) multibyte, not one-byte characters are the common lowest denominator. Converting the test to TCHAR.h I had to remember that I'm using multi-byte characters. E.g. in some places I needed to replace sizeof(buf) to sizeof(buf)/sizeof(_TCHAR). > > In fact, code became cleaner after I removed "if > > (has_unicode()) " blocks, A<->W conversions, > letters > > "A", "W" from API names. I feel that in this case > I > > don't need to "think twice" - once in terms of > ANSII, > > the second time - in terms of Unicode. > > But we want people to think twice, and write a test > adapted to the > function they are testing; you don't test ASCII and > Unicode the same > way, except superficially. It would be silly for me to separate W and A checks everywhere if they are different only in a few cases. > This TCHAR crap is just a marketing tool to let > Microsoft pretend that > converting to Unicode is easy; but it's not usable > in real life Nope. Purpose of TCHAR.h is support of compilation of the same code for both - Unicode and ASCII platforms. You still have to make the same decisions as with moving to pure Unicode API. > how many apps do you know that ship both an A and a W > exe?) I came across a few OS projects which use TCHAR: * Tcl - e.g. see http://tcl.apache.org/sources/tcl/win/tclWinFCmd.c.html * XEmacs - this article will be interesting for you: http://www.xemacs.org/Architecting-XEmacs/windows-I18N.html You will agree with me - it is difficult to find this sort of statistics. But many application have separate binaries for Windows NT and for Windows 95. One of differences between these binaries can be usage of Unicode. > We don't use > it in Wine, and we must not use it in Wine tests > either. We don't use TCHAR in Wine because it does not give us any advantages. W and A Wine functions can't exist in parallel universes, they must interact, probably factor out common behaviour. But I can see which advantages we'll have with using TCHAR with wine tests. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 22, 2002

Re: [PATCH] Overlapped recv(), WSARecv()

by lawson_whitney＠juno.com

On Tue, 22 Jan 2002, Martin Wilck wrote: > IE and Netscape on Wine users, where are you ? :-) > > Thanks again, > Martin > > If I could work out how to make netscrape use a proxy, maybe I could see what winehq looks like to a cluttered browser :-). Lawson

Jan. 22, 2002

sparc solaris build

by Srdjan Matovina -- Customer Engineering

Hi, I've built wine-20011226 on sparc with the only one issue left open: The resource compiler wrc core dumps when hit the bitmap (BINRES) part of .rc file. There is an alignment problem inside convert_bitmap() in newstruc.c file. The alignment problem came out from BITMAPINFOHEADER struct. But this was just the beginning! I've commented out body of convert_bitmap() just to see what will happen when run libtest/hello test case. After running wineserver, the libtest/hello core with the same problem: Program terminated by signal BUS (invalid address alignment). This time at different place: RtlSecondsSince1970ToTime from ntdll.so (time.c) struct FILETIME. Obviously I'll have an alignment problem with every structure in general. Is there any guideline for this kind of problem? Thanks Srdjan

Jan. 22, 2002

Re: [PATCH] Overlapped recv(), WSARecv()

by Martin Wilck

On Mon, 21 Jan 2002 lawson_whitney(a)juno.com wrote: > Sometimes, not often, these sessions can fail for no > good reason, or at least not one that has anything to do with program > code on this end. I thought maybe trace was changing the timing of > things, so I tried the app without a trace, but with tcpdump active. > AFAICT, it worked fine. Twice. Some good news, after all!! > Sorry, maybe I put you and me both to a lot of trouble because of an > unrelated glitch. I would feel better if somebody else besides me would > take a swat at testing these winsock patches, too. Yeah. Well I need to prepare new patches anyway. IE and Netscape on Wine users, where are you ? :-) Thanks again, Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Jan. 22, 2002

Re: C testing framework. ASCII/Unicode portable version

by Alexandre Julliard

"Dimitrie O. Paun" <dimi(a)cs.toronto.edu> writes: > With all due respect Alexandre, I can't understand your point. When does > the _semantics_ of the function differ based on the string > encoding??? Functions that take strings usually do something with them, so this is part of the function semantics, and it differs between ASCII and Unicode. A fundamental part of that is making sure that all characters are preserved correctly (no W->A->W round-trip) and it's precisely the thing that will never get tested with the TCHAR stuff. If all you want is to call the function with some random string, then you don't really need to call both A and W since they usually use the same code anyway. So just call the A function and you will have tested as much (or as little) of the W function that you would have by recompiling the TCHAR code as Unicode, while avoiding the whole macro mess. -- Alexandre Julliard julliard(a)winehq.com

Jan. 22, 2002

Re: C testing framework. ASCII/Unicode portable version

by Dimitrie O. Paun

On Tue, 22 Jan 2002, Alexandre Julliard wrote: > But we want people to think twice, and write a test adapted to the > function they are testing; you don't test ASCII and Unicode the same > way, except superficially. With all due respect Alexandre, I can't understand your point. When does the _semantics_ of the function differ based on the string encoding??? If it does, it most likely is a bug, simple as that. In fact, one can view the Unicode case as a different encoding, and if every string pointer passed in the Win32 API had an associated encoding with it, we would have never needed the A/W pair of functions. Point is, the encoding/decoding from/to A/W is orthogonal to the semantics of the function in 99.99% of the cases. As such, we should not fundamentaly mix them in the tests. -- Dimi.

Jan. 22, 2002

Re: C testing framework. ASCII/Unicode portable version

by Dimitrie O. Paun

On Tue, 22 Jan 2002, Andriy Palamarchuk wrote: > --- "Dimitrie O. Paun" <dimi(a)cs.toronto.edu> wrote: > > > I have a number of observations: > > -- we should rename wt_helper.h to something like > > wine/tests.h > > I'm open for suggestions. I used this name to avoid > name clashes with Perl winetest framework. > BTW, wt = Wine Test. Well, yeah, I figured that much, but is ugly like hell. > I'd prefer more recognizable name than "test.h". It's not test.h, it's wine/tests.h which is both clean, recognizable, and pretty. In code, you have: #include "wine/tests.h" > > -- maybe we should not use main as the main > > funtion, > > but rather something like 'test'. This way we > > can > > provide the main and have another level of > > indirection which can be put to good use. > > (like we should not need the explicit > > end_tests()) > > -- another thing we can do is to have the tests in > > > > functions named testXXX. This way we can use nm > > to generate the main function, and so we can > > put > > a bunch of tests in the same executable. > > > Whether we'll use these ideas depends on architecture > of the whole testing process. Duh! :) But I thought that's what we're working on...:) > > -- wt_helper.h should include tchar.h, and > > redefine > > _T to call a function to transform the string > > to > > Unicode if need be. This way we get rid of the > > compiler requirement. > > Using function instead of macro won't work in all the > cases, e.g. in this one: > > _TCHAR buf[100] = _T("foo") So, don't do that. Francois showed a number of good ways of doing it. In any case, I think we should discourage the use of explicit strings in the tests, for reasons outlined by Alexandre. I think we should use a teststr() call instead of most hardcoded strings. > > -- I still think my teststr() idea is worth doing. > > Do you want an implementation? > > I like the idea, but do not need such Unicode strings > generator for my test :-) Can you implement it with a > small real test which shows advantages of teststr()? Fine, I'll try to do that, it's just that I'm _very_ busy at the moment. I guess this means more late nights... :) > > -- Why do you do: > > _T(__FILE__) > > Files are ASCII, no need to _T them. > > __FILE__is a macro which is expanded to file name. I > use _T with it for simplicity - to have the same > ASCII/Unicode mode processing for everything. > Otherwise I'd have to explicitely call ASCII functions > for file names processing, probably do A->W > conversion. But we don't need it. I know what __FILE__ does, it returns an ASCII string, so we should just work with it as such. -- Dimi.

Jan. 22, 2002

Re: C testing framework. ASCII/Unicode portable version

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > In the worst case people, who do not have such > compiler will be able to run tests in ANSII mode only. That's clearly not an option. > Here I don't agree with you. Programming with TCHAR is > *exactly* the same as programming with WCHAR, but with > different names. You think once - in WCHAR terms and > get as a bonus ANSII version! You don't think in WCHAR terms. There isn't a single real Unicode character in your test, it's all purely ASCII. That's the main problem with TCHAR, you have to stick to the lower common denominator, which means no Unicode chars, no multi-byte support, etc. > In fact, code became clearner after I removed "if > (has_unicode()) " blocks, A<->W conversions, letters > "A", "W" from API names. I feel that in this case I > don't need to "think twice" - once in terms of ANSII, > the second time - in terms of Unicode. But we want people to think twice, and write a test adapted to the function they are testing; you don't test ASCII and Unicode the same way, except superficially. This TCHAR crap is just a marketing tool to let Microsoft pretend that converting to Unicode is easy; but it's not usable in real life (how many apps do you know that ship both an A and a W exe?) We don't use it in Wine, and we must not use it in Wine tests either. -- Alexandre Julliard julliard(a)winehq.com

Jan. 22, 2002

Re: C testing framework. ASCII/Unicode portable version

by Francois Gouget

Just commenting from the side-lines :-) On Tue, 22 Jan 2002, Andriy Palamarchuk wrote: [...] > Using function instead of macro won't work in all the > cases, e.g. in this one: > > _TCHAR buf[100] = _T("foo") I would rather avoid such constructs precisely because of the compiler support problems. We have to support _T because of legacy windows code, but if we write the code then it should be very easy to avoid its use entirely: _TCHAR buf[100]; .... and at the start of the functions using buf: { unicode(buf,sizeof(buf),"foo"); ... or as a macro: STR2UNICODE(buf,"foo"); with a secondary use as: wstr=unicode(NULL,0,"foo"); // allocate and return a unicode string > > -- I still think my teststr() idea is worth doing. > > Do you want an implementation? > > I like the idea, but do not need such Unicode strings > generator for my test :-) Can you implement it with a > small real test which shows advantages of teststr()? I like the teststr() idea too. It's a bit complex but it sounds like it could help write better tests. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm

Jan. 22, 2002

Re: C testing framework. ASCII/Unicode portable version

by Andriy Palamarchuk

--- "Dimitrie O. Paun" <dimi(a)cs.toronto.edu> wrote: > I have a number of observations: > -- we should rename wt_helper.h to something like > wine/tests.h I'm open for suggestions. I used this name to avoid name clashes with Perl winetest framework. BTW, wt = Wine Test. I'd prefer more recognizable name than "test.h". > -- maybe we should not use main as the main > funtion, > but rather something like 'test'. This way we > can > provide the main and have another level of > indirection which can be put to good use. > (like we should not need the explicit > end_tests()) > -- another thing we can do is to have the tests in > > functions named testXXX. This way we can use nm > to generate the main function, and so we can > put > a bunch of tests in the same executable. Whether we'll use these ideas depends on architecture of the whole testing process. > -- wt_helper.h should include tchar.h, and > redefine > _T to call a function to transform the string > to > Unicode if need be. This way we get rid of the > compiler requirement. Using function instead of macro won't work in all the cases, e.g. in this one: _TCHAR buf[100] = _T("foo") > -- I still think my teststr() idea is worth doing. > Do you want an implementation? I like the idea, but do not need such Unicode strings generator for my test :-) Can you implement it with a small real test which shows advantages of teststr()? > -- if TCHAR is not available, we should > typedef _TCHAR TCHAR > in wine/tests.h Yes, we'll be able to do this. I came across opposite situation. Cygwin has TCHAR, but not _TCHAR. Already submitted bug report to cygwin project. AFAICS TCHAR and _TCHAR have almost the same semantics. MBCS Survival Guide at http://www.microsoft.com/globaldev/fareast/mbcssg.asp says: "For ANSI conformance, the "official" type is _TCHAR. In practice, either TCHAR or _TCHAR is acceptable." > -- Why do you do: > _T(__FILE__) > Files are ASCII, no need to _T them. __FILE__is a macro which is expanded to file name. I use _T with it for simplicity - to have the same ASCII/Unicode mode processing for everything. Otherwise I'd have to explicitely call ASCII functions for file names processing, probably do A->W conversion. > More comments later :) Look forward :-) Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 22, 2002

Re: C testing framework. ASCII/Unicode portable version

by Dimitrie O. Paun

On Mon, 21 Jan 2002, Andriy Palamarchuk wrote: > Attached version of the C testing framework, which is > implemented with using TCHAR.H macros, so it is > portable between ASCII and Unicode platforms. Also > implemented test which can be used to test ASCII and > Unicode API. Cool. I have a number of observations: -- we should rename wt_helper.h to something like wine/tests.h -- maybe we should not use main as the main funtion, but rather something like 'test'. This way we can provide the main and have another level of indirection which can be put to good use. (like we should not need the explicit end_tests()) -- another thing we can do is to have the tests in functions named testXXX. This way we can use nm to generate the main function, and so we can put a bunch of tests in the same executable. -- wt_helper.h should include tchar.h, and redefine _T to call a function to transform the string to Unicode if need be. This way we get rid of the compiler requirement. -- I still think my teststr() idea is worth doing. Do you want an implementation? -- if TCHAR is not available, we should typedef _TCHAR TCHAR in wine/tests.h -- Why do you do: _T(__FILE__) Files are ASCII, no need to _T them. More comments later :) -- Dimi.

Jan. 22, 2002

Article about WINE on DesktopLinux.com

by Roland

Hello, I found a very interesting article about WINE there: http://www.desktoplinux.com/articles/AT5502857506.html I have to fully agree with that author, I think he is a real genius! :))) Roland

Jan. 22, 2002

Re: C testing framework. ASCII/Unicode portable version

by Andriy Palamarchuk

--- Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > "Andriy Palamarchuk" <apa3a(a)yahoo.com> wrote: > > > Attached version of the C testing framework, which > is > > implemented with using TCHAR.H macros, so it is > > portable between ASCII and Unicode platforms. Also > > implemented test which can be used to test ASCII > and > > Unicode API. > > You probably want to know that in order to use > TCHAR.H > you need either gcc >= 2.96, I know this :-( I strongly prefer to use straigt TCHAR programming, without any conversions. This is why I started to work with it in the first place. There is no such issue for Windows compilers. Can we have requirement of 2-byte Unicode characters compiler for the tests? In the worst case people, who do not have such compiler will be able to run tests in ANSII mode only. > or mess with converting > 4-byte unicode strings to 2-byte and vice versa. Do you mean using -fwritable-strings parameter or performing explicit conversion? Can we hide explicit conversion in the _T/_TEXT macros? > I would > prefer to avoid the whole bunch of confusion with > all that > mess and use straight CHAR and WCHAR types. Yes, it > will > mean to have separate tests for ANSI and Unicode and > will > require slightly more work to type > WCHAR str[] = {'u','n','i','c','o','d','e',0}; > instead of a simple > WCHAR str[] = L"unicode"; IMHO this is much bigger mess than with compilers. > Please take into account the fact that everyone, who > uses TCHAR, > actually needs to think twice in any case. TCHAR > makes it only > harder to understand, what really happens. Here I don't agree with you. Programming with TCHAR is *exactly* the same as programming with WCHAR, but with different names. You think once - in WCHAR terms and get as a bonus ANSII version! In fact, code became clearner after I removed "if (has_unicode()) " blocks, A<->W conversions, letters "A", "W" from API names. I feel that in this case I don't need to "think twice" - once in terms of ANSII, the second time - in terms of Unicode. I moved test completely to using TCHAR (attached). Compare it with the version which uses explicit "W"/"A" calls. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 22, 2002

Re: C testing framework. ASCII/Unicode portable version

by Dmitry Timoshkov

"Andriy Palamarchuk" <apa3a(a)yahoo.com> wrote: > Attached version of the C testing framework, which is > implemented with using TCHAR.H macros, so it is > portable between ASCII and Unicode platforms. Also > implemented test which can be used to test ASCII and > Unicode API. You probably want to know that in order to use TCHAR.H you need either gcc >= 2.96, or mess with converting 4-byte unicode strings to 2-byte and vice versa. I would prefer to avoid the whole bunch of confusion with all that mess and use straight CHAR and WCHAR types. Yes, it will mean to have separate tests for ANSI and Unicode and will require slightly more work to type WCHAR str[] = {'u','n','i','c','o','d','e',0}; instead of a simple WCHAR str[] = L"unicode"; Please take into account the fact that everyone, who uses TCHAR, actually needs to think twice in any case. TCHAR makes it only harder to understand, what really happens. -- Dmitry.

Jan. 21, 2002

Re: [PATCH] Overlapped recv(), WSARecv()

by lawson_whitney＠juno.com

On Mon, 21 Jan 2002, Martin Wilck wrote: > On Thu, 17 Jan 2002 lawson_whitney(a)juno.com wrote: > > > > Perhaps I screwed up the blocking semantics of non-overlapped IO. > > That's what it looks like to me. > > I can't make sense out of these traces. The numbers of bytes transferred > are different, but you were transferring different data. > The general pattern of function calls and messages is very similar > with and without the patch. Especially the error patterns are similar. > > Martin > > Btw I don't think I can help with the serial app. I see no indication > that overlapped IO plays a role there. > > Maybe I was hallucinating, or maybe the juno server was just having a bad half-hour. Sometimes, not often, these sessions can fail for no good reason, or at least not one that has anything to do with program code on this end. I thought maybe trace was changing the timing of things, so I tried the app without a trace, but with tcpdump active. AFAICT, it worked fine. Twice. One other possibility, - the script I used to run the app using wine as last built (instead of the installed wine) invokes it --winver nt40. I don't think I did that earlier, and the app might behave differently. I've installed the patches for now and I'll beat on them a bit more and see if anything shakes loose. Sorry, maybe I put you and me both to a lot of trouble because of an unrelated glitch. I would feel better if somebody else besides me would take a swat at testing these winsock patches, too. Lawson

Jan. 21, 2002

Re: Decorationless managed windows again

by Alexandre Julliard

Ove Kaaven <ovehk(a)ping.uio.no> writes: > This is incorrect, but I guess my code was also. For example, dialog boxes > are popup windows parented by their owner. They are not clipped to their > parent, but dialogs should probably also be managed. Hmm... You seem to confuse parent and owner. win->parent is always the real parent in the window hierarchy, no matter whether the window is owned or not. It will be the desktop for all top-level windows, including menus, popup dialogs, etc. Of course to make things simple the 'parent' parameter of CreateWindow sometimes means parent and sometimes owner. But in the window data structure they are two separate fields. In any case I don't think we can use the owner to distinguish managed/non-managed either. -- Alexandre Julliard julliard(a)winehq.com

Jan. 21, 2002

Re: Decorationless managed windows again

by Ove Kaaven

On 21 Jan 2002, Alexandre Julliard wrote: > Ove Kaaven <ovehk(a)ping.uio.no> writes: > > > These won't be managed. Notice that my patch only manages popup windows if > > they are children of the desktop, which I assume neither menus nor > > tooltips are. > > Of course they are. They cannot be children of another window or they > would get clipped to the window rectangle. This is incorrect, but I guess my code was also. For example, dialog boxes are popup windows parented by their owner. They are not clipped to their parent, but dialogs should probably also be managed. Hmm...

Jan. 21, 2002

Re: Some fixes for dumb X errors :-)

by Alexandre Julliard

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > PS for Alexandre: we once discussed how we could 'streamline' this X error > handling (ie to prevent doing the same kind of code at three different > locations in the Wine code). Did you progress on this issue or not ? Yes, here's what I came up with. Basically you have to wrap the call that might fail with X11DRV_expect_error/X11DRV_check_error. Would this work for what you need to do? Index: dlls/x11drv/x11drv_main.c =================================================================== RCS file: /opt/cvs-commit/wine/dlls/x11drv/x11drv_main.c,v retrieving revision 1.47 diff -u -r1.47 x11drv_main.c --- dlls/x11drv/x11drv_main.c 2001/11/30 23:15:32 1.47 +++ dlls/x11drv/x11drv_main.c 2002/01/21 18:58:48 @@ -63,6 +63,12 @@ static char *desktop_geometry; static XVisualInfo *desktop_vi; +static x11drv_error_callback err_callback; /* current callback for error */ +static Display *err_callback_display; /* display callback is set for */ +static void *err_callback_arg; /* error callback argument */ +static int err_callback_result; /* error callback result */ +static int (*old_error_handler)( Display *, XErrorEvent * ); + #define IS_OPTION_TRUE(ch) \ ((ch) == 'y' || (ch) == 'Y' || (ch) == 't' || (ch) == 'T' || (ch) == '1') #define IS_OPTION_FALSE(ch) \ @@ -97,12 +103,57 @@ } #endif /* NO_REENTRANT_X11 */ + +/*********************************************************************** + * X11DRV_expect_error + * + * Setup a callback function that will be called on an X error. The + * callback must return non-zero if the error is the one it expected. + * This function acquires the x11 lock; X11DRV_check_error must be + * called in all cases to release it. + */ +void X11DRV_expect_error( Display *display, x11drv_error_callback callback, void *arg ) +{ + wine_tsx11_lock(); + XSync( display, False ); + err_callback = callback; + err_callback_display = display; + err_callback_arg = arg; + err_callback_result = 0; +} + + +/*********************************************************************** + * X11DRV_check_error + * + * Check if an expected X11 error occurred; return non-zero if yes. + * Also release the x11 lock obtained in X11DRV_expect_error. + */ +int X11DRV_check_error(void) +{ + int ret = err_callback_result; + XSync( err_callback_display, False ); + err_callback = NULL; + wine_tsx11_unlock(); + return ret; +} + + /*********************************************************************** * error_handler */ -static int error_handler(Display *display, XErrorEvent *error_evt) +static int error_handler( Display *display, XErrorEvent *error_evt ) { - DebugBreak(); /* force an entry in the debugger */ + if (err_callback && display == err_callback_display) + { + if ((err_callback_result = err_callback( display, error_evt, err_callback_arg ))) + { + TRACE( "got expected error\n" ); + return 0; + } + } + if (synchronous) DebugBreak(); /* force an entry in the debugger */ + old_error_handler( display, error_evt ); return 0; } @@ -297,6 +348,7 @@ screen = DefaultScreenOfDisplay( display ); visual = DefaultVisual( display, DefaultScreen(display) ); root_window = DefaultRootWindow( display ); + old_error_handler = XSetErrorHandler( error_handler ); /* Initialize screen depth */ @@ -328,11 +380,7 @@ */ TSXOpenIM( display, NULL, NULL, NULL); - if (synchronous) - { - XSetErrorHandler( error_handler ); - XSynchronize( display, True ); - } + if (synchronous) XSynchronize( display, True ); screen_width = WidthOfScreen( screen ); screen_height = HeightOfScreen( screen ); Index: include/x11drv.h =================================================================== RCS file: /opt/cvs-commit/wine/include/x11drv.h,v retrieving revision 1.95 diff -u -r1.95 x11drv.h --- include/x11drv.h 2002/01/04 18:27:45 1.95 +++ include/x11drv.h 2002/01/21 18:59:08 @@ -391,7 +391,9 @@ extern void X11DRV_SetFocus( HWND hwnd ); extern Cursor X11DRV_GetCursor( Display *display, struct tagCURSORICONINFO *ptr ); -extern void X11DRV_expect_error( unsigned char request, unsigned char error, XID id ); +typedef int (*x11drv_error_callback)( Display *display, XErrorEvent *event, void *arg ); + +extern void X11DRV_expect_error( Display *display, x11drv_error_callback callback, void *arg ); extern int X11DRV_check_error(void); extern void X11DRV_register_window( Display *display, HWND hwnd, struct x11drv_win_data *data ); extern void X11DRV_set_iconic_state( WND *win ); -- Alexandre Julliard julliard(a)winehq.com

Jan. 21, 2002

Re: Decorationless managed windows again

by Alexandre Julliard

Ove Kaaven <ovehk(a)ping.uio.no> writes: > These won't be managed. Notice that my patch only manages popup windows if > they are children of the desktop, which I assume neither menus nor > tooltips are. Of course they are. They cannot be children of another window or they would get clipped to the window rectangle. -- Alexandre Julliard julliard(a)winehq.com

Jan. 21, 2002

Re: Decorationless managed windows again

by Ove Kaaven

On 21 Jan 2002, Alexandre Julliard wrote: > Ove Kaaven <ovehk(a)ping.uio.no> writes: > > > The logic in this patch is now somewhat revised according to Alexandre's > > comments. I did not make this configurable, though, thinking that if the > > user's WM really is too old to support them, then he probably wouldn't > > mind getting more top-level windows managed anyway... > > Top-level windows maybe not, but menus and tooltips with wm > decorations are pretty annoying... These won't be managed. Notice that my patch only manages popup windows if they are children of the desktop, which I assume neither menus nor tooltips are.

Jan. 21, 2002

Re: Decorationless managed windows again

by Alexandre Julliard

Ove Kaaven <ovehk(a)ping.uio.no> writes: > The logic in this patch is now somewhat revised according to Alexandre's > comments. I did not make this configurable, though, thinking that if the > user's WM really is too old to support them, then he probably wouldn't > mind getting more top-level windows managed anyway... Top-level windows maybe not, but menus and tooltips with wm decorations are pretty annoying... so I applied it, but without the is_window_managed changes, we will need a better algorithm there. -- Alexandre Julliard julliard(a)winehq.com

Jan. 21, 2002

Re: Some musings about DGA2 support in Wine...

by Lionel Ulmer

> It seems the right thing is to setup DGA in the thread that needs to > receive the events, using the normal thread display. But this will > require understanding exactly why doing other X calls on this display > breaks event processing, and finding a work around for that. Well, this was the answer I dreaded (and the one solution I did not propose in my mail :-) ) : to look under the hood of XFree and try to see why standard X programming would lock up the DGA2 events... I will try to see what I can do (nobody should hold its breath though as I do not have much hacking time in the next weeks and as I started trying to make work Marcus' preliminary Xvideo patch). In the same kind of solution, one could also remove most of TG's DIB code once we enter DGA2 mode, but as I do not know at all how all this is working, I will let someone else investigate this particular option :-) Lionel PS: what happened to my other DGA2 related patch I sent friday evening (the one adding X error checking) ? -- Lionel Ulmer - http://www.bbrox.org/

Jan. 21, 2002