wine-devel

wine-devel@winehq.org

9 participants
84457 discussions

couple of questions about pthreads (scheduler/pthread.c) in wine
by Juraj Hercek 14 Jun '03

14 Jun '03

Hi, I've ported an application which uses a library - let's call it aceutilities.so - which in turn uses ACE library (http://www.cs.wustl.edu/~schmidt/ACE.html). ACE uses libpthread.so library. So the dependency is like this: my_application -> aceutilities.so -indirectly via ace library-> libpthread.so Wine's scheduler/pthread.c (compiled code resides in ntdll.dll.so) defines couple of symbols, which are defined (if we don't take symbol versions into consideration) also in libpthread.so. Now you probably feel what's my problem: After loading application into memory, dynamic linker loads wine stuff first, then when loading aceutilities.so into memory, pthread symbols are defined in module ntdll.dll.so - already loaded into memory - and so it doesn't try to load libpthread.so, because pthread symbols are already resolved. My questions are: 1) Why Winelib uses it's own implementation of pthreads (at least it looks like this is intention)? 2) Is it possible to force linker to use symbols from libpthread.so instead of symbols from ntdll.dll.so? (I don't know how to tell linker to use symbol, e.g. pthread_cond_wait, from specified library, i.e. /lib/libpthread.so.0). Thanks for help, Juraj

4 5

Re: wineconsole init
by PETREOLLE Sylvain 14 Jun '03

14 Jun '03

Could we have settings that avoid the error message about ncurses ? To have working non-buffered keyboard input in dos programs, I must disable curses support.

2 1

new compile problem - curses.c:790: conflicting types for `WCCURSES_InitBackend'
by hatky 14 Jun '03

14 Jun '03

I was updating the cvs after the last commit rain from alexander and it does not compile to be sure I removed the tree and checked it out again and I still get the error: gcc -c -I. -I. -I../../include -I../../include -D_REENTRANT -fPIC -DUNICODE -Wall -mpreferred-stack-boundary=2 -gstabs+ -Wpointer-arith -g -O2 -o curses.o curses.c curses.c:790: conflicting types for `WCCURSES_InitBackend' winecon_private.h:96: previous declaration of `WCCURSES_InitBackend' make[2]: *** [curses.o] Error 1 make[2]: Leaving directory `/home/hatky/wine-source/wine/programs/wineconsole' make[1]: *** [wineconsole] Error 2 make[1]: Leaving directory `/home/hatky/wine-source/wine/programs' make: *** [programs] Error 2 I did not notice anyone else asking about this so I wonder it this is some version of a package I have.... I have mandrake9.1 with the latest updates... It is a completly clean tree (just checked out fully), Hatky. __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com

1 0

Re: advapi32: added Ace/Acl functions
by PETREOLLE Sylvain 13 Jun '03

13 Jun '03

Could you resubmit your patch using cvs diff -u ? This would be great.

1 0

Windows 2000 winetest results from source release 20030508
by Josh Metzler 13 Jun '03

13 Jun '03

I retrieved the wine source release of 20030508. I ran ./tools/winapi/msvcmaker --no-wine. Note: I did this in Cygwin, and I had to make some changes to the perl script to get it to run. I also created a wine subdirectory under each of the test subdirs, and copied test.h into it. The MSVC versions couldn't find this file otherwise. Also, I was unable to compile shlwapi_test even after copying unicode.h into the shlwapi/test/wine subdir I had created. I tried to run all the tests that said they needed retested, or that had any errors according to http://fgouget.free.fr/wine/tests-en.shtml. I ran these tests from within MSVC++ 6.0 on a Windows 2000 SP3 machine, and tried to find out what an API returned when it was different from what the test expected. If someone could suggest how the tests should deal with different return values on different Windows versions, and also tell me the best way to create patches, I would be willing to try to help fix some of these tests. Josh Metzler -- kernel32_test locale locale.c:154: Test failed: GetTimeFormat got '' instead of '4' locale.c:155: Test failed: GetTimeFormat: got 1 instead of 2 locale.c:181: Test failed: GetTimeFormat got '8.@:56AM' instead of '8.@:56.@:AM' locale.c:182: Test failed: GetTimeFormat: got 9 instead of 12 locale.c:190: Test failed: GetTimeFormat got '' instead of '3' locale.c:191: Test failed: GetTimeFormat: got 1 instead of 2 locale.c:466: Test failed: GetDateFormat got '5/4/2002' instead of '5/4/02' locale.c:467: Test failed: GetDateFormat: got 9 instead of 7 locale.c:489: Test failed: GetDateFormat check DATE_YEARMONTH with null format expected ERROR_INVALID_FLAGS got return of '10' and error of '0' locale: 112 tests executed, 0 marked as todo, 9 failures. Notes: 489: GetDateFormat returned 10, buffer contained "May, 2002" In other words, the function succeeded. path path.c:514: Test failed: GetLongPathNameA: wrong return code, 97 instead of 42 path.c:881:TMP=C:\DOCUME~1\josh\LOCALS~1\Temp path.c:892:TMP=C:\WINNT path.c:902:TMP=C:\ path.c:912:TMP=C: path: 1730 tests executed, 0 marked as todo, 1 failure. Notes: 514: Counting the characters, the size of the long path name was 96. The function did exactly what the MSDN library said it will do - return the lenght of the buffer necessary to hold the long path name. process tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. process.c:870: Test failed: StartupInfoA:lpDesktop expected (null), got WinSta0\Default process.c:871: Test failed: StartupInfoA:lpTitle expected (null), got C:\cygwin\home\josh\wine\dlls\kernel\tests\Output\Win32_MSVC_Headers\kernel32_test.exe tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. process.c:918: Test failed: StartupInfoA:lpDesktop expected (null), got WinSta0\Default process.c:919: Test failed: StartupInfoA:lpTitle expected (null), got C:\cygwin\home\josh\wine\dlls\kernel\tests\Output\Win32_MSVC_Headers\kernel32_test.exe process: 309 tests executed, 0 marked as todo, 4 failures. Notes: looks like Windows 2000 fills in the window station and title if they are null. I wonder who owns that memory? thread thread: 113 tests executed, 0 marked as todo, 0 failures. /************************************************************************/ netapi32_test access access.c:110: Test failed: Bad Network Path: rc=0 access: 23 tests executed, 0 marked as todo, 1 failure. Notes: NetUserGetInfo succeeds when passed an empty string, getting user info for the local computer. Test expected ERROR_BAD_PATH as the return value. /************************************************************************/ oleaut32_test vartest vartest.c:1761:======== Testing VarUI1FromXXX ======== vartest.c:1849:======== Testing VarUI2FromXXX ======== vartest.c:1936:======== Testing VarUI4FromXXX ======== vartest.c:2022:======== Testing VarI1FromXXX ======== vartest.c:2088:======== Testing VarI2FromXXX ======== vartest.c:2133:======== Testing VarI4FromXXX ======== vartest.c:2177:======== Testing VarR4FromXXX ======== vartest.c:2224:======== Testing VarR8FromXXX ======== vartest.c:2244:======== Testing VarDateFromXXX ======== vartest.c:2315:======== Testing VarBoolFromXXX ======== vartest.c:2371:======== Testing VarBSTRFromXXX ======== vartest.c:2604:======== Testing Hi-Level Variant API ======== vartest.c:2691:======== Testing different VARTYPES ======== vartest: 1875 tests executed, 0 marked as todo, 0 failures. /************************************************************************/ shell32_test shlfileop shlfileop: 121 tests executed, 0 marked as todo, 0 failures. /************************************************************************/ urlmon_test generated generated: 4 tests executed, 0 marked as todo, 0 failures. /************************************************************************/ user32_test sysparams sysparams.c:1112:strict=0 sysparams.c:214:testing SPI_{GET,SET}BEEP sysparams.c:350:testing SPI_{GET,SET}MOUSE sysparams.c:455:testing SPI_{GET,SET}KEYBOARDSPEED sysparams.c:487:testing SPI_ICONHORIZONTALSPACING sysparams.c:530:testing SPI_{GET,SET}SCREENSAVETIMEOUT sysparams.c:564:testing SPI_{GET,SET}SCREENSAVEACTIVE sysparams.c:601:testing SPI_{GET,SET}KEYBOARDDELAY sysparams.c:634:testing SPI_ICONVERTICALSPACING sysparams.c:685:testing SPI_{GET,SET}ICONTITLEWRAP sysparams.c:718:testing SPI_{GET,SET}MENUDROPALIGNMENT sysparams.c:754:testing SPI_{GET,SET}DOUBLECLKWIDTH sysparams.c:785:testing SPI_{GET,SET}DOUBLECLKHEIGHT sysparams.c:817:testing SPI_{GET,SET}DOUBLECLICKTIME sysparams.c:869:testing SPI_{GET,SET}MOUSEBUTTONSWAP sysparams.c:895:testing SPI_GETFASTTASKSWITCH sysparams.c:910:testing SPI_{GET,SET}DRAGFULLWINDOWS sysparams.c:948:testing SPI_{GET,SET}WORKAREA sysparams.c:992:testing SPI_{GET,SET}SHOWSOUNDS sysparams.c:1042:testing SPI_{GET,SET}DESKWALLPAPER sysparams: 412 tests executed, 0 marked as todo, 0 failures. /************************************************************************/ winspool_test info info: 10 tests executed, 0 marked as todo, 0 failures.

1 0

Re: wine-devel digest, Vol 1 #2004 - 15 msgs
by Emmanuel Goldstein 13 Jun '03

13 Jun '03

> On Thu, 12 Jun 2003 20:52:34 +1200, Sir Emmanuel Goldstein scribed thus: > > wIntegrate appears to use an internal, custom implementation of Winsock. > > That is, I cannot see it link winsock when i do -debugmsg +dll. > I doubt that.... the correct channel is +loaddll, try with that. Ok, I've run it with +loaddll. wIntegrate is linking an ActiveX control, wWinsock.ocx. > > -debugmsg +winsock yeilds a little information, but not much. i tried a > > -debugmsg +all, but that filled up my hard disc and caused X to crash. > > What can I do to help further determine the problem? > > Try a +relay trace. For something as vague as this you need to investigate > further really, there is an infinite multitude of things that could be > going wrong. I tried running the program with native dlls. In the end, I wound up with a Winsock error 138. I tried a relay trace, this crashed my X session (before you ask, i'm running debian woody.)

