March 2003 - Wine-devel - list.winehq.org

Re: Small rephrasing in the packaging guide
by Alexandre Julliard 04 Mar '03

04 Mar '03

Francois Gouget <fgouget(a)free.fr> writes: > --- documentation/packaging.sgml 28 Jan 2003 01:06:50 -0000 1.14 > +++ documentation/packaging.sgml 4 Mar 2003 03:41:14 -0000 > @@ -468,7 +468,7 @@ > > <listitem id=libfiles> > <para>Shared Object Library Files</para> > - <para>This list may NOT necessarily current!</para> > + <para>This list may NOT be current!</para> The truth is that the list will never be current, and IMO it's useless to have it here. It would be much better to explain how to get the correct list by running make install. Any volunteer? -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Named Pipe patch
by Tony Lambregts 04 Mar '03

04 Mar '03

Mike McCormack wrote: > > Hi, > > This patch probably shouldn't be applied... it's just to let everybody > know where I'm at with the named pipes code. > > The patch moves away from using unix pipes to implement named pipes, > and instead implements pipes internally. This is necessary to > implement message mode properly (without race conditions). > > I don't have time to work on it this week, so don't expect anything > new before the weekend. If anybody wants to play with it or comment, > feel welcome. > > I've started trying to pass some of Dan's tests, but it still fails... > Dan, your test's coverage is great! > > Mike > > > <patch police> cvs diff -u </patch police> -- Tony Lambregts

1 0

POSIX / pthreads / wineserver - can I help?
by Stefan Jones 04 Mar '03

04 Mar '03

Hi all, I have been following for a few months now the recent glibc and nptl changes. How glibc now eliminated it's own version of wineserver in it's thread implementation with nptl. I have also read up on the difficulties the mono people have with linking to wine due to pthreads. I am a gentoo developer with some spare time. I recently came across your pending problem when we put glibc-2.3.2-pre1 into our unstable branch. I have read up on some of the wine-devel email archives. I have a machine setup with the 2.5 kernel and nptl to do some wine development on! I have also noticed the winex problems outlined at http://www.transgaming.com/papers/shmserver.html I figured a proper solution to the wine thread thing would also for the most part solve that problem also as most wineserver calls like mutexes, thread signalling which take up the CPU time can be migrated to glibc and thus the new 2.5 kernel by using futexes and the new thread syscalls and tls. This is especially true after I read the functions in scheduler/client.c, reading / writing to a pipe per syscall! I am not that experienced a developer, but I am useful. I have started reading up the wine source code and understand basics of the wineserver message passing and the TEB / tls system. I know little about windows programming though. Any hint on what I can work on, help, to get this working again? My idea is to alter wine so that it runs on any 100% ish POSIX threading system, aka glibc, and thus offload many tasks to the system library and solve the difficulties for good. This may be difficult / impossible esp. for windows only syscalls, but for those the Winex shm idea may work, with minimal errno hacking. (as the errno can be set by the calling thread ). Any ideas where I can start ? Stefan

6 10

miranda
by Geoff Thorpe 04 Mar '03

04 Mar '03

Hi all, I've been fishing round for something resembling a feature-full yet not overly flakey I-M client (with support for the commonly-used protocols). After finding many of the X11-native clients insufficient in many respects, I'd been making do with trillian under wine. However that too experiences many problems and the modern win32 obsession of creating irritating GUI mutations is probably the reason. Eg. window creation sometimes hangs wine, dragging window location sometimes hangs wine, fonts seem to go haywire from time to time, preferences dialog seems to have various breakages, etc. So I was interested in trying out "Miranda I-M" which looked from the screenshots (in default mode anyhow) to be a reasonably conventional-looking win32 GUI client and seems to be under active development judging by sourceforge stats. Unfortunately after installation, which went pretty well, the program fails to start quite early on with this; fixme:file:FindFirstChangeNotificationA this is not supported yet (non-trivial). <sigh> Am I going to regret enquiring what this means? :-) So my question is in two parts; (1) is the above something that I can work on and/or help anyone else work on? (2) does anyone know of any other win32-based I-M client (supporting at least ICQ, Yahoo, MSN, AIM) that is stable under wine? Cheers, Geoff -- Geoff Thorpe geoff(a)geoffthorpe.net http://www.geoffthorpe.net/

7 11

Re: revised direct sound capture patches
by Alexandre Julliard 04 Mar '03

04 Mar '03

Robert Reif <reif(a)earthlink.net> writes: > tests.diff: dlls/dsound/tests/dsound.c dlls/winmm/tests/wave.c > fixes direct sound capture test to handle notifications properly > don't give error when driver not present > minor cleanups > add waveIn tests to winmm The winmm test fails for me (with the alsa driver): wave.c:351: Test failed: waveInGetDevCapsA: MMSYSERR_BADDEVICEID expected, got 5 Also next time please send separate patches in separate mails. Thanks. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: DLL loading: using ELF/so loading scheme
by Alexandre Julliard 04 Mar '03

