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

Re: wine/ library/debug.c include/wine/library.h i ...

by Dimitrie O. Paun

On January 3, 2003 06:48 pm, Dan Kegel wrote: > Yes, but consider the poor sod who has already used the identifier TRACE > (precisely because it's a convenient name, as you point out) > and is trying to build with winelib. Sure, we could have some switch > to turn on and off the short names, but that gets hard to read... I don't understand -- no winelib app include wine/debug.h, none will get this problem. Unless they _explicitely_ decide to use our debugging API, and they _explicitly_ #include <wine/debug.h>. In which case they are aware of the problem. And in any event, they will want their own debug.h header where they can do whatever renaming they want. In fact, if we export just the long versions (which I'm OK with), they _will_ have to have their own debug.h to provide more convenient names, in which case they will probably be different from what we use in Wine anyway. Or we can suggest our short names, so their debug.h can look like so: #define WINE_NICE_DBG_API #include <wine/debug.h> Of course, MFC apps can do a number of trivail things to avoid the TRACE conflict. So they are not a problem in any event. It's simple, nice, easy to use and understand. In the long run we end up with a lot more uniformity. But this is besides the point. What I'm arguing against is using the long names internally. This makes little sense, since I am virtually sure nobody else will. So we will loose clarity, neatness, and convenience for the very purpose of uniformity with some Winelib apps, that's not going to be there in the first place since they are not gonna use the long names, and are going to invent their own anyhow. What I'm saying is that if we provide people with an easy way to have convenient names, 99.99% will simply use those names, and we'll have a lot more of this uniformity. The few that choose not to, have a quite a few easy ways to choose their own names. -- Dimi.

Jan. 3, 2003

Re: Update: Wine & Mozilla

by Steven Edwards

> I will be lending those guys a hand with the port. Mostly the > work seems to be done, they just need a gentle nudge to get it > in the tree (I hope :)). > > As always, your comments and suggestions are highly appreciated. > when/if I ever get more time I will try to help. I just got married so my time to work on wine/reactos/mingw has gone to /dev/null for about another month. btw: nice work on visual-mingw. Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

Jan. 3, 2003

Re: wine/ library/debug.c include/wine/library.h i ...

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > They'll most like have to do something like this anyway, with the only > difference that the defines come after the include, but hey, it's a small > price to pay! And if they don't like it, they don't need to use our headers > at all, they can implement their own macros on top of the functions we export > from ntdll. Come on, they are a few lines of code, is it really worth > complicating the Wine code for it? Yes; if we make that API available then we have a responsibility to try to make it usable for as many situations as possible, even if that means some extra work for us. We can't simply use what's most convenient for us and ignore the problems it will cause for others; if we do that then we might as well not export the API at all. So we need to find a compromise between convenience and uniqueness. Clearly the TRACE etc. macros are not unique enough, we already have had several conflicts with them, that's why we have the WINE_* form. And for the other functions we need some kind of prefix too; not necessarily "wine_dbgstr_" but I don't think "dbg_" is unique enough. -- Alexandre Julliard julliard(a)winehq.com

Jan. 3, 2003

Windows 2000 conformance tests

by Dave Miller

I notice the status page has a couple of empty spaces remaining under win 2000. I suspect this is due to my report being somewhat unreadable, so I want to point out the results for these tests were included. The message in the archive is here: http://www.winehq.com/hypermail/wine-devel/2002/12/0994.html. All of the tests which are missing a status passed, with only user32/win providing any output beyond the 0 failures message.

Jan. 3, 2003

Re: MAX_LIGHTS redefinition

by Francois Gouget

On Fri, 3 Jan 2003, Lionel Ulmer wrote: > On Thu, Jan 02, 2003 at 10:35:55PM -0800, Francois Gouget wrote: > > > > MAX_LIGHTS is defined in two places: > > > > * mesa.c > > #define MAX_LIGHTS 8 > > > > * d3d_private.h > > #define MAX_LIGHTS 16 > > > > So this patch removes the definition from mesa.c. Hopefully this is ok. > > This is fixed in one of the 10 or so pending D3D patches. At least, in my > working tree I do not have the problem anymore :-) Oh my, there are still D3D patches pending! I remember seeing quite a few getting committed yesterday. Just ignore my patch then :-) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ $live{free} || die "";

Jan. 3, 2003

Re: wine/ library/debug.c include/wine/library.h i ...

by Francois Gouget

