December 2005 - Wine-Devel - list.winehq.org

Re: Continuum Attached logs

by Vitaliy Margolen

Saturday, December 17, 2005, 2:08:53 PM, Corey McClymonds wrote: > Sorry about that, it would appear the logs aren't on the previous email of mine, so here they are. Don't post big attachments, and please, don't use html e-mail as well. Thank you. Please open a bug in bugzilla and _attach_ this information to the bug. Looking at your trace I don't see anything that indicates what the problem is, or what is so complicated about startup sequence of this game. You need to do some more research... Vitaliy.

Dec. 17, 2005

Re: WLDAP32: link to the reentrant version of libldap

by Hans Leidekker

On Thursday 15 December 2005 01:52, Robert Reif wrote: > >>This patch breaks builds on RH9 and appears to be responsible for the > >>build breakage on http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php > nm shows that the symbols are in libldap.so but not libldap_r.so. Can you try this patch? -Hans

Dec. 17, 2005

Continuum Attached logs

by Corey McClymonds

Sorry about that, it would appear the logs aren't on the previous email of mine, so here they are. ----------------------------------------------------------- WINEDEBUG=+loaddll wine Continuum.exe trace:loaddll:load_builtin_dll Loaded module L"kernel32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\advapi32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\gdi32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\user32.dll" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "krnl386.exe" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "system.drv" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "gdi.exe" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "user.exe" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\winex11.drv" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\imm32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\iphlpapi.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\rpcrt4.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\ole32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\shlwapi.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\comctl32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\shell32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\uxtheme.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\ddraw.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\ws2_32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\wsock32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\winmm.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\dsound.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\winealsa.drv" : builtin ALSA lib timer_hw.c:269:(snd_timer_hw_open) extended read is not supported (SNDRV_TIMER_IOCTL_TREAD) ALSA lib timer_hw.c:269:(snd_timer_hw_open) extended read is not supported (SNDRV_TIMER_IOCTL_TREAD) ALSA lib seq_hw.c:455:(snd_seq_hw_open) open /dev/snd/seq failed: No such file or directory trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\msacm32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\msacm.drv" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\midimap.dll" : builtin -------------------------------------------- WINEDEBUG=+seh wine Continuum.exe trace:seh:__regs_RtlRaiseException code=80000003 flags=0 addr=0x7fc1fef0 trace:seh:__regs_RtlRaiseException eax=00000000 ebx=004c4050 ecx=004c4048 edx=004c405a esi=7bef4647 edi=004c4a4d trace:seh:__regs_RtlRaiseException ebp=000c1dd8 esp=7fc1fef0 cs=0073 ds=007b es=007b fs=1007 gs=0033 flags=00200246 trace:seh:__regs_RtlRaiseException code=c000001d flags=0 addr=0x4c40f2 trace:seh:__regs_RtlRaiseException eax=00000000 ebx=7bef01bc ecx=00000000 edx=bec35266 esi=7fc1fef4 edi=005283c2 trace:seh:__regs_RtlRaiseException ebp=000c1dd8 esp=7fc1fef4 cs=0073 ds=007b es=007b fs=1007 gs=0033 flags=00210202 ALSA lib timer_hw.c:269:(snd_timer_hw_open) extended read is not supported (SNDRV_TIMER_IOCTL_TREAD) ALSA lib timer_hw.c:269:(snd_timer_hw_open) extended read is not supported (SNDRV_TIMER_IOCTL_TREAD) ALSA lib seq_hw.c:455:(snd_seq_hw_open) open /dev/snd/seq failed: No such file or directory

Dec. 17, 2005

Comparing a complicated program startup to windows

by Corey McClymonds

There is a game, known as Continuum, that has a very complicated setup before it actually starts the game, to prevent cheating. Due to this, the relay is very large, about 4MB, before it starts to repeat itself. I have gotten the +loaddll and the +seh logs at the bottom. I was just wondering, would it be possible to do the same startup on a Windows machine, and compare its relay to the relay from Wine. If this is possible, how would I go about this? Corey McClymonds

Dec. 17, 2005

Re: SCREENSHOT: Windows Genuine Advantage 'GenuineCheck.exe' program generating key on Wine!

by Hans Leidekker

