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

Re: Re: 2nd try closed reg keys. make sure CryptSetProviderEx doesnt delete the 'Type XXX' key

by James Hawkins

hehe i'm sorry about the sill errors...I will look over it very carefully this time and make sure all the leaks are gone. On Fri, 27 Aug 2004 12:28:45 -0700, Alexandre Julliard <julliard(a)winehq.org> wrote: > James Hawkins <truiken(a)gmail.com> writes: > > > Changelog > > * make CryptSetProviderEx only delete the 'Name' value and not > > delete the entire 'Type XXX' key when deleting the default provider. > > You are still leaking keys, and it doesn't even build (CryptCloseKey > is not a valid function). Please take your time, look over the code > carefully, fix all the leaks, then build and test it before > resubmitting. There's no hurry, you don't need to send a new patch > within 10 minutes of getting my mail <g> > > -- > Alexandre Julliard > julliard(a)winehq.org > -- James Hawkins

Aug. 27, 2004

Re: 2nd try closed reg keys. make sure CryptSetProviderEx doesnt delete the 'Type XXX' key

by Alexandre Julliard

James Hawkins <truiken(a)gmail.com> writes: > Changelog > * make CryptSetProviderEx only delete the 'Name' value and not > delete the entire 'Type XXX' key when deleting the default provider. You are still leaking keys, and it doesn't even build (CryptCloseKey is not a valid function). Please take your time, look over the code carefully, fix all the leaks, then build and test it before resubmitting. There's no hurry, you don't need to send a new patch within 10 minutes of getting my mail <g> -- Alexandre Julliard julliard(a)winehq.org

Aug. 27, 2004

Re: DbgHelp: Fix for Includes with Relative Paths

by Eric Pouech

> Is the attached patch correct? yes

Aug. 27, 2004

Re: winetest can't parse subtest for msvcrt(d)

by Saulius Krasuckas

On 27 Aug 2004, Vincent Béron wrote: > Just redirecting it to glibc would be trivial, but the problem is that's > not the Right Thing To Do (tm) as both don't have exactly the same > behavior, and that some apps rely on the msvcrt behavior (ie, break when > using glibc's). This part if fine. Now please tell me: why printing result of msvcrt* tests should depend on the difference of this behaviour? I mean, why do we need msvcrt functions to print information about the behaviour of another msvcrt functions? I always used to thought this is extremely uncorrelated stuff: 1, testing function of the lib; 2, printing results of the test. Are both thingies hardly tied? Forgive my ignorance, but I am afraid I won't be able to undrestand this just by digging in the Wine src. Thanks. > I'm sure there are some other reasons like the path used by characters > to be drawn on screen (glibc's stdlib vs some console handler path for > msvcrt), etc.

Aug. 27, 2004

Re: Problem in mutex?

by Alexandre Julliard

Shachar Shemesh <wine-devel(a)shemesh.biz> writes: > #define NUMTHREADS 3000 > > [...] > WaitForMultipleObjects(NUMTHREADS, threads, TRUE, INFINITE); That's probably not the cause of the deadlock, but you can't wait for more than 64 objects with WaitForMultipleObjects, so your code won't wait for the threads to terminate. -- Alexandre Julliard julliard(a)winehq.org

Aug. 27, 2004

Re: closed reg keys. make sure CryptSetProviderEx doesnt delete the 'Type XXX' key

by Alexandre Julliard

James Hawkins <truiken(a)gmail.com> writes: > Changelog > * make CryptSetProviderEx only delete the 'Name' value and not > delete the entire 'Type XXX' key when deleting the default provider. You are still leaking key handles... -- Alexandre Julliard julliard(a)winehq.org

Aug. 27, 2004

Re: Problem in mutex?

by Shachar Shemesh

