- Wine-Devel - list.winehq.org

CommonUnimpStub looping
by Stefan Leichter Aug. 30, 2004

Aug. 30, 2004

Hello, trying to install ie6 on current wine gives me an endless loop with function calls to CommonUnimpStub(). I started with .wine and dirve_c created by wine and installed dcom98, vc c++ runtime, vb 5 + 6 Runtime What i found so far is that it happens when the iebatch.exe gets started. The call the DllMain of the gdi32.dll never returns. In the traces i can see: 0016:Call PE DLL (proc=0x4080e5a4,module=0x40800000 L"gdi32.dll",reason=PROCESS_ATTACH,res=0x1) but a line like 0016:Ret PE DLL (proc=0x409b15a4,module=0x409a0000 L"gdi32.dll",reason=PROCESS_ATTACH,res=0x1) retval=1 is not inside the log file. Any tips to get around this problem ? Bye Stefan

3 3

mixing SHELL32.DLL and SHFOLDER.DLL
by Saulius Krasuckas Aug. 29, 2004

Aug. 29, 2004

Using native version of SHELL32.DLL (from the Win98 install) and builtin version of SHFOLDER.DLL ends up in Wine failure: [s2(a)katleriai wine]$ WINEDLLOVERRIDES="shell32=n" WINEDEBUG=+loaddll wine /home/s2/cc/Program\ Files/mIRC/mirc 2>&1 | grep -i [^a-z]sh trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\shlwapi.dll" : builtin trace:loaddll:load_dll Loaded module L"C:\\windows\\system\\shell32.dll" : native trace:loaddll:MODULE_LoadModule16 Loaded module "shell.dll" : native trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\shfolder.dll" : builtin err:module:find_forwarded_export function not found for forward 'shell32.SHGetFolderPathA' used by L"c:\\windows\\system\\shfolder.dll". If you are using builtin L"shfolder.dll", try using the native one instead. err:commdlg:DllMain Failed to get entry point "SHGetFolderPathA" for hinst = 0x41930000 This situation was already discussed three years ago or so [1], [3]. The most initiative person here was Juergen Schmied, it seems. Besides another things on Sun, 03 Dec 2000, Juergen Schmied wrote [2]: > Hmm, shlfolder is introduced for systems with a older version of > shell32.dll. I think we should use it just like it's done in cdlg32.c > and get the function with GetProcAdress. Bye the way: this way is used > in several cases of functions within shell32 introduced in later > versions. I'm currently having a patch for comdlg32 and shell32 to the > imports. Will send it soon. AFAICS, there was no patches sent against the SHFOLDER.DLL. Dear Wine developers, can I expect this situation to change soon? Please tell me: should I wait even more, or should I try writing a patch on my own? TIA. [1] http://www.winehq.org/hypermail/wine-devel/2000/12/index.html#41 [2] http://www.winehq.org/hypermail/wine-devel/2000/12/0048.html [3] http://www.winehq.org/hypermail/wine-devel/2001/07/index.html#4

3 4

RE: patch: shell32.dll - SHELL_ArgifyW expands env-vars
by Jens Collin Aug. 29, 2004

Aug. 29, 2004

Is there anything wrong with this patch? I can't see my changes taken place in CVS. Let me know and I'll fix 'em. /J -----Original Message----- From: wine-patches-admin(a)winehq.org [mailto:wine-patches-admin(a)winehq.org] On Behalf Of Jens Collin Sent: den 8 augusti 2004 17:55 To: wine-patches(a)winehq.org Subject: patch: shell32.dll - SHELL_ArgifyW expands env-vars changelog: * lookup of envoronment-vars in SHELL_ArgifyW in shell32.dll added. (Such as %SystemRoot%).

2 1

Winrash / Winetest
by Stephen Ogletree Aug. 29, 2004

Aug. 29, 2004

