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

Googletalk and Wine

by Andrew Neil Ramage

Googletalk is a free chat program from Google with integrated VoIP. I installed the program and received a message saying Googletalk required Windows 2000, XP or 2003. The program started after installation and almost immewdiately crashed. Here is the output. andrew(a)apollo:~/Download/Windows> wine googletalk.exe wine: cannot find 'googletalk.exe' andrew(a)apollo:~/Download/Windows> wine googletalk-setup.exe fixme:win:SetWindowTextA setting text "Google Talk Setup" of other process window (nil) should not use SendMessage fixme:win:SetWindowTextA setting text "Google Talk Setup" of other process window (nil) should not use SendMessage fixme:richedit:RichEditANSIWndProc WM_SETFONT: stub fixme:richedit:RichEditANSIWndProc EM_AUTOURLDETECT: stub fixme:richedit:RichEditANSIWndProc EM_EXLIMITTEXT: stub err:menubuilder:InvokeShellLinker failed to fork and exec wineshelllink err:menubuilder:InvokeShellLinker failed to fork and exec wineshelllink fixme:advapi:LookupAccountSidW ((null),sid=0x403cf860,0x406dfcf8,0x406dfcf4(64),0x406dfd78,0x406dfcf0(64),0x406dfcd4): semi-stub fixme:ole:CoInitializeSecurity ((nil),-1,(nil),(nil),0,3,(nil),0,(nil)) - stub! err:ole:CoGetClassObject class {304ce942-6e39-40d8-943a-b913c40c9cd4} not registered fixme:ole:CoCreateInstance no classfactory created for CLSID {304ce942-6e39-40d8-943a-b913c40c9cd4}, hres is 0x80040154 andrew(a)apollo:~/Download/Windows> fixme:advapi:LookupAccountSidW ((null),sid=0x403cf868,0x406dfcf8,0x406dfcf4(64),0x406dfd78,0x406dfcf0(64),0x406dfcd4): semi-stub fixme:ole:CoInitializeSecurity ((nil),-1,(nil),(nil),0,3,(nil),0,(nil)) - stub! fixme:richedit:RichEditANSIWndProc WM_SETFONT: stub fixme:richedit:RichEditANSIWndProc EM_SHOWSCROLLBAR: stub fixme:richedit:RichEditANSIWndProc EM_SHOWSCROLLBAR: stub fixme:richedit:RichEditANSIWndProc EM_SETTEXTMODE: stub fixme:richedit:RichEditANSIWndProc WM_SETFONT: stub fixme:richedit:RichEditANSIWndProc EM_SHOWSCROLLBAR: stub fixme:richedit:RichEditANSIWndProc EM_SHOWSCROLLBAR: stub fixme:richedit:RichEditANSIWndProc EM_HIDESELECTION: stub err:x11drv:X11DRV_CreateWindow invalid window height -2 fixme:keyboard:RegisterHotKey (0x3002e,0,0x00000008,27): stub fixme:richedit:RichEditANSIWndProc EM_HIDESELECTION: stub fixme:richedit:RichEditANSIWndProc EM_HIDESELECTION: stub fixme:sensapi:IsNetworkAlive 0x406de880 fixme:richedit:RichEditANSIWndProc EM_HIDESELECTION: stub wine: Unhandled exception (thread 0018), starting debugger... WineDbg starting on pid 0x15 Unhandled exception: page fault on write access to 0x0074006f in 32-bit code (0x401b140e). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:401b140e ESP:42cb686c EBP:42cb6894 EFLAGS:00210206( - 00 - RIP1) EAX:00740065 EBX:401ebbd4 ECX:006e006c EDX:00740063 ESI:403d0ed8 EDI:403d0f00 Stack dump: 0x42cb686c: 403d0380 00000020 401f2a20 401f2ace 0x42cb687c: 00000000 00000028 40360000 401ebbd4 0x42cb688c: 403d0ed8 00000028 42cb68d4 401b1be7 0x42cb689c: 401b13a0 401b13a0 42cb68c8 00004000 0x42cb68ac: 401f2ace 401f2ace 401b08de 00043bd8 0x42cb68bc: 00000001 40360000 40360000 401ebbd4 Backtrace: =>1 0x401b140e in ntdll (+0x2140e) (0x42cb6894) 2 0x401b1be7 in ntdll (+0x21be7) (0x42cb68d4) 3 0x401b1e2a RtlFreeHeap in ntdll (0x42cb6908) 4 0x40703dde in wininet (+0x13dde) (0x42cb692c) 5 0x40709693 WININET_Release in wininet (0x42cb6958) 6 0x4070edb9 InternetCloseHandle in wininet (0x42cb697c) fixme:dbghelp:sffip_cb NIY on 'googletalk.pdb' 7 0x004142c9 in googletalk (+0x142c9) (0x4221b164) 8 0x00000000 (0x005778c8) 9 0x00413230 in googletalk (+0x13230) (0x004131c0) 0x401b140e: movl %eax,0xc(%edx) Modules: Module Address Debug info Name (84 modules) PE 0x00400000-00720000 Export googletalk ELF 0x40000000-40018000 Deferred ld-linux.so.2 ELF 0x40031000-4004a000 Deferred libwine.so.1 ELF 0x4004a000-4005c000 Deferred libpthread.so.0 ELF 0x4005c000-40175000 Deferred libc.so.6 ELF 0x40175000-40179000 Deferred libdl.so.2 ELF 0x4017a000-401f5000 Export ntdll<elf> \-PE 0x40190000-401f5000 \ ntdll ELF 0x4020d000-40302000 Deferred libwine_unicode.so.1 ELF 0x40302000-40325000 Deferred libm.so.6 ELF 0x40470000-40581000 Deferred kernel32<elf> \-PE 0x404a0000-40581000 \ kernel32 ELF 0x406e0000-40726000 Export wininet<elf> \-PE 0x406f0000-40726000 \ wininet ELF 0x40726000-40746000 Deferred mpr<elf> \-PE 0x40730000-40746000 \ mpr ELF 0x40746000-40878000 Deferred user32<elf> \-PE 0x40770000-40878000 \ user32 ELF 0x40878000-4126c000 Deferred gdi32<elf> \-PE 0x40890000-4126c000 \ gdi32 ELF 0x41342000-4134a000 Deferred libgcc_s.so.1 ELF 0x4134a000-4138c000 Deferred advapi32<elf> \-PE 0x41360000-4138c000 \ advapi32 ELF 0x4138c000-413eb000 Deferred shlwapi<elf> \-PE 0x413a0000-413eb000 \ shlwapi ELF 0x413eb000-41479000 Deferred ole32<elf> \-PE 0x41400000-41479000 \ ole32 ELF 0x41479000-414c4000 Deferred rpcrt4<elf> \-PE 0x41490000-414c4000 \ rpcrt4 ELF 0x414c4000-414e4000 Deferred iphlpapi<elf> \-PE 0x414d0000-414e4000 \ iphlpapi ELF 0x414e4000-415ad000 Deferred shell32<elf> \-PE 0x41500000-415ad000 \ shell32 ELF 0x415ad000-4166b000 Deferred comctl32<elf> \-PE 0x415c0000-4166b000 \ comctl32 ELF 0x4166b000-41696000 Deferred ws2_32<elf> \-PE 0x41670000-41696000 \ ws2_32 ELF 0x41696000-41717000 Deferred winmm<elf> \-PE 0x416a0000-41717000 \ winmm ELF 0x41717000-4173e000 Deferred crypt32<elf> \-PE 0x41720000-4173e000 \ crypt32 ELF 0x4173e000-41752000 Deferred sensapi<elf> \-PE 0x41740000-41752000 \ sensapi ELF 0x41752000-4176d000 Deferred version<elf> \-PE 0x41760000-4176d000 \ version ELF 0x4176d000-41783000 Deferred lz32<elf> \-PE 0x41770000-41783000 \ lz32 ELF 0x41783000-4181c000 Deferred oleaut32<elf> \-PE 0x417a0000-4181c000 \ oleaut32 ELF 0x4181c000-41830000 Deferred msimg32<elf> \-PE 0x41820000-41830000 \ msimg32 ELF 0x41830000-4188d000 Deferred setupapi<elf> \-PE 0x41840000-4188d000 \ setupapi ELF 0x4188d000-418b1000 Deferred msacm32<elf> \-PE 0x418a0000-418b1000 \ msacm32 ELF 0x418b1000-418ce000 Deferred secur32<elf> \-PE 0x418c0000-418ce000 \ secur32 ELF 0x418e6000-41955000 Deferred libfreetype.so.6 ELF 0x4196d000-4199b000 Deferred libfontconfig.so.1 ELF 0x4199b000-419ba000 Deferred libexpat.so.0 ELF 0x419ba000-41a40000 Deferred winex11.drv<elf> \-PE 0x419d0000-41a40000 \ winex11.drv ELF 0x41a40000-41a42000 Deferred xlcutf8load.so.2 ELF 0x41a58000-41a60000 Deferred libsm.so.6 ELF 0x41a60000-41a78000 Deferred libice.so.6 ELF 0x41a78000-41a7e000 Deferred libxxf86dga.so.1 ELF 0x41a7e000-41a83000 Deferred libxxf86vm.so.1 ELF 0x41a83000-41a91000 Deferred libxext.so.6 ELF 0x41a91000-41b8d000 Deferred libx11.so.6 ELF 0x41b8d000-41bfa000 Deferred libgl.so.1 ELF 0x41bfa000-41c19000 Deferred ximcp.so.2 ELF 0x41c19000-41c37000 Deferred imm32<elf> \-PE 0x41c20000-41c37000 \ imm32 ELF 0x41c4f000-41c58000 Deferred libxcursor.so.1 ELF 0x41c58000-41c60000 Deferred libxrender.so.1 ELF 0x41ec0000-41f03000 Deferred wineoss.drv<elf> \-PE 0x41ed0000-41f03000 \ wineoss.drv ELF 0x41f03000-41f1c000 Deferred msacm.drv<elf> \-PE 0x41f10000-41f1c000 \ msacm.drv ELF 0x42130000-42145000 Deferred midimap.drv<elf> \-PE 0x42140000-42145000 \ midimap.drv ELF 0x42902000-42943000 Deferred riched20<elf> \-PE 0x42910000-42943000 \ riched20 ELF 0x7bf00000-7bf03000 Deferred <wine-loader> Threads: process tid prio (all id:s are in hex) 00000015 (D) C:\Program Files\Google\Google Talk\googletalk.exe 00000018 0 <== 00000017 0 00000016 0 WineDbg terminated on pid 0x15 Anyone know what went wrong ? -- Andrew You can be the captain I will draw the chart Sailing into destiny Closer to the heart Closer to the Heart by Rush (A Farewell to Kings, 1977) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Aug. 26, 2005