1 0

Re: [xplane] Re: DSound buffer underrun problems with X-Plane
by Christian Neumair 13 Jun '03

13 Jun '03

Am Fre, 2003-06-13 um 08.29 schrieb stationairskyhawk: > --- In xplane(a)yahoogroups.com, Christian Neumair <chris@g...> wrote: > > I'm currently testing a cool flight simulator called X-Plane. It's > > really working great on wine, the performance is supersonic. The only > > downer is that the engine sound is a bit staccato, i.e. it has small > > breaks. My non-debug debian wine continuously outputs: > > > > "err:dsound:DSOUND_MixOne underrun on sound buffer 0x4b4c47c8" > > This is a known issue. When x-plane's performance becomes supersonic, it is natural > to expect the sound to drop out. Many have found that by reducing x-plane's > performance to subsonic levels, the sounds returns. I don't think this is the reason. I'm not on a very fast machine, but the sound problems occur independent of my graphic settings. They even are revisable when X-Plane shows its splash screen and loads the last used plane which makes me believe that something goes wrong in wine's sound mixing code. regs, Chris

1 0

Re: Debuging Wine
by Jarmo 13 Jun '03

13 Jun '03

Hi, I am trackin a weard bug and I would need a help a little. I am trying to run Orbiter in winex. Orbiter runs without problems in windows. It seems that Orbiter.exe is using a call that does not exist in wine. How can I find out the name of that call ? access to call 0x406cd420 Main_Direct3DDevice_SetTexture works fine just before this call. Code causing the crash: 0x004513c0 movl %eax,0x4c(%esp) 0x004513c4 call *0x84(%eax) this will lead 0xdead001e Relocation entries: 0x406cd010 is address of Main_Direct3DDevice_DrawIndexedPrimitiveVB 0x406cd3a0 is address of Main_Direct3DDevice_GetTexture 0x406f0910 (DDRAW.DLL): 406cd2f0 406ccae0 406ccc70 406cce60 0x406f0920 (DDRAW.DLL): 406cd010 *! dead001e !* 406cd3a0 406cd420 0x406f0930 (DDRAW.DLL): 406cd530 406cd5f0 406cd700 406cd760 Relocation entries: 0003d91c R_386_32 Main_Direct3DDevice_DrawPrimitiveVB 0003d920 R_386_32 Main_Direct3DDevice_DrawIndexedPrimitiveVB 0003d924 ? ? ? ? 0003d928 R_386_32 Main_Direct3DDevice_GetTexture 0003d92c R_386_32 Main_Direct3DDevice_SetTexture Regards, Jarmo

3 2

SoftICE for wine
by Gerhard W. Gruber 12 Jun '03

12 Jun '03

Three weeks ago I was trying to find a crash in Agent. Since I don't know the code of wine so well I tried to do this with a debugger. My experience was rather frustrating. GDB and winegdb are not exactly what I call userfriendly. On a Windows system I would have found this error within a few hours but I didn't come to terms with winedbg and gdb. So I was looking for an alternative and I found a project on sourceforge named pICE. This project was abandoned about two years ago, but I was interested in it and now I got the administration for it. pICE is a kernel debugger for linux similar to SoftICE and I thought it would be nice to have such a tool. My intention is to add extensions to support wine debugging as well (this was my primary reason) and now I would like to know if this is would be of interest to you as well and if yes (what I hope :) ) what extensions are needed in order to support wine. I guess that winedbg is similar in that respect that it is also an extension of gdb, am I right? If somebody knows the details I would like to hear it. But don't expect anything soon because I still need to dig into the code of pICE to make it stable first. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)

3 7

EXC_RtlRaiseException call to unimplemented function kernel32.dll.CreateRemoteThread
by tux＠leahcim.com 12 Jun '03

12 Jun '03

Hi, i've installed the latest cvs rpm ( wine-cvs-unstripped-20030612-1.i386.rpm ) and it seems to work with most applications. however when I try to make the ud agent run it fails with the following exception as soon as the calculation engine attempts to start: (C:\udagent\ud_1706422_0.dir\ud_ligfit_Release.exe,...): [...] fixme:seh:EXC_RtlRaiseException call to unimplemented function kernel32.dll.CreateRemoteThread fixme:msvcrt:_XcptFilter (-2147483392,0x40890a38)semi-stub wine: Unhandled exception, starting debugger... err:seh:start_debugger Couldn't start debugger ("debugger/winedbg 11 84") (2) But according to the Changelog of an older version the CreateRemoteThread thingy has been implemented: * include/winbase.h: Francois Gouget <fgouget(a)codeweavers.com> Added CreateRemoteThread. any ideas ? I'd be grateful for any suggestions. -- Stefan

3 3

Debuging Wine
by Jarmo 12 Jun '03

12 Jun '03

Hi, I am trying to have Orbiter running under winex in Linux. I have plenty of experience in programming but I haven't used much debuggers. I would have few questions. What is the difference between dll load methods "builtin" and "so" when debugging witch one should be used ? When using "so" mode this error is generated. I added "_ftol" in libmsvcrt.so and that error is no longer generated. Is that right thing to do ? When using "builtin" mode these errors won't appear. But it will crash the same way. ---------------------------------------------------------------------------------------------------- fixme:win32:ELF_FindExportedFunction function ftol not found: /usr/local/lib/libwine.so: undefined symbol: ftol err:win32:PE_fixup_imports No implementation for MSVCRT.dll.237(_ftol) imported from C:\Orbit_new\Modules\Luna.dll, setting to 0xdeadbeef fixme:win32:ELF_FindExportedFunction function ??3@YAXPAX@Z not found: /usr/local/lib/libwine.so: undefined symbol: ??3 err:win32:PE_fixup_imports No implementation for MSVCRT.dll.16(??3@YAXPAX@Z) imported from C:\Orbit_new\Modules\Luna.dll, setting to 0xdeadbeef fixme:win32:ELF_FindExportedFunction function ?terminate@@YAXXZ not found: /usr/local/lib/libwine.so: undefined symbol: ?terminate err:win32:PE_fixup_imports No implementation for MSVCRT.dll.46(?terminate@@YAXXZ) imported from C:\Orbit_new\Modules\Luna.dll, setting to 0xdeadbeef --------------------------------------------------------------------------------------------------- What are these ? No debug information in 32bit DLL 'DDRAW.DLL' (0x406c8000) *** Invalid address 0x40011f80 (_end+0x478) from msvcrt.spec: @ forward -noimport _ftol ntdll._ftol @ cdecl ?terminate@@YAXXZ() MSVCRT_terminate This is the final crash. ------------------------------------------------------------------------------------------------ First chance exception: page fault on read access to 0xdead001e in 32-bit code (0xdead001e). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:2007 GS:0007 EIP:dead001e ESP:406a287c EBP:004b3b88 EFLAGS:00210202( R- 00 I - - 1 ) EAX:406f08a0 EBX:403a62d4 ECX:433c0e10 EDX:433c0e00 ESI:403a62d4 EDI:00000000 Stack dump: 0x406a287c (MSVCRT.DLL.193+0x3f48ec): 004513ca 403a62d4 433c0e00 433c0e10 0x406a288c (MSVCRT.DLL.193+0x3f48fc): 00000001 00000000 433c0e20 406cbdf0 0x406a289c (MSVCRT.DLL.193+0x3f490c): 403a62d4 433fdbc0 406cb900 00000000 0x406a28ac (MSVCRT.DLL.193+0x3f491c): 00000000 00000000 406cb900 00000000 0x406a28bc (MSVCRT.DLL.193+0x3f492c): 00000000 433fdbc0 0047017a 00470185 0x406a28cc (MSVCRT.DLL.193+0x3f493c): 406f08a0 40738820 ff000000 406a2a28 0x406a28dc (MSVCRT.DLL.193+0x3f494c): 0400: sel=2007 base=4011b460 limit=00000000 32-bit rw- Backtrace: =>0 0xdead001e (MSVCRT.DLL._winver+0x99fe36ce) (ebp=004b3b88) 1 0x433c0de0 (MSACM32.DLL.acmStreamUnprepareHeader+0x33d190) (ebp=00000001) 0xdead001e (MSVCRT.DLL._winver+0x99fe36ce): *** Invalid address 0xdead001e (MSVCRT.DLL._winver+0x99fe36ce) -- no code -- ---------------------------------------------------------------------------------------------------- I know very little about this. It seems that processor is trying to execute code in 0xdead001e. That would indicate a missing function. If that what it is. What is the missing function ? Where it shoud be ? What is calling it ? What is "1e" in 0xdead001e I dumped MSACM32.DLL and it does not inport any MSVCRT.DLL functions. acmStreamUnprepareHeader disassembly doesn't show anything weard either. Regards, Jarmo