On Fri, 3 Jan 2003, Dimitrie O. Paun wrote: [...] > Obviously, if people are going to use our interface, they are not going > to use our long names directly. Why not allow them the option of using > our short names? How many apps are going to have a TRACE macro _if_ they > decide to use our debugging API? In the MFC, afx.h defines a TRACE macro. So no MFC-based application can use Wine's short names. Actually, no MFC-based application will compile correctly if we export our own TRACE macro (having macro redefinitions is not acceptable). To me that's a pretty significant section of potential Winelib apps (both in importance and in numbers). Many commercial applications are using Visual C++ and Winelib and I think it's important to make it easy for them to use Winelib to recompile their applications on Unix. So I think TRACE should not be exported by default. I am not opposed to a -DWINE_SHORT_DBG_API however. I'm not too concerned about the length of these function names but we could reduce the name length by replacing the 'WINE_' prefix by just 'W' though that would slightly increase the risk of collisions. And we could replace 'debugstr_' with just 'debug_' or 'dbg_' or maybe 'dump_' (though dump is not quite correct). So the main choices are: WINE_TRACE WTRACE and wine_debugstr_rect wine_debug_rect wine_dump_rect wine_dbg_rect wdump_rect wdbg_rect wstr_rect -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Advice is what we ask for when we already know the answer but wish we didn't -- Eric Jong

Jan. 3, 2003

Re: wine/ library/debug.c include/wine/library.h i ...

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Granted. But there is a fundamental difference: all other wine_* functions > are so esoteric and rarely used, that we could even call them > wine_esoteric_function_... and no one would be bothered by it :) It's not only the wine_* functions. There is no conceptual difference between code that resides in a dll inside the Wine tree and code in a Winelib dll outside the Wine tree. You can happily copy code back and forth between Wine and the Winelib app, and you expect it to work. That's the principle of least suprise again <g> > Obviously, if people are going to use our interface, they are not going > to use our long names directly. Why not allow them the option of using > our short names? How many apps are going to have a TRACE macro _if_ they > decide to use our debugging API? And if they do, they can -DWINE_NO_SHORT_DBG_API > and be done with it (or we can enable it only if -DWINE_SHORT_DBG_API). I'm not opposed to a define to export the TRACE/FIXME/ERR/WARN macros, but that's not a general solution. We don't want to have to explain "sure the API is broken but if you define this magic symbol you can make it sane again". We should define a sane API in the first place. -- Alexandre Julliard julliard(a)winehq.com

Jan. 3, 2003

Re: wine/ library/debug.c include/wine/library.h i ...

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > That includes me. But since we're not going to rename everything > (and this makes me so happy, I would have hate it if we did), the > confusion is still going to be there. People are still going to > have to learn that there is this mapping. But than, for magically > chosen, obscure functions, they will have to learn another rule! That's not another rule, it's just the standard behavior: functions are called the same way under Wine and under Winelib. If we use the wine_* functions in Wine too, then the rule is that in Winelib everything is identical, except that TRACE/ERR/WARN/FIXME have to be prefixed with WINE_. That's certainly easier and more consistent than having a separate rule for the debugstr functions that is different from everything else. > Furthermore, in this very case it's not clear at all to me we are > aiming at anything better. I have seen no project that uses this > long names for its debugging API. There are many reasons why not, > I will not hash them here, but this simple observation should tell > us something. We can certainly come up with shorter names if that's what bothers you; personally I don't think that e.g. wine_dbgstr_guid is much worse than debugstr_guid, but I'm certainly open to other suggestions. The important thing is to have only one name and stick to it everywhere; this in turn implies that it must be unique enough to not risk conflicting with other identifiers. -- Alexandre Julliard julliard(a)winehq.com

Jan. 3, 2003

Re: wine/ library/debug.c include/wine/library.h i ...

by Dimitrie O. Paun

On January 3, 2003 02:37 pm, Alexandre Julliard wrote: > You can happily copy code back and > forth between Wine and the Winelib app, and you expect it to > work. That's the principle of least suprise again <g> Darn, I knew you gonna get me on this one! :) Hehe, what goes around comes around. ;) > I'm not opposed to a define to export the TRACE/FIXME/ERR/WARN macros, > but that's not a general solution. We don't want to have to explain > "sure the API is broken but if you define this magic symbol you can > make it sane again". We should define a sane API in the first place. Hey, it is the same API afterall. It is not broken, it just uses different names, and you have to admit the names are a bit nicer on the eye. And speaking of these prefixes and all, I don't see why we have to use wine_ to prefix things. We can imagine this is a debugging API that Wine uses as well, so it might as well use a different prefix. What about dbg_? :) If you really want to export only one symbol, fine, lets export the short ones only. The 1% of apps that have conflicts can do things (in mydebug.h): #define TRACE DEBUG #define WARN WARNING #include <wine/debug.h> They'll most like have to do something like this anyway, with the only difference that the defines come after the include, but hey, it's a small price to pay! And if they don't like it, they don't need to use our headers at all, they can implement their own macros on top of the functions we export from ntdll. Come on, they are a few lines of code, is it really worth complicating the Wine code for it? -- Dimi.