Re: undocumented shell32 stuff

by Saulius Krasuckas

* On Fri, 26 Aug 2005, Robert Shearman wrote: > > What program are you running and which platform is it designed to run > on? I ask because the win9x shell32 exports SHLocalAlloc at a different > ordinal to the NT shell32. It isn't a standalone program, it's a Win98 Explorer. > Our shell32 mostly has the ordinals for the win9x shell32, so if the > program is designed to run on NT then stub you are hitting is really > something else. Makes big sense. Thank you for explanation, Rob. Is this tip on the Wine web or should it be there?

Aug. 26, 2005

Re: OpenGL windowing and wglMakeCurrent

by Lionel Ulmer

On Wed, Aug 24, 2005 at 02:40:48PM -0700, Russ wrote: > Trying to get my 3-D app to run under WINE using the same binary with the odd > workaround or two. It uses OpenGL in various subwindows of the main window as > needed. Under WINE, the subwindow graphics all get drawn in the lower left > corner of the overall X11 window, and the entire X11 window's redraw is > mangled---OpenGL is affecting the entire X11 Window. This is basically the problem which is tracked through Bugzilla bug 2398 (URL: http://bugs.winehq.org/show_bug.cgi?id=2398) In summary, the problem is as follows: due to some 'features' of Win32 handling of windows and DCs, having a Win32 window <=> X11 window one to one mapping is not feasible (it was done once but Alexandre removed it as part of the window management rewrite as it lead to some problems in applications). In the current Wine code, there is only one X11 window for each top-level Win32 window, everything else inside these windows (clipping, ...) is done internally by Wine. The easiest way to fix the issue would be to 'override' the 'glViewport' call and pass to GLX no the viewport as decided by the Win32 application but the one relative to the X11 window taking into account the Win32 DC position relative to this X11 window (one could do the same with glScissor). This should work ... except that it won't handle the case where the DC is partially obscured by something (i.e. where Wine should do its own clipping) and one would need also to override all the 'buffer' functions (like glReadBuffer / glWriteBuffer). In that case, one could still imagine hacks (like using clip planes or stencil tests) but the big problem with that is that we use GL ressources to do this => if the application itself uses stencilling or clip planes, we are facing a ressource conflict. So we have two possible solutions: = write our own GLX extension that exports to the user the clip-list handling (the drivers must export something like that to the X11 server to be able to do propper window-level clipping, the goal of this extension would just be to enable the actual application to insert in this list its own clip rectangles). = use pbuffers for all GL renderings and use Wine's standard GDI functions to 'blit' this on screen. This has the advantage that the application would be completely 'fooled' without having to hack any GL calls. The problem would now only be when to flush this pbuffer on screen (which would lead to changes to the thunks for front-buffer operations or single-buffered operations). The first solution would clearly be the best but we need some volunteers to: = draft the GL extension = check with people to see if they think something like that would be acceptable (maybe by coding it in the X.org tree for some cards where the GL driver is open source) = push for the extension to be included in the 'commercial' GL drivers (NVIDIA / ATI) Lionel -- Lionel Ulmer - http://www.bbrox.org/