(I sent a version of this to wine-users originally and Ivan said to send it over here to wine-devel) On windows XP, with the latest patches/service packs, I got the errors below. Since these were popups and/or crashes, I'm assuming they need to be reported manually. 0. Small issue: The winrash installer (NSIS) concludes with a window that has 3 lines that are in blue text to suggest a hyperlink (and the surrounding text even says "Click the text below to make a bookmark for the test results") but clicking the text has no visible effect (when moving the cursor over the text, the cursor does change shape to indicate the text is clickable, so at least that much works...). My default browser is Opera and my security settings in IE are maxed out, with everything possible disabled. In Opera, I typically keep popups, plugins, and javascript disabled, but none of that should keep normal URL to a html page from opening. Since installing winrash didn't do anything except put the service in place and start it, I figured I'd go ahead and download the test manually. This rest of this email pertains to /winetest-200407091000-kevin-mingw.exe/ 1. I received the "Can't parse subtests output of msvcrtd" message during 'extraction'. I assume this is the same error Holly reported. 2. I had a message indicating a timeout during the user32 tests (before the network tests - this appears to be the same message Holly reported). Also, I remember the timeout was occurring back when we first tried out this testing program a month or two (or 3?) ago, so its a bug thats been around a while. 3. I am still seeing an error that I pointed out in the first round (or a long time ago, at least..) of testing where the test crashes Explorer (this is after the timeout, but before the prompt to send the results). Explorer crashing causes all of my desktop icons to reset to their positions from when I last logged in/out (which has been a week or two, so this was significant change), as well as causes some of the SysTray icons to vanish, and finally, of course I lose the start menu bar and the bar containing the running application names for a moment, while Windows XP nicely restarts explorer.exe. Meanwhile, there's no indication of trouble from the winetest window. FWIW: When I agreed to submit my test results, I did *not* receive any warning about my log being too big. Stephen Ogletree

2 1

tips needed for implementing the common control ICC_STANDARD_CLASSES
by James Hawkins Aug. 29, 2004

Aug. 29, 2004

Hi, I've had a lot of people ask me about how well kazaa lite runs in wine, so I will be working on getting it to work. The install file is called klitekpp243e.exe, and the setup works great. (NOTE: im trying to get the app to work without having to use any native dlls) After the installation of klite, a program called KLConfigWizard.exe is run. It's a dialog box with some text initially, then when you click the next button, the user encounters a fatal error and we're sent to the debugger. The error is: fixme:commctrl:InitCommonControlsEx Unknown class! dwICC=0x4000 The unknown class is one of the two control classes left to be implemented in commctrl: ICC_STANDARD_CLASSES. I would like to implement this class, but I have no idea where to start. I've searched msdn for ICC_STANDARD_CLASSES, but it only turned up a link to the INITCOMMONCONTROLSEX structure. If anyone has any ideas or hints that they can give me, I would really appreciate it. Thanks for your time. -- James Hawkins

3 6

winetest can't parse subtest for msvcrt(d)
by Saulius Krasuckas Aug. 29, 2004

Aug. 29, 2004

On linuxe I get this: [s2(a)katleriai s2]$ wine /usr/local/lib/wine/winetest.exe.so Usage: /tmp/wctW5ad4P/msvcrt_test.exe.so test_name Valid test names: cpp environ file headers heap scanf string time ..while Wine Test Shell pops up a message box with the error text: "Can't parse subtests output of msvcrt". I think that's due to some additional \r\n-s in the output of "msvcrt_test.exe.so". Here goes my observation and comparision to the case of "mlang_test.exe.so" (which works smoothly with the winetest): [s2(a)katleriai tests]$ wine msvcrt_test.exe.so | head -n 1 | od -t x1 0000000 55 73 61 67 65 3a 20 6d 73 76 63 72 74 5f 74 65 0000020 73 74 2e 65 78 65 2e 73 6f 20 74 65 73 74 5f 6e 0000040 61 6d 65 0d 0a 0000045 [s2(a)katleriai tests]$ wine mlang_test.exe.so | head -n 1 | od -t x1 0000000 55 73 61 67 65 3a 20 6d 6c 61 6e 67 5f 74 65 73 0000020 74 2e 65 78 65 2e 73 6f 20 74 65 73 74 5f 6e 61 0000040 6d 65 0a 0000043 As the "Valid test names:" string is printed by calling fprintf(), I suppose some differences arise due to incorrect linkage or such: [s2(a)katleriai tests]$ nm msvcrt_test.exe.so | grep fprintf 0001e100 D fprintf 0001e180 D vfprintf [s2(a)katleriai tests]$ nm mlang_test.exe.so | grep fprintf U fprintf@@GLIBC_2.0 U vfprintf@@GLIBC_2.0 It seems we realy are using msvcrt version of the fprintf(), which works in true-M$-way and adds an additional \r here. Next goes last lines from the build process: [s2(a)katleriai tests]$ (make clean && make) | tail -n 1 ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole cpp.o environ.o file.o headers.o heap.o scanf.o string.o time.o testlist.o -o msvcrt_test.exe.so -L../../../libs/port -lwine_port -L../../../dlls -L../../../libs -lmsvcrt [s2(a)katleriai tests]$ (make clean && make) | tail -n 1 ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole mlang.o testlist.o -o mlang_test.exe.so -L../../../libs/port -lwine_port -L../../../dlls -L../../../libs -lole32 -lgdi32 -lkernel32 -lntdll -luuid Can we fix it? I have no idea on how to link it right with the GLIBC. Of course, I am not sure this is the core of the problem. It would be nice to have winetest running in linux without such two hits (one for the msvcrt and another one for the msvcrtd). Or is this just my linux box configuration flawed?