3 3

Re: quartz once again: was DEVENUM.DLL Implementation
by Brian Vincent (C) 12 Jun '03

12 Jun '03

> By the way, nobody ever knew *why* Hidenori asked to have his code removed. > The fact that it's due to legal issues with the code are only, as far as I > know, rumors. Not true, here's what Hidenori wrote (WWN #122): "My all MultiMedia codes are completely written from scratch. No disassembling. I believe there are no legal issues. But, I cannot warrant... I should protect myself from any potential problems now..." "The main issues for me are 1) restrictions of EULA - some codes may be based on information from non-VS6. I don't want to battle with EULA. 2) afraid to many pending patents. I cannot check all patents... and there are some other reasons I don't want to write..." "So, finally, I decided to solicite Alexandre..." http://www.winehq.com/hypermail/wine-devel/2002/05/0080.html He asked for it to be removed, I think Alexandre is right in not distributing it. I'm not sure Gav ever got permission to redistribute with WineX. The last thing I remember seeing from him was they asked for permission but hadn't received a reply. --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

1 0

DSound buffer underrun problems with X-Plane
by Christian Neumair 12 Jun '03

12 Jun '03

I'm currently testing a cool flight simulator called X-Plane. It's really working great on wine, the performance is supersonic. The only downer is that the engine sound is a bit staccato, i.e. it has small breaks. My non-debug debian wine continuously outputs: "err:dsound:DSOUND_MixOne underrun on sound buffer 0x4b4c47c8" after reporting once: "fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x4038ac70,00010021,1):stub" I'm not sure how complicated it is to resolve that but I assume for an advanced wine hacker familiar with directx (especially those currently working on it, *hint*, *hint*) it isn't very hard to fix. The problem is reproducible with the current stable version 6.71 and the brand-new 7.0 beta. You can fetch both betas under http://x-plane.com. Thanks in advance! You do a great job! regs, Chris

1 0

Re: Re: wIntegrate vs Wine
by Pouech Eric DMI AEI CAEN 12 Jun '03

12 Jun '03

> > -debugmsg +winsock yeilds a little information, but not much. i tried a > > -debugmsg +all, but that filled up my hard disc and caused X to crash. What > > can I do to help further determine the problem? > > Try a +relay trace. For something as vague as this you need to investigate > further really, there is an infinite multitude of things that could be > going wrong. you can also edit dlls/winsock/socket.c and set DEBUG_SOCK_ADDR to 1, you'll get a bit more of traces A+

1 0

wIntegrate vs Wine
by Emmanuel Goldstein 12 Jun '03

12 Jun '03

Hi All, I'm trying to run an application called wIntegrate under Linux. wIntegrate is basically a terminal emulator that translates traffic to/from a Telnet-like server into a Windows-like app, with dialog boxes and such. wIntegrate appears to use an internal, custom implementation of Winsock. That is, I cannot see it link winsock when i do -debugmsg +dll. The application starts up correctly but when I attempt to open a connection, i get a message ("connecting to xxx") and nothing more. netstat reveals the connection has been made (by wine) on wIntegrates behalf. i think that what is happening is that wIntegrate is somehow not being told that the connection has been initialised successfully. -debugmsg +winsock yeilds a little information, but not much. i tried a -debugmsg +all, but that filled up my hard disc and caused X to crash. What can I do to help further determine the problem?

2 1

Re: Re: Discovering which critical sections threads are in
by Pouech Eric DMI AEI CAEN 12 Jun '03

12 Jun '03

right, but looking inside the CRITICAL_SECTION which the thread blocked on, you can get the tid of the thread which holds the cs (OwningThread field IIRC). A+ > Message du 12/06/03 10:31 > De : Mike Hearn <mike(a)theoretic.com> > A : wine-devel(a)winehq.com > Copie à : > Objet : Re: Discovering which critical sections threads are in > On Wed, 11 Jun 2003 22:31:39 +0200, Sir Eric Pouech scribed thus: > > normally there's a message printed out when a critsect times out like: > > section 0x12345678 myCS wait timed out, retrying (60 sec) tid=xxxx > > and the tid gives you the thread id of the thread holding the cs > > then, you can use it for example in 'bt <tid>' to get a backtrace of > > that particular thread and look at what it's doing > > Yup, sure, I know how to do that. But the backtrace tells you which thread > blocked, and where it was when it blocked. It doesn't tell you which > thread is already inside it (so you can go find out why it never left). > > In the end yesterday I just stuck some trace statements in and used emacs > to process the resulting huge file :) i feel there should be a better way > though.... maybe having a linked list of RTL_CRITICAL_SECTION structs that > the debugger can walk. > > >

1 0

Discovering which critical sections threads are in
by Mike Hearn 12 Jun '03

12 Jun '03

Hi all, I'm trying to debug a deadlock I get when trying to open the print dialog in Internet Explorer, the backtrace I get looks like this: =>0 0x420cdb44 (NTDLL.DLL.memcpy+0x516f4) (ebp=435f0c54) 1 0x400b8d2f (NTDLL.DLL.NtWaitForMultipleObjects+0x133 in libntdll.dll.so) (ebp=435f0cf0) 2 0x400b7557 (usr1_handler+0x3b(__signal=0xa, __context=0x4f) [signal_i386.c:1132] in libntdll.dll.so) (ebp=435f0d1c) 3 0x42028c48 (NTDLL.DLL.toupper+0x6748) (ebp=437126e8) 4 0x400b8d2f (NTDLL.DLL.NtWaitForMultipleObjects+0x133 in libntdll.dll.so) (ebp=43712784) 5 0x400b8d59 (NtWaitForSingleObject+0x25(handle=0x260, alertable=0x0, timeout=0x437127c0) [sync.c:594] in libntdll.dll.so) (ebp=437127a4) 6 0x400a6e53 (RtlpWaitForCriticalSection+0xdb(crit=0x70460350) [critsection.c:162] in libntdll.dll.so) (ebp=43712828) 7 0x400a7020 (RtlEnterCriticalSection+0x34(crit=0x70460350) [critsection.c:1920] in libntdll.dll.so) (ebp=4371283c) 8 0x70457e56 (MLANG.DLL.ConvertINetString+0x4f85 in C:\WINDOWS\SYSTEM\MLANG.DLL) (ebp=4371286c) 9 0x70eaf851 (MSHTML.DLL.com_ms_osp_ospmrshl_releaseByValExternal+0x82912 in C:\WINDOWS\SYSTEM\MSHTML.DLL) (ebp=43712990) 10 0x70e60c0f (MSHTML.DLL.com_ms_osp_ospmrshl_releaseByValExternal+0x33cd0 in C:\WINDOWS\SYSTEM\MSHTML.DLL) (ebp=43712a2c) 11 0x70d94e1c (MSHTML.DLL.EntryPoint+0xbd49 in C:\WINDOWS\SYSTEM\MSHTML.DLL) (ebp=43712a4c) 12 0x70cbe59f (MSHTML.DLL..text+0x6d59f in C:\WINDOWS\SYSTEM\MSHTML.DLL) (ebp=43712a6c) 13 0x70d570e3 (MSHTML.DLL.DllGetClassObject+0x17b2f in C:\WINDOWS\SYSTEM\MSHTML.DLL) (ebp=43712ce4) 14 0x70d3bff7 (MSHTML.DLL.DllCanUnloadNow+0x28c44 in C:\WINDOWS\SYSTEM\MSHTML.DLL) (ebp=43712d50) 15 0x70e2621d (MSHTML.DLL.CreateHTMLPropertyPage+0x41f87 in C:\WINDOWS\SYSTEM\MSHTML.DLL) (ebp=43712d8c) 16 0xffffffff (OLE32.DLL..reloc+0x80018fff) (ebp=00000000) The null ebp at the top is kind of odd, I think this stack might be the result of a demarshalled RPC call. But anyway. As you can see it's blocking on a critical section, but I don't know how to find out which thread has got suck inside it. I tried putting trace statements in Rtl(Enter/Leave)CriticalSection, oops, not a good idea, waaaay too much spew there to be useful. So, what I'd like to know is whether there is any way to find out which thread has entered that critical section. Also, is this even a good idea, or is there a better way to debug thread deadlocks? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

3 2

PATCH - More comdlg32 win16/32 splitting
by Steven Edwards 11 Jun '03

11 Jun '03

Hello, More work on splitting the Win16/32 support. There are a few problems I have thought about that will need to be addressed after we are done. In some places we might still be including headers we dont need. I will fix this later as one of my goals once all of this code is split is to be able to build these dlls with either WINE, MS_VC or Mingw headers. Also if there is a comdlg32 guru still lurking on the list I am going to need your help soon with the printer dialog support. Thanks Steven Changelog: Split Win16/32 color dialog support Supporting compiling out 16 bit find dialog support Index: Makefile.in =================================================================== RCS file: /home/wine/wine/dlls/commdlg/Makefile.in,v retrieving revision 1.29 diff -u -r1.29 Makefile.in --- Makefile.in 7 Jun 2003 00:33:32 -0000 1.29 +++ Makefile.in 11 Jun 2003 21:43:47 -0000 @@ -18,7 +18,6 @@ filedlg.c \ filedlg95.c \ filedlgbrowser.c \ - finddlg.c \ finddlg32.c \ filetitle.c \ fontdlg.c \ @@ -26,7 +25,9 @@ printdlg.c C_SRCS16 = \ + colordlg16.c \ fontdlg16.c \ + finddlg.c RC_SRCS= rsrc.rc Index: colordlg.c =================================================================== RCS file: /home/wine/wine/dlls/commdlg/colordlg.c,v retrieving revision 1.40 diff -u -r1.40 colordlg.c --- colordlg.c 29 Apr 2003 22:52:02 -0000 1.40 +++ colordlg.c 11 Jun 2003 21:44:16 -0000 @@ -40,6 +40,7 @@ WINE_DEFAULT_DEBUG_CHANNEL(commdlg); #include "cdlg.h" +#include "colordlg.h" static INT_PTR CALLBACK ColorDlgProc( HWND hWnd, UINT wMsg, WPARAM wParam, LPARAM lParam ); @@ -63,28 +64,6 @@ 0x00808040L, 0x00C0C0C0L, 0x00400040L, 0x00FFFFFFL }, }; -struct CCPRIVATE -{ - LPCHOOSECOLORW lpcc; /* points to public known data structure */ - LPCHOOSECOLOR16 lpcc16; /* save the 16 bits pointer */ - int nextuserdef; /* next free place in user defined color array */ - HDC hdcMem; /* color graph used for BitBlt() */ - HBITMAP hbmMem; /* color graph bitmap */ - RECT fullsize; /* original dialog window size */ - UINT msetrgb; /* # of SETRGBSTRING message (today not used) */ - RECT old3angle; /* last position of l-marker */ - RECT oldcross; /* last position of color/satuation marker */ - BOOL updating; /* to prevent recursive WM_COMMAND/EN_UPDATE processing */ - int h; - int s; - int l; /* for temporary storing of hue,sat,lum */ - int capturedGraph; /* control mouse captured */ - RECT focusRect; /* rectangle last focused item */ - HWND hwndFocus; /* handle last focused item */ -}; - -#define LCCPRIV struct CCPRIVATE * - /*********************************************************************** * CC_HSLtoRGB [internal] */ @@ -355,7 +334,7 @@ * CC_MouseCheckResultWindow [internal] * test if double click one of the result colors */ -static int CC_MouseCheckResultWindow( HWND hDlg, LPARAM lParam ) +int CC_MouseCheckResultWindow( HWND hDlg, LPARAM lParam ) { HWND hwnd; POINT point; @@ -808,7 +787,7 @@ /*********************************************************************** * CC_HookCallChk [internal] */ -static BOOL CC_HookCallChk( LPCHOOSECOLORW lpcc ) +BOOL CC_HookCallChk( LPCHOOSECOLORW lpcc ) { if (lpcc) if(lpcc->Flags & CC_ENABLEHOOK) @@ -817,11 +796,10 @@ return FALSE; } - /*********************************************************************** * CC_WMInitDialog [internal] */ -static LONG CC_WMInitDialog( HWND hDlg, WPARAM wParam, LPARAM lParam, BOOL b16 ) +LONG CC_WMInitDialog( HWND hDlg, WPARAM wParam, LPARAM lParam, BOOL b16 ) { int i, res; int r, g, b; @@ -952,7 +930,7 @@ /*********************************************************************** * CC_WMCommand [internal] */ -static LRESULT CC_WMCommand( HWND hDlg, WPARAM wParam, LPARAM lParam, WORD notifyCode, HWND hwndCtl ) +LRESULT CC_WMCommand( HWND hDlg, WPARAM wParam, LPARAM lParam, WORD notifyCode, HWND hwndCtl ) { int r, g, b, i, xx; UINT cokmsg; @@ -1104,7 +1082,7 @@ /*********************************************************************** * CC_WMPaint [internal] */ -static LRESULT CC_WMPaint( HWND hDlg, WPARAM wParam, LPARAM lParam ) +LRESULT CC_WMPaint( HWND hDlg, WPARAM wParam, LPARAM lParam ) { HDC hdc; PAINTSTRUCT ps; @@ -1124,11 +1102,10 @@ return TRUE; } - /*********************************************************************** * CC_WMLButtonUp [internal] */ -static LRESULT CC_WMLButtonUp( HWND hDlg, WPARAM wParam, LPARAM lParam ) +LRESULT CC_WMLButtonUp( HWND hDlg, WPARAM wParam, LPARAM lParam ) { LCCPRIV lpp = (LCCPRIV)GetWindowLongA(hDlg, DWL_USER); if (lpp->capturedGraph) @@ -1141,11 +1118,10 @@ return 0; } - /*********************************************************************** * CC_WMMouseMove [internal] */ -static LRESULT CC_WMMouseMove( HWND hDlg, LPARAM lParam ) +LRESULT CC_WMMouseMove( HWND hDlg, LPARAM lParam ) { LCCPRIV lpp = (LCCPRIV)GetWindowLongA(hDlg, DWL_USER); int r, g, b; @@ -1179,10 +1155,11 @@ } return 0; } + /*********************************************************************** * CC_WMLButtonDown [internal] */ -static LRESULT CC_WMLButtonDown( HWND hDlg, WPARAM wParam, LPARAM lParam ) +LRESULT CC_WMLButtonDown( HWND hDlg, WPARAM wParam, LPARAM lParam ) { LCCPRIV lpp = (LCCPRIV)GetWindowLongA(hDlg, DWL_USER); int r, g, b, i; @@ -1234,7 +1211,6 @@ return FALSE; } - /*********************************************************************** * ColorDlgProc32 [internal] * @@ -1297,158 +1273,6 @@ break; } return FALSE ; -} - -/*********************************************************************** - * ColorDlgProc (COMMDLG.8) - */ -BOOL16 CALLBACK ColorDlgProc16( HWND16 hDlg16, UINT16 message, - WPARAM16 wParam, LONG lParam ) -{ - BOOL16 res; - HWND hDlg = HWND_32(hDlg16); - - LCCPRIV lpp = (LCCPRIV)GetWindowLongA(hDlg, DWL_USER); - if (message != WM_INITDIALOG) - { - if (!lpp) - return FALSE; - res=0; - if (CC_HookCallChk(lpp->lpcc)) - res = CallWindowProc16( (WNDPROC16)lpp->lpcc16->lpfnHook, hDlg16, message, wParam, lParam); - if (res) - return res; - } - - /* FIXME: SetRGB message - if (message && message == msetrgb) - return HandleSetRGB(hDlg, lParam); - */ - - switch (message) - { - case WM_INITDIALOG: - return CC_WMInitDialog(hDlg, wParam, lParam, TRUE); - case WM_NCDESTROY: - DeleteDC(lpp->hdcMem); - DeleteObject(lpp->hbmMem); - HeapFree(GetProcessHeap(), 0, lpp->lpcc); - HeapFree(GetProcessHeap(), 0, lpp); - SetWindowLongA(hDlg, DWL_USER, 0L); /* we don't need it anymore */ - break; - case WM_COMMAND: - if (CC_WMCommand(hDlg, wParam, lParam, - HIWORD(lParam), HWND_32(LOWORD(lParam)))) - return TRUE; - break; - case WM_PAINT: - if (CC_WMPaint(hDlg, wParam, lParam)) - return TRUE; - break; - case WM_LBUTTONDBLCLK: - if (CC_MouseCheckResultWindow(hDlg,lParam)) - return TRUE; - break; - case WM_MOUSEMOVE: - if (CC_WMMouseMove(hDlg, lParam)) - return TRUE; - break; - case WM_LBUTTONUP: /* FIXME: ClipCursor off (if in color graph)*/ - if (CC_WMLButtonUp(hDlg, wParam, lParam)) - return TRUE; - break; - case WM_LBUTTONDOWN:/* FIXME: ClipCursor on (if in color graph)*/ - if (CC_WMLButtonDown(hDlg, wParam, lParam)) - return TRUE; - break; - } - return FALSE ; -} - - - -/*********************************************************************** - * ChooseColor (COMMDLG.5) - */ -BOOL16 WINAPI ChooseColor16( LPCHOOSECOLOR16 lpChCol ) -{ - HINSTANCE16 hInst; - HANDLE16 hDlgTmpl16 = 0, hResource16 = 0; - HGLOBAL16 hGlobal16 = 0; - BOOL16 bRet = FALSE; - LPCVOID template; - FARPROC16 ptr; - - TRACE("ChooseColor\n"); - if (!lpChCol) return FALSE; - - if (lpChCol->Flags & CC_ENABLETEMPLATEHANDLE) - hDlgTmpl16 = lpChCol->hInstance; - else if (lpChCol->Flags & CC_ENABLETEMPLATE) - { - HANDLE16 hResInfo; - if (!(hResInfo = FindResource16(lpChCol->hInstance, - MapSL(lpChCol->lpTemplateName), - RT_DIALOGA))) - { - COMDLG32_SetCommDlgExtendedError(CDERR_FINDRESFAILURE); - return FALSE; - } - if (!(hDlgTmpl16 = LoadResource16(lpChCol->hInstance, hResInfo))) - { - COMDLG32_SetCommDlgExtendedError(CDERR_LOADRESFAILURE); - return FALSE; - } - hResource16 = hDlgTmpl16; - } - else - { - HRSRC hResInfo; - HGLOBAL hDlgTmpl32; - LPCVOID template32; - DWORD size; - if (!(hResInfo = FindResourceA(COMDLG32_hInstance, "CHOOSE_COLOR", RT_DIALOGA))) - { - COMDLG32_SetCommDlgExtendedError(CDERR_FINDRESFAILURE); - return FALSE; - } - if (!(hDlgTmpl32 = LoadResource(COMDLG32_hInstance, hResInfo)) || - !(template32 = LockResource(hDlgTmpl32))) - { - COMDLG32_SetCommDlgExtendedError(CDERR_LOADRESFAILURE); - return FALSE; - } - size = SizeofResource(GetModuleHandleA("COMDLG32"), hResInfo); - hGlobal16 = GlobalAlloc16(0, size); - if (!hGlobal16) - { - COMDLG32_SetCommDlgExtendedError(CDERR_MEMALLOCFAILURE); - ERR("alloc failure for %ld bytes\n", size); - return FALSE; - } - template = GlobalLock16(hGlobal16); - if (!template) - { - COMDLG32_SetCommDlgExtendedError(CDERR_MEMLOCKFAILURE); - ERR("global lock failure for %x handle\n", hDlgTmpl16); - GlobalFree16(hGlobal16); - return FALSE; - } - ConvertDialog32To16((LPVOID)template32, size, (LPVOID)template); - hDlgTmpl16 = hGlobal16; - } - - ptr = GetProcAddress16(GetModuleHandle16("COMMDLG"), (LPCSTR) 8); - hInst = GetWindowLongA(HWND_32(lpChCol->hwndOwner), GWL_HINSTANCE); - bRet = DialogBoxIndirectParam16(hInst, hDlgTmpl16, lpChCol->hwndOwner, - (DLGPROC16) ptr, (DWORD)lpChCol); - if (hResource16) FreeResource16(hDlgTmpl16); - if (hGlobal16) - { - GlobalUnlock16(hGlobal16); - GlobalFree16(hGlobal16); - } - return bRet; } /*********************************************************************** --- /dev/null Wed Jun 11 17:47:59 2003 +++ colordlg16.c Tue Jun 10 19:44:40 2003 @@ -0,0 +1,195 @@ +/* + * COMMDLG - Color Dialog + * + * Copyright 1994 Martin Ayotte + * Copyright 1996 Albrecht Kleine + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +/* BUGS : still seems to not refresh correctly + sometimes, especially when 2 instances of the + dialog are loaded at the same time */ + +#include <ctype.h> +#include <stdlib.h> +#include <stdio.h> +#include <string.h> +#include "windef.h" +#include "winbase.h" +#include "wingdi.h" +#include "wine/winbase16.h" +#include "wine/winuser16.h" +#include "commdlg.h" +#include "dlgs.h" +#include "wine/debug.h" +#include "cderr.h" + +WINE_DEFAULT_DEBUG_CHANNEL(commdlg); + +#include "cdlg.h" +#include "colordlg.h" + +/*********************************************************************** + * ColorDlgProc (COMMDLG.8) + */ +BOOL16 CALLBACK ColorDlgProc16( HWND16 hDlg16, UINT16 message, + WPARAM16 wParam, LONG lParam ) +{ + BOOL16 res; + HWND hDlg = HWND_32(hDlg16); + + LCCPRIV lpp = (LCCPRIV)GetWindowLongA(hDlg, DWL_USER); + if (message != WM_INITDIALOG) + { + if (!lpp) + return FALSE; + res=0; + if (CC_HookCallChk(lpp->lpcc)) + res = CallWindowProc16( (WNDPROC16)lpp->lpcc16->lpfnHook, hDlg16, message, wParam, lParam); + if (res) + return res; + } + + /* FIXME: SetRGB message + if (message && message == msetrgb) + return HandleSetRGB(hDlg, lParam); + */ + + switch (message) + { + case WM_INITDIALOG: + return CC_WMInitDialog(hDlg, wParam, lParam, TRUE); + case WM_NCDESTROY: + DeleteDC(lpp->hdcMem); + DeleteObject(lpp->hbmMem); + HeapFree(GetProcessHeap(), 0, lpp->lpcc); + HeapFree(GetProcessHeap(), 0, lpp); + SetWindowLongA(hDlg, DWL_USER, 0L); /* we don't need it anymore */ + break; + case WM_COMMAND: + if (CC_WMCommand(hDlg, wParam, lParam, + HIWORD(lParam), HWND_32(LOWORD(lParam)))) + return TRUE; + break; + case WM_PAINT: + if (CC_WMPaint(hDlg, wParam, lParam)) + return TRUE; + break; + case WM_LBUTTONDBLCLK: + if (CC_MouseCheckResultWindow(hDlg,lParam)) + return TRUE; + break; + case WM_MOUSEMOVE: + if (CC_WMMouseMove(hDlg, lParam)) + return TRUE; + break; + case WM_LBUTTONUP: /* FIXME: ClipCursor off (if in color graph)*/ + if (CC_WMLButtonUp(hDlg, wParam, lParam)) + return TRUE; + break; + case WM_LBUTTONDOWN:/* FIXME: ClipCursor on (if in color graph)*/ + if (CC_WMLButtonDown(hDlg, wParam, lParam)) + return TRUE; + break; + } + return FALSE ; +} + + + +/*********************************************************************** + * ChooseColor (COMMDLG.5) + */ +BOOL16 WINAPI ChooseColor16( LPCHOOSECOLOR16 lpChCol ) +{ + HINSTANCE16 hInst; + HANDLE16 hDlgTmpl16 = 0, hResource16 = 0; + HGLOBAL16 hGlobal16 = 0; + BOOL16 bRet = FALSE; + LPCVOID template; + FARPROC16 ptr; + + TRACE("ChooseColor\n"); + if (!lpChCol) return FALSE; + + if (lpChCol->Flags & CC_ENABLETEMPLATEHANDLE) + hDlgTmpl16 = lpChCol->hInstance; + else if (lpChCol->Flags & CC_ENABLETEMPLATE) + { + HANDLE16 hResInfo; + if (!(hResInfo = FindResource16(lpChCol->hInstance, + MapSL(lpChCol->lpTemplateName), + RT_DIALOGA))) + { + COMDLG32_SetCommDlgExtendedError(CDERR_FINDRESFAILURE); + return FALSE; + } + if (!(hDlgTmpl16 = LoadResource16(lpChCol->hInstance, hResInfo))) + { + COMDLG32_SetCommDlgExtendedError(CDERR_LOADRESFAILURE); + return FALSE; + } + hResource16 = hDlgTmpl16; + } + else + { + HRSRC hResInfo; + HGLOBAL hDlgTmpl32; + LPCVOID template32; + DWORD size; + if (!(hResInfo = FindResourceA(COMDLG32_hInstance, "CHOOSE_COLOR", RT_DIALOGA))) + { + COMDLG32_SetCommDlgExtendedError(CDERR_FINDRESFAILURE); + return FALSE; + } + if (!(hDlgTmpl32 = LoadResource(COMDLG32_hInstance, hResInfo)) || + !(template32 = LockResource(hDlgTmpl32))) + { + COMDLG32_SetCommDlgExtendedError(CDERR_LOADRESFAILURE); + return FALSE; + } + size = SizeofResource(GetModuleHandleA("COMDLG32"), hResInfo); + hGlobal16 = GlobalAlloc16(0, size); + if (!hGlobal16) + { + COMDLG32_SetCommDlgExtendedError(CDERR_MEMALLOCFAILURE); + ERR("alloc failure for %ld bytes\n", size); + return FALSE; + } + template = GlobalLock16(hGlobal16); + if (!template) + { + COMDLG32_SetCommDlgExtendedError(CDERR_MEMLOCKFAILURE); + ERR("global lock failure for %x handle\n", hDlgTmpl16); + GlobalFree16(hGlobal16); + return FALSE; + } + ConvertDialog32To16((LPVOID)template32, size, (LPVOID)template); + hDlgTmpl16 = hGlobal16; + } + + ptr = GetProcAddress16(GetModuleHandle16("COMMDLG"), (LPCSTR) 8); + hInst = GetWindowLongA(HWND_32(lpChCol->hwndOwner), GWL_HINSTANCE); + bRet = DialogBoxIndirectParam16(hInst, hDlgTmpl16, lpChCol->hwndOwner, + (DLGPROC16) ptr, (DWORD)lpChCol); + if (hResource16) FreeResource16(hDlgTmpl16); + if (hGlobal16) + { + GlobalUnlock16(hGlobal16); + GlobalFree16(hGlobal16); + } + return bRet; +} --- /dev/null Wed Jun 11 17:49:48 2003 +++ colordlg.h Wed Jun 11 17:49:44 2003 @@ -0,0 +1,82 @@ +/* + * COMMDLG - Color Dialog + * + * Copyright 1994 Martin Ayotte + * Copyright 1996 Albrecht Kleine + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +/* BUGS : still seems to not refresh correctly + sometimes, especially when 2 instances of the + dialog are loaded at the same time */ + +#ifndef _WINE_COLORDLG_H +#define _WINE_COLORDLG_H + +#include <ctype.h> +#include <stdlib.h> +#include <stdio.h> +#include <string.h> +#include "windef.h" +#include "winbase.h" +#include "wingdi.h" +#include "wine/winbase16.h" +#include "wine/winuser16.h" +#include "commdlg.h" +#include "dlgs.h" +#include "wine/debug.h" +#include "cderr.h" + +#include "cdlg.h" + +struct CCPRIVATE +{ + LPCHOOSECOLORW lpcc; /* points to public known data structure */ + LPCHOOSECOLOR16 lpcc16; /* save the 16 bits pointer */ + int nextuserdef; /* next free place in user defined color array */ + HDC hdcMem; /* color graph used for BitBlt() */ + HBITMAP hbmMem; /* color graph bitmap */ + RECT fullsize; /* original dialog window size */ + UINT msetrgb; /* # of SETRGBSTRING message (today not used) */ + RECT old3angle; /* last position of l-marker */ + RECT oldcross; /* last position of color/satuation marker */ + BOOL updating; /* to prevent recursive WM_COMMAND/EN_UPDATE processing */ + int h; + int s; + int l; /* for temporary storing of hue,sat,lum */ + int capturedGraph; /* control mouse captured */ + RECT focusRect; /* rectangle last focused item */ + HWND hwndFocus; /* handle last focused item */ +}; + +#define LCCPRIV struct CCPRIVATE * + +/* + * Internal Functions + * Do NOT Export to other programs and dlls + */ + +BOOL CC_HookCallChk( LPCHOOSECOLORW lpcc ); +int CC_MouseCheckResultWindow( HWND hDlg, LPARAM lParam ); +LONG CC_WMInitDialog( HWND hDlg, WPARAM wParam, LPARAM lParam, BOOL b16 ); +LRESULT CC_WMLButtonDown( HWND hDlg, WPARAM wParam, LPARAM lParam ); +LRESULT CC_WMLButtonUp( HWND hDlg, WPARAM wParam, LPARAM lParam ); +LRESULT CC_WMCommand( HWND hDlg, WPARAM wParam, LPARAM lParam, WORD + notifyCode, HWND hwndCtl ); +LRESULT CC_WMMouseMove( HWND hDlg, LPARAM lParam ); +LRESULT CC_WMPaint( HWND hDlg, WPARAM wParam, LPARAM lParam ); + +#endif /* _WINE_COLORDLG_H */

1 0

Re: Resend - Split Ole Win16/32
by Gregory M. Turner 11 Jun '03

11 Jun '03

On Sunday 08 June 2003 08:10 pm, Steven Edwards wrote: > I didnt want this one to get lost in the vacation =) > > Thanks > Steven > > Changelog: Separate Win16 and Win32 support in Ole32 since you seem to have a handle on the 16/32 BS, Steven, maybe you or some other kind observer can help me out with my cabinet.dll work. Apparently, cabinet.dll supports the same API as 16-bit and 32-bit interfaces... I was wondering, do you know what, if anything, I need to do to support the 16-bit versions of these API's in dlls/cabinet? I would just ignore the issue, but since installers (the primary consumers of cabinet.dll, of course), even for 32-bit proggies, seem to be 16 bit sometimes, I guess the issue may crop up from time to time for some unlucky souls... -- "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw gmt