Aug. 26, 2005

Re: Crash on glBegin() (Was: Help with debugging needed)

by Lionel Ulmer

> As far as I can tell from a quick look, no. All ddraw calls are done from the > same thread, there are only a few imm32 calls from another thread. OK, a shame :-) > I have noticed that it creates multiple DirectDraw and Direct3D devices, some > of them are freed, re-created and freed again. At the time of the crash due > to reference counting, there are at least 2 DirectDraw and 2 Direct3D > objects. Is this going to work? Well, there should be no issue with that except if there is some issue in the GL drivers about an application having multiple contexts created at the same time? > Do you still want to see a +ddraw,+tid trace? I can upload one to my homepage. Well, if it's not multithreaded in DDraw, no need. I still have to look at your other trace with the refcounting issue to try to see where the problem lies. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Aug. 26, 2005

DLL loading

by Bojan �ffff8aernek

hello, I'd like to load a DLL from a memory buffer. The regular Win32 API function to load DLLs, however, takes a path name. So, I'm looking for resources about this kind of thing, but it has to work both under win32 and unix+wine. There used to be a web page about just this thing, but I lost the link. Any ideas? Thanks. ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs

Aug. 26, 2005

Re: PATCH: sensap IsNetworkAlive

by Vijay Kiran Kamuju