Mike Hearn wrote: >> However, the program doesn't run properly. When running it, I get >> deadlocked. >> >> Does anyone have any explanation? Is it a bug in my Win32 code? > > > Doubt it, it *looks* OK. But the acid test is to run it on Windows. > > I've not used the mutex APIs much though, so could well be wrong. > >>> err:ntdll:RtlpWaitForCriticalSection section 0x4017fec0 "?" wait >>> timed out in thread 0009, blocked by 0000, retrying (60 sec) >> > > Well, this must be a Wine internal critical section and 0 is an > invalid thread ID. So it looks like something is going badly wrong > inside Wine. > > What does the backtrace of thread 9 look like? > > thanks -mike > > Wine-dbg>info thread > process tid prio (all id:s are in hex) > 00000008 (D) Z:\home\sun\sources\wine\threadtest\threadtest.exe > 00000009 0 <== > Wine-dbg>bt > Backtrace: > =>1 0x400484d1 (0x402fac54) > 2 0x401e5462 NTDLL_wait_for_multiple_objects+0x122(count=0x0, > handles=0x0, flags=0x8, timeout=0x402fad10) > [/home/sun/sources/wine/wine/dlls/ntdll/sync.c:587] in ntdll (0x402facf8) > 3 0x401e39cc usr1_handler+0x4c(__signal=0xa, __context=0x33) > [/home/sun/sources/wine/wine/dlls/ntdll/signal_i386.c:1160] in ntdll > (0x402fad1c) > 4 0xffffe420 (0x406bcd98) > 5 0x401e5462 NTDLL_wait_for_multiple_objects+0x122(count=0x1, > handles=0x406bce8c, flags=0xc, timeout=0x406bcebc) > [/home/sun/sources/wine/wine/dlls/ntdll/sync.c:587] in ntdll (0x406bce3c) > 6 0x401e54d6 NtWaitForMultipleObjects+0x66(count=0x1, > handles=0x406bce8c, wait_all=0x0, alertable=0x0, timeout=0x406bcebc) > [/home/sun/sources/wine/wine/dlls/ntdll/sync.c:605] in ntdll (0x406bce64) > 7 0x401e552c NtWaitForSingleObject+0x3c(handle=0x2c98, > alertable=0x0, timeout=0x406bcebc) > [/home/sun/sources/wine/wine/dlls/ntdll/sync.c:614] in ntdll (0x406bce84) > 8 0x401bfd15 RtlpWaitForCriticalSection+0x115(crit=0x4017fec0) > [/home/sun/sources/wine/wine/dlls/ntdll/critsection.c:220] in ntdll > (0x406bcf24) > 9 0x401bffa9 RtlEnterCriticalSection+0x49(crit=0x4017fec0) > [/home/sun/sources/wine/wine/dlls/ntdll/critsection.c:298] in ntdll > (0x406bcf3c) > 10 0x406cf980 (0x406bfe90) > 11 0x405b318afixme:dbghelp:elf_load_debug_info Unsupported Dwarf2 > information > (0x406bff20) > 12 0x404ffe52 start_process+0xf2(arg=0x0) > [/home/sun/sources/wine/wine/dlls/kernel/process.c:1014] in kernel32 > (0x406bfff4) > 13 0x4001d151 wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000) I find that there are several disturbing things here: 1. There is only one process. How did that happen? 2. The debugger cannot load the debug info for my winelib application. What the....? 3. When compiling this in Visual Studio 6 and running on wine: > sun(a)sun:~/sources/wine/threadtest$ time ../wine/wine Debug/main.exe > > /dev/null > Program exit 299732 > > real 0m17.826s > user 0m3.244s > sys 0m5.671s Just for comparison, when running on Windows, I get as far as 298015, but in less time. In order to achieve this, I lowered the stack (second CreateThread parameter) to 8*1024, to avoid running out of memory. This does not solve the problem when compiled as winelib, though. Could this be a winelib problem?? In short - things are getting weirder..... Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Aug. 27, 2004

RE: Problem in mutex?

by Francois Gouget

On Fri, 27 Aug 2004, Michael Drüing wrote: > Hi, > > running the program in WinXP results in an output like this: > Failed to create thread 8 > Failed to create thread 8 > .... (repeated quite often) > Failed to create thread 8 > Failed to create thread 8 > Program exit 33060 > > Watching the program with the taskmanager shows that it seems to only create > about 2000 threads, after which it seems to get these "out of memory" > errors. Unless you've done something special, each thread gets a 1MB stack. So 2000 threads works out to about 2GB which exhausts the virtual memory space. I have not read the code but I assume you don't try to create 2000 concurrent threads. Could it be that somehow the resources used by each thread are not getting released? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ La terre est une b\xEAta...

Aug. 27, 2004

Re: winetest can't parse subtest for msvcrt(d)

by Vincent Béron

Le ven 27/08/2004 à 11:38, Saulius Krasuckas a écrit : [snip] > MSVCRT.DLL.SO fprintf() doesn't get redirected? OK, lets switch to glibc > (or anything who works properly). Isn't it trivial to do? Just redirecting it to glibc would be trivial, but the problem is that's not the Right Thing To Do (tm) as both don't have exactly the same behavior, and that some apps rely on the msvcrt behavior (ie, break when using glibc's). I'm sure there are some other reasons like the path used by characters to be drawn on screen (glibc's stdlib vs some console handler path for msvcrt), etc. Vincent

Aug. 27, 2004

Re: tips needed for implementing the common control ICC_STANDARD_CLASSES

by James Hawkins

I'm reading through msdn some more and they say ICC_STANDARD_CLASSES should "Load one of the intrinsic User32 control classes. The user controls include button, edit, static, listbox, combobox, and scrollbar." If I'm remembering, those controls are already implemented in wine/controls. Maybe ICC_STANDARD_CLASSES just loads one/several of these controls for the user. I'm really not sure though, and I'm sure someone on wine-devel knows a lot more about this than me. On Fri, 27 Aug 2004 12:48:03 -0400, James Hawkins <truiken(a)gmail.com> wrote: > 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 > -- James Hawkins

Aug. 27, 2004