2 1

Re: Broken links on WineHQ
by Brian Vincent (C) 11 Jun '03

11 Jun '03

> I'm wondering what to do about the WWN vs. Wine Kernel Cousin anchor > issue. It would be nice if they had the same anchor naming scheme... > > http://www.winehq.com/index.php?issue=173#WinINet%20Work > corresponds to > http://kt.zork.net/wine/wn20030606_173.html#3 I've stopped using Zack's <kcref> tag, you'll find that in quite a few issues. Lately I've been hardcoding WineHQ URL's as normal <a href=""> links. So when I refer to a back issue I'll just link to it on www.winehq.com. --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

1 0

Broken links on WineHQ
by tom wickline 11 Jun '03

11 Jun '03

And I was down to olny 164 :) I am spending a couple days with my sister at this time but as soon as I get home I will run the script and start looking at links to fix :) >Do we have a volunteer for running the script from time to time? Sure I can do this. And *try* to fix what I can... Trust me im not shy to ask for help :) What shall my new post be called Link Maintainer :) ? There is also one other problem.. And this one is much harder to fix. Here is my example http://www.winehq.com/?page=download RpmFind Look at : http://rpmfind.net/linux/rpm2html/search.php?query=Wine&submit=Search+... now look at : http://rpmseek.com/rpm-pl/wine.html?hl=com&cs=wine:PN:0:0:0 The rpmfind link is good but *I* think the rpmseek link is much better. This is just one example and there are a couple more as well but the main thing is to get as many of these fixed as possible :) Thanks again for the script.. Tom --------------------------------- Do you Yahoo!? Free online calendar with sync to Outlook(TM).