Hi, According to MSDN, >+#define NETWORK_ALIVE_RAS 2 must be #define NETWORK_ALIVE_WAN 2 I think so, see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/syncmgr/sy… Thanks, Vijay

Aug. 26, 2005

Re: undocumented shell32 stuff

by Robert Shearman

Saulius Krasuckas wrote: >I have stumbled upon a unimplemented function shell32.dll.SHLocalAlloc . > What program are you running and which platform is it designed to run on? I ask because the win9x shell32 exports SHLocalAlloc at a different ordinal to the NT shell32. Our shell32 mostly has the ordinals for the win9x shell32, so if the program is designed to run on NT then stub you are hitting is really something else. -- Rob Shearman

Aug. 26, 2005

undocumented shell32 stuff

by Saulius Krasuckas

I have stumbled upon a unimplemented function shell32.dll.SHLocalAlloc . OpenRCE page says it is related to kernel32.dll.LocalAlloc [1], and authors of the NSElib (The NameSpace Extension Library) defines it taking two int-params [2]. They define the function in ShlExt.h file which says: // This file can be considered to be in the public domain. // The latest version can normally be found here: // http://www.whirlingdervishes.com/nselib/public // The file is based on various sources, and includes definitions // that were taken over from various places, including // Microsoft documentation and header files. It also contains // many definitions that were introduced by Whirling Dervishes // Software. OTOH, there is one page on the web [3], which declares itself as a homepage of the ShlExt.h and which describes history of the file. It seems as prototype which was extended by Whirling Dervishes Software and based on which their NSElib was built. Earlier ShlExt.h was beeing included in the PSDK, but now it isn't AFAICS. And this is another quote from [2]: // februari 2003: Henk Devos: Made compatible with the // october 2003 Platform SDK // januari 2003: Henk Devos: added some more undefined flags, // including the ones for CDefFolderMenu_Create2. // september 2002: Henk Devos: Made compatible with new Platform SDK // januari 2002: Henk Devos: Added comments with ordinals of // all exports in Windows 2000 version of shell32.dll // 24/06/99 Some changes made by Henk Devos It stays above the changelog of the old file [4]. What developers think about this story? Can we start importing it into our tree? If not, should I declare SHLocalAlloc() somewhere? And where should I put it's code, maybe dlls/shell32/utility.c ? [1] http://www.openrce.org/reference_library/win32_call_chains/2000SP4/SHLWAPI/… [2] http://www.whirlingdervishes.com/nselib/mfc/samples/source.php [3] http://www.mvps.org/user32/shlext.html#shlext [4] http://www.mvps.org/user32/shlext.zip

