wine-devel August 2004

wine-devel@winehq.org

122 participants
273 discussions

Re: working together on stdole.tlb and a end to dcom9x
by Filip Navara 30 Aug '04

30 Aug '04

Jacek Caban wrote: [snip] > I don't thik it Wine's bug. Applications don't depend on this stuff > and Wine's ref handling is correct. Of course that applications depend on this stuff. This is common code: LoadTypeLib("stdole.tlb", &ptlibStdOle); ptlibStdOle->GetTypeInfoOfGuid(IID_IUnknown, &ptinfoIUnknown)); ptlibStdOle->GetTypeInfoOfGuid(IID_IDispatch, &ptinfoIDispatch)); ptlibStdOle->Release(); Now with Wine the last Release will cause the typelib object to be destroyed and resulting that any later typeinfo references to typelib are invalid pointers. Regards, Filip

2 2

ScrollBars and Wine
by Diego 'Flameeyes' Pettenò 30 Aug '04

30 Aug '04

Hi, Last tuesday I reported some problems with Ultima OnLine AutoPatch ( http://article.gmane.org/gmane.comp.emulators.wine.user/7046 ), with the last CVS and now I found some more information about the problem. Seems like this NULL Pointer (because I think it's this the problem, seeing the 0x00000000) is dereferenced everytime a scrollbar changes position or size (at least while it's painted). I had a similar problem trying to use Inside UO (program to find out data inside the UO files, wrote in Delphi) and everytime I moved a scrollbar I got an NULL Pointer Exception (but in that case it was handled by the Delphi's Exception Handler, so the program didn't closed). Similar problems have Dependency Walker and also native Regedit. Every time I have this: Backtrace: =>1 0x00000000 (0x00001396) 2 0x00000000 (0x00000000) 0x00000000: addb %al,0x0(%eax) as backtrace. With the CVS of two weeks ago at least Dependency Walker run fine without problems at all. -- Diego "Flameeyes" Pettenò dgp85(a)users.sourceforge.net - http://flameeyes.web.ctonet.it/

1 0

trouble debugging
by James Hawkins 30 Aug '04

30 Aug '04

Hi, I'm having a real tough time debugging a program im trying to get to run called KLConfigWizard.exe. I had a problem earlier that was fixed by a tip from Rob. After trying a bunch of different native dll's that this program uses, I located the culprit dll (which is about as much as I seem to be able to do.) If I use native shlwapi then the crash doesnt happen. When i'm not using native shlwapi, the output I get is: [truiken@cmu-127081 Kazaa Lite K++]$ wine KLConfigWizard.exe Please use the registry key HKEY_CURRENT_CONFIG\Sotfware\Fonts\LogPixels to set the screen resolution and remove the "Resolution" entry in the config file fixme:commctrl:InitCommonControlsEx Unknown class! dwICC=0x4000 wine: Unhandled exception (thread 0009), starting debugger... fixme:console:SetConsoleCtrlHandler (0x405fbab0,1) - no error checking or testing yet WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00000000). In 32 bit mode. 0x00000000: addb %al,0x0(%eax) Wine-dbg>bt Backtrace: =>1 0x00000000 (0x00000000) Wine-dbg>q WineDbg terminated on pid 0x8 I do have the log of WINEDEBUG=trace+all, but the log file is ~243mb? I tried scanning through it looking for anything that would give me a clue, but it was hard to tell where any error was. It also doesnt help that the backtrace doesnt contain much of anything. Any ideas? -- James Hawkins

2 3

Re: CommonUnimpStub looping
by Juan Lang 30 Aug '04

30 Aug '04

Mike wrote: > On Sun, 29 Aug 2004 09:23:31 -0700, Steven Edwards > wrote: > > I dont see how native loading of Advapi32 ever > > worked anyway. Its a case like ntdll, kernel32, > > user32 or gdi. Maybe the Win9x advapi32 can..... > > I thought native NT advapi just forwarded to ntdll? Yeah. It depends on a bunch of security APIs that aren't implemented in ntdll though. The win9x advapi32 used to sort of work under wine iirc. I forget at what point that stopped being the case, probably about the time the builtin one became useful. --Juan __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail

1 0

CommonUnimpStub looping
by Stefan Leichter 30 Aug '04

30 Aug '04

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 29 Aug '04

29 Aug '04

Using native version of SHELL32.DLL (from the Win98 install) and builtin version of SHFOLDER.DLL ends up in Wine failure: [s2@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 29 Aug '04

29 Aug '04

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@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 29 Aug '04

29 Aug '04

(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 29 Aug '04

29 Aug '04

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 29 Aug '04

29 Aug '04

On linuxe I get this: [s2@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@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@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@katleriai tests]$ nm msvcrt_test.exe.so | grep fprintf 0001e100 D fprintf 0001e180 D vfprintf [s2@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@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@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

← Newer
1
2
3
4
5
6
7
...
28
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel August 2004