2 1

SMP Problems?
by OverrideX 11 Jun '03

11 Jun '03

Hi guys, I've been playing System Shock 2 in wine for the past couple of weeks, ever since Lionel Ulmer's surface locking patch that got it working - the other day I installed a second cpu in this box, and wine is freezing up playing ss2, if I disable SMP in the kernel, all is fine - it's not a hard lockup, I can simply killall wine.bin and wine exits with a successful status. I've noticed now that playing with SMP disabled, there are small pauses every so often, which seem to be the wine freezes instead of just pauses when SMP is enabled. The console output looks like this: err:dsound:DSOUND_MixOne underrun on sound buffer 0x40437f48 err:ntdll:RtlpWaitForCriticalSection section 0x77e340 "?" wait timed out, retrying (60 sec) tid=0009 err:ntdll:RtlpWaitForCriticalSection section 0x77e340 "?" wait timed out, retrying (60 sec) tid=000c Wine exited with a successful status I'm pretty sure it only happens at the same time a sound's about to play, but I can't be sure. Any suggestions would be appreciated - if anyone wants anymore info please let me know and I'll be happy to provide it, cc me any replies if you can -Dan -- OverrideX <overridex(a)punkass.com> GPG Key Fingerprint = 4AD5 CE9C D7C8 0069 BDD3 7F72 3AB2 642A 5A5D EB89 In spite of everything, I still believe that people are good at heart. -- Ann Frank