04 Mar '03

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > is this still needed ? it seems to me we have written wrappers for > lots of needed part (opengl, odbc...) IMO it should be killed. This may require writing a few more wrappers though. -- Alexandre Julliard julliard(a)winehq.com

1 0

GlobalInterfaceTable?
by Mike Hearn 04 Mar '03

04 Mar '03

Hi, As part of a program that creates an instance of MSXML2.DOMDocument, I get the following errors: fixme:ole:CoCreateInstance no classfactory created for CLSID {00000323-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {6c736db1-bd94-11d0-8a23-00aa00b58e10}, hres is 0x80040154 (actually there are some more beforehand, but they don't seem fatal). Anyway, the first one seems to be StdGlobalInterfaceTable, which MSDN indicates should be implemented by Windows. Is this right, and if so, does Wine implement it? I grepped the sources and the only mention is in an IDL file, so I'd assume not. thanks -mike

4 5

F6 handline (SCADIII)
by Uwe Bonnes 04 Mar '03

04 Mar '03

Hallo, running Mike's SCAD3, e.g. a keypress on F5 gives: 0009:Call user32.TranslateAcceleratorA(00010023,0000038f,006a9978) ret=0062c2cd 0009:Call kernel32.LockResource16(0000038f) ret=407f4635 0009:Ret kernel32.LockResource16() retval=403e4d98 ret=407f4635 trace:accel:TranslateAccelerator TranslateAccelerators hAccel=0x38f, hWnd=0x10023,msg->hwnd=0x1002d, msg->message=0101, wParam=00000074, lParam=c03f0001 warn:accel:TranslateAccelerator couldn't translate accelerator key 0009:Ret user32.TranslateAcceleratorA() retval=00000000 ret=0062c2cd F6 gives: 0009:Call user32.TranslateAcceleratorA(00010023,0000038f,006a9978) ret=0062c2cd 0009:Call kernel32.LockResource16(0000038f) ret=407f4635 0009:Ret kernel32.LockResource16() retval=403e4d98 ret=407f4635 trace:accel:TranslateAccelerator TranslateAccelerators hAccel=0x38f, hWnd=0x10023,msg->hwnd=0x1002d, msg->message=0100, wParam=00000075, lParam=400001 trace:accel:translate_accelerator found accel for virt_key 0075 (scan 0040) trace:menu:GetMenu for 0x10023 returning 0x8c trace:accel:translate_accelerator , sending WM_COMMAND, wParam=1e150 and for another call: 0009:Call user32.TranslateAcceleratorA(00010023,0000038f,006a9978) ret=0062c2cd 0009:Call kernel32.LockResource16(0000038f) ret=407f4635 0009:Ret kernel32.LockResource16() retval=403e4d98 ret=407f4635 trace:accel:TranslateAccelerator TranslateAccelerators hAccel=0x38f, hWnd=0x10023,msg->hwnd=0x1002d, msg->message=0101, wParam=00000075, lParam=c0400001 trace:accel:translate_accelerator found accel for virt_key 0075 (scan 0040) trace:accel:translate_accelerator , but won't send WM_{SYS}COMMAND, reason is #1 0009:Ret user32.TranslateAcceleratorA() retval=00000001 ret=0062c2cd It seems, that F6 gets somehow translated. If I return FALSE in the code path emitting the "but won't send WM_{SYS}COMMAND, reason is" branch, F6 works as expected. Could anybody comment on that patch? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Index: wine/controls/menu.c =================================================================== RCS file: /home/wine/wine/controls/menu.c,v retrieving revision 1.162 diff -u -w -r1.162 menu.c --- wine/controls/menu.c 4 Mar 2003 02:14:58 -0000 1.162 +++ wine/controls/menu.c 4 Mar 2003 10:26:38 -0000 @@ -4744,6 +4744,7 @@ TRACE_(accel)(", but won't send WM_{SYS}COMMAND, reason is #%d\n",mesg); if(mesg==0) ERR_(accel)(" unknown reason - please report!"); + return FALSE; } return TRUE; }

2 1

Problem in listview with LVM_OWNERDATA set too late
by Dan Kegel 04 Mar '03

04 Mar '03

The test program http://www.kegel.com/ownerdata.exe shows a problem with OWNERDATA listview controls which pick up that attribute after being created. (No, this is not per the spec. Yes, a real program does that.) To see the problem, run ownerdata.exe, and select "View / Capture View". The window should NOT be blank. Methinks it's a bug, or at least a missing feature, in our listview. Dimi Paun thinks so, too, and wants me to file a bug about it. I will when I'm less swamped... - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

1 0

Re: A relay trace indenting tool, take 2
by Alexandre Julliard 03 Mar '03

03 Mar '03

Duane Clark <dclark(a)akamail.com> writes: > Changelog: > A tool for indenting calls in relay traces. It would be much better to merge that into examine-relay, rather than having two different scripts basically doing the same parsing. -- Alexandre Julliard julliard(a)winehq.com

2 1