On Saturday 17 December 2005 07:00, Segin wrote: > The attached screenshot (UNMODIFIED) depicts the WGA 'GenuineCheck.exe' > program that is used on the microsoft web site to 'validate' Windows so > that you can download crap. Normally, it will not generate the needed If WGA enables downloading crap, why are you spending effort running it on Wine? > key under Wine, but I have a screenshot (attached) of it doing so. I > don't know is this is worth noting, as i couldn't tell you how I made it > work (a LOT of things, too many to even count). However, I thought it > might be something of intrest. If this is in any way useful to the > development of Wine, please let me know. It can be very simple to make Wine compatible with the WGA check, the patch below used to do it for me. Patches like this are not likely to be applied to mainstream Wine though. As has been discussed before, it's not wise to engage in a hide and seek game with Microsoft, since they will allways be able to change the check one more time. They _are_ straddling the fence though, because the check can be seen as a means to tie applications to their OS. They use it to control distribution of "OS components" that applications depend on and where the term "OS component" is given a rather broad interpretation. Of course, the right way for Wine to circumvent the WGA check is to provide open source implementations of those OS components. -Hans Index: dlls/ntdll/reg.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/reg.c,v retrieving revision 1.68 diff -u -r1.68 reg.c --- dlls/ntdll/reg.c 9 Dec 2005 13:52:46 -0000 1.68 +++ dlls/ntdll/reg.c 17 Dec 2005 12:49:16 -0000 @@ -115,6 +115,14 @@ { NTSTATUS ret; DWORD len = attr->ObjectName->Length; + static const WCHAR GenuineCheck[] = + { 'G','e','n','u','i','n','e','C','h','e','c','k','.','e','x','e',0 }; + static const WCHAR WineConfig[] = + { 'S','O','F','T','W','A','R','E', + '\\','W','i','n','e', + '\\','W','i','n','e', + '\\','C','o','n','f','i','g',0 }; + LDR_MODULE *pldr; TRACE( "(%p,%s,%lx,%p)\n", attr->RootDirectory, debugstr_us(attr->ObjectName), access, retkey ); @@ -133,6 +141,16 @@ } SERVER_END_REQ; TRACE("<- %p\n", *retkey); + + if (!LdrFindEntryForAddress( NtCurrentTeb()->Peb->ImageBaseAddress, &pldr )) + { + if (!strcmpiW( attr->ObjectName->Buffer, WineConfig ) && + !strcmpiW( pldr->BaseDllName.Buffer, GenuineCheck )) + { + TRACE( "Enabling workaround for GenuineCheck.exe\n" ); + return STATUS_INVALID_PARAMETER; + } + } return ret; }

Dec. 17, 2005

Re: [wined3d] Converting Wined3d to use WGL instead of GLX

by Aric Cyr

On 12/17/05, Lionel Ulmer <lionel.ulmer(a)free.fr> wrote: > On Wed, Dec 14, 2005 at 03:53:12AM +0000, Aric Cyr wrote: > > So now I am stuck... if I use wglGetProcAddress for OpenGL extensions I get > > crashes in most D3D9 applications. If I use glXGetProcAddress in wined3d > > everything works fine, but then wined3d is still dependent on glx. > > The answer is easy (did not read the complete thread in details to know if > you found out the solution or not): basically, 'wglGetProcAddress' returns > functions as expected by Win32 applications, so using the 'stdcall' calling > convention whereas 'glXGetProcAddress' returns them in the standard Unix > calling convention 'cdecl'. > > So you basically have the same problem with GL extensions that you had with > direct linking to OpenGL32.DLL instead of to libGL.so => all the calls going > through function pointers that you retrieved via 'wglGetProcAddress' will go > through thunks to change the calling convention (at the price of a slight > performance hit). That's exactly right. That's the conclusion I came to as well. It's all buried in my previous reply somewhere :) > Moreover, you will have a nice 'header' head-ache as you won't be able to > rely on the Linux distribution's version of 'glext.h' but on a version > compatible with Windows that adds the proper 'STDCALL' types to the function > pointer prototypes. Actually the header 'ache' doesn't hurt so much. The standard (official) glext.h from SGI defines APIENTRY, which we can just define to WINAPI (or __stdcall) before including glext.h. By default, on Linux anyways, APIENTRY is defined as nothing so there shouldn't be any problems. I have this all working already, and managed to get rid of all those horrible copy&paste #defines in wined3d_gl.h and a few other places as well. All-in-all things look a lot cleaner both in dlls/opengl32 and dlls/wined3d. The only catch is to watch out for what should be WINAPI and what should not, but it seems I got it all under control so far. Looking forward to your comments once I start sending the patches in. Regards, Aric -- Aric Cyr <Aric.Cyr at gmail dot com> (http://acyr.net)

Dec. 17, 2005

Re: Create new mailing list wine-isv?

by Scott Ritchie

On Fri, 2005-12-16 at 23:45 -0700, Vitaliy Margolen wrote: > Friday, December 16, 2005, 11:26:28 PM, Scott Ritchie wrote: > > On Fri, 2005-12-16 at 19:48 +0100, Alexandre Julliard wrote: > >> The goal is not to prevent regressions between every minor point > >> release, it's to make releases frequently enough that regressions can > >> be found and fixed quickly, so that they don't creep into the next > >> major release. Now, if you think that doesn't work I'm certainly open > >> to doing things differently. What do you suggest? > >> > > If I may make a humble suggestion, it would be to time another stable > > (or semi-stable), regression-proofed release to roughly coincide with > > the various distributions freezing schedules. Ubuntu, for instance has > > an upstream version freeze on Jan 19th and a Feature Freeze on Feb 2nd. > > In my ideal world, we would have a Wine release just before that Jan > > 19th deadline, go into regression-fix and bughunt mode, and then have a > > release come out around Feb 2nd that had no regressions relative to 0.9 > > and the Jan 19th release. > > That sounds to aggressive to me. We still a long ways away from major > pieces falling into place. Most regressions you see, especially with > games caused be major developments in d3d part of Wine. I don't think > that will be "fixed" by then. Add six months, then, to time it with the next release. That sounds reasonable. Thanks, Scott Ritchie