3 5

Fwd: [Wine-d3d] d3d8 todo: updated
by Raphaël Junqueira 10 Jun '03

10 Jun '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, only a little "reminder" of what is done, and what we need. I sugest having a global todo for all directx (dinput,dplay,dsound,dmusic,ddraw,d3d[1..9],dshow/quartz) ;) DONE (since last TODO list) ======================= o Performance o Get more of the SDK samples to work with it o Try to get a game working with it: War3, MaxPayne, UT2003, mafia, GTA3, ... o Checking for opengl extenstions before using certain functions o Use max values from opengl rather than hardcoded values o Buffer support (GetFrontBuffer, GetBackBuffer) o TexturePalettes (not really tested as i don't have gta3) o Gamma Ramp o MultiplyTransform o Mipmap support o Dirty Areas o CubeMap support o Raster states o Better debug/cleaner debug channels NEED MORE WORK: ==================== - - -- Device interface: -- o CreateRenderTarger / GetRenderTarget support (Optimisation, MemoryManager) o CreateAdditionalSwapChain/Swap Chains (Optimisation, MemoryManager) o Get/CreateDepthStencilSurface (Optimisation, MemoryManager) o Pixel and Vertex shaders support: - merge of the hw support patch in my shader tree - support of pixel shader - ps2.0 - vs3.0 o Tex Op: really use of caps - - -- Surfaces/Textures interfaces -- o Better Textures management: - unlock always reload all surface (really slow for cube maps used after a Render to surface) - see if when a texture is used as render surfaces the apps must use SetTexture after that for using it (and this way restoring the new texture to cg mem) o CopyRect: - dont lock/Unlock when not really needed - use glTexSubImage2d for optimisation when possible o Lock/Unlock: - only restore or copy when needed (exemple no save renders when WRITE_ONLY flags was used) o Preload function for textures - - -- DirectX interface: -- o Better Caps code (must be detected at DirectX8 init, only once) o Check* functions o Window sizes / fullscreen support is awful - its a real hack at the moment TODO ====== o More Performance (many users complains about that) o Get the last SDK samples (principally blending and bump) to work o D3D9 support (easy but need a lot of d3d8 cleanup/ and the d3dcore split) o A Memory Manager singleton who manage allocation and life cycle of cg object (vertex buffers, surfaces, textures, ... as directx have) better for performances and easy management of cg memory Missing Functionalities: =================== - - -- General -- o Private Data (Get/Set) support o Priority Levels (Should be reasonably easy as opengl has this functionality) o LOD support - - -- Device interface -- o nPatchs (Rect,Tri) o GetInfo (need a Better Caps code) o Reset (need Memory Manager) o ResrceMgrDiscard (need Memory Manager) o Cursor functions (already begin but almost a stub) o UpdateTexture (already begin but almost a stub) o TestCoop support o ValidateDevice (need a Better Caps code) Regards, Raphael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+5mrFp7NA3AmQTU4RAnRTAJ9MK4/d9Srq8LxyP4EkcHG4da3fOwCbBzvN iwq1mdYKjyq0UB6uBj72Fl4= =SnhY -----END PGP SIGNATURE-----