3 7

Re: CommonUnimpStub looping
by Mike Hearn Aug. 29, 2004

Aug. 29, 2004

On Sun, 29 Aug 2004 13:26:37 +0100, Robert Shearman wrote: > Use the attached patch and run with warn+module. > > Rob There's no need, I debugged this in January. The problem is that the IE installer contains its own copy of advapi32 but it doesn't actually implement all the functions that ours does. In particular some are exported but just forward to the CommonUnimpStub function which is a bit like our code which throws an exception. Our GDI32 implementation uses one of the registry APIs that is implemented by our advapi32 implementation, but when IE is loaded the advapi32 inside the installer package takes precendence with the result that the GDI is linked to stub code. So things blow up. The solution is to force advapi32 to builtin so the older native version is never loaded. thanks -mike

1 0

Re: W->A cleanup of DirectDrawEnumerateEx part 4
by Mike McCormack Aug. 29, 2004

Aug. 29, 2004

You should post one patch not four that depend upon each other. Rule of Thumb: * After each patch is applied, the CVS should build and work. Mike James Hawkins wrote: > Changelog > * cleanup cross calls in DirectDrawEnumerateEx >

2 1

cleanup w->a cross calls in printdrv
by James Hawkins Aug. 29, 2004

Aug. 29, 2004

I want to send this through wine-devel first to see if there are any problems with it. In gdi_private.h I had to change the parameters that pStartDoc accepted from DOCINFOA to DOCINFOW. I know I shouldn't change public api headers, but this one is private so the change seems acceptable. If it's not let me know. Another problem that might popup is the way the DOCINFOW struct is filled in the StartDocA function: len = MultiByteToWideChar( CP_ACP, 0, doc->lpszDocName, -1, NULL, 0 ); docName = HeapAlloc( GetProcessHeap(), 0, len * sizeof(WCHAR) ); MultiByteToWideChar( CP_ACP, 0, doc->lpszDocName, -1, docName, len ); docW.lpszDocName = docName; <--- is this assignment a problem? if(docName) HeapFree( GetProcessHeap(), 0, (LPWSTR)docName ); The reason why I had to make a docName variable is because docW.lpszDocName is a LPCWSTR so there were warnings when i had docW.lpszDocName directly in the call to MultiByteToWideChar. Changelog * cleanup w->a cross calls in StartDoc -- James Hawkins

2 1

Wine's X11drv integration in Mac OS X
by Pierre d'Herbemont Aug. 29, 2004

Aug. 29, 2004

Hi, We are currently porting Wine to Mac OS X. Currently Wine has a display driver for X11, and we would like to continue to use it for the Mac OS X port: to display the GUI interface, we don't need the Aqua UI elements since we prefer to use Windows theming system, and given the complexity and amount of work done in x11drv . But we also would like to be able to build something that behaves like a normal Carbon or Cocoa App, with a Dock Icon, and a Menu Bar, which would be managed by some Carbon code in Wine itself. I had a look to the X11CallCarbonAndCocoa [1] sample code, but the trouble is that the X11 window still belongs to X11.app, a mouse click in the Dock to get the App's Windows to the front doesn't work for the X11 Window, and the menu bar for this Window is still the X11.app's menu bar. So I'd like to know if there is a way for the Wine Carbon instance to own the X11 Windows Wine created. At least it would be a feature that we'd like to see :) Thanks, Pierre. PS: I am not subscribed to the x11-users so please CC me. I am also CC-ing the wine-devel and darwine-devel, sorry about that. [1] http://developer.apple.com/samplecode/X11CallCarbonAndCocoa/ X11CallCarbonAndCocoa.html

1 0