Jan. 3, 2003

Problema running wine20021219 with Xfree 4.2.99

by Alejandro Lorenzo

I have problems running wine with the snapshot of the new Xfree86 the wine release is 200211219 and i have compiled it from sources without any error. Anytime i try to use wine i get: err:module:BUILTIN32_dlopen failed to load .so lib for builtin x11drv.dll: /usr/local/lib/wine/x11drv.dll.so: undefined symbol: XF86VidModeSetGammaRamp Could not load graphics driver 'x11drv' err:win:GetDesktopWindow Wine init error: either you're trying to use an invalid native USER.EXE config, or some graphics/GUI libraries or DLLs didn't initialize properly. Aborting. also tried to make a --debugmsg +relay but i cannot get nothing clear: i get a lot of output of the style (i think this is the interesting part of the log for this, if it necessary, i can attach all the log) 08077198:Ret advapi32.RegOpenKeyA() retval=00000000 ret=40801f57 08077198:Call advapi32.RegQueryValueExA(00000030,408185ff "GraphicsDriver",00000000,40692cd8,40692ce4,40692cdc) ret=40801f89 08077198:Call ntdll.RtlInitAnsiString(40692af4,408185ff "GraphicsDriver") ret=40906280 08077198:Ret ntdll.RtlInitAnsiString() retval=0000000f ret=40906280 08077198:Call ntdll.RtlAnsiStringToUnicodeString(40110178,40692af4,00000000) ret=4090629c 08077198:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=4090629c 08077198:Call ntdll.NtQueryValueKey(00000030,40110178,00000002,40692afc,00000100,40692af0) ret=409062d4 08077198:Ret ntdll.NtQueryValueKey() retval=00000000 ret=409062d4 08077198:Call ntdll.RtlUnicodeToMultiByteSize(40692aec,40692b08 L"x11drv",0000000e) ret=409063e3 08077198:Ret ntdll.RtlUnicodeToMultiByteSize() retval=00000000 ret=409063e3 08077198:Call ntdll.RtlUnicodeToMultiByteN(40692ce4,00000007,00000000,40692b08,0000000e) ret=40906418 08077198:Ret ntdll.RtlUnicodeToMultiByteN() retval=00000000 ret=40906418 08077198:Call ntdll.RtlNtStatusToDosError(00000000) ret=409064dd 08077198:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=409064dd 08077198:Ret advapi32.RegQueryValueExA() retval=00000000 ret=40801f89 08077198:Call advapi32.RegCloseKey(00000030) ret=40801f95 08077198:Call ntdll.NtClose(00000030) ret=409056f6 08077198:Ret ntdll.NtClose() retval=00000000 ret=409056f6 08077198:Call ntdll.RtlNtStatusToDosError(00000000) ret=409056fc 08077198:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=409056fc 08077198:Ret advapi32.RegCloseKey() retval=00000000 ret=40801f95 08077198:Call kernel32.LoadLibraryA(40692ce4 "x11drv") ret=40801f9b err:module:BUILTIN32_dlopen failed to load .so lib for builtin x11drv.dll: /usr/local/lib/wine/x11drv.dll.so: undefined symbol: XF86VidModeSetGammaRamp 08077198:Ret kernel32.LoadLibraryA() retval=00000000 ret=40801f9b Could not load graphics driver 'x11drv' 08077198:Ret PE DLL (proc=0x40802830,module=0x40770000,type=1,res=0x1) retval=0 08077198:Call user32.UserSignalProc(00000100,08074198,00000007,00000000) ret=400b7355 08077198:Ret user32.UserSignalProc() retval=00000000 ret=400b7355 08077198:Call user32.UserSignalProc(00000010,08077198,00000007,00000000) ret=400b7341 08077198:Ret user32.UserSignalProc() retval=00000000 ret=400b7341 08077198:Call user32.UserSignalProc(00000200,08074198,00000007,00000000) ret=400b7355 08077198:Ret user32.UserSignalProc() retval=00000000 ret=400b7355 08077198:Call user32.UserSignalProc(00000600,08074198,00000007,00000000) ret=400b7355 08077198:Ret user32.UserSignalProc() retval=00000000 ret=400b7355

Jan. 3, 2003