1 0

Broken links on WineHQ
by Francois Gouget 10 Jun '03

10 Jun '03

Hi, I see that Tom has been fixing broken links lately. So I have industrialized the process a bit: I have run linklint on WineHQ.com and it found 164 dead links. I wrote a wrapper script around linklint, it's mostly syntactic sugar but I find the linklint options to be pretty unintuitive so the script will allow me to re-check the site later. Even better, I have included the script below so anyone can run it and check WineHQ for dead links. Do we have a volunteer for running the script from time to time? Note: the script directs linklint to check at most one page per second so as to limit the impact on the site. I have also uploaded the result files to my web site so everyone can check them out and start sending patches without running the script and hammering WineHQ. The most interesting pages are: * http://fgouget.free.fr/wine/linklint/errorF.html Lists broken internal links with the pages they occur in. I.e. it will tell you page http://www.winehq.com/foo points to http://www.winehq.com/bar and bar does not exist. We have 4 of these. * http://fgouget.free.fr/wine/linklint/errorAX.html Lists missing anchors in our pages. I.e. it will tell you page http://www.winehq.com/foo points to http://www.winehq.com/bar#Here but there is not 'Here' anchor in the bar page. We have 57 of these. * http://fgouget.free.fr/wine/linklint/urlfailF.html Lists broken external links. I.e. it will tell you page http://www.winehq.com/foo points to sites like http://dcerpc.net/ but the host name does not resolve or the URL is 404, etc. We have 154 of these. * http://fgouget.free.fr/wine/index.html Index to the internal links reports. * http://fgouget.free.fr/wine/urlindex.html Index to the external links reports. Dimitrie. Quite a few errors are caused by www.dssd.ca resolution problems. I remember you saying that there was some trouble with it. What's the status? Another common source of errors is that the WWN articles don't use numbers as the article index, unlike the Wine Kernel Cousin articles. That probably causes some confusion. --- #!/bin/sh host="www.winehq.com" seeds="-ignore /hypermail/@ -ignore /pipermail/@ /@" mode="all" local_options="-htmlonly -redirect" remote_options="-htmlonly" report_dir="linklint" while [ $# -gt 0 ] do if [ "$1" = "--host" ] then host="$2" shift 2 elif [ "$1" = "--local" ] then mode="local" shift elif [ "$1" = "--remote" ] then mode="remote" shift elif [ "$1" = "--all" ] then mode="all" shift elif [ "$1" = "--retry" ] then remote_options="$remote_options -retry" shift else echo "Usage: check [--host hostname] [--local|--remote|--all] [--retry]" >&2 exit 2 fi done if [ "$mode" != "remote" ] then time linklint -doc $report_dir $local_options -http -host $host $seeds fi if [ "$mode" != "local" ] then time linklint -doc $report_dir -cache $report_dir $remote_options -netmod -docbase http://$host @@ fi --- -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.

1 1

Re: Typo fixes
by Jeremy Newman 10 Jun '03

10 Jun '03