Dec. 17, 2005

Re: [wined3d] Converting Wined3d to use WGL instead of GLX

by Lionel Ulmer

On Wed, Dec 14, 2005 at 03:53:12AM +0000, Aric Cyr wrote: > So now I am stuck... if I use wglGetProcAddress for OpenGL extensions I get > crashes in most D3D9 applications. If I use glXGetProcAddress in wined3d > everything works fine, but then wined3d is still dependent on glx. The answer is easy (did not read the complete thread in details to know if you found out the solution or not): basically, 'wglGetProcAddress' returns functions as expected by Win32 applications, so using the 'stdcall' calling convention whereas 'glXGetProcAddress' returns them in the standard Unix calling convention 'cdecl'. So you basically have the same problem with GL extensions that you had with direct linking to OpenGL32.DLL instead of to libGL.so => all the calls going through function pointers that you retrieved via 'wglGetProcAddress' will go through thunks to change the calling convention (at the price of a slight performance hit). Moreover, you will have a nice 'header' head-ache as you won't be able to rely on the Linux distribution's version of 'glext.h' but on a version compatible with Windows that adds the proper 'STDCALL' types to the function pointer prototypes. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Dec. 17, 2005

Re: [wined3d] Converting Wined3d to use WGL instead of GLX

by Joris Huizer

Aric Cyr wrote: > Now everything works fine, except this brings up another issue with > wglGetProcAddress. The problem is that all gl extensions function pointers are > declared WINAPI, and indeed this is what type of functoin wglGetProcAddress is > expected to return. However for extensions that are not registered in > opengl_ext.c wglGetProcAddress falls back to glXGetProcAddressARB which would > return a non-WINAPI function pointer. After the first call to such a function > we would have corrupted the stack. There doesn't seem to be a nice way to fix > this that I can think of. wglGetProcAddress should never return a non-WINAPI > function though, as that is just asking for trouble. Better to return NULL > instead of falling back to glXGetProcAddressARB. > Maybe it'd be possible to make a wrapper function -- a WINAPI function pointer that just does a call to this glXGetProcAddressARB ? (Just me thinking aloud ;-) )

Dec. 17, 2005

Re: [wined3d] Converting Wined3d to use WGL instead of GLX

by James Liggett

On Sat, 2005-12-17 at 07:07 +0000, Aric Cyr wrote: > > Thanks for the suggestion, but I already have wine compiled with only "-g". > Last time I checked gcc doesn't enable optimizations unless a -O option is > specified explicitly (don't know if this has changed though). > > Anyways, I think I finally figured this all out. As I thought it turned out to > be stack corruption, due to differing calling conventions. It just required > fixing up my function pointers to be WINAPI (which I believe becomes stdcall) > for all the wgl functions. I think you're right IIRC. I think all win32 calls are stdcall (or sometimes pascal, which is more or less the same thing I think, where the function cleans up the stack and not the caller, as opposed to cdecl, where the opposite happens) Calling conventions are a lot of fun, aren't they? :) > > Now everything works fine, except this brings up another issue with > wglGetProcAddress. The problem is that all gl extensions function pointers are > declared WINAPI, and indeed this is what type of functoin wglGetProcAddress is > expected to return. However for extensions that are not registered in > opengl_ext.c wglGetProcAddress falls back to glXGetProcAddressARB which would > return a non-WINAPI function pointer. After the first call to such a function > we would have corrupted the stack. There doesn't seem to be a nice way to fix > this that I can think of. wglGetProcAddress should never return a non-WINAPI > function though, as that is just asking for trouble. Better to return NULL > instead of falling back to glXGetProcAddressARB. I agree here as well. The whole idea here is to avoid glx and use the WGL layer to abstract it, right? It would be a really bad idea to trust glXGetProcAddressARB because you can't really know for sure if the calling convention is right, and that issue becomes a problem with any shared library on any platform, precisely because of the problems you were experiencing with the stack. > > As an aside to the wglGetProcAddress issue, all GL extenions called by wined3d > are now passed through the thunks. It is only one extra function call so the > impact should be minimal (too bad we can't inline these!), but I thought I > should mention it anyways. Good work! ;-) > > After cleaning up everything I've worked on I think I'll start submitting > patches. First some pre-requisite patches for dlls/opengl32 and include/ and > then the changes for dlls/wined3d. All together it is quite a large change, but > I should be able to break it up into manageable pieces (hopefully!). Great! I'd really like to see this kind of thing come to fruition. I think it would be especially good to see wined3d run on windows for testing purposes. > > Regards, > Aric > > >

Dec. 17, 2005