Aug. 26, 2005

More compatible memory arrangement ?: dlls/winsock.c: WS_dup_pe()

by Krzysztof C.

Hi, I was having a problem with a game, it couldn't connect to the server, so I started debugging things, and it ofcourse brought me to dlls/winsock.c but the problem seems to be on the game side ( unfortunately its closed-source, so I can only guess what's happening ). The debugging showed that when the game was getting server's ip from DNS (WS_gethostbyname()), it was getting wrong values. Then I started looking for the cause, and I found out that the game was incorrectly reading the hostent/WS_hostent structure. It was assuming that the ip address was at particular offset from the beginning of the structure, it didn't follow the pointers and thus it was getting wrong data. Then I rewrote few lines of the code and now it looks like: "pointer | pointer | pointer | ... data | data | data | .... " and everything works fine. So I assume that Microsoft's winsock arrange this structure this way, but I am not sure if it is 100% compatible way solving "one application problem", although few other programs dependent on this function worked fine with this change. Anyway I left the topic with question mark because I would like to know someone else's opinion on that. ( btw. I am new to mailing lists and it is my first post, so please don't be too rough on me in your responses : ) Index: dlls/winsock/socket.c =================================================================== RCS file: /home/wine/wine/dlls/winsock/socket.c,v retrieving revision 1.188 diff -u -p -r1.188 socket.c --- dlls/winsock/socket.c 25 Aug 2005 10:22:12 -0000 1.188 +++ dlls/winsock/socket.c 25 Aug 2005 22:20:58 -0000 @@ -3343,16 +3343,16 @@ static struct WS_hostent *WS_dup_he(cons p_to->h_addrtype = p_he->h_addrtype; p_to->h_length = p_he->h_length; - p = (char *)(p_to + 1); + p = (char *)p_to + sizeof(struct hostent); + p_to->h_addr_list = (char **)p; + p += list_dup(p_he->h_addr_list, p_to->h_addr_list, p_he->h_length); + p_to->h_name = p; - strcpy(p, p_he->h_name); - p += strlen(p) + 1; + strcpy(p_to->h_name, p_he->h_name); + p += strlen(p_he->h_name) + 1; p_to->h_aliases = (char **)p; - p += list_dup(p_he->h_aliases, p_to->h_aliases, 0); - - p_to->h_addr_list = (char **)p; - list_dup(p_he->h_addr_list, p_to->h_addr_list, p_he->h_length); + list_dup(p_he->h_aliases, p_to->h_aliases, 0); return p_to; }

Aug. 26, 2005

Re: Crash on glBegin() (Was: Help with debugging needed)

by Lionel Ulmer

On Tue, Aug 23, 2005 at 12:35:16PM +0000, Stefan Dösinger wrote: > I'll try to reproduce the behaviour and write a small test for this problem > and the reference counting issue. However, this may take some time... Could you do a +ddraw,+tid trace and check that all DirectX calls are done from the same thread ? If not, Wine is doing bad stuff that may lead to crashes in the GL drivers depending on the way they handle TLS and then your problem is a 'classical' one (for which the solution is still in the 'need to be done one day' phase :-) ). Lionel (back from vacation so a bit 'mail-lagged' :-) ) -- Lionel Ulmer - http://www.bbrox.org/

Aug. 25, 2005