Francois, hmmmm, I don't know why, but this patch did not go. This is what I got. [jnewman@jnewman lostwages]$ patch -p0 < typos.diff patching file wwn/wn19990718_4.xml Hunk #1 FAILED at 977. Hunk #2 FAILED at 996. 2 out of 2 hunks FAILED -- saving rejects to file wwn/wn19990718_4.xml.rej patching file wwn/wn20010611_97.xml Hunk #1 FAILED at 373. 1 out of 1 hunk FAILED -- saving rejects to file wwn/wn20010611_97.xml.rej patching file wwn/wn20020213_115.xml Hunk #1 FAILED at 623. 1 out of 1 hunk FAILED -- saving rejects to file wwn/wn20020213_115.xml.rej patching file wwn/wn20020807_131.xml Hunk #1 FAILED at 361. 1 out of 1 hunk FAILED -- saving rejects to file wwn/wn20020807_131.xml.rej patching file wwn/wn20021025_141.xml Hunk #1 FAILED at 553. 1 out of 1 hunk FAILED -- saving rejects to file wwn/wn20021025_141.xml.rej patching file wwn/wn20021122_145.xml Hunk #1 FAILED at 598. 1 out of 1 hunk FAILED -- saving rejects to file wwn/wn20021122_145.xml.rej patching file wwn/wn20030516_170.xml Hunk #1 FAILED at 404. Hunk #2 FAILED at 414. 2 out of 2 hunks FAILED -- saving rejects to file wwn/wn20030516_170.xml.rej patching file wwn/wn20030523_171.xml Hunk #1 FAILED at 274. Hunk #2 FAILED at 400. 2 out of 2 hunks FAILED -- saving rejects to file wwn/wn20030523_171.xml.rej On Mon, 2003-06-09 at 16:28, Francois Gouget wrote: > Apparently some typo fixes were not applied the first time around. So > here's the second round. It can be applied by doing: > > cd lostwages > patch -p0 </path/to/email.txt > > > Changelog: > Fix common typos in the web site. > > > Index: wwn/wn19990718_4.xml > =================================================================== > RCS file: /home/wine/lostwages/wwn/wn19990718_4.xml,v > retrieving revision 1.1.1.1 > diff -u -r1.1.1.1 wn19990718_4.xml > --- wwn/wn19990718_4.xml 2 Dec 2002 17:08:24 -0000 1.1.1.1 > +++ wwn/wn19990718_4.xml 9 Jun 2003 20:40:39 -0000 > @@ -977,13 +977,13 @@ > > > At present, it is possible to run multiple Win32 apps by starting > -seperate Wine processes manually at the command line, which would then > -start seperate Wine server processes along with the app. These processes > +separate Wine processes manually at the command line, which would then > +start separate Wine server processes along with the app. These processes > cannot communicate amongst each other using standard Win32 IPC APIs, > may have problems due to unserialized access to registry files, etc. > Some of this may be solvable by having a shared Wine server process. > Extending the Wine server model in this way is not what people are > -discussing as seperate address spaces though, right? > +discussing as separate address spaces though, right? > > > > @@ -996,14 +996,14 @@ > > > The problem with the shared address space model is that it does not > -provide the memory protection that would be provided with the seperated > +provide the memory protection that would be provided with the separated > model, and that the new process will not have the same memory layout > it would have had in Windows, right? > > > > If that's all it is, why is it a big deal? Unless I'm mistaken, > -providing seperated address spaces will be a big deal, requiring > +providing separated address spaces will be a big deal, requiring > marshalling of all message data, and various other tweaky-to-get-right > tasks. On the other side of the coin, how common is the use of > CreateProcess amongst the apps people want to run? Is this useful > Index: wwn/wn20010611_97.xml > =================================================================== > RCS file: /home/wine/lostwages/wwn/wn20010611_97.xml,v > retrieving revision 1.1.1.1 > diff -u -r1.1.1.1 wn20010611_97.xml > --- wwn/wn20010611_97.xml 2 Dec 2002 17:08:15 -0000 1.1.1.1 > +++ wwn/wn20010611_97.xml 9 Jun 2003 20:41:01 -0000 > @@ -372,7 +373,7 @@ > <quote who="Patrick Stridvall"> > However regardless of this, uname shouldn't be used > (at least not directly). Autoconf provides a standard > -way to do this (which BTW happends to use uname). > +way to do this (which BTW happens to use uname). > It can be used as below. > <code>AC_CANONICAL_HOST > > Index: wwn/wn20020213_115.xml > =================================================================== > RCS file: /home/wine/lostwages/wwn/wn20020213_115.xml,v > retrieving revision 1.1.1.1 > diff -u -r1.1.1.1 wn20020213_115.xml > --- wwn/wn20020213_115.xml 2 Dec 2002 17:08:21 -0000 1.1.1.1 > +++ wwn/wn20020213_115.xml 9 Jun 2003 20:41:11 -0000 > @@ -622,7 +623,7 @@ > contribute significantly to the project. Only the developers contribute, > and it is not at all clear to me that they would stop. > > -Marcus Meissner has already shown that the existance of our AFPLed DCOM > +Marcus Meissner has already shown that the existence of our AFPLed DCOM > code didn't stop him from going ahead and doing it himself. On the > contrary - it helped him, since he got hints from our design. It's a shame > that he had to, since we've been working hard to find a way to contribute > Index: wwn/wn20020807_131.xml > =================================================================== > RCS file: /home/wine/lostwages/wwn/wn20020807_131.xml,v > retrieving revision 1.1.1.1 > diff -u -r1.1.1.1 wn20020807_131.xml > --- wwn/wn20020807_131.xml 2 Dec 2002 17:08:38 -0000 1.1.1.1 > +++ wwn/wn20020807_131.xml 9 Jun 2003 20:41:21 -0000 > @@ -359,7 +361,7 @@ > registries in addition to compiling wine so most of the time if you > already have these set up then it is not nessesary to use wineinstall. > > - However the structure of both the .wine/config and registries and thier > + However the structure of both the .wine/config and registries and their > contents has changed over time and as new features are added to wine. > For example over time more functionality has been added to the various > dlls and in the default config file various dlls now default to builtin > Index: wwn/wn20021025_141.xml > =================================================================== > RCS file: /home/wine/lostwages/wwn/wn20021025_141.xml,v > retrieving revision 1.2 > diff -u -r1.2 wn20021025_141.xml > --- wwn/wn20021025_141.xml 9 Jun 2003 15:18:38 -0000 1.2 > +++ wwn/wn20021025_141.xml 9 Jun 2003 20:41:25 -0000 > @@ -552,7 +553,7 @@ > to do page rendering and such. > > Malte replied, <quote who="Malte Starostik"> > -Hmm, we're implementing the absolutely neccessary parts in reaktivate > +Hmm, we're implementing the absolutely necessary parts in reaktivate > with Konqueror, but that's run from inside Konq already, so it's a bit > special. Maybe there would be a way to use either browser with those > interfaces? :-)</quote> > Index: wwn/wn20021122_145.xml > =================================================================== > RCS file: /home/wine/lostwages/wwn/wn20021122_145.xml,v > retrieving revision 1.1 > diff -u -r1.1 wn20021122_145.xml > --- wwn/wn20021122_145.xml 2 Dec 2002 17:40:34 -0000 1.1 > +++ wwn/wn20021122_145.xml 9 Jun 2003 20:41:28 -0000 > @@ -597,14 +598,14 @@ > reentrent variant if present as well as having an > alternative implementation if not. > > -As to the implict existance question: I'm not sure. > +As to the implict existence question: I'm not sure. > First of all, to answer the related question: > Should you have a alternative implementation for > defined(HAVE_GETPWUID) && !defined(HAVE_GETPWNAM)? > > IMHO the answer is no. It is not worth the effort to > support hypotetical platforms unless we can verify the > -existance of one. > +existence of one. > > To return to the original question: > I suggest that we should detect the presence or absence > Index: wwn/wn20030516_170.xml > =================================================================== > RCS file: /home/wine/lostwages/wwn/wn20030516_170.xml,v > retrieving revision 1.2 > diff -u -r1.2 wn20030516_170.xml > --- wwn/wn20030516_170.xml 9 Jun 2003 15:18:38 -0000 1.2 > +++ wwn/wn20030516_170.xml 9 Jun 2003 20:41:40 -0000 > @@ -403,7 +404,7 @@ > > </section><section > title="Separating 16/32 Bit OLE Functions" > - subject="PATCH - Start seperating 16/32 in Ole and ole32 memlockbytes" > + subject="PATCH - Start separating 16/32 in Ole and ole32 memlockbytes" > archive="http://www.winehq.com/hypermail/wine-devel/2003/05/0404.html" > posts="2" > startdate="05/15/2003" > @@ -413,7 +414,7 @@ > OLE32. He gave an update of what he's trying to do and some of > the issues involved: > <quote who="Steven Edwards"> > - I am doing some work trying to seperate Ole* and Ole32 for use in > + I am doing some work trying to separate Ole* and Ole32 for use in > ReactOS. Before we can make use of most of the WINE code all of the > Non-Win32api imported functions are going to need to be compiled out or > rewitten. I dont need someone to do this for me but I am going to need a > Index: wwn/wn20030523_171.xml > =================================================================== > RCS file: /home/wine/lostwages/wwn/wn20030523_171.xml,v > retrieving revision 1.1 > diff -u -r1.1 wn20030523_171.xml > --- wwn/wn20030523_171.xml 27 May 2003 14:25:49 -0000 1.1 > +++ wwn/wn20030523_171.xml 9 Jun 2003 20:41:41 -0000 > @@ -273,7 +274,7 @@ > At one point Dimi thought a dsp2make utility would be a useful addition and Steven > mentioned ReactOS had one. He went on to discuss some future plans, > <quote who="Steven Edwards"> > - My goal if the ReactOS guys can get more then winhello working is to have WINEs > + My goal if the ReactOS guys can get more than winhello working is to have WINEs > shell32 and comctl32 running for Linux world</quote>. > > All in all the meeting was quite successful and a lot of people were glad to > @@ -399,7 +400,7 @@ > will put in the new interface (that will also let me implement some of > GetCharacterProperties more obscure features). That is not likely to > happen. I suspect FriBidi has fallen off the end of the earth. It does > -not implement mirroring, nor does it implement Arabic Shaping (wierd, > +not implement mirroring, nor does it implement Arabic Shaping (weird, > considering that the maintainer is from Iran). It only supports UCS-4. > > Also - like I told Mike H on IRC, static linking ICU will mean that we -- Jeremy Newman <jnewman(a)winehq.org>

2 1

Jump to page:

2025

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