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

CryptoAPI
by Travis Michielsen Sept. 4, 2001

Sept. 4, 2001

Hi, I was going to start implementing the Cypto API (in advapi32.dll) over the next few weeks. As of yet these functions are no more than stubs. However, I am finding increased use of this API as more applications becomed networkable and relying more heavily on internet connections. I was hoping to implement these functions by using the OpenSSL library (if/when available). This library seems to have similar capabilities. One of my concerns is about legal issues. What special concerns should I note about cryptographic software? Are there any special copyright issues I should be aware of? Another question is about design. M$ seems to split the cryptographic software into different dlls (rsabase.dll, rsasig.dll, dssbase.dll, etc.). Should I do this as well so that, applications can use the native dlls if necessary or should I simply implement it entirely though advapi32.dll which and avoid the need to create several new (and very small) dlls under wine? Because most of the code is already in another library (OpenSSL) creating extra dlls seems abit unnecessary. - Travis _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

3 4

Re: wine-devel digest, Vol 1 #445 - 9 msgs
by Robert Lunnon Aug. 30, 2001

Aug. 30, 2001

Attempt 2 :-) I am trying to get winsock to work under Solaris and need a little help. When connecting, the call to connect doesn't generate a syn packet as expected, The problem appears to be WSOCK32_socket, where the type of socket is passed as type 1 for a tcp service, as it turns out the Solaris header file defines SOCK_STREAM as 2 and SOCK_DGRAM as 1 which makes the subsequent call to connect succeed without establishing a connection because a UDP endpoint was created instead of a tcp one. Now to find out where SOCK_STREAM is getting defined as 1 :-/ I probably need to check the standard function calls between a solaris binary and a windows one so does someone have a simple test program and a unix source (IE windows binary with unix compatible source code) that I can use to compare behaviours between the two environments ? Thanks Bob

2 1

Re: [PATCH] DestroyWindow16
by eric pouech Aug. 30, 2001

Aug. 30, 2001

Gerard Patel wrote: > > As DestroyWindow does a lot of handle comparaisons, it is necessary > to give it a real 32 bit handle. This avoids a systematic crash when > ForteFreeAgent 16 bit exits. I have not looked for other places where > this can be necessary - but it would not be surprising that this happens. perhaps as an extension of the relay code ? (it would mean typing correctly windows handles in spec files though) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Problems with WM_PAINT and threads
by Ove Kaaven Aug. 30, 2001

Aug. 30, 2001

After trying to merge Wine 20010824 into WineX, I've encountered a threading issue. A window is created in an app thread: 0806d1f0:Call user32.CreateWindowExA(00000000, 403cb0d4 "Afx:400000:3",0055b674 "3DMark - Display Window", 80000000,00000000,00000000,00000280,000001e0,00000000, 00000000,00400000,00000000) ret=5f40c486 trace:win:WIN_CreateWindowEx "3DMark - Display Window" "Afx:400000:3" 00000000 80000000 0,0 640x480 0000 0000 00400000 (nil) trace:win:WIN_CreateWindowEx winproc type is 2 (WIN_PROC_32A) ... This works fine, until our ddraw update thread somehow decides to send it a message after syncing its own window 31bc: 08107170:Ret x11drv.CreateWindow() retval=00000001 ret=407f542f trace:win:WIN_CreateWindowEx created window 31bc 08107170:Call x11drv.SetWindowPos(44a12e88) ret=407fb159 trace:x11drv:X11DRV_SetWindowPos hwnd 31bc, swp (0,0)-(0,0) flags 0000255b trace:x11drv:X11DRV_SetWindowPos current (0,0)-(800,600), style 84000000 warn:x11drv:SWP_DoOwnedPopups (31bc) hInsertAfter = 0000 trace:x11drv:X11DRV_sync_whole_window_position setting win 3200001 pos 0,0,800x600 after 8081268 changes=40 trace:x11drv:X11DRV_SetWindowPos mapping win 31bc trace:x11drv:X11DRV_SetWindowPos status flags = 1843 08107170:Ret x11drv.SetWindowPos() retval=00000001 ret=407fb159 trace:win:RedrawWindow 31bc (0000) NULL 0,0-0,0 0000 flags=0180 trace:win:RDW_UpdateRgns hwnd 31bc [0000] -> hrgn [0000], flags [0180] trace:win:RDW_Paint hwnd 31bc [0000] -> hrgn [0000], flags [0180] 08107170:Call x11drv.MsgWaitForMultipleObjectsEx(00000002,44a12da4,ffffffff,000000ff,00000000) ret=407e4237 trace:x11drv:X11DRV_Expose win 31bc (3200002) 0,0 800x600 trace:win:RedrawWindow 31bc (0000) rect 0,0-800,600 0000 flags=0005 trace:win:RDW_UpdateRgns hwnd 31bc [174a] -> hrgn [0000], flags [0005] trace:win:RDW_Paint hwnd 31bc [174a] -> hrgn [0000], flags [0005] 08107170:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000002 ret=407e4237 08107170:Call x11drv.MsgWaitForMultipleObjectsEx(00000000,00000000,00000000,00000000,00000000) ret=407a1ca4 08107170:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000102 ret=407a1ca4 trace:msg:MSG_peek_message got type 5 msg f hwnd 0 wp 0 lp 0 trace:win:WIN_FindWinToRepaint found 3124 trace:win:RedrawWindow 3124 (1746) NULL 0,0-0,0 0000 flags=0050 trace:win:RDW_UpdateRgns hwnd 3124 [1746] -> hrgn [0000], flags [0050] trace:win:RDW_Paint hwnd 3124 [1746] -> hrgn [0000], flags [0050] trace:message:SPY_EnterMessage (00003124) "3DMark - D..." message [000f] WM_PAINT dispatched wp=00000000 lp=00000000 08107170:Call window proc 0x5f4019fa (hwnd=00003124,msg=WM_PAINT,wp=00000000,lp=00000000) ^^^^^^^^ ^^^^^^^^ After Wine dispatches this WM_PAINT message from the wrong thread, 3DMark2000 fails to locate its thread-local data, gets confused, and crashes. Maybe Alexandre did a mistake somewhere in his restructures?

1 0

Re: BUG with wine/dlls/ntdll/string.c:_ultoa() ???!!??
by Uwe Bonnes Aug. 30, 2001

Aug. 30, 2001

>>>>> "Johann" == Johann Messner <johann.messner(a)zid.uni-linz.ac.at> writes: Johann> Hi there, First: thanks & compliments for your impressive Johann> project!!! Johann> please check wine/dlls/ntdll/string.c:_ultoa() ... I think there Johann> is a bug in it ... There are for sure more bug... Johann> hans Johann> ==> this is the path to it in the web cvs: ... Johann> ==> this is the source snippet with the patch as suggested ... Did you test? As no win function is uses, you can easily write a test programm wrapper, like static char *_ultoa(... void main() { char buffer[32]; printf(" x %d, radix %d, result %s\n",1000,10,_ultoa(1000,buffer,10)); printf("... } The loop decrements p after use, so p needs to be corrected and I would think that the original version is right. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Mouse Events
by Brad Campbell Aug. 30, 2001

Aug. 30, 2001

G'day all, Maiden post. Please be gentle.. I had a problem using wine with a touchscreen under XFree 4.0.2. With the help of Gerard Patel and Ove Kaaven I have come up with a patch that solves my problem, and does not appear to disrupt any of the other machines and programs I use. I have looked at several ways of achieving this, and this seems to be the least messy. This has been tested with both the touchscreen and also ps/2 mouse and works well with both. I'm not a C programmer at all, and have little experience with the WINE code. All comments both positive and negative appreciated.. Thanks.. To be applied to windows/input.c --- input.c Wed Aug 29 21:00:42 2001 +++ input.c.new Wed Aug 29 20:59:01 2001 @@ -195,43 +195,43 @@ if (mi->dwFlags & (!SwappedButtons? MOUSEEVENTF_LEFTDOWN : MOUSEEVENTF_RIGHTDOWN)) { MouseButtonsStates[0] = AsyncMouseButtonsStates[0] = TRUE; - queue_raw_hardware_message( WM_LBUTTONDOWN, keystate, 0, PosX, PosY, + queue_raw_hardware_message( WM_LBUTTONDOWN, keystate, 0, mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } if (mi->dwFlags & (!SwappedButtons? MOUSEEVENTF_LEFTUP : MOUSEEVENTF_RIGHTUP)) { MouseButtonsStates[0] = FALSE; - queue_raw_hardware_message( WM_LBUTTONUP, keystate, 0, PosX, PosY, + queue_raw_hardware_message( WM_LBUTTONUP, keystate, 0, mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } if (mi->dwFlags & (!SwappedButtons? MOUSEEVENTF_RIGHTDOWN : MOUSEEVENTF_LEFTDOWN)) { MouseButtonsStates[2] = AsyncMouseButtonsStates[2] = TRUE; - queue_raw_hardware_message( WM_RBUTTONDOWN, keystate, 0, PosX, PosY, + queue_raw_hardware_message( WM_RBUTTONDOWN, keystate, 0, mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } if (mi->dwFlags & (!SwappedButtons? MOUSEEVENTF_RIGHTUP : MOUSEEVENTF_LEFTUP)) { MouseButtonsStates[2] = FALSE; - queue_raw_hardware_message( WM_RBUTTONUP, keystate, 0, PosX, PosY, + queue_raw_hardware_message( WM_RBUTTONUP, keystate, 0, mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } if (mi->dwFlags & MOUSEEVENTF_MIDDLEDOWN) { MouseButtonsStates[1] = AsyncMouseButtonsStates[1] = TRUE; - queue_raw_hardware_message( WM_MBUTTONDOWN, keystate, 0, PosX, PosY, + queue_raw_hardware_message( WM_MBUTTONDOWN, keystate, 0, mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } if (mi->dwFlags & MOUSEEVENTF_MIDDLEUP) { MouseButtonsStates[1] = FALSE; - queue_raw_hardware_message( WM_MBUTTONUP, keystate, 0, PosX, PosY, + queue_raw_hardware_message( WM_MBUTTONUP, keystate, 0, mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } if (mi->dwFlags & MOUSEEVENTF_WHEEL) { queue_raw_hardware_message( WM_MOUSEWHEEL, MAKELONG( keystate, mi->mouseData), 0, - PosX, PosY, mi->time, mi->dwExtraInfo ); + mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } } -- Brad Campbell /"\ Save the Forests \ / ASCII RIBBON CAMPAIGN Burn a Greenie. X AGAINST HTML MAIL / \

1 1

Comment from IBM developer re FS register corruption
by Jeremy White Aug. 30, 2001

Aug. 30, 2001

At LinuxWorld today, a couple of developers from IBM stopped by and mentioned a patch that they recently sent to Linus (which he accepted with dismay at such a long standing bug, and apparently committed to the 2.4.8 tree). Sadly, I have forgotten the woman's name, but she indicated that there was a race condition that could sometimes cause the fs register to become corrupt, and that this problem had existing in all versions of Linux, as far as they could tell. She indicated that the patch had a fairly innocuous description, but it might be worth understanding this problem better (although from her description, it didn't sound like a good workaround was available). Cheers, Jeremy p.s. Wine was a finalist for best open source project, but lost out to KDE. Next time, the crystal plaque is ours. I can feel it.

1 0

Powerdvd running under linux
by Robert Lowery Aug. 30, 2001

Aug. 30, 2001

Hi I have a graphics card with an SIS6326 chipset. Under Windows 98 (using PowerDVD), I get fantastic performance on my Pention 233MMX as it supports YUV->RGB, Motion Compensation and iDCT in hardware. This chipset is not currently supported under Linux. What do you think the chances are of PowerDVD working with hardware acceleration under WINE/WINEX? What sort of performance should I expect? Please cc replies to my email, as I am not subscribed Thank-you for your help -Robert

3 2

./configure file in cvs
by Gioele Barabucci Aug. 29, 2001

Aug. 29, 2001

Hello everyone, why is there a ./configure file in your cvs? configure was meant to be created for endusers, not for developers. Many projects based on auto* tools create a ./autogen.sh or ./bootstrap script. The fact is that the configure supplied (and all the auto* files) creates lot of confusion and some errors sometime. simple as: #!/bin/sh # rm -f configure ltmain.sh config.guess config.sub echo "Running libtoolize..." libtoolize --force --copy >/dev/null echo "Running aclocal..." aclocal $ACLOCAL_FLAGS echo "Running autoheader..." $use_autoheader echo "Running autoconf..." $use_autoconf echo "Running automake..." automake --add-missing --copy --foreign -- Gioele Barabucci (Gb]) <gioeleb(a)tiscalinet.it>

3 2

Re:Call for Volunteers (Re: Newbie work?)
by Eric Pouech Aug. 29, 2001

Aug. 29, 2001

> Also I'm thinking about starting an additional section for > 'hard(er)' projects that would significantly improve Wine. > Maybe it > could also list projects that are already underway and for which help > would be appreciated (DCOM?, STRICT handles?). I think that when folks start working on a rather large chunk they should talk about it a bit more (that they started, post some ideas on how it should be done, call for contributions...). All developpers are rather terse on this matter. > Easy: > Medium (I expect these would take longer or be a bit harder) > * Provide a pedump utility > #91: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=91 > I know there's sample code that does that already floating around so > it should be relatively simple. > Eric Pouech seems to be working on this. I did not check if his > pedump dump the imports/exports but it probably does. yes, but it's missing delayed imports and resource. disass could be provided to. A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un vu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

2 1

Re: Newbie work?
by Gerard Patel Aug. 29, 2001

Aug. 29, 2001

At 03:25 PM 28/08/2001 -0700, you wrote: >I noticed that there was a file on >ftp://ibiblio.org/pub/Linux/ALPHA/wine/ about projects for newbie wine >developers. I also noticed that it was written in 1994. So I was wondering >if there was a more up to date version or if anyone had some ideas of >usefull work that a developer new to wine could do? www.winehq.com/projects The one I would like to be done is 'loadable fonts'. It's difficult but it would make many people happy with Wine from some posts I see on cemw. Gerard

1 0

Re: Crash in latest version
by Gerard Patel Aug. 29, 2001

Aug. 29, 2001

At 04:03 PM 28/08/2001 -0700, you wrote: >Gerard Patel <gerard.patel(a)nerim.net> writes: > >> What this means is that any use of 16 bit code with >> window handles in Wine will break as the handles >> will be truncated. I already see many new crashes... > >Actually truncated handles should work just fine, the generation >number is simply ignored if it is zero. There may theoretically be >problems when we pass a truncated handle to a 32-bit app that compares >it to a full 32-bit handle stored previously, but this should be >fairly rare behavior. So your crashes are probably caused by something >else. > .Backtrace for the next crash : Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00462b9b). In 32-bit mode. 0x00462b9b (eudora.exe.EntryPoint+0xb2ee in H:\eudora\eudora\eudora.exe): movl 0x0(%eax),%eax >0 0x00462b9b (eudora.exe.EntryPoint+0xb2ee in H:\eudora\eudora\eudora.exe) (ebp=406159c0) 1 0x00462dd7 (eudora.exe.EntryPoint+0xb52a in H:\eudora\eudora\eudora.exe) (ebp=40615a04) 2 0x40724e33 (WINPROC_CallWndProc+0x73(proc=0x462daa, hwnd=0x3b, msg=0x87, wParam=0x0, lParam=0x0) [winproc.c:171] in libuser32.so) (ebp=40615a30) 3 0x4072a919 (WINPROC_CallProc32WTo32A+0x89(func=0x462daa, hwnd=0x3b, msg=0x87, wParam=0x0, lParam=0x0) [winproc.c:2442] in libuser32.so) (ebp=40615a58) 4 0x4072af32 (CallWindowProcW+0xb2(func=0x40dc1069, hwnd=0x3b, msg=0x87, wParam=0x0, lParam=0x0) [winproc.c:2683] in libuser32.so) (ebp=40615a8c) 5 0x406c37fe (call_window_proc+0x9e(hwnd=0x3b, msg=0x87, wparam=0x0, lparam=0x0, unicode=0x1) [message.c:1108] in libuser32.so) (ebp=40615ae4) 6 0x406c434b (SendMessageTimeoutW+0xcb(hwnd=0x3b, msg=0x87, wparam=0x0, lparam=0x0, flags=0x0, timeout=0xffffffff, res_ptr=0x40615b68) [message.c:1498] in libuser32.so) (ebp=40615b44) 7 0x406c45c7 (SendMessageW+0x37(hwnd=0x3b, msg=0x87, wparam=0x0, lparam=0x0) [message.c:1576] in libuser32.so) (ebp=40615b78) 8 0x406fb4ec (DEFDLG_SetFocus+0x5c(hwndDlg=0x1003a, hwndCtrl=0x3b) [defdlg.c:32] in libuser32.so) (ebp=40615b9c) 9 0x406fb5d7 (DEFDLG_RestoreFocus+0x67(hwnd=0x1003a) [defdlg.c:74] in libuser32.so) (ebp=40615b This crash goes away by changing the HWND16 in DIALOG_INFO to HWND. I have a third new one for you, but I have not the time to search for the reason this night (there is no hint of 16 bit handles here) 0x4071ff50 (GetParent+0x30 [win.c:2143] in libuser32.so): movl 0x20(%eax),%esi 2143 retvalue = wndPtr->parent->hwndSelf; Wine-dbg>bt bt Backtrace: =>0 0x4071ff50 (GetParent+0x30(hwnd=0x20021) [win.c:2143] in libuser32.so) (ebp=40615e7c) 1 0x4070a17f (DefMDIChildProcA+0x1f(hwnd=0x20021, message=0x82, wParam=0x0, lParam=0x0) [mdi.c:1617] in libuser32.so) (ebp=40615e98) 2 0x00474107 (eudora.exe.EntryPoint+0x1c85a in H:\eudora\eudora\eudora.exe) (ebp=40615f54) 3 0x00462ba3 (eudora.exe.EntryPoint+0xb2f6 in H:\eudora\eudora\eudora.exe) (ebp=40615fc8) 4 0x00462dd7 (eudora.exe.EntryPoint+0xb52a in H:\eudora\eudora\eudora.exe) (ebp=4061600c) 5 0x40724e83 (WINPROC_CallWndProc+0x73(proc=0x462daa, hwnd=0x20021, msg=0x82, wParam=0x0, lParam=0x0) [w inproc.c:171] in libuser32.so) (ebp=40616038) 6 0x4072ae72 (CallWindowProcA+0xb2(func=0x462daa, hwnd=0x20021, msg=0x82, wParam=0x0, lParam=0x0) [winpr oc.c:2647] in libuser32.so) (ebp=4061606c) 7 0x406c3823 (call_window_proc+0xc3(hwnd=0x20021, msg=0x82, wparam=0x0, lparam=0x0, unicode=0x0) [messag e.c:1112] in libuser32.so) (ebp=406160c4) 8 0x406c4496 (SendMessageTimeoutA+0xd6(hwnd=0x20021, msg=0x82, wparam=0x0, lparam=0x0, flags=0x0, timeou t=0xffffffff, res_ptr=0x40616148) [message.c:1544] in libuser32.so) (ebp=40616124) 9 0x406c4617 (SendMessageA+0x37(hwnd=0x20021, msg=0x82, wparam=0x0, lparam=0x0) [message.c:1587] in libu ser32.so) (ebp=40616158) 10 0x4071d6a4 (WIN_DestroyWindow+0x94(wndPtr=0x40403d54) [win.c:420] in libuser32.so) (ebp=40616180) 11 0x4071ebb2 (DestroyWindow+0x282(hwnd=0x20021) [win.c:1243] in libuser32.so) (ebp=406161a0) 12 0x40708506 (MDIDestroyChild+0xd6(parent=0x1002b, ci=0x403f4528, child=0x20021, flagDestroy=0x1) [mdi. c:712] in libuser32.so) (ebp=406161c4) 13 0x407096d2 (MDIClientWndProc_common+0x3d2(hwnd=0x1002b, message=0x221, wParam=0x20021, lParam=0x0, un icode=0x0) [mdi.c:1295] in libuser32.so) (ebp=40616218) 14 0x407099f6 (MDIClientWndProcA+0x36(hwnd=0x1002b, message=0x221, wParam=0x20021, lParam=0x0) [mdi.c:14 06] in libuser32.so) (ebp=4061623c) 15 0x40724e03 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=40616260) 16 0x40724e83 (WINPROC_CallWndProc+0x73(proc=0x407099c0, hwnd=0x1002b, msg=0x221, wParam=0x20021, lParam =0x0) [winproc.c:171] in libuser32.so) (ebp=4061628c) 17 0x4072ae72 (CallWindowProcA+0xb2(func=0x407099c0, hwnd=0x1002b, msg=0x221, wParam=0x20021, lParam=0x0 ) [winproc.c:2647] in libuser32.so) (ebp=406162c0) 18 0x406c3823 (call_window_proc+0xc3(hwnd=0x1002b, msg=0x221, wparam=0x20021, lparam=0x0, unicode=0x0) [ message.c:1112] in libuser32.so) (ebp=40616318) 19 0x406c4496 (SendMessageTimeoutA+0xd6(hwnd=0x1002b, msg=0x221, wparam=0x20021, lparam=0x0, flags=0x0, All I can say for now is that wndPtr->parent is NULL. And I have yet another 20 apps to try :-) Gerard

1 0

Re: Crash in latest version
by Alexandre Julliard Aug. 29, 2001

Aug. 29, 2001

Gerard Patel <gerard.patel(a)nerim.net> writes: > This crash goes away by changing the HWND16 in DIALOG_INFO to HWND. Seems to be less rare than I hoped then ;-) I've added a fix. > All I can say for now is that wndPtr->parent is NULL. This one should be fixed too. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Crash in latest version
by Gerard Patel Aug. 29, 2001

Aug. 29, 2001

At 10:34 PM 28/08/2001 +0200, you wrote: >Notice the change in the hwnd Windows handles are now generated on the server. This is a historical moment, btw :-) Now Wine has all the architectural features of Win 95 Not everything is implemented, FindWindow does not yet work across processes for example. But it's an important step nonetheless. Alexandre Julliard has implemented the 'generation' feature of handles. The higher part of a 32 bit handle is used for a counter that is incremented from a window creation to another, avoiding the age-old problem of windows being deleted, then braindead application trying to use their handles, using newly created windows instead. What this means is that any use of 16 bit code with window handles in Wine will break as the handles will be truncated. I already see many new crashes... The dialog code uses a 16 bit only Api (FillWindow) The following (and simplistic) patch should make your app crash a bit later. Gerard --- defdlg.c.orig Tue Aug 21 15:09:31 2001 +++ defdlg.c Wed Aug 29 00:07:28 2001 @@ -135,10 +135,18 @@ static LRESULT DEFDLG_Proc( HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam, DIALOGINFO *dlgInfo ) { + HBRUSH hbrush; switch(msg) { case WM_ERASEBKGND: - FillWindow16( hwnd, hwnd, (HDC16)wParam, (HBRUSH16)CTLCOLOR_DLG ); + hbrush = SendMessageA( hwnd, WM_CTLCOLORDLG, + wParam, (LPARAM)hwnd ); + if (hbrush ) + { + RECT r; + GetClientRect(hwnd, &r); + FillRect( (HDC) wParam, &r, hbrush ); + } return 1; case WM_NCDESTROY:

1 0

Call for Volunteers (Re: Newbie work?)
by Francois Gouget Aug. 28, 2001

Aug. 28, 2001

Hi, On Tue, 28 Aug 2001, Daniel Sabo wrote: > I noticed that there was a file on > ftp://ibiblio.org/pub/Linux/ALPHA/wine/ about projects for newbie wine > developers. I also noticed that it was written in 1994. So I was wondering > if there was a more up to date version or if anyone had some ideas of > usefull work that a developer new to wine could do? Unfortunately this file does not seem very helpful. Time for another round of my Call for Volunteers it seems :-) Note that I did not get much time to update it so please send me your ideas. Also I'm thinking about starting an additional section for 'hard(er)' projects that would significantly improve Wine. Maybe it could also list projects that are already underway and for which help would be appreciated (DCOM?, STRICT handles?). But first, many thanks go to all those who fixed bugs from the previous call for volunteers and especially to Maciek Kaliszewski for his wrc fixes. What is the "Call for Volunteers"? I have built a list of projects that should be easy to tackle by new Wine developpers. The main goal is to provide the needed inspiration to potential Wine developpers that just are not motivated by the standard 'grep FIXME' answer (and I can understand them). So here goes. Easy: * PrgWin95/98: System metrics differ from the Win9x values #48: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=48 One day I'll fix this one... I swear. Unless you want to work on it first. In that case I'll provide you with my test application and dumps of the metrics for Win95, Win98, NT4, 2000, ... * The doc about the command line arguments and the config file is out of date. See TextCP, XVideoPort and Synchronous for instance. I'm sure there are plenty of other things that are out of date. * Metabug: Test Wine with the VXCL samples #242: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=242 Get the VXCL samples, test them with Wine and report the bugs in the bugzilla database. I know there's lots of them. Then people (or yourself) can start fixing these bugs in a distributed fashion. You can probably start reporting the most obvious bugs just by testing in Wine, but for more subtle bugs you will need two computers (or Win4Lin/VmWare) to more easily compare the behavior in Windows and in Wine. * Metabug: Test Wine with the Common Control Spy Samples #239: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=239 Get the Common Control Spy samples and test Wine with them. You will need the native comctl32 dll but you can do the tests without rebooting between each test or using two computers. * PrgWin95: Listbox getting a recessed border instead of a flat one #56: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=56 (I can provide you with the sample application) This one my be fixed, to check... * I think it would be nice to add a tool that displays the dlls version information like 'About' does in the windows explorer. I have some code you could use as a starting point and I think it could be merged with winver. In fact this would be almost stabdard windows programming. * Tabs are missing their inner border #243: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=243 There's a bug in the drawing of the border of the common control tabs. Fixing each of the four instances of the code is easy. It would be interesting to find a way to factorize some of this code. Medium (I expect these would take longer or be a bit harder) * Quickbooks Pro Timer does not accept date (GetCalendarInfoA error) #276: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=276 GetCalendarInfoA/W are not implemented yet. They involve quite a lot of internationalisation aspects, but providing a first implementation that at least handles the common cases should be feasible. * Provide a pedump utility #91: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=91 I know there's sample code that does that already floating around so it should be relatively simple. Eric Pouech seems to be working on this. I did not check if his pedump dump the imports/exports but it probably does. * CreateIcon does not resize bitmaps #175: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=175 I did a similar fix somewhere some time ago. I can provide a sample application and I might be able to point you in the right direction. * winemaker: 'winemaker --nomfc' does not have the intended effect #227: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=227 * winemaker: Ignores the '--with-{mfc,wine}' options once they are cached #225: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=225 If you're familiar with autoconf and know how configure scripts should behave... * StrokePath ignores PS_JOIN_xxx #11: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=11 This should not be too difficult to fix but it would certainly help if you are familiar with GDI. * Checking the differences between what's in the Windows dlls and what's in our spec files... and fix the contents of our spec files as appropriate. I already have a list of all the APIs in each of the dlls for Win95, Win98, NT4 and Wine2000, plus a script that can show the differences. * Enhancing the above perl script. In particular it could be made smarter wrt. detecting whether an API is exported by ordinal or not. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95

1 0

Newbie work?
by Daniel Sabo Aug. 28, 2001

Aug. 28, 2001

I noticed that there was a file on ftp://ibiblio.org/pub/Linux/ALPHA/wine/ about projects for newbie wine developers. I also noticed that it was written in 1994. So I was wondering if there was a more up to date version or if anyone had some ideas of usefull work that a developer new to wine could do? Daniel Sabo

2 1

Re: Crash in latest version
by Alexandre Julliard Aug. 28, 2001

Aug. 28, 2001

Gerard Patel <gerard.patel(a)nerim.net> writes: > What this means is that any use of 16 bit code with > window handles in Wine will break as the handles > will be truncated. I already see many new crashes... Actually truncated handles should work just fine, the generation number is simply ignored if it is zero. There may theoretically be problems when we pass a truncated handle to a 32-bit app that compares it to a full 32-bit handle stored previously, but this should be fairly rare behavior. So your crashes are probably caused by something else. -- Alexandre Julliard julliard(a)winehq.com

1 0

Crash in latest version
by Uwe Bonnes Aug. 28, 2001

Aug. 28, 2001

Hallo, sorry, the failure in the last mail was with an executable cvs-updated to " wine/ dlls/ttydrv/wnd.c dlls/x11drv/desktop.c ..." Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

1 0

Crash in latest version
by Uwe Bonnes Aug. 28, 2001

Aug. 28, 2001

Hallo, after an CVS update this evening including up to http://cvs.winehq.com/patch.py?id=999019609445169733371586 msdev.exe crashes earlier than before, when opening FILE->NEW This is from the relay log: 080681b8:CALL mfc42.2385: @(00000014,00000088,00000000) ret=5f47abec 080681b8:Call user32.CallWindowProcA(40d20259,00010052,00000014,00000088,00000000) ret=5f47a172 080681b8:Call window proc 0x4077d990 (hwnd=00010052,msg=WM_ERASEBKGND,wp=00000088,lp=00000000) 080681b8:Call window proc 0x5f47e7c0 (hwnd=00010052,msg=WM_ERASEBKGND,wp=00000088,lp=00000000) 080681b8:Ret window proc 0x5f47e7c0 (hwnd=00010052,msg=WM_ERASEBKGND,wp=00000088,lp=00000000) retval=00000000 080681b8:Call window proc 0x5f4bc820 (hwnd=00000052,msg=WM_CTLCOLORDLG,wp=00000088,lp=00000052) ^^^^^^^^ Notice the change in the hwnd. Backtrace is: =>0 0x5f4791e7 (AfxCallWndProc+0xc7(pWnd=0x0, hWnd=0x52, nMsg=0x136, wParam=0x88, lParam=0x52) [wincore.cpp:215] in D:\WINE95\SYSTEM\MFC42.DLL) (ebp=405c5110) 1 0x5f479539 (AfxWndProc+0x39(hWnd=0x52, nMsg=0x136, wParam=0x88, lParam=0x52) [wincore.cpp:368] in D:\WINE95\SYSTEM\MFC42.DLL) (ebp=405c5130) 2 0x5f4bc86a (AfxWndProcBase+0x4a(hWnd=0x52, nMsg=0x136, wParam=0x88, lParam=0x52) [afxstate.cpp:220] in D:\WINE95\SYSTEM\MFC42.DLL) (ebp=405c5160) 3 0x40793be7 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405c5184) 4 0x40793c66 (WINPROC_CallWndProc+0x76(proc=0x5f4bc820, hwnd=0x52, msg=0x136, wParam=0x88, lParam=0x52) [winproc.c:171] in libuser32.so) (ebp=405c51b0) 5 0x407999cb (CallWindowProcA+0x3b(func=0x5f4bc820, hwnd=0x52, msg=0x136, wParam=0x88, lParam=0x52) [winproc.c:2631] in libuser32.so) (ebp=405c51d8) 6 0x40733673 (call_window_proc+0xc3(hwnd=0x52, msg=0x136, wparam=0x88, lparam=0x52, unicode=0x0) [message.c:1112] in libuser32.so) (ebp=405c5224) 7 0x407342f0 (SendMessageTimeoutA+0xd0(hwnd=0x52, msg=0x136, wparam=0x88, lparam=0x52, flags=0x0, timeout=0xffffffff, res_ptr=0x405c52ac, hwnd=0x52) [message.c:1542] in libuser32.so) (ebp=405c527c) 8 0x40734469 (SendMessageA+0x39(hwnd=0x52, msg=0x136, wparam=0x88, lparam=0x52) [message.c:1587] in libuser32.so) (ebp=405c52b0) 9 0x407810b9 (PAINT_GetControlBrush+0x39(hParent=0x52, hWnd=0x52, hDC=0x88, ctlType=0x4) [painting.c:439] in libuser32.so) (ebp=405c52d8) 10 0x40781138 (PaintRect16+0x48(hwndParent=0x52, hwnd=0x52, hdc=0x88, hbrush=0x4, rect=0x405c5330) [painting.c:456] in libuser32.so) (ebp=405c52fc) 11 0x4078106b (FillWindow16+0x7b(hwndParent=0x52, hwnd=0x52, hdc=0x88, hbrush=0x4) [painting.c:430] in libuser32.so) (ebp=405c5348) 12 0x4076a3bd (DEFDLG_Proc+0xed(hwnd=0x10052, msg=0x14, wParam=0x88, lParam=0x0, dlgInfo=0x4041f91c) [defdlg.c:142] in libuser32.so) (ebp=405c536c) Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

1 0

Codeweavers announces CrossOver plugin
by Marcus Meissner Aug. 28, 2001

Aug. 28, 2001

Hi, Codeweavers has announced the CrossOver plugin, allowing Shockwave, Quicktime etc. to run in your favorite browser :) http://www.codeweavers.com/about/press_releases/?id=20010827.xml Ciao, Marcus

2 2

Wine in the press
by Eric Pouech Aug. 28, 2001

Aug. 28, 2001

http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2806411,00.html not a very good review for Wine indeed, but worth the reading this simply pinpoints what has to be fixed & enhanced A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un vu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

1 0

Re: strange code
by Alexandre Julliard Aug. 27, 2001

Aug. 27, 2001

Andreas Mohr <a.mohr(a)mailto.de> writes: > in PROFILE_LoadWineIni(), we return from processing in case we're not > the boot thread only *after* having created HKLM\\Software\\Wine\\Wine > registry keys: > > if (!CLIENT_IsBootThread()) return 1; /* already loaded */ > > Why ?? After all the registry is globally shared in > wineserver, so it shouldn't be necessary to create them again > via NtCreateKey if we're not the wine boot process. We don't need to create the keys, but we need to create the handle to the key. We could use NtOpenKey instead but NtCreateKey works just as well and avoids duplicating code. -- Alexandre Julliard julliard(a)winehq.com

1 0

strange code
by Andreas Mohr Aug. 27, 2001

Aug. 27, 2001

Hi all, in PROFILE_LoadWineIni(), we return from processing in case we're not the boot thread only *after* having created HKLM\\Software\\Wine\\Wine registry keys: if (!CLIENT_IsBootThread()) return 1; /* already loaded */ Why ?? After all the registry is globally shared in wineserver, so it shouldn't be necessary to create them again via NtCreateKey if we're not the wine boot process. Am I right ? -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

help me with WIN95 value of version16()
by Ladislav Sladecek Aug. 27, 2001

Aug. 27, 2001

The return value of GetVersion16() for win95 changed recently from 0x5f03 to 0x304 in misc/version.c (patch 1.43 -> 1.44). The version of "real" win95 I use (Czech, win95 2nd ed) gives 0x5f03 while "wine --winver win95" gives 0x304. As I do not have the US version of win95 I am not able to determine the right value. Since people from many countries read this group I ask for help. I created a simple test (compiled binary attached or compile yourselves in a 16 bit compiler). Please let me know what do your win95 (win98) returns. #include <windows.h> int WINAPI WinMain() { char s[1024]; DWORD v; v = GetVersion(); wsprintf(s,"GetVersion returned: 0x%0x",v); MessageBox(NULL,s,"lsla(a)post.cz",0); return 0; } Ladislav Sladecek

3 4

Re: help me with WIN95 value of version16()
by Gerard Patel Aug. 27, 2001

Aug. 27, 2001

At 08:57 AM 27/08/2001 -0700, you wrote: <snip> > Now, why would we have a version with 3.95 and another with 3.4? Is >it a Win95 vs Win95 OSR2 issue? I tested it on an original Win95, not on OSR2. I have no idea if OSR2 or 98 or Me behave differently, but I doubt it, else there would be a huge number of complaints in past Usenet postings archived on Google. IMO to fix the problem it's sufficient to change GetVersion16 along the lines of : if version = 0400 and winversion=win95 then version = 3.95 Gerard

1 0

Re: help me with WIN95 value of version16()
by Gerard Patel Aug. 27, 2001

Aug. 27, 2001

At 08:34 PM 26/08/2001 -0700, you wrote: >> The return value of GetVersion16() for win95 changed recently from 0x5f03 to >> 0x304 in misc/version.c (patch 1.43 -> 1.44). The version of "real" win95 I use >> (Czech, win95 2nd ed) gives 0x5f03 while "wine --winver win95" gives 0x304. >> As I do not have the US version of win95 I am not able to determine the right >> value. > > I would like to help you and I have a Win95 system around. But I >don't have a Win16 compiler as these things are getting quite rare. I can compile and run 16 bits apps, on win3.1 if needed (it's a pain because it's old hardware I hardly use otherwise) GetVersion 16 bits must be a special case, returns 3.95, while 32 bits apps get 4.00 Gerard

2 1

propably simple
by Ibrahim Hamouda Aug. 27, 2001

Aug. 27, 2001

I'm sorry for posting to the developers group, although I'm not one. I just have a simple question and the other news group is not helping. for three days now I'm trying to get an application connects to a MSSQL database on a windows box. I'm running the following: Mandrake 8.0 wine 20010731 windows 98 partition and sql server is installed on it My application is built in Powerbuilder 6.0. it comes up with the user name and password box which should be authenticated through the database. when I submit the user name and password I get the following error: [Microsoft][ODBC SQL SERVER DRIVER][TCP?IP SOCKET]General network error on the linux box I've already setup the MSSQL alias in the client connectivity utility of the sql server. I just want to know if I'm configuring the native and builtin wrong in my conf file or what I'm trying to do is not doable at all. I'll appreciate an answer so I can get some sleep, I'm literaly working on that for three days. Ibrahim Hamouda Internode Networks

2 1

keyboard problem
by Stefan Leichter Aug. 27, 2001

Aug. 27, 2001

Hello all, after a long time of debugging (because of my little experience with windows programing and debugging), i found the problem that breaks the keyboard input of my favorite game "You Don't Know Jack" (demos of newer versions downloadable at http://www.take2.de/downloads/demos.php) The problem is that the game is waiting for keyboard input by checking for the messages WM_KEYDOWN, WM_CHAR and WM_KEYUP at least for the keys 1-0 and a-z. But wine generates the messages WM_SYSKEYDOWN, WM_SYSCHAR? and WM_SYSKEYUP. The problem is in the file "windows/message.c" in the methode "process_raw_keyboard_message" in the line 383: if (msg->message < WM_SYSKEYDOWN) msg->message += WM_SYSKEYDOWN - WM_KEYDOWN; For some reason i do not understand the message becomes changed. If i remove this line the game recognize the keyboard input and is playable (somehow). An other option(untested) for the game is to change the line to something like this: if (msg->message < WM_KEYDOWN) msg->message += WM_SYSKEYDOWN - WM_KEYDOWN; Does anyone know why the message becomes changed? Or does anyone know a better fix for the problem? Is there a program the need the line as it is? Tschüß Stefan PS: I am not subscriped to this mailing list, but i'm reading the newsgroup wine.devel. So it will take some time to see my answers to your questions in the mailing list

3 3

Re: keyboard problem
by Gerard Patel Aug. 27, 2001

Aug. 27, 2001

At 05:49 PM 26/08/2001 -0700, you (Daniel Sabo) wrote: <snip> >As far as i can see the function is ok, maybe GetFocus is bugged? > >static BOOL process_raw_keyboard_message( MSG *msg, ULONG_PTR extra_info ) >{ > if (!(msg->hwnd = GetFocus())) > { > /* Send the message to the active window instead, */ > /* translating messages to their WM_SYS equivalent */ > msg->hwnd = GetActiveWindow(); > if (msg->message < WM_SYSKEYDOWN) msg->message += WM_SYSKEYDOWN - WM_KEYDOWN; > } >... I doubt GetFocus is bugged. What is quite probable is that the focus/active window handling is not behaving like Windows does (if there is really *one* behaviour in the different versions of Windows, that is). Another possibility (less probable in this case) could be that the Ms doc about WM_SYS* messages is inaccurate or incomplete. Gerard

1 0

undefined symbol send
by lawson_whitney＠juno.com Aug. 25, 2001

Aug. 25, 2001

Good day! I just got a new binutils about a year ago (well, maybe it was 2) to keep up with y'all. Is my as dragging again? make[1]: Entering directory `/oof/Wine-20010824/loader/dos' gcc -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boun dary=2 -fPIC -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o dosmod ./dosmod.c /tmp/cc1rBlP7.s: Assembler messages: /tmp/cc1rBlP7.s:1355: Error: undefined symbol send in operation /tmp/cc1rBlP7.s:1355: Error: undefined symbol signal in operation make[1]: *** [dosmod] Error 1 make[1]: Leaving directory `/oof/Wine-20010824/loader/dos' make: *** [loader/dos/dosmod] Error 2 [whit(a)giftie Wine-20010824]$ as --version GNU assembler 2.10.90 Copyright 2000 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `i586-mandrake-linux'. Regards, Lawson ---oof--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 1

__ws_select
by Robert Lunnon Aug. 25, 2001

Aug. 25, 2001

I'm trying to hack on wine to get it working properly on Solaris X86. Now that the basic things are working on Solaris, I have run into a problem with networking. The Network apps block on a read operation. Here is a debug trace of ftp for example bash-2.03$ wine ftp -debugmsg +winsock,+thread -managed trace:winsock:WSOCK32_LibMain 0xdf630000 0x1 1 trace:winsock:WSAStartup verReq=101 trace:winsock:WSAStartup succeeded trace:winsock:WSOCK32_getservbyname 'ftp', 'tcp' fixme:console:SetConsoleCtrlHandler (1001dc5,1) - no error checking or testing yet ftp> o ftp.cdrom.com trace:winsock:WSOCK32_gethostbyname ftp.cdrom.com trace:winsock:WSOCK32_socket af=2 type=1 protocol=0 trace:winsock:WSOCK32_socket created 0030 trace:winsock:WSOCK32_bind socket 0030, ptr 1008700, length 16 trace:winsock:WSOCK32_setsockopt socket 0030, lev 65535, opt 0x8, ptr df7666d4, len 4 trace:winsock:WSOCK32_connect socket 0030, ptr 1008700, length 16 trace:winsock:WSOCK32_getsockname socket: 0030, ptr 1008760, ptr 10 Connected to wcarchive.cdrom.com. trace:winsock:__ws_select read df766570, write 0, excp 0 trace:winsock:fd_set_unimport Connection closed by remote host. ftp> Can anyone give me a starting point, I only have basic tcp knowledge Thanks in advance Bob

1 0

ICQ 2000b
by Daniel Walker Aug. 24, 2001

Aug. 24, 2001

ICQ appears to get in some kind of loop. It eventually crashes with a stack overflow, but there are 16000+ lines in the backtrace so .... The sequence below repeats over and over in the backtrace .. Wine did load this application at one time, right? Or has someone seen this before? Daniel Walker 16429 0x406eb4ac (SendMessageA+0x38(hwnd=0x2a0, msg=0x47, wparam=0x0, lparam=0x405b5858) [message.c:1588] in libuser32.so) (ebp=405b57bc) 16430 0x40a7add6 (X11DRV_SetWindowPos+0x632(winpos=0x405b5858) [winpos.c:856] in libx11drv.so) (ebp=405b5840) 16431 0x40747a3c (SetWindowPos+0x50(hwnd=0x2a0, hwndInsertAfter=0x0, x=0x0, y=0x0, cx=0x0, cy=0x0, flags=0x40) [winpos.c:1840] in libuser32.so) (ebp=405b5874) 16432 0x408f561b (SHAppBarMessage+0x147(msg=0x9, data=0x405b58d0) [shell32_main.c:537] in libshell32.so) (ebp=405b58b4) 16433 0x2194bca6 (ICQCORE.DLL.?AlwaysCheckBounds(a)BCDbListCtrl@@UAE_NXZ+0x403 in C:\PROGRAM FILES\ICQ\ICQCORE.DLL) (ebp=405b5904) 16434 0x2194c273 (ICQCORE.DLL.?AlwaysCheckBounds(a)BCDbListCtrl@@UAE_NXZ+0x9d0 in C:\PROGRAM FILES\ICQ\ICQCORE.DLL) (ebp=405b5998) 16435 0x5f401cea (MFC42.DLL.6374+0x22 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b59b8) 16436 0x5f401c73 (MFC42.DLL.1109+0x74 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b5a18) 16437 0x5f401bfb (MFC42.DLL.1578+0x2a in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b5a34) 16438 0x5f401bba (MFC42.DLL.1579+0x39 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b5a60) 16439 0x40748037 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405b5a84) 16440 0x407480b9 (WINPROC_CallWndProc+0x75(proc=0x5f401b81, hwnd=0x2a0, msg=0x47, wParam=0x0, lParam=0x405b5c4c) [winproc.c:171] in libuser32.so) (ebp=405b5ab0) 16441 0x4074db5e (CallWindowProcA+0x3a(func=0x5f401b81, hwnd=0x2a0, msg=0x47, wParam=0x0, lParam=0x405b5c4c) [winproc.c:2656] in libuser32.so) (ebp=405b5ad8) 16442 0x406ea6d6 (call_window_proc+0xc2(hwnd=0x2a0, msg=0x47, wparam=0x0, lparam=0x405b5c4c, unicode=0x0) [message.c:1112] in libuser32.so) (ebp=405b5b24) 16443 0x406eb333 (SendMessageTimeoutA+0xcf(hwnd=0x2a0, msg=0x47, wparam=0x0, lparam=0x405b5c4c, flags=0x0, timeout=0xffffffff, res_ptr=0x405b5bac, hwnd=0x2a0) [message.c:1566] in libuser32.so) (ebp=405b5b7c) 16444 0x406eb4ac (SendMessageA+0x38(hwnd=0x2a0, msg=0x47, wparam=0x0, lparam=0x405b5c4c) [message.c:1588] in libuser32.so) (ebp=405b5bb0) 16445 0x40a7add6 (X11DRV_SetWindowPos+0x632(winpos=0x405b5c4c) [winpos.c:856] in libx11drv.so) (ebp=405b5c34) 16446 0x40747a3c (SetWindowPos+0x50(hwnd=0x2a0, hwndInsertAfter=0x0, x=0x0, y=0x0, cx=0x0, cy=0x0, flags=0x40) [winpos.c:1840] in libuser32.so) (ebp=405b5c68) 16447 0x408f561b (SHAppBarMessage+0x147(msg=0x9, data=0x405b5cc4) [shell32_main.c:537] in libshell32.so) (ebp=405b5ca8) 16448 0x2194bca6 (ICQCORE.DLL.?AlwaysCheckBounds(a)BCDbListCtrl@@UAE_NXZ+0x403 in C:\PROGRAM FILES\ICQ\ICQCORE.DLL) (ebp=405b5cf8) 16449 0x2194c273 (ICQCORE.DLL.?AlwaysCheckBounds(a)BCDbListCtrl@@UAE_NXZ+0x9d0 in C:\PROGRAM FILES\ICQ\ICQCORE.DLL) (ebp=405b5d8c) 16450 0x5f401cea (MFC42.DLL.6374+0x22 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b5dac) 16451 0x5f401c73 (MFC42.DLL.1109+0x74 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b5e0c) 16452 0x5f401bfb (MFC42.DLL.1578+0x2a in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b5e28) 16453 0x5f401bba (MFC42.DLL.1579+0x39 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b5e54) 16454 0x40748037 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405b5e78) 16455 0x407480b9 (WINPROC_CallWndProc+0x75(proc=0x5f401b81, hwnd=0x2a0, msg=0x47, wParam=0x0, lParam=0x405b6040) [winproc.c:171] in libuser32.so) (ebp=405b5ea4) 16456 0x4074db5e (CallWindowProcA+0x3a(func=0x5f401b81, hwnd=0x2a0, msg=0x47, wParam=0x0, lParam=0x405b6040) [winproc.c:2656] in libuser32.so) (ebp=405b5ecc) 16457 0x406ea6d6 (call_window_proc+0xc2(hwnd=0x2a0, msg=0x47, wparam=0x0, lparam=0x405b6040, unicode=0x0) [message.c:1112] in libuser32.so) (ebp=405b5f18) 16458 0x406eb333 (SendMessageTimeoutA+0xcf(hwnd=0x2a0, msg=0x47, wparam=0x0, lparam=0x405b6040, flags=0x0, timeout=0xffffffff, res_ptr=0x405b5fa0, hwnd=0x2a0) [message.c:1566] in libuser32.so) (ebp=405b5f70) [Here is the very begining, this doesn't repeat.] 16460 0x40a7add6 (X11DRV_SetWindowPos+0x632(winpos=0x405b6040) [winpos.c:856] in libx11drv.so) (ebp=405b6028) 16461 0x40747a3c (SetWindowPos+0x50(hwnd=0x2a0, hwndInsertAfter=0x0, x=0x0, y=0x0, cx=0x0, cy=0x0, flags=0x40) [winpos.c:1840] in libuser32.so) (ebp=405b605c) 16462 0x408f561b (SHAppBarMessage+0x147(msg=0x0, data=0x405b60b8) [shell32_main.c:537] in libshell32.so) (ebp=405b609c) 16463 0x2194bca6 (ICQCORE.DLL.?AlwaysCheckBounds(a)BCDbListCtrl@@UAE_NXZ+0x403 in C:\PROGRAM FILES\ICQ\ICQCORE.DLL) (ebp=405b60ec) 16464 0x2194c1e9 (ICQCORE.DLL.?AlwaysCheckBounds(a)BCDbListCtrl@@UAE_NXZ+0x946 in C:\PROGRAM FILES\ICQ\ICQCORE.DLL) (ebp=405b6118) 16465 0x5f401f1b (MFC42.DLL.5163+0x20f in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b6194) 16466 0x5f401cea (MFC42.DLL.6374+0x22 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b61b4) 16467 0x5f401c73 (MFC42.DLL.1109+0x74 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b6214) 16468 0x5f401bfb (MFC42.DLL.1578+0x2a in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b6230) 16469 0x5f401bba (MFC42.DLL.1579+0x39 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b625c) 16470 0x40748037 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405b6280) 16471 0x407480b9 (WINPROC_CallWndProc+0x75(proc=0x5f401b81, hwnd=0x2a0, msg=0x1, wParam=0x0, lParam=0x403b09d4) [winproc.c:171] in libuser32.so) (ebp=405b62ac) 16472 0x4074d76d (WINPROC_CallProc32WTo32A+0x85(func=0x5f401b81, hwnd=0x2a0, msg=0x1, wParam=0x0, lParam=0x403b09d4) [winproc.c:2441] in libuser32.so) (ebp=405b62d4) 16473 0x4074dca7 (CallWindowProcW+0x93(func=0x41030b41, hwnd=0x2a0, msg=0x1, wParam=0x0, lParam=0x405b66b4) [winproc.c:2692] in libuser32.so) (ebp=405b62fc) 16474 0x406ea6b1 (call_window_proc+0x9d(hwnd=0x2a0, msg=0x1, wparam=0x0, lparam=0x405b66b4, unicode=0x1) [message.c:1108] in libuser32.so) (ebp=405b6348) 16475 0x406eb1f4 (SendMessageTimeoutW+0xc8(hwnd=0x2a0, msg=0x1, wparam=0x0, lparam=0x405b66b4, flags=0x0, timeout=0xffffffff, res_ptr=0x405b63cc) [message.c:1508] in libuser32.so) (ebp=405b639c) 16476 0x406eb460 (SendMessageW+0x38(hwnd=0x2a0, msg=0x1, wparam=0x0, lparam=0x405b66b4) [message.c:1577] in libuser32.so) (ebp=405b63d0) 16477 0x40a79215 (X11DRV_CreateWindow+0x2dd(hwnd=0x2a0, cs=0x405b66b4, unicode=0x1) [window.c:927] in libx11drv.so) (ebp=405b6418) 16478 0x40741a00 (WIN_CreateWindowEx+0x6d4(cs=0x405b66b4, classAtom=0x8002, type=0x3) [win.c:812] in libuser32.so) (ebp=405b6490) 16479 0x40741fe8 (CreateWindowExW+0x14c(exStyle=0x10080, className=0x8002, windowName=0x21a5e00e, style=0x80cc0044, x=0x0, y=0x0, width=0xad, height=0x10a, parent=0x0, menu=0x0, instance=0x21880000, data=0x0) [win.c:1039] in libuser32.so) (ebp=405b66e4) 16480 0x40723989 (DIALOG_CreateIndirect+0x3ad(hInst=0x21880000, dlgTemplate=0x21a5e034, win32Template=0x1, owner=0x0, dlgProc=0x5f408e75, param=0x0, procType=0x2, modal=0x0) [dialog.c:833] in libuser32.so) (ebp=405b678c) 16481 0x40723dbc (CreateDialogIndirectParamA+0x30(hInst=0x21880000, dlgTemplate=0x21a5dff0, owner=0x0, dlgProc=0x5f408e75, param=0x0) [dialog.c:1006] in libuser32.so) (ebp=405b67c0) 16482 0x5f40a1a1 (MFC42.DLL.2147+0xc9 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b6828) 16483 0x5f40a35e (MFC42.DLL.2168+0x27 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b6cec) 16484 0x00401555 (Icq.exe..text+0x555 in C:\Program Files\ICQ\Icq.exe) (ebp=405b6e0c) 16485 0x5f40b4f3 (MFC42.DLL.1576+0x47 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b6ecc) 16486 0x400d005d (start_process+0x195 [process.c:390] in libntdll.so) (ebp=405b6f30) 16487 0x400d394c (SYSDEPS_DoCallOnStack+0x20(func=0x400cfec8, arg=0x0) [sysdeps.c:183] in libntdll.so) (ebp=405b6ff0) 16488 0x400d39f3 (SYSDEPS_CallOnStack+0x2f in libntdll.so) (ebp=bffff89c) 16489 0x400d3aa0 (SYSDEPS_SwitchToThreadStack+0x94(func=0x400cfec8) [sysdeps.c:238] in libntdll.so) (ebp=bffff8d8) 16490 0x400d03ee (PROCESS_InitWine+0x1ca(argc=0x5, argv=0xbffff954, win16_exe_name=0x804c620, win16_exe_file=0x804c724) [process.c:522] in libntdll.so) (ebp=bffff8f0) 16491 0x0804b1e6 (Letext [main.c] in wine) (ebp=bffff908) 16492 0x402789cb (__libc_start_main+0xff(main=0x804b1cc, argc=0x5, argv=0xbffff954, init=0x80486d4, fini=0x804b224, rtld_fini=0x4000ae60, stack_end=0xbffff94c) [libc-start.c:92] in libc.so.6) (ebp=bffff928) 16493 0x08049021 (_start+0x21 in wine) (ebp=00000000)

2 2

Re: dumping utility
by Alexandre Julliard Aug. 24, 2001

Aug. 24, 2001

eric pouech <eric.pouech(a)wanadoo.fr> writes: > what about winextract ? Seems a bit too generic, google turns up a number of Windows programs with this name already. I guess we should start a naming contest ;-) Maybe winedump? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: dumping utility
by Alexandre Julliard Aug. 24, 2001

Aug. 24, 2001

Marcus Meissner <marcus(a)jet.franken.de> writes: > Actually for Caldera I am already putting all non-user called programs > (wineserver,winedbg,wineshelllink, and dosmod) into /usr/lib/wine. At least wineserver and winedbg can legitimately be started directly, so I would leave them in /usr/bin. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: dumping utility
by Alexandre Julliard Aug. 24, 2001

Aug. 24, 2001

eric pouech <eric.pouech(a)wanadoo.fr> writes: > I choose the later because I didn't like to have a dump utility > named specmaker... however, we can go back to the former, and go > for another name ;-) I think that may be better. And a name starting in 'wine' would be better than specmaker anyway, this would make sure we don't conflict with other projects. -- Alexandre Julliard julliard(a)winehq.com

3 2

Re: Wininet vs. winsock.h
by Alexandre Julliard Aug. 24, 2001

Aug. 24, 2001

Francois Gouget <fgouget(a)free.fr> writes: > I recently discovered that xemacs does colorization of diffs when > they have a .diff extension. So I changed the naming convention for my > patches. Also if you modify '/etc/mime.types' to contain 'text/plain txt > text diff' (soon to be the default in Debian) you can read such files > without problem from within pine. If you could convince pine to not encode your patches in base64 that would be even better. It makes my life easier when I can simply pipe the whole mail into patch, instead of having to decode mime stuff first. In fact unless your mailer mangles white space, simply putting the patch inline is better than as an mime attachment. -- Alexandre Julliard julliard(a)winehq.com

1 0

WSAStartup16
by Francois Gouget Aug. 24, 2001

Aug. 24, 2001

WSAStartup16 seems wrong. As I understand it all the Win16 structures have a 1 byte alignment. Thus the WSASTARTUP structure used by WSAStartup16 should have a 1 byte alignment. But WSAStartup16 uses the Win32 structure! Why is this important? Here's why: - the last field, lpVendorInfo, will be misaligned - the structure will be larger than it should (by 2 bytes). And since we do a memcpy of sizeof(WSADATA) to the pointer provided by the application we could have a buffer overflow - this creates a dependency between winsock16.h and winsock.h which greatly bothers me Or did I miss something? Changelog: * include/wine/winsock16.h, dlls/winsock/socket.c Add WSASTARTUP16 a 1 byte alignment version of WSASTARTUP for win16 -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

1 0

Re: dumping utility
by Eric Pouech Aug. 24, 2001

Aug. 24, 2001

this can be done of course... I think we could start with a bin hex dumper... if has to be checked whether the x86 disassembler from the debugger could be used here... but a bit of tweaking will be required (like taking care of addresses, how opcodes are read, how output is generated...) OTOH binutils' objdump has greatly evolued and now also includes lots of PE facilities... so I think we'd better focus on pure windows areas (IMO resource dumping is perhaps more needed than the disas feature...) than this one A+ > >>>>> "eric" == eric pouech <eric.pouech(a)wanadoo.fr> writes: > > eric> thanks for your effort. I applied your patch and get the > eric> following: > >> > wine/tools/specmaker> ./pedump -x /dosd/cae/gcprevue/gcprevue.exe > eric> this has to be called with ./pedump -x -d > eric> /dosd/cae/gcprevue/gcprevue.exe as the Usage lines (almost) > eric> mention ;-) > > That looks better with the -d. > > Is pedumper expected to get a disassembler too? > > Bye > -- > Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > > > --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un vu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

1 0

Re: dumping utility
by Uwe Bonnes Aug. 24, 2001

Aug. 24, 2001

eric pouech writes: > this is a first shot at the PE-dump utility for wine > since, lots of code could/will be shared with specmaker (PE image file > browsing, symbol demangling...), I decided to turn specmaker into a > multi-mode utility > > the executable made out of the sources in specmaker dir can now be > launched under 3 different names: > - specmaker: you keep all the old features of specmaker (except -S > option) > - winedemangle: this replaces the -S option of specmaker > - pedump: PE (and .DBG) file dumping utility... lots of PE dir dumping > still > need to be written (like resources or typelib information) > Hallo Eric, thanks for your effort. I applied your patch and get the following: > wine/tools/specmaker> ./pedump -x /dosd/cae/gcprevue/gcprevue.exe > Unrecognized option > Usage: > -h Display this help message > -d <dll> Use dll for input file and generate implementation code > -C Turns on symbol demangling > -f Dumps file header information > -j sect_name Dumps only the content of section sect_name (import, export, debug) > -x Dumps everything Do I do something wrong? Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

2 2

Re: dumping utility
by Alexandre Julliard Aug. 24, 2001

Aug. 24, 2001

eric pouech <eric.pouech(a)wanadoo.fr> writes: > the executable made out of the sources in specmaker dir can now be > launched under 3 different names: > - specmaker: you keep all the old features of specmaker (except -S > option) > - winedemangle: this replaces the -S option of specmaker > - pedump: PE (and .DBG) file dumping utility... lots of PE dir dumping > still This seems to duplicate a lot of code that is in cvdump. Are there still things that cvdump does that your pedump doesn't support, or should I remove cvdump completely? Also I'm not convinced we need a separate winedemangle binary, we are already installing a bit too many things in /usr/bin. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: _CheckNotSysLevel()
by Alexandre Julliard Aug. 23, 2001

Aug. 23, 2001

Daniel Walker <diwalker(a)earthlink.net> writes: > It seems Wise installers break inside _CheckNotSysLevel() . I think > every Wise installer I've tried breaks .. The cuteftp package was one of > them .. How about posting a backtrace? -- Alexandre Julliard julliard(a)winehq.com

3 4

Re: ReadFile and other issues
by Alexandre Julliard Aug. 23, 2001

Aug. 23, 2001

eric pouech <eric.pouech(a)wanadoo.fr> writes: > anyway, I'd like to get back to simple vs complex consoles if I got > you right, a simple console handle should be in fact nothing more > than a regular file handle which unix fd is set to either 0 or 1 it > means that no enhanced mode is used, nothing but the standard libc > line editing facilities of the input stream so the use would > adequate for a simple program that just uses equivalent of puts/gets > (and associated) functions Exactly yes. > however, I find this very limiting for people who want to use a CUI > exe in a pure unix console mode (either when X11 isn't started, or a > session done over IP in telnet for example) that's why I was > wondering if wineconsole shouldn't also support a (n)curse like > interface (in addition to the USER32 one) to help in this area Sure, once the architecture is in place we can have different implementations of wineconsole, including curses support. The important thing is that this is in a separate application, so that ReadConsole doesn't need to know about things like xterm escape sequences. > last but not least, recent exchanges made a simple < 1kloc patch a more > serious project of several kloc :-/ I can do the wineserver part if you like. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: ReadFile and other issues
by Alexandre Julliard Aug. 23, 2001

Aug. 23, 2001

eric pouech <eric.pouech(a)wanadoo.fr> writes: > well, the issue here is that, even in line editing mode, ReadConsole > and ReadConsoleInput can be used. the former drops all non keyboard > events and produces a string, whereas the later returns the available > input records... > so, to implement what you propose, the wineconsole would have to know > in advance which one of the two functions will be called next: > - in case of ReadConsole, it has to keep all incoming input records, and > release just the string when it's done editing the line > - in case of ReadConsoleInput, all generated input records must be > available in the server to the calling app OK I see what you mean. Yes this implies that we must be able to tell the server to only return input events to the thread doing the ReadConsole. If I get this right, it also means line editing has to be done in ReadConsole, and that you can't see what you type when the app is not reading. Very annoying, but I guess it's more Windows-like... -- Alexandre Julliard julliard(a)winehq.com

2 1

_CheckNotSysLevel()
by Daniel Walker Aug. 23, 2001

Aug. 23, 2001

It seems Wise installers break inside _CheckNotSysLevel() . I think every Wise installer I've tried breaks .. The cuteftp package was one of them .. Daniel Walker

1 0

Re: ReadFile and other issues
by Alexandre Julliard Aug. 22, 2001

Aug. 22, 2001

eric pouech <eric.pouech(a)wanadoo.fr> writes: > fairly acceptable ;-) except that in line editing mode we need to lock > the input buffer on a single thread (that's the way the queue is > handled, > at least, on NT 2000 - didn't check the others) (the granularity for > getting access to the queue is not the input record, but the line (up to > '\n')) I guess line editing could be done by wineconsole, and the input records would only be sent to the server once we have a complete line. Or do we need more locking than this? > I was thinking of either a anonmymous file or an anonymous mapping for > the content of the screen buffer... with an array attribute and char > may be some additional info on each row to indicate the rendering > program about the rows which have been modified... The problem with a shared buffer is that you need to lock against simultaneous access, which means a hung thread can hang the whole console. I'd prefer to have the server simply report to wineconsole the bounding rect of the screen buffer area that has been modified, and have wineconsole use ReadConsoleOutput to retrieve the buffer contents from the server. It's only a few Kbytes to copy at most so performance should be acceptable. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: ReadFile and other issues
by Alexandre Julliard Aug. 22, 2001

Aug. 22, 2001

"Eric Pouech"<eric.pouech(a)voila.fr> writes: > if we want to go into this, there are a few points to agree on first: > - since console handles can be inherited, the Wine console window should > be run in a different process than the one which uses the console (and > add communication means between the first process, and the process > rendering the console) > - how should we know a program needs either a simple or a complex > console (we could use a registry key in the per process area) We need a separate process yes. I was thinking of something like a 'wineconsole' Winelib app. Then if you want to run an app with a separate console you use wineconsole instead of wine to start it. A new wineconsole could also be launched when the app does an AllocConsole, or some other function that requires a complex console. The communication with the console can probably go through the server. Input events can simply be put in the queue by wineconsole using WriteConsoleInput. Output should probably go to a server screen buffer object, which would then signal wineconsole that its contents changed. -- Alexandre Julliard julliard(a)winehq.com

2 1

custom CFLAGS
by mdew Aug. 22, 2001

Aug. 22, 2001

too my previous subject... err:module:map_image Could not map section .data, file probably truncated the problem was my custom CFLAGS, which havent caused me too many problems...till lately ...(using wine) export CFLAGS="-O3 -ffast-math -fthread-jumps -fcse-follow-jumps -mpentiumpro -march=pentiumpro -mcpu=i686 -malign-loops=2" err:module:map_image Could not map section .data, file probably truncated /usr/local/bin/wine: can't exec './xxx.exe': error=21 gcc 2.95.4-6 (Debian Sid) I havent tried gcc-3.0.1 yet, i trust gcc-2.95.4 still...give it another few versions before i'll look at gcc3. in paticular is the use of -O3 over -O2, -O2 will work, -O3 will fail..why is that? -- id: 9DF3262C key fingerprint: B556 04DA CFD9 78DD 9215 A970 8196 FB6D 9DF3 262C

2 3

Re: ReadFile and other issues
by Eric Pouech Aug. 22, 2001

Aug. 22, 2001

> I'm not sure we should be converting xterm input into INPUT_RECORD. It > may be better to have two modes, a simple console that returns an fd > to ReadFile and no input records (and then ReadConsoleInput could > generate them on the fly if necessary), and a complex console that > supports all the features but that doesn't have an associated fd at > all. > > IMO the current xterm-based console support is a ugly hack; we should > do a proper Windows console using a normal Wine window with a message > loop to retrieve input events. And usage of stdin/stdout should be > limited to programs that don't need special console features, and > should only support ReadFile/WriteFile. if we want to go into this, there are a few points to agree on first: - since console handles can be inherited, the Wine console window should be run in a different process than the one which uses the console (and add communication means between the first process, and the process rendering the console) - how should we know a program needs either a simple or a complex console (we could use a registry key in the per process area) A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un vu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

1 0

Re: (no subject)
by Alexandre Julliard Aug. 22, 2001

Aug. 22, 2001

Mike McCormack <mike_mccormack(a)start.com.au> writes: > How about returning a function pointer instead of an id? > > When the file handle is registered with the wine-server, we would also > send function pointers for the read and write operations. This way we > could have seperate implementations of ReadFile or WriteFile for > different types of handles... You can't do that. The ReadFile can be done from another process, and the pointer won't be valid there. -- Alexandre Julliard julliard(a)winehq.com

1 0

(no subject)
by Mike McCormack Aug. 22, 2001

Aug. 22, 2001

Hi Eric, How about returning a function pointer instead of an id? When the file handle is registered with the wine-server, we would also send function pointers for the read and write operations. This way we could have seperate implementations of ReadFile or WriteFile for different types of handles... Mike > - extend the get_handle_fd to also return an id corresponding > to the type fd being used. ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: documentation make fix
by Mike McCormack Aug. 21, 2001

Aug. 21, 2001

Yeah, that looks better, and seems to work too. thanks, Mike Original message from: Francois Gouget <fgouget(a)free.fr> > >On Tue, 21 Aug 2001, Mike McCormack wrote: > >> >> Not that anybody uses the documentation anyway... :-) >> >> ChangeLog: >> * recurse all directories when making docs. >> Don't fail if C_SRCS is empty. > > Maybe the attached patch would be a better way to do this: > - use the regular make trick for recursing > - test whether we have targets before entering the for loop > > Note that I did not really test it. > > > Well, I have done a little testing now. And c2man is not happy if you >don't create documentation/man3w beforehand... > So I added an mkdir too, same for doc-html. > > >-- >Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > "Utilisateur" (nom commun) : > Mot utilis� par les informaticiens en lieu et place d'"idiot". ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: reaktivate
by Malte Starostik Aug. 21, 2001

Aug. 21, 2001

Am Montag, 20. August 2001 08:59 schrieb Per Wigren: > I get this when I'm trying to load an Active-X component in konqueror: > > konqueror: /usr/lib/libreaktivate: could not load library > '/usr/lib/libreaktivate.so' as Winelib application: > /usr/X11R6/lib/libXv.so.1: undefined symbol: XGetErrorDatabaseText > > Any ideas what to do? Using cvs from today of both wine and reaktivate. Never seen that one before, but it's IMHO rather a wine problem. Has anyone seen this before? Or, did you by any chance update some but not all X libraries? -- Malte Starostik PGP: 1024D/D2F3C787 [C138 2121 FAF3 410A 1C2A 27CD 5431 7745 D2F3 C787]

1 0

Re: ReadFile and other issues
by Alexandre Julliard Aug. 21, 2001

Aug. 21, 2001

eric pouech <eric.pouech(a)wanadoo.fr> writes: > no, reading of input_records would be sone as it is today, with > the specific console request 'read_console_input' OK, we agree then. > the only thing we'd have to have is another request to get the fd from > a console input handle (get_handle_fd would no longer work), and we > still need a (background) mechanism to convert the unix xterm characters > into INPUT_RECORD (a get_console_fd should do). Anyway, those fd are > even rather static (they only change on Alloc|Free Console and at > process startup if we inherit them from parent), so we can savely keep > them around, process wide I'm not sure we should be converting xterm input into INPUT_RECORD. It may be better to have two modes, a simple console that returns an fd to ReadFile and no input records (and then ReadConsoleInput could generate them on the fly if necessary), and a complex console that supports all the features but that doesn't have an associated fd at all. IMO the current xterm-based console support is a ugly hack; we should do a proper Windows console using a normal Wine window with a message loop to retrieve input events. And usage of stdin/stdout should be limited to programs that don't need special console features, and should only support ReadFile/WriteFile. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: ReadFile and other issues
by Alexandre Julliard Aug. 21, 2001

Aug. 21, 2001

eric pouech <eric.pouech(a)wanadoo.fr> writes: > to implement properly this (mainly the ability to forward ReadFile calls > to ReadConsole for console handles), I'd like to do the following: > - extend the get_handle_fd to also return an id corresponding to the > type fd being used. As of today, handle / fd relationship mainly > assumes that we can map a Windows operation on a handle onto a similar > operation on a unix fd. The ReadFile/ReadConsoleInput doesn't fit in > this category. I'm not sure I understand you right; are you suggesting that get_handle_fd should return an fd from which you can read input records in the case of a console? It would seem preferable to have get_handle_fd simply fail with a special error code saying that the handle is a console, and then ReadFile can fall back to using ReadConsoleInput which doesn't require an fd at all. > - this type of feature would help in other areas too. For example, we > never check that Comm functions really get a Comm handle... Well, we check by the fact that we then do a serial ioctl on the fd, which will fail if it isn't serial. I'm not sure we need more checks. -- Alexandre Julliard julliard(a)winehq.com

2 1

Archive of overlapped serial I/O example code, experiences
by Dan Kegel Aug. 21, 2001

Aug. 21, 2001

For what it's worth, here is some example test code I wrote for win32 demoing overlapped serial I/O: http://www.alumni.caltech.edu/~dank/serio/serio.zip It might be of some use to people testing wine. I haven't tried it yet there. Also, http://www.alumni.caltech.edu/~dank/overlap.htm chronicles the problems many people have had with serial I/O under win95. The messages there get into interesting details of how people use overlapped serial I/O, and how serial I/O really behaves under various flavors of windows. Again, might be of some use, who knows. - Dan -- "I have seen the future, and it licks itself clean." -- Bucky Katt

1 0

ReadFile and other issues
by eric pouech Aug. 21, 2001

Aug. 21, 2001

while we're at talking about the ReadFile implementation with overlapped data, there's (an unrelated) point about ReadFile I'd like to discuss I've started looking at implementing proper console input in Wine (mainly the line mode editing). Apart from providing the functionnality, it would also allow to remove this unneeded code from the debugger the Win32 console input API is made of two layers 1/ the low level : each input event is stored into an INPUT_RECORD struct 2/ the high level which uses the low level events to make strings of them 1/ two functions are used: ReadConsoleInput(A|W) 2/ three functions are used: ReadFile and ReadConsole(A|W) the current implementation in Wine, makes the handle to the console input a file handle to the fd gotten from the console hence, the current implementation is broken in several ways - ReadFile is implemented as a raw read on the input fd, whereas it should be a higher level of function (forwarded from ReadFile to ReadConsole) - wait operations on handle are wrong: currently the handle is signaled as soon as a char is read (at the unix level) from the stdin fd, whereas it should be done at the level of the INPUT_RECORD queue to implement properly this (mainly the ability to forward ReadFile calls to ReadConsole for console handles), I'd like to do the following: - extend the get_handle_fd to also return an id corresponding to the type fd being used. As of today, handle / fd relationship mainly assumes that we can map a Windows operation on a handle onto a similar operation on a unix fd. The ReadFile/ReadConsoleInput doesn't fit in this category. - this type of feature would help in other areas too. For example, we never check that Comm functions really get a Comm handle... would such a mechanism be acceptable ? if so, should we do for every handle in the server, or just the ones we might convert into unix fd (file, consoles, pipes, sockets, "serials"...) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Re: icons uncoloured
by Gerard Patel Aug. 21, 2001

Aug. 21, 2001

At 01:39 PM 21/08/2001 GMT, you wrote: >I've just done a cvs update and recompiled and now the icons come up in >gray, if at all. > >Is this a known issue? I suspect it could be solved by this one I just sent to wine-patches Gerard Index: graphics/x11drv/bitmap.c =================================================================== RCS file: /home/wine/wine/graphics/x11drv/bitmap.c,v retrieving revision 1.32 diff -u -r1.32 bitmap.c --- graphics/x11drv/bitmap.c 2001/08/20 19:19:18 1.32 +++ graphics/x11drv/bitmap.c 2001/08/21 14:17:07 @@ -73,7 +73,7 @@ if (hbitmap == dc->hBitmap) return hbitmap; /* nothing to do */ if (!(bmp = GDI_GetObjPtr( hbitmap, BITMAP_MAGIC ))) return 0; - if (bmp->header.dwCount) + if (bmp->header.dwCount && (hbitmap != GetStockObject(DEFAULT_BITMAP))) { WARN( "Bitmap already selected in another DC\n" ); GDI_ReleaseObj( hbitmap ); ~ ~

2 1

icons uncoloured
by Bill Medland Aug. 21, 2001

Aug. 21, 2001

I've just done a cvs update and recompiled and now the icons come up in gray, if at all. Is this a known issue? Bill

1 0

Re: documentation make fix
by Francois Gouget Aug. 21, 2001

Aug. 21, 2001

On Tue, 21 Aug 2001, Mike McCormack wrote: > > Not that anybody uses the documentation anyway... :-) > > ChangeLog: > * recurse all directories when making docs. > Don't fail if C_SRCS is empty. Maybe the attached patch would be a better way to do this: - use the regular make trick for recursing - test whether we have targets before entering the for loop Note that I did not really test it. Well, I have done a little testing now. And c2man is not happy if you don't create documentation/man3w beforehand... So I added an mkdir too, same for doc-html. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".

1 0

Re: fix for Lawson's CLOCAL problem
by Mike McCormack Aug. 21, 2001

Aug. 21, 2001

Hi Alexandre, >Of course, I have no problem with that. The create_file request takes >attributes, so create_serial can do the same (it would be better if >create_serial were done inside create_file, but that's another >story...) agreed. >> Another question: do you think it would be possible to implement a >> "write memory" message from the wineserver to the client? .. >But that would require multiple copies of the data (and many context >switches for large reads); that wouldn't be very efficient. I think >the current approach is much better. What is the problem with doing >CancelIo? IMO it would be messy to implement CancelIo with the current architecture. If it were all in the server (including actual read and write calls) it might be simpler... but probably not efficient, like you say. i think most of the data transferred from a serial port is pretty small though... but if the scheme was expanded to handle overlapped socket operations that wouldn't be true. Additionally, i though it might be useful to have a way to write small chunks of data to the client's memory. For example, when implementing WaitForNamedPipe and ConnectNamedPipe, i need to write a result code into an overlapped structure... it's only 4 bytes, but i need to create a new type of APC to deal with it. If i had a method to write directly into client memory, it would be simpler. Mike ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: fix for Lawson's CLOCAL problem
by Alexandre Julliard Aug. 21, 2001

Aug. 21, 2001

Mike McCormack <mike_mccormack(a)start.com.au> writes: > Hmmm. i'm not exactly sure about this. i don't think the server ever > blocked on serial port reads or opens... i think the reason Lawson had > problems was that the client thread was blocking in the overlapped > read code. (FILE_AsyncReadService in files/file.c) I don't know if this was Lawson problem, but open() can potentially block on a serial port, and we cannot have that in the server; so your change to set O_NONBLOCK is good, but it shouldn't depend on FILE_FLAG_OVERLAPPED. > If we use non-blocking fds unconditionally, a non overlapped ReadFile > may result in a busy loop in the client thread. Sure, you need to reset the O_NONBLOCK flag to do blocking reads. > Additionally, overlapped read (and write) requests should fail unless > the handle is opened with FILE_FLAG_OVERLAPPED. There are programs > that depend on that behaviour (as reported by Eric Kohl, 3 Feb 2001 on > this list). This is another reason to propagate CreateFile's > attributes parameter into the wineserver. Of course, I have no problem with that. The create_file request takes attributes, so create_serial can do the same (it would be better if create_serial were done inside create_file, but that's another story...) > Another question: do you think it would be possible to implement a > "write memory" message from the wineserver to the client? This message > would be carried over wait_fd and would be received by the client > asynchronously in wait_reply(). The message would contain a length, > address and data to be written. If this is possible, i could move > async i/o back into the server, keep it efficient and perhaps > implement CancelIo properly... But that would require multiple copies of the data (and many context switches for large reads); that wouldn't be very efficient. I think the current approach is much better. What is the problem with doing CancelIo? -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: winsock stuff
by Daniel Walker Aug. 21, 2001

Aug. 21, 2001

This seems to work.. Daniel Walker --- server/sock.c 2001/05/14 20:09:39 1.18 +++ server/sock.c 2001/08/21 01:31:04 @@ -113,9 +113,14 @@ { struct sock *sock = (struct sock *)obj; unsigned int emask; + char rBuf; assert( sock->obj.ops == &sock_ops ); if (debug_level) fprintf(stderr, "socket %d select event: %x\n", sock->obj.fd, event); + + if (event == POLLIN && !recvfrom(sock->obj.fd, &rBuf, sizeof(rBuf), MSG_PEEK, NULL, NULL)) + event = POLLHUP; + if (sock->state & WS_FD_CONNECT) { /* connecting */

1 0

Re: fix for Lawson's CLOCAL problem
by Mike McCormack Aug. 21, 2001

Aug. 21, 2001

Hi Alexandre, Hmmm. i'm not exactly sure about this. i don't think the server ever blocked on serial port reads or opens... i think the reason Lawson had problems was that the client thread was blocking in the overlapped read code. (FILE_AsyncReadService in files/file.c) If we use non-blocking fds unconditionally, a non overlapped ReadFile may result in a busy loop in the client thread. Additionally, overlapped read (and write) requests should fail unless the handle is opened with FILE_FLAG_OVERLAPPED. There are programs that depend on that behaviour (as reported by Eric Kohl, 3 Feb 2001 on this list). This is another reason to propagate CreateFile's attributes parameter into the wineserver. Another question: do you think it would be possible to implement a "write memory" message from the wineserver to the client? This message would be carried over wait_fd and would be received by the client asynchronously in wait_reply(). The message would contain a length, address and data to be written. If this is possible, i could move async i/o back into the server, keep it efficient and perhaps implement CancelIo properly... Mike > The open on the server side must always be non-blocking, we cannot > have the server block on anything. If there are cases where we need to > block on open, it will have to be done on the client side. ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: winsock stuff
by Alexandre Julliard Aug. 21, 2001

Aug. 21, 2001

Daniel Walker <diwalker(a)earthlink.net> writes: > How is it unreliable? Why is MSG_PEEK more reliable? I'm not opposed to > using MSG_PEEK , just curios.. FIONREAD is unreliable because you cannot distinguish between an EOF condition and an empty receive buffer. recvmsg(MSG_PEEK) is supposed to return 0 on EOF, and EWOULDBLOCK on empty buffer, so you can determine the real status. > Another issue is why doesn't poll() give > us a POLLHUP? That would be ideal, get poll() to work the way we need it > too. As I understand it poll() returns POLLHUP only when both directions of the socket have been closed; but if you shutdown() only the read or write side, you don't get POLLHUP so that you can continue using poll() for the other direction. This has apparently been changed between kernels 2.2 and 2.4; in 2.2 POLLHUP is returned as soon as the read side of the socket has been closed. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: winsock stuff
by Alexandre Julliard Aug. 21, 2001

Aug. 21, 2001

Daniel Walker <diwalker(a)earthlink.net> writes: > To improve on this patch we could only do the FIONREAD if the sock is > in a non-blocking state. That's the only time that doing the FIONREAD > would be an advantage. Also we wouldn't need to worry about screwing up > blocking sockets. Even further, we could only do the FIONREAD if socket > is non-blocking and looking for an FD_CLOSE event. Using FIONREAD is simply not an option, it cannot be made reliable. A possibility to detect EOF could be a recvmsg with MSG_PEEK flag, though you should probably verify first that it behaves as expected. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: winsock stuff
by Alexandre Julliard Aug. 20, 2001

Aug. 20, 2001

Daniel Walker <diwalker(a)earthlink.net> writes: > I noticed that WSAEnumNetworkEvents() was returning all events that had > occurred and not just the events that had been selected with > WSAEventsSelect(). Win98 will trigger the event object for all events > but WSAEnumNetworkEvents() (in win98) would return zero if the event > hadn't been selected. I was trying to gain compatibility with win98. I'd suggest doing the masking in WSAEnumNetworkEvents then. > An FD_READ event with a zero buffer would mean that the other side > closed the connection so it would be equivalent to a POLLHUP from poll() > .. I didn't find an occasion when poll() actually returned POLLHUP when > the socket closed, on Linux anyway. The application that I was testing > got confused when recv() returned zero. Even though recv() can legally > return zero, I think non-blocking applications are going to be looking > for FD_CLOSE events as opposed to recv() returning zero. But FIONREAD can return 0 bytes even when the socket isn't closed (for instance if another thread got the data first). You can only determine that it was really closed when you do the actual read. So I don't really see how we can avoid having recv() return zero; well maybe we can make it return EWOULDBLOCK and tell the server the connection is closed, but I'm not sure it's any better. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: winsock stuff
by Alexandre Julliard Aug. 20, 2001

Aug. 20, 2001

Daniel Walker <diwalker(a)earthlink.net> writes: > -changed get_socket_event() so it only returns events that > the application is looking for. > -Changed sock_poll_event() to interpret a POLLIN event with > zero bytes waiting to be read as a POLLHUP. This doesn't look really right to me. Could you please explain a bit more what it is supposed to fix? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Refcounting in SelectObject
by Alexandre Julliard Aug. 20, 2001

Aug. 20, 2001

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Appended code tries to clean up better by: > - Remembering an unsuccessfull DeleteObject by adding 0x8000 to the Refcount > - Call DeleteObject in SelectObject when the RefCount of the released handle > is 0x8000 > - Decrementing the RefCount when a hBitmap is still selected into a DC when > DeleteDC is called for that DC > - Call DeleteObject in DeleteDC when RefCount is 0x8000 > > For some applications I tested, I always saw the delayed DeleteObject done > after the refused DeleteObject in the first place. Is this approach better? Yes, looks good. Though we can probably safely use the dwCount field in GDIOBJHDR since it is not used for anything useful right now, instead of adding new fields. I've changed that and applied the patch. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: fix for Lawson's CLOCAL problem
by Alexandre Julliard Aug. 20, 2001

Aug. 20, 2001

Mike McCormack <mike_mccormack(a)start.com.au> writes: > Open serial ports with O_NONBLOCK if FILE_FLAG_OVERLAPPED is > specified. The open on the server side must always be non-blocking, we cannot have the server block on anything. If there are cases where we need to block on open, it will have to be done on the client side. -- Alexandre Julliard julliard(a)winehq.com

1 0

-clocal and the wineserver
by lawson_whitney＠juno.com Aug. 19, 2001

Aug. 19, 2001

Good day! Any time clocal falls out of the modem's termios (say I use cu -l on it) the wineserver hangs trying to open it, or at least the app hangs, and I haven't found a way to kill it without killing the wineserver. Both 16 and 32 bit versions of juno are affected. I haven't really investigated it very thouroughly, but I wasted a lot of time restoring backup versions of the app and wine. Should I look into mickey-mousing the open to avoid the problem, or - is it really a wineserver problem which I am probably not even marginally competent to muck with? I'd be glad to make traces or winedbg output, but it seems the problem should be easy to duplicate. Hmmm, setting clocal back on from another terminal unhangs the app. That is neater than killing the wineserver, I guess. terminal.exe from wfw 3.11 behaves similarly, with an extra twist: it hangs on the Win16Mutex until somebody sets clocal (well, I guess carrier detect would work, too). [whit(a)giftie user0001]$ wine terminal.exe err:ntdll:RtlpWaitForCriticalSection section 0x400fad6c "syslevel.c: Win16Mutex" wait timed out, retrying (60 sec) fs=008f fixme:pthread_kill_other_threads_np Console: Making console complex (creating an xterm)... fixme:pthread_kill_other_threads_np fixme:pthread_kill_other_threads_np fixme:pthread_kill_other_threads_np fixme:pthread_kill_other_threads_np Warning: locale not supported by Xlib, locale set to C Warning: X locale modifiers not supported, using default xterm: unable to open font "vga", trying "fixed".... Failed to open input method passed master doesn't match slave name passed master doesn't match slave name [whit(a)giftie user0001]$ Regards, Lawson ---oof--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0

Re: PATCH: olepictures black & white
by Alexandre Julliard Aug. 19, 2001

Aug. 19, 2001

Marcus Meissner <marcus(a)jet.franken.de> writes: > Somehow the loaded JPEGs are now black & white in the IPicture implementation. > > Exchanging CreateCompatibleDC(0) by CreateDCA("DISPLAY",0,0,0); makes > them colored again. > > But I am not sure whether the problem itself was a bug on my side, or > on the WINE side... Maybe a bit of both... I think the patch below should fix the GDI part; but is there any reason you don't use GetDC(0) instead of CreateCompatibleDC? It would avoid creating a new DC every time. Index: objects/dib.c =================================================================== RCS file: /opt/cvs-commit/wine/objects/dib.c,v retrieving revision 1.60 diff -u -r1.60 dib.c --- objects/dib.c 2001/08/17 00:07:42 1.60 +++ objects/dib.c 2001/08/19 19:27:42 @@ -875,7 +875,9 @@ /* Now create the bitmap */ - if (fColor) handle = CreateCompatibleBitmap( hdc, width, height ); + if (fColor) + handle = CreateBitmap( width, height, GetDeviceCaps( hdc, PLANES ), + GetDeviceCaps( hdc, BITSPIXEL ), NULL ); else handle = CreateBitmap( width, height, 1, 1, NULL ); if (!handle) return 0; -- Alexandre Julliard julliard(a)winehq.com

1 0

PATCH: oleauto header problem
by Nikolas Zimmermann Aug. 19, 2001

Aug. 19, 2001

Hi there, Reaktivate doesn't compile anymore. We need this patch. Bye Bye Niko -- Nikolas Zimmermann wildfox(a)kde.org

1 0

Re: WM_GETTEXTLENGTH change in winproc.c
by Gerard Patel Aug. 19, 2001

Aug. 19, 2001

At 02:35 PM 18/08/2001 -0700, you wrote: >For standard controls like buttons it should never be a problem since >there is both an ASCII and Unicode win proc, so in a pure ASCII app we >should never do the conversion. I think the problem is that the >dialog code does a CreateWindowW, so the button is Unicode even though >the app does everything in ASCII. I guess we'll have to maintain both >A and W win procs inside each window, not only inside the class. How about creating Ascii windows when the app calls DialogBox..A variants ? Gerard

1 0

Re: WM_GETTEXTLENGTH change in winproc.c
by Alexandre Julliard Aug. 18, 2001

Aug. 18, 2001

Gerard Patel <gerard.patel(a)nerim.net> writes: > How about creating Ascii windows when the app calls DialogBox..A variants ? That could be a workaround, but since dialog resources are Unicode it's better to avoid converting back and forth. Besides, Windows maintains two different win procs for windows of standard classes so we should do it this way too. I'll try to come up with something. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: WM_GETTEXTLENGTH change in winproc.c
by Gerard Patel Aug. 18, 2001

Aug. 18, 2001

At 01:19 PM 18/08/2001 -0700, you wrote: > >The idea is that 6 Unicode chars can yield more than 6 ASCII chars >with DBCS text. The MSDN doc states that WM_GETTEXTLENGTH can return >more than the actual size when mixing ASCII and Unicode. > >What does the app do exactly? Maybe there are cases where the >conversion can be avoided. WM_GETTEXTLENGTH, WM_GETTEXT, then DrawText with the length returned by WM_GETTEXTLENGTH. If the app had used the length returned by WM_GETTEXT, it would have worked all right of course - maybe that's the reason why the problem does not appear more often ? In the following trace Cancel is the text of a button in a dialog box. Gerard 080682e8:Call window proc 0x5f404ae6 (hwnd=000026dc,msg=WM_DRAWITEM,wp=00000002,lp=40586474) 080682e8:Call user32.GetPropA(000026dc,5f49c94c "AfxOldWndProc423") ret=5f404b09 080682e8:Ret user32.GetPropA() retval=40ac0259 ret=5f404b09 080682e8:Call user32.CallWindowProcA(40ac0259,000026dc,0000002b,00000002,40586474) ret=5f404b4b 080682e8:Call window proc 0x406a7980 (hwnd=000026dc,msg=WM_DRAWITEM,wp=00000002,lp=40586474) 080682e8:Call window proc 0x43d715 (hwnd=000026dc,msg=WM_DRAWITEM,wp=00000002,lp=40586474) 080682e8:Call user32.GetWindowLongA(000026dc,00000008) ret=0043d727 080682e8:Ret user32.GetWindowLongA() retval=40586914 ret=0043d727 080682e8:Call user32.GetWindowTextLengthA(00002e0c) ret=0043bb82 trace:message:SPY_EnterMessage (00002e0c) "Cancel" message [000e] WM_GETTEXTLENGTH sent from self wp=00000000 lp=00000000 080682e8:Call window proc 0x43d28b (hwnd=00002e0c,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) 080682e8:Call user32.CallWindowProcA(40ac00f1,00002e0c,0000000e,00000000,00000000) ret=0043d2b8 080682e8:Call window proc 0x40679e8c (hwnd=00002e0c,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) trace:message:SPY_EnterMessage (00002e0c) DefWindowProc32: WM_GETTEXTLENGTH [000e] wp=00000000 lp=00000000 trace:message:SPY_ExitMessage (00002e0c) DefWindowProc32: WM_GETTEXTLENGTH [000e] returned 00000006 080682e8:Ret window proc 0x40679e8c (hwnd=00002e0c,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) retval=00000006 080682e8:Ret user32.CallWindowProcA() retval=0000000c ret=0043d2b8 080682e8:Ret window proc 0x43d28b (hwnd=00002e0c,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) retval=0000000c trace:message:SPY_ExitMessage (00002e0c) "Cancel" message [000e] WM_GETTEXTLENGTH returned 0000000c 080682e8:Ret user32.GetWindowTextLengthA() retval=0000000c ret=0043bb82 080682e8:Call ntdll.RtlEnterCriticalSection(5f4d0088) ret=5f4020bd 080682e8:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=5f4020bd 080682e8:Call ntdll.RtlLeaveCriticalSection(5f4d0088) ret=5f402103 080682e8:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=5f402103 080682e8:Call user32.GetWindowTextA(00002e0c,413904e0,0000000d) ret=0043bba9 trace:message:SPY_EnterMessage (00002e0c) "Cancel" message [000d] WM_GETTEXT sent from self wp=0000000d lp=413904e0 080682e8:Call window proc 0x43d28b (hwnd=00002e0c,msg=WM_GETTEXT,wp=0000000d,lp=413904e0) 080682e8:Call user32.CallWindowProcA(40ac00f1,00002e0c,0000000d,0000000d,413904e0) ret=0043d2b8 080682e8:Call window proc 0x40679e8c (hwnd=00002e0c,msg=WM_GETTEXT,wp=0000000d,lp=403a7328) trace:message:SPY_EnterMessage (00002e0c) DefWindowProc32: WM_GETTEXT [000d] wp=0000000d lp=403a7328 trace:message:SPY_ExitMessage (00002e0c) DefWindowProc32: WM_GETTEXT [000d] returned 00000006 080682e8:Ret window proc 0x40679e8c (hwnd=00002e0c,msg=WM_GETTEXT,wp=0000000d,lp=403a7328) retval=00000006 080682e8:Ret user32.CallWindowProcA() retval=00000006 ret=0043d2b8 080682e8:Ret window proc 0x43d28b (hwnd=00002e0c,msg=WM_GETTEXT,wp=0000000d,lp=413904e0) retval=00000006 trace:message:SPY_ExitMessage (00002e0c) "Cancel" message [000d] WM_GETTEXT returned 00000006 080682e8:Ret user32.GetWindowTextA() retval=00000006 ret=0043bba9 <snip unrelated painting instructions> 080682e8:Call gdi32.GetTextExtentPoint32A(00000088,413b00d0,00000006,40585f68) ret=0043c022 080682e8:Call x11drv.GetTextExtentPoint(4037c808,4039d238,00000006,40585f68) ret=40747c04 trace:text:X11DRV_GetTextExtentPoint L"Cancel"... 6 080682e8:Ret x11drv.GetTextExtentPoint() retval=00000001 ret=40747c04 080682e8:Ret gdi32.GetTextExtentPoint32A() retval=00000001 ret=0043c022 <snip a few text painting preparation> 080682e8:Call user32.DrawTextA(00000088,413904e0 "Cancel",0000000c,40585f28,00000100) ret=0043c13a trace:text:DrawTextExW L"Cancel", 12 , [(9,4),(51,20)]

1 0

Re: WM_GETTEXTLENGTH change in winproc.c
by Alexandre Julliard Aug. 18, 2001

Aug. 18, 2001

Gerard Patel <gerard.patel(a)nerim.net> writes: > WM_GETTEXTLENGTH, WM_GETTEXT, then DrawText with the > length returned by WM_GETTEXTLENGTH. > If the app had used the length returned by WM_GETTEXT, it would > have worked all right of course - maybe that's the reason why > the problem does not appear more often ? For standard controls like buttons it should never be a problem since there is both an ASCII and Unicode win proc, so in a pure ASCII app we should never do the conversion. I think the problem is that the dialog code does a CreateWindowW, so the button is Unicode even though the app does everything in ASCII. I guess we'll have to maintain both A and W win procs inside each window, not only inside the class. -- Alexandre Julliard julliard(a)winehq.com

1 0

WM_GETTEXTLENGTH change in winproc.c
by Gerard Patel Aug. 18, 2001

Aug. 18, 2001

I don't understand it : case WM_GETTEXTLENGTH: 719 case CB_GETLBTEXTLEN: 720 case LB_GETTEXTLEN: 721 /* there may be one DBCS char for each Unicode char */ 722 return result * 2; This has a bad effect on one of my test apps - returns a length of 12 for a text of 6 characters, displays funny symbols after the text. The Unicode window proc returns 6, why the unicode/ascii conversion should make it 12 ? The Api returns number of chars, not bytes. Gerard

1 0

Re: WM_GETTEXTLENGTH change in winproc.c
by Alexandre Julliard Aug. 18, 2001

Aug. 18, 2001

Gerard Patel <gerard.patel(a)nerim.net> writes: > I don't understand it : > > case WM_GETTEXTLENGTH: > 719 case CB_GETLBTEXTLEN: > 720 case LB_GETTEXTLEN: > 721 /* there may be one DBCS char for each Unicode char */ > 722 return result * 2; > > This has a bad effect on one of my test apps - returns a length of 12 > for a text of 6 characters, displays funny symbols after the text. > > The Unicode window proc returns 6, why the unicode/ascii conversion > should make it 12 ? The Api returns number of chars, not bytes. The idea is that 6 Unicode chars can yield more than 6 ASCII chars with DBCS text. The MSDN doc states that WM_GETTEXTLENGTH can return more than the actual size when mixing ASCII and Unicode. What does the app do exactly? Maybe there are cases where the conversion can be avoided. -- Alexandre Julliard julliard(a)winehq.com

1 0

not-yet-connected sockets?
by Daniel Walker Aug. 18, 2001

Aug. 18, 2001

The problem is that poll returns POLLHUP when a socket isn't connected, then wine ignores the socket and it's events .. I realize this has been known for a some time(since linux 2.4), but why hasn't it been fix? Doesn't this effect a lot of non-blocking socket applications? Daniel Walker

3 13

Re: Toolbar background error
by Gerard Patel Aug. 18, 2001

Aug. 18, 2001

At 06:54 PM 17/08/2001 -0700, you wrote: <snip> >But their solution is still not correct IMO. How about something like >this? All clear for me on this one, tested without problem for all of my test apps - at least the one surviving the Gdi lock slaughter :-) Gerard

1 0

Re:CryptoAPI
by Eric Pouech Aug. 18, 2001

Aug. 18, 2001

from a pure technical point of view, the crypto API is in a pure WOSA style : - a set of high level API (in advapi) - an extendable set of low level service providers (here for example the crypto algos - RSA....) - the high level maps the fonctional request of the user onto on of the available SP. so, my advice here would be to implement this type of scheme. This would allow to: - use native DLLs if they exist (and go beyond what's supported by Linux) - still allow to use Linux lib (just build a wrapper DLL to that lib) and you should be all set from a copyright point of view: - Wine use a X11 like licence, so make sure all the external libs you use are not GPL (LGPL is fine). If they are GPL, you won't be able to ship the result with Wine. - Use of native DLL is granted as long as you have a Windows licence on the target machine (native DLLs shall not be shipped with Wine, Wine should be configured to use the local resources) from an exportation point of view: - some countries (US as an example) puts lots of contraints on the type of crypto algo to be used outside of the US. So those shouldn't be shipped with Wine's, but be provided as an external resource) > Hi, > > I was going to start implementing the Cypto API (in advapi32.dll) over the > next few weeks. As of yet these functions are no more than stubs. However, > I am finding increased use of this API as more applications becomed > networkable and relying more heavily on internet connections. > > I was hoping to implement these functions by using the OpenSSL library > (if/when available). This library seems to have similar capabilities. > > One of my concerns is about legal issues. What special concerns should I > note about cryptographic software? Are there any special copyright issues I > should be aware of? > > Another question is about design. M$ seems to split the cryptographic > software into different dlls (rsabase.dll, rsasig.dll, dssbase.dll, etc.). > Should I do this as well so that, applications can use the native dlls if > necessary or should I simply implement it entirely though advapi32.dll which > and avoid the need to create several new (and very small) dlls under wine? > Because most of the code is already in another library (OpenSSL) creating > extra dlls seems abit unnecessary. > > - Travis > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > > --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un vu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

2 1

Re: Toolbar background error
by Alexandre Julliard Aug. 18, 2001

Aug. 18, 2001

Marcus Meissner <marcus(a)jet.franken.de> writes: > I suggest reading the Corel CVS for this part of the code. > > They rewrote this part like _5_ times. But their solution is still not correct IMO. How about something like this? Index: windows/defwnd.c =================================================================== RCS file: /opt/cvs-commit/wine/windows/defwnd.c,v retrieving revision 1.59 diff -u -r1.59 defwnd.c --- windows/defwnd.c 2001/08/10 22:51:43 1.59 +++ windows/defwnd.c 2001/08/18 00:21:43 @@ -461,10 +461,13 @@ HBRUSH hbr = GetClassLongW( wndPtr->hwndSelf, GCL_HBRBACKGROUND ); if (!hbr) return 0; - /* GetClientRect used to be GetClipBox, but it is not what - * Windows does, and it breaks badly with CS_PARENTDC */ - GetClientRect( wndPtr->hwndSelf, &rect ); - DPtoLP( hdc, (LPPOINT)&rect, 2 ); + if (GetClassLongW( wndPtr->hwndSelf, GCL_STYLE ) & CS_PARENTDC) + { + /* can't use GetClipBox with a parent DC or we fill the whole parent */ + GetClientRect( wndPtr->hwndSelf, &rect ); + DPtoLP( hdc, (LPPOINT)&rect, 2 ); + } + else GetClipBox( hdc, &rect ); FillRect( hdc, &rect, hbr ); return 1; } -- Alexandre Julliard julliard(a)winehq.com

1 0

dsound ??
by Bobby Bingham Aug. 17, 2001

Aug. 17, 2001

Hello all, I completely rebuilt my computer a while back, and updated wine, so I'm not sure which is causing it, but not dsound doesn't seem to work where it did before. Starcraft doesn't play any music, sound, etc, but it's installer still plays it's sound (without dsound). Before this I hadn't updated WINE for a while, so I'm not sure when it broke. Bobby Bingham

1 0

Re: Toolbar background error
by Gerard Patel Aug. 17, 2001

Aug. 17, 2001

At 11:08 AM 17/08/2001 -0700, you wrote: >That's not what Windows does. If you pass a window DC to WM_ERASEBKGND >it only erases an area equivalent to the client area (shifted to be >relative to the whole window), so GetClientRect is correct IMO. The >non-client area should be painted upon WM_NCPAINT, not WM_ERASEBKGND. How do you test this under Windows ? In my test app, I have a white brush as class brush. So my window is white. If I add after the BeginPaint : GetClientRect(hwnd, &r); r.top += 200; FillRect(ps.hdc, &r, (HBRUSH) COLOR_WINDOW) the lower part of my window is painted with the beautiful window color (brown) Now if I add immediately after : hdc = GetWindowDC(hwnd); SendMessage(hwnd, WM_ERASEBKGND, (WPARAM) hdc, 0); ReleaseDC(hwnd, hdc); I get a window that is completely white; maybe I am missing something but I should see a small brown strip at the lower part of the window, corresponding to the caption + menu height, no ? Gerard

1 0

Re: Toolbar background error
by Gerard Patel Aug. 17, 2001

Aug. 17, 2001

At 02:33 PM 17/08/2001 GMT, you wrote: <snip> >So how does an application modify the location of the client rectangle >after it has been created? By changing rgrc[0] when responding to WM_NCCALCSIZE. It seems that it is only possible to erase properly the 'custom' nonclient area by using GetWindowDC... So : --- defwnd.c.orig Sat Aug 11 10:23:18 2001 +++ defwnd.c Fri Aug 17 19:47:17 2001 @@ -462,8 +462,12 @@ if (!hbr) return 0; /* GetClientRect used to be GetClipBox, but it is not what - * Windows does, and it breaks badly with CS_PARENTDC */ - GetClientRect( wndPtr->hwndSelf, &rect ); + * Windows does, and it breaks badly with CS_PARENTDC + * GetClientRect breaks too when we are called with a window + * DC (!!) - what next ? */ + rect.left = rect.top = 0; + rect.right = wndPtr->rectWindow.right - wndPtr->rectWindow.left; + rect.bottom = wndPtr->rectWindow.bottom - wndPtr->rectWindow.top; DPtoLP( hdc, (LPPOINT)&rect, 2 ); FillRect( hdc, &rect, hbr ); return 1; What do you think ? Gerard

2 1

Re: Toolbar background error
by Alexandre Julliard Aug. 17, 2001

Aug. 17, 2001

Gerard Patel <gerard.patel(a)nerim.net> writes: > Now if I add immediately after : > > hdc = GetWindowDC(hwnd); > SendMessage(hwnd, WM_ERASEBKGND, (WPARAM) hdc, 0); > ReleaseDC(hwnd, hdc); > > I get a window that is completely white; maybe I am missing something but > I should see a small brown strip at the lower part of the window, corresponding > to the caption + menu height, no ? Yes; actually I realize now that my test app uses the CS_PARENTDC style, which is why I see that. The behavior that you observe is what happens without CS_PARENTDC; so it's actually more complex that I thought, we'll need to explicitly test the CS_PARENTDC flag. Sigh... -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Problems building with extern inline functions in winebase.h
by Alexandre Julliard Aug. 17, 2001

Aug. 17, 2001

Mike Bond <mbond(a)cox.rr.com> writes: > A couple days ago a number of inline functions were put into winebase.h. > Since then I have been unable to build, using gcc 2.96-81 (RedHat). Apparently > this version of gcc thinks that because there is an extern prefixing the > inline, even though the function does in fact have a body, that the > function really is external. Removing the extern, just having inline as > one would do in C++, does not appear to work correctly either, and causes > the function to appear as a exported symbol in all the object files that > header gets included with, thus resulting in multiple definitions. This patch should fix the build failure, though it doesn't explain why gcc doesn't inline such a simple function. Index: dlls/kernel/kernel32.spec =================================================================== RCS file: /opt/cvs-commit/wine/dlls/kernel/kernel32.spec,v retrieving revision 1.39 diff -u -r1.39 kernel32.spec --- dlls/kernel/kernel32.spec 2001/08/06 17:50:42 1.39 +++ dlls/kernel/kernel32.spec 2001/08/16 16:30:03 @@ -922,7 +922,9 @@ @ stub GetProcessPriorityBoost @ stdcall GetThreadPriorityBoost(long ptr) GetThreadPriorityBoost @ stdcall InterlockedCompareExchange (ptr long long) InterlockedCompareExchange +@ stdcall InterlockedCompareExchangePointer(ptr ptr ptr) InterlockedCompareExchangePointer @ stdcall InterlockedExchangeAdd (ptr long ) InterlockedExchangeAdd +@ stdcall InterlockedExchangePointer(ptr ptr) InterlockedExchangePointer @ stdcall IsProcessorFeaturePresent(long) IsProcessorFeaturePresent @ stdcall OpenWaitableTimerA(long long str) OpenWaitableTimerA @ stdcall OpenWaitableTimerW(long long wstr) OpenWaitableTimerW Index: scheduler/critsection.c =================================================================== RCS file: /opt/cvs-commit/wine/scheduler/critsection.c,v retrieving revision 1.30 diff -u -r1.30 critsection.c --- scheduler/critsection.c 2001/08/09 21:21:13 1.30 +++ scheduler/critsection.c 2001/08/16 16:30:11 @@ -86,7 +86,7 @@ /*********************************************************************** * InterlockedCompareExchange (KERNEL32.@) */ -/* PVOID WINAPI InterlockedCompareExchange( PVOID *dest, PVOID xchg, PVOID compare ); */ +/* LONG WINAPI InterlockedCompareExchange( PLONG dest, LONG xchg, LONG compare ); */ __ASM_GLOBAL_FUNC(InterlockedCompareExchange, "movl 12(%esp),%eax\n\t" "movl 8(%esp),%ecx\n\t" @@ -95,10 +95,31 @@ "ret $12"); /*********************************************************************** + * InterlockedCompareExchangePointer (KERNEL32.@) + */ +/* PVOID WINAPI InterlockedCompareExchangePointer( PVOID *dest, PVOID xchg, PVOID compare ); */ +__ASM_GLOBAL_FUNC(InterlockedCompareExchangePointer, + "movl 12(%esp),%eax\n\t" + "movl 8(%esp),%ecx\n\t" + "movl 4(%esp),%edx\n\t" + "lock; cmpxchgl %ecx,(%edx)\n\t" + "ret $12"); + +/*********************************************************************** * InterlockedExchange (KERNEL32.@) */ /* LONG WINAPI InterlockedExchange( PLONG dest, LONG val ); */ __ASM_GLOBAL_FUNC(InterlockedExchange, + "movl 8(%esp),%eax\n\t" + "movl 4(%esp),%edx\n\t" + "lock; xchgl %eax,(%edx)\n\t" + "ret $8"); + +/*********************************************************************** + * InterlockedExchangePointer (KERNEL32.@) + */ +/* PVOID WINAPI InterlockedExchangePointer( PVOID *dest, PVOID val ); */ +__ASM_GLOBAL_FUNC(InterlockedExchangePointer, "movl 8(%esp),%eax\n\t" "movl 4(%esp),%edx\n\t" "lock; xchgl %eax,(%edx)\n\t" -- Alexandre Julliard julliard(a)winehq.com

4 5

Re: Toolbar background error
by Alexandre Julliard Aug. 17, 2001

Aug. 17, 2001

Gerard Patel <gerard.patel(a)nerim.net> writes: > By changing rgrc[0] when responding to WM_NCCALCSIZE. > It seems that it is only possible to erase properly the 'custom' nonclient > area by using GetWindowDC... So : > > --- defwnd.c.orig Sat Aug 11 10:23:18 2001 > +++ defwnd.c Fri Aug 17 19:47:17 2001 > @@ -462,8 +462,12 @@ > if (!hbr) return 0; > > /* GetClientRect used to be GetClipBox, but it is not what > - * Windows does, and it breaks badly with CS_PARENTDC */ > - GetClientRect( wndPtr->hwndSelf, &rect ); > + * Windows does, and it breaks badly with CS_PARENTDC > + * GetClientRect breaks too when we are called with a window > + * DC (!!) - what next ? */ > + rect.left = rect.top = 0; > + rect.right = wndPtr->rectWindow.right - wndPtr->rectWindow.left; > + rect.bottom = wndPtr->rectWindow.bottom - wndPtr->rectWindow.top; > DPtoLP( hdc, (LPPOINT)&rect, 2 ); > FillRect( hdc, &rect, hbr ); > return 1; > > What do you think ? That's not what Windows does. If you pass a window DC to WM_ERASEBKGND it only erases an area equivalent to the client area (shifted to be relative to the whole window), so GetClientRect is correct IMO. The non-client area should be painted upon WM_NCPAINT, not WM_ERASEBKGND. -- Alexandre Julliard julliard(a)winehq.com

1 0

err:module:map_image Could not map section .data, file probably truncated
by mdew Aug. 17, 2001

Aug. 17, 2001

a number of apps that wouldve worked normally ..are now failing to load due to this error.. err:module:map_image Could not map section .data, file probably truncated /usr/local/bin/wine: can't exec './xxx.exe': error=21 -- id: 9DF3262C key fingerprint: B556 04DA CFD9 78DD 9215 A970 8196 FB6D 9DF3 262C

3 3

Re: Does Wine's winhlp work?
by Gerard Patel Aug. 17, 2001

Aug. 17, 2001

At 02:43 PM 17/08/2001 +0200, you wrote: >I was about to ask the same question. My impression was that: >i) 'winhelp' is completely non-functional <snip> I think so - I have never found one help file that it can read. Gerard

1 0

Re: Toolbar background error
by Gerard Patel Aug. 17, 2001

Aug. 17, 2001

At 05:10 PM 16/08/2001 GMT, you wrote: >It's the client rectangle in the toolbar (I believe). I've handed the >issue back to Guy. I think that's a general issue, not specific to toolbars. We are seeing it for toolbars because it's a trick that is used mainly for toolbars. What happens I think is that some apps are not satisfied with the standard toolbar look. They want to have a bigger border around the buttons. That is not provided by the standard control, at least when these apps were written (maybe it is now, I am not following these matters closely). What these apps are doing is playing with WM_NCCALCSIZE to restrict the client rectangle to something smaller than what remains when the system clips the true nonclient area. In the case of one of my test apps, this is done by subclassing (the Wine code is never called). Since GetWindowRect returns only the width and the height of the client area, and is setting the origin to 0 - 0, the custom client area appears higher that it is to WM_ERASEBKGND and the lower part of the window is not painted (toolbar in the case of the app I see) Now, I don't know yet how should be done the erasing of this custom nonclient area :-/ Gerard

2 1

Re: Does Wine's winhlp work?
by Waldek Hebisch Aug. 17, 2001

Aug. 17, 2001

David D. Hagood wrote: >Is Wine's WinHelp program supposed to work? By that I mean, if I invoke >that program with a Windows help file, is it supposed to be able to >display the contents of the help file as Window's winhelp.exe would? I was about to ask the same question. My impression was that: i) 'winhelp' is completely non-functional ii) part reading help files only handles very old help files I implemented code to read somewhat newer help files, to degree that 'hlp2sgml' program is able to get some output, but since data structures used by graphical part are largly NOT filled, 'winhelp' itself has more reasons not to work (I have not sent patch to 'hlpfile.c' in case 'winhelp' actually can read some files). -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

1 0

Does Wine's winhlp work?
by David D. Hagood Aug. 17, 2001

Aug. 17, 2001

Is Wine's WinHelp program supposed to work? By that I mean, if I invoke that program with a Windows help file, is it supposed to be able to display the contents of the help file as Window's winhelp.exe would? I ask because 1) I have a program (DeLorme's AAA MapNGo) that uses WinHelp format documents for some of its normal operation, and 2) I have a WinHelp format file I'd dearly like to be able to access directly from Wine. When I try to launch Wine's Winhelp, it brings up a window, but the window is empty. If I go to File->Open and try to open a WinHelp file, I get the same result. Is there some setup I'm missing?

3 2

Refcounting in SelectObject
by Uwe Bonnes Aug. 17, 2001

Aug. 17, 2001

Hallo, we discussed this January 2001 with no final outcome. Some application (gcprevue version 9) does 080673a0:Call gdi32.SelectObject(000011d4,000011d8) ret=5f485bb1 080673a0:Ret gdi32.SelectObject() retval=00000044 ret=5f485bb1 080673a0:Call gdi32.DeleteObject(000011d8) ret=5f487813 080673a0:Ret gdi32.DeleteObject() retval=00000001 ret=5f487813 080673a0:Call gdi32.BitBlt(000011d4,00000000,00000000,0000008c,000001a7,000009d0,00000000,00000000,00cc0020) ret=0048d1e6 and gets an XErrorEvent and fails to Debugbreak. Starting theapplication with winedbg still gets this error, but DebugBreak isn't executed and the application proceeds. The Windows Api explicitly tells for DeleteObject: Return Value: ... If the specified handle is not valid or is currently selected into a device context, the return value is FALSE. Windows Internals tells about some elements in GDIOBJHDR in debugbuild of windows and has pseudo code for incrementing some refrence counters in SelectObject. Appended patch tries to implement this scheme. The original discussion dissolved into nothing after Andi saw the need for such refcounting, but also mentioned possible resource leakage. Appended code tries to clean up better by: - Remembering an unsuccessfull DeleteObject by adding 0x8000 to the Refcount - Call DeleteObject in SelectObject when the RefCount of the released handle is 0x8000 - Decrementing the RefCount when a hBitmap is still selected into a DC when DeleteDC is called for that DC - Call DeleteObject in DeleteDC when RefCount is 0x8000 For some applications I tested, I always saw the delayed DeleteObject done after the refused DeleteObject in the first place. Is this approach better? Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing -- Index: wine/include/gdi.h =================================================================== RCS file: /home/wine/wine/include/gdi.h,v retrieving revision 1.50 diff -u -r1.50 gdi.h --- wine/include/gdi.h 2001/08/15 23:33:20 1.50 +++ wine/include/gdi.h 2001/08/16 23:23:12 @@ -45,6 +45,9 @@ HANDLE16 hNext; WORD wMagic; DWORD dwCount; + WORD wMetaList; + WORD wSelCount;/* only in debug builds of windows */ + WORD wObjTask;/* only in debug builds of windows */ } GDIOBJHDR; Index: wine/objects/gdiobj.c =================================================================== RCS file: /home/wine/wine/objects/gdiobj.c,v retrieving revision 1.54 diff -u -r1.54 gdiobj.c --- wine/objects/gdiobj.c 2001/08/16 19:13:52 1.54 +++ wine/objects/gdiobj.c 2001/08/16 23:23:13 @@ -374,6 +374,7 @@ obj->hNext = 0; obj->wMagic = magic|OBJECT_NOSYSTEM; obj->dwCount = ++count; + obj->wSelCount = 0; TRACE_SEC( *handle, "enter" ); return obj; @@ -545,6 +546,15 @@ GDI_ReleaseObj( obj ); return TRUE; } + + if(header->wSelCount) + { + TRACE("delayed for %04x because object in use, count %d\n", + obj,header->wSelCount); + header->wSelCount+=0x8000; /* mark for delete */ + GDI_ReleaseObj( obj ); + return FALSE; + } TRACE("%04x\n", obj ); @@ -814,12 +824,32 @@ HGDIOBJ WINAPI SelectObject( HDC hdc, HGDIOBJ handle ) { HGDIOBJ ret = 0; + GDIOBJHDR *header; + DC * dc = DC_GetDCUpdate( hdc ); if (!dc) return 0; TRACE("hdc=%04x %04x\n", hdc, handle ); if (dc->funcs->pSelectObject) ret = dc->funcs->pSelectObject( dc, handle ); GDI_ReleaseObj( hdc ); + if (ret) + { + if (!(header = GDI_GetObjPtr( handle, MAGIC_DONTCARE ))) return 0; + header->wSelCount++; + GDI_ReleaseObj(handle); + if (!(header = GDI_GetObjPtr( ret, MAGIC_DONTCARE ))) return 0; + if(header->wSelCount) + header->wSelCount--; + if(header->wSelCount == 0x8000) /* handle delayed DeleteObject*/ + { + header->wSelCount = 0; + GDI_ReleaseObj(ret); + TRACE("executing delayed DeleteObject for %04x\n",ret); + DeleteObject(ret); + } + else + GDI_ReleaseObj(ret); + } return ret; } Index: wine/objects/dc.c =================================================================== RCS file: /home/wine/wine/objects/dc.c,v retrieving revision 1.62 diff -u -r1.62 dc.c --- wine/objects/dc.c 2001/08/16 19:01:23 1.62 +++ wine/objects/dc.c 2001/08/16 23:23:14 @@ -766,6 +766,25 @@ if (dc->hGCClipRgn) DeleteObject( dc->hGCClipRgn ); if (dc->pAbortProc) THUNK_Free( (FARPROC)dc->pAbortProc ); if (dc->hookThunk) THUNK_Free( (FARPROC)dc->hookThunk ); + if (dc->hBitmap) + { + GDIOBJHDR * header; + if ((header = GDI_GetObjPtr( dc->hBitmap, MAGIC_DONTCARE ))) + { + if(header->wSelCount ) + header->wSelCount--; + if(header->wSelCount == 0x8000) + { + header->wSelCount = 0; + GDI_ReleaseObj(dc->hBitmap); + TRACE("executing delayed DeleteObject for %04x\n",dc->hBitmap); + DeleteObject(dc->hBitmap); + } + else + GDI_ReleaseObj(dc->hBitmap); + + } + } PATH_DestroyGdiPath(&dc->path); GDI_FreeObject( hdc, dc );

1 0

Re: DC lock in CreateDIBitmap
by Alexandre Julliard Aug. 16, 2001

Aug. 16, 2001

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > CreateDIBitmap is called with the HDC lock hold, and when the (fColor) clause > is true, CreateDCA() checks that the lock is not hold. A laymans approach to > release hdc before CreateDCA() and reopen it afterwards resulted in this > report asr startup, with no visual output: I don't think we should be using CreateDC at all in CreateDIBitmap. Could you try this? Index: objects/dib.c =================================================================== RCS file: /opt/cvs-commit/wine/objects/dib.c,v retrieving revision 1.59 diff -u -r1.59 dib.c --- objects/dib.c 2001/08/15 23:33:20 1.59 +++ objects/dib.c 2001/08/16 21:08:12 @@ -875,12 +875,7 @@ /* Now create the bitmap */ - if (fColor) - { - HDC tmpdc = CreateDCA( "DISPLAY", NULL, NULL, NULL ); - handle = CreateCompatibleBitmap( tmpdc, width, height ); - DeleteDC( tmpdc ); - } + if (fColor) handle = CreateCompatibleBitmap( hdc, width, height ); else handle = CreateBitmap( width, height, 1, 1, NULL ); if (!handle) return 0; -- Alexandre Julliard julliard(a)winehq.com

2 1

Problems building with extern inline functions in winebase.h
by Mike Bond Aug. 16, 2001

Aug. 16, 2001

A couple days ago a number of inline functions were put into winebase.h. Since then I have been unable to build, using gcc 2.96-81 (RedHat). Apparently this version of gcc thinks that because there is an extern prefixing the inline, even though the function does in fact have a body, that the function really is external. Removing the extern, just having inline as one would do in C++, does not appear to work correctly either, and causes the function to appear as a exported symbol in all the object files that header gets included with, thus resulting in multiple definitions. I'm not sure what the correct solution would be, other than using the older function call method for this version of gcc. Perhaps I'm just missing some variant on the use of inline? -- TTFN MikeB

5 5

Re: patch.py?id=997918367324549717828631
by Alexandre Julliard Aug. 16, 2001

Aug. 16, 2001

lawson_whitney(a)juno.com writes: > I can't remember that I've ever seen the fixme that was here before, > but I'll check again when I send this. No, the CheckNotSysLevel calls were not done before. I added a few of them in GDI to find potential locking bugs; seems pretty successful so far ;-) I think this should fix your problem: Index: objects/dc.c =================================================================== RCS file: /opt/cvs-commit/wine/objects/dc.c,v retrieving revision 1.61 diff -u -r1.61 dc.c --- objects/dc.c 2001/08/15 23:33:20 1.61 +++ objects/dc.c 2001/08/16 17:34:45 @@ -524,7 +524,9 @@ success=FALSE; } GDI_ReleaseObj( hdcs ); + GDI_ReleaseObj( hdc ); DeleteDC( hdcs ); + if (!(dc = DC_GetDCPtr( hdc ))) return FALSE; } GDI_ReleaseObj( hdc ); return success; -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: [resend] Don't crash when CUPS is installed
by mm＠caldera.de Aug. 16, 2001

Aug. 16, 2001

In article <997995321.1690.4.camel(a)bugg> you wrote: > Hi all, > Having CUPS installed and a printer in CUPS configured would crash an > application I'm looking at. The reason was that the printer would be > added with a NULL name. > - if (!AddPrinterA(NULL,2,(LPBYTE)&pinfo2a)) { > + if (!AddPrinterA(printers[i],2,(LPBYTE)&pinfo2a)) { This will just make the printer not added AT ALL, since there is the following code in AddPrinterW: if(pName != NULL) { ERR("pName = %s - unsupported\n", debugstr_w(pName)); SetLastError(ERROR_INVALID_PARAMETER); return 0; } Please do not apply. Ciao, Marcus

1 0

DC lock in CreateDIBitmap
by Uwe Bonnes Aug. 16, 2001

Aug. 16, 2001

Hallo, with the new GDI_CheckNotLock() stuff, some application (gcprevue 9) fails with > err:win32:_CheckNotSysLevel Holding lock 0x4079b9e8 level 3 Backtrace is: Backtrace: =>0 0x400e21d1 (_CheckNotSysLevel+0x51(lock=0x4079b9e8) [syslevel.c:152] in libntdll.so) (ebp=405c6090) 1 0x4078261c (GDI_CheckNotLock+0x1c [gdiobj.c:510] in libgdi32.so) (ebp=405c60a0) 2 0x4077823d (CreateDCA+0x1d(driver=0x407909d3, device=0x0, output=0x0, initData=0x0, s=0x0, s=0x0, s=0x407909d3) [dc.c:558] in libgdi32.so) (ebp=405c61e8) 3 0x4077bbc6 (CreateDIBitmap+0x166(hdc=0xdec, header=0x41eadb50, init=0x0, bits=0x0, data=0x41eadb50, coloruse=0x0) [dib.c:881] in libgdi32.so) (ebp=405c6218) 4 0x409f9479 (X11DRV_DIB_CreateDIBSection+0x359(dc=0x404225f4, bmi=0x41eadb50, usage=0x0, bits=0x411000d8, section=0x0, offset=0x0, ovr_pitch=0x0) [dib.c:3914] in libx11drv.so) (ebp=405c62a0) 5 0x4077bd75 (DIB_CreateDIBSection+0x65(hdc=0xdec, bmi=0x41eadb50, usage=0x0, bits=0x411000d8, section=0x0, offset=0x0, ovr_pitch=0x0) [dib.c:944] in libgdi32.so) (ebp=405c62d4) 6 0x4077bdd1 (CreateDIBSection+0x31(hdc=0xdec, bmi=0x41eadb50, usage=0x0, bits=0x411000d8, section=0x0, offset=0x0) [dib.c:961] in libgdi32.so) (ebp=405c6304) 7 0x00401fba (gcprevue.exe..text+0xfba in D:\cae\gcp9.0.0.8\gcprevue.exe) (ebp=ffffffff) CreateDIBitmap is called with the HDC lock hold, and when the (fColor) clause is true, CreateDCA() checks that the lock is not hold. A laymans approach to release hdc before CreateDCA() and reopen it afterwards resulted in this report asr startup, with no visual output: fixme:win32:PE_CreateModule Security directory ignored err:win32:_LeaveSysLevel (0x4079ba08, level 3): Invalid state: count 0 mutex (nil). err:ntdll:RtlpWaitForCriticalSection section 0x4010fb88 "rtl.c: peb_lock" wait timed out, retrying (60 sec) fs=030f err:ntdll:RtlpWaitForCriticalSection section 0x4010fb88 "rtl.c: peb_lock" wait timed out, retrying (60 sec) fs=031f err:ntdll:RtlpWaitForCriticalSection section 0x4079ba08 "gdiobj.c: GDI_level" wait timed out, retrying (60 sec) fs=008f How to cure this problem? Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

1 0

Stupid Winedbg question
by Bobby Bingham Aug. 16, 2001

Aug. 16, 2001

Ok, I feel like an idiot for having to ask this, but it's my first time realing using the debugger. When wine starts the debugger on an exception, it opens it up in another xterm. Is there an easy way to copy it's output? The usual select and middle-click isn't working because it doesn't let me select the text to begin with. Thanks in advance for your patience. Bobby Bingham

3 2

Re: Extra space at bottom of toolbar
by Guy L. Albertelli Aug. 16, 2001

Aug. 16, 2001

-----Original Message----- From: Bobby Bingham <uhmmmm(a)ameritech.net> To: Wine Devel <wine-devel(a)winehq.com> Date: Thursday, August 16, 2001 12:28 AM Subject: Extra space at bottom of toolbar >Has anyone else seen this... In WinZip 8.0 (I don't know about other >versions/software), there are about 6 extra pixels at the bottom of the >toolbar below the buttons. Does anyone know what's causing this? I can look >into it if I get some time, but I was wondering if anybody knew. > >Bobby Bingham > > The current CVS shows the following differences between the builtin control and the native one: 1. Button top-left corner is 2 pixels too high. 2. Button is 2 pixels too short. 3. Background bar is 2 pixels too wide. This gives the 6 pixels you noticed. Items 1 & 2 are definitely within the toolbar.c. Item 3 may be in either toolbar or rebar. I need to work on moving screenshots from Win to Linux for comparison. Guy

1 0

Re: Protocol for adding FIXMEs
by Alexandre Julliard Aug. 16, 2001

Aug. 16, 2001

"Bill Medland" <medbi01(a)accpac.com> writes: > However I am occasionally frustrated by the number of times I see the same > FIXME (e.g. the pthread_rwlock* and the "kill other threads" one). I also > recognise from posts that these disconcert newbies whereas after a couple > of weeks one gets used to them. > > So maybe it is better to use FIXME comments where one knows that something > is wrong but it doesn't seem to matter. FIXME macros should be used in cases where we know something is wrong but we don't expect this part of the code to ever get used. This way if some app triggers the wrong code we can hear about it. It doesn't make sense to add FIXME output to parts of the code we know are going to be called, it just generates noise; a comment is much better in this case. > (For example the WM_NCCALCSIZE message uses wParam as a Boolean value and > if it is TRUE then the lParam no longer points to a simple rectangle but to > a structure whose first element is a rectangle. Very little if any code > handles that case explicitly.) I don't think this specific case is a FIXME at all. Apps are allowed to ignore the extra information if they don't have any use for it. -- Alexandre Julliard julliard(a)winehq.com

1 0

_CheckNotSysLevel (was: patch.py?id=997918367324549717828631)
by lawson_whitney＠juno.com Aug. 16, 2001

Aug. 16, 2001

On Thu, 16 Aug 2001 whit(a)giftie.alien.org wrote: > Good day! > > I can't remember that I've ever seen the fixme that was here before, > but I'll check again when I send this. > Is that a new fixme? I reversed just this patch and there are more of this fixme than any other. Hope the backtrace I sent before is useful. Regards, Lawson ---oof--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0

Re: _CheckNotSysLevel Patch
by Alexandre Julliard Aug. 16, 2001

Aug. 16, 2001

Bobby Bingham <uhmmmm(a)ameritech.net> writes: > winedbg winzip32 > ... > err:win32:_CheckNotSysLevel Holding lock 0x40800fe8 level 3 > err:win32:_CheckNotSysLevel Holding lock 0x40800fe8 level 3 > Stopped on breakpoint 1 at 0x004677fa (WINZIP32.EXE.EntryPoint in C:\Program > Files\WinZip\WINZIP32.EXE) If you run under winedbg directly the CheckNotSysLevel breakpoints are ignored, and it only stops at the program entry point; and the backtrace there is useless. Please run it under wine and let it start the debugger by itself when encountering the first CheckNotSysLevel, then you should get a proper backtrace. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: _CheckNotSysLevel Patch
by Alexandre Julliard Aug. 16, 2001

Aug. 16, 2001

Bobby Bingham <uhmmmm(a)ameritech.net> writes: > err:win32:_CheckNotSysLevel Holding lock 0x40800fe8 level 3 > err:seh:start_debugger Couldn't start debugger (winedbg 134640360 52) (2) > Read the Wine Developers Guide on how to set up winedbg or another debugger > > if the debugger is set up, I can continue, and and it works just fine. Before the continue, could you please do a backtrace and mail it to me? Thanks. -- Alexandre Julliard julliard(a)winehq.com

2 1

Protocol for adding FIXMEs
by Bill Medland Aug. 16, 2001

Aug. 16, 2001

What do people think? I seem to have a knack for finding things that are probably going to need fixing at some point but for which I do not have time or knowledge currently. My first temptation is to add a FIXME macro in the code directly. However I am occasionally frustrated by the number of times I see the same FIXME (e.g. the pthread_rwlock* and the "kill other threads" one). I also recognise from posts that these disconcert newbies whereas after a couple of weeks one gets used to them. So maybe it is better to use FIXME comments where one knows that something is wrong but it doesn't seem to matter. (For example the WM_NCCALCSIZE message uses wParam as a Boolean value and if it is TRUE then the lParam no longer points to a simple rectangle but to a structure whose first element is a rectangle. Very little if any code handles that case explicitly.) I know that the manual (wine-devel 8.0) says to add FIXMEs I am concerned that this could lead to ridiculously large traces that hide the important stuff (to say nothing of upsetting timing) Any other views? Bill

1 0

RE: Toolbar background error
by Medland, Bill Aug. 16, 2001

Aug. 16, 2001

I'll handle it. I have this horrible feeling its the compiler again (2.96-85; RedHat 7.1). (It seems to be a side-effect of DPtoLP!!??) Bill > -----Original Message----- > From: Guy L. Albertelli [SMTP:galberte(a)neo.lrun.com] > Sent: Wednesday, August 15, 2001 7:30 PM > To: Bill Medland > Cc: Wine Devel > Subject: Re: Toolbar background error > > > -----Original Message----- > From: Bill Medland <medbi01(a)accpac.com> > To: wine-devel(a)winehq.com <wine-devel(a)winehq.com> > Date: Wednesday, August 15, 2001 4:39 PM > Subject: Re: Toolbar background error > > > >> > >> > >In case you haven't found it yet it is in windows/defwnd.c; the change > made > >between 1.57 and 1.58. Are you going to handle it? > > > >Bill > > > > > Bill, > > Great job in tracking it down. I probably won't get to having time till > Friday evening. If you see the problem and know the fix, by all means go > and > fix it. Otherwise I will look into this Friday. > > Thanks again, > Guy

3 2

patch.py?id=997918367324549717828631
by lawson_whitney＠juno.com Aug. 16, 2001

Aug. 16, 2001

Good day! I guess native riched32.dll does something nasty to provoke the new DbgBreakPoint in _CheckNotSysLevel. Builtin riched32 doesn't, of course, but then the app won't start. I can't remember that I've ever seen the fixme that was here before, but I'll check again when I send this. I've attached a backtrace. I'd appreciate some guidance on what else might be useful, or maybe a pointer to some doco on critical sections in Wine, even it is in .sgml, .c or .h in case I have to debug it myself. Regards, Lawson

1 0

Wine call graph; wineserver; the "big picture"
by Phillip Schmitz Aug. 16, 2001

Aug. 16, 2001

[I mistakenly posted this to comp.emulators.ms-windows.wine / wine-users rather than here. Thanks to eric pouech for his reply there. Sorry if you've already seen this there] Hi, I've been lurking for a while now with a view to starting work on wine - specifically COM and DCOM. I know some people have started some work and there might be some patent issues with COM at least - so maybe DCOM is a better bet (I had the possibly naive idea of implementing COM via DCOM - it would be almost transparent, slower but less "dangerous"). I've read most of the developer docs and some relevant source but I'm still having problems grokking the interrelationships between different parts of wine and the role(s) of wineserver. I have a general understanding of Win32 from a programatic point of view rather than wine's implementation details. While I'm quite willing to "read the source" there's rather a lot of it :) and rather deep dependencies (even with tags one jumps around for a while trying to understand what does what). Does anyone have a call graph for wine or a (decent, open-source) program for making one. I've considered Source-Navigator but it seems like the required database would be twice the size of the wine source! Since (D)COM affects many parts of function and message handling and process address space tampering I considered the less ambitious project of fixing up (Net)DDE first - at least then the all-important Hearts will run networked. Is anyone actively working on that (the source has sporadic updates)? I don't want to start hacking off on a tangent. The different behaviours of win9x and NT will also be a problem since I don't have a real NT installation Also, what do people use in terms of test-suites? custom win32 apps? free/shareware? While I have quite a few larger apps like Office etc I imagine it's better to try smaller, more specific apps at first. I want to do comparisons and communication with Win95/8 in VMWare and don't really want to _purchase more Win32 apps_ for testing! Thanks for any experience or insight you might share. Phillip

6 5

Extra space at bottom of toolbar
by Bobby Bingham Aug. 16, 2001

Aug. 16, 2001

Has anyone else seen this... In WinZip 8.0 (I don't know about other versions/software), there are about 6 extra pixels at the bottom of the toolbar below the buttons. Does anyone know what's causing this? I can look into it if I get some time, but I was wondering if anybody knew. Bobby Bingham

2 1

_CheckNotSysLevel Patch
by Bobby Bingham Aug. 16, 2001

Aug. 16, 2001

Ever since _CheckNotSysLevel was implemented in the CVS yesterday, I can't run any programs if the debugger isn't set up. I get: ... err:win32:_CheckNotSysLevel Holding lock 0x40800fe8 level 3 err:seh:start_debugger Couldn't start debugger (winedbg 134640360 52) (2) Read the Wine Developers Guide on how to set up winedbg or another debugger if the debugger is set up, I can continue, and and it works just fine. Somehow I don't recall windows not running programs without setting up the debugger :-) Bobby Bingham

1 0

Re: Toolbar background error
by Guy L. Albertelli Aug. 16, 2001

Aug. 16, 2001

-----Original Message----- From: Bill Medland <medbi01(a)accpac.com> To: wine-devel(a)winehq.com <wine-devel(a)winehq.com> Date: Wednesday, August 15, 2001 4:39 PM Subject: Re: Toolbar background error >> >> >In case you haven't found it yet it is in windows/defwnd.c; the change made >between 1.57 and 1.58. Are you going to handle it? > >Bill > Bill, Great job in tracking it down. I probably won't get to having time till Friday evening. If you see the problem and know the fix, by all means go and fix it. Otherwise I will look into this Friday. Thanks again, Guy

1 0

Re: Toolbar background error
by Guy L. Albertelli Aug. 16, 2001

Aug. 16, 2001

-----Original Message----- From: Bill Medland <medbi01(a)accpac.com> To: wine-devel(a)winehq.com <wine-devel(a)winehq.com> Date: Wednesday, August 15, 2001 1:58 PM Subject: Re: Toolbar background error > >BTW since you are working on controls I thought I'd better let you know >this. > >I intend at some point working on the ListView control's handling of the >text in the large icon view unless someone gets there first. However it >will require corrections to DrawText/DrawTextEx's handling of the >EDIT_CONTROL style flag first (which affects the word wrapping/cutting of >long words in multiline stuff). In addition from a quick experiment I >think that quite a lot of work will be required within listview.c because >it appears to be unstably dependent on the fact that the size of the text >portion is currently constant; the clipping and repainting falls to pieces >when the size of the text depends on whether the icon is selected or not >etc. > >I thought I'd better let people know in case they get there before me. > Sounds great!! Have at it!! Guy

1 0

Re: toolbar
by Guy L. Albertelli Aug. 16, 2001

Aug. 16, 2001

-----Original Message----- From: Mike McCormack <mike_mccormack(a)start.com.au> To: galberte(a)neo.lrun.com <galberte(a)neo.lrun.com> Date: Wednesday, August 15, 2001 8:11 PM Subject: Re: toolbar >Hey Guy, > >i updated from CVS thismorning, and saw some messages in wine-devel >about the toolbar, so did a quick test with WinZip 8. > >Everything seems to be fine! There are still some minor drawing >problems, but they were there before. They are: > >* button sometimes remains in the clicked state after i click it... >for example after clicking on the Open button in WinZip, the Open File >dialog appears, but the Open button is still in the clicked state. It >remains that way until i move the mouse over it again. Yes , I have seen this also. I am not sure what the problem is or even where. Possibilities: - WM_MOUSELEAVE not always getting generated. - Toolbar processing of WM_MOUSELEAVE is not 100% correct. - Something totally else. > >* sometimes after the tooltips disappear, the rectangle around the >edge of the button is not redrawn, so there is a "mark" where the >tooltip was. > I have not seen this, but I haven't looked for it. Thanks, Guy

1 0

Re: Toolbar background error
by Guy L. Albertelli Aug. 15, 2001

Aug. 15, 2001

Bill, Can you try the current CVS and let me know how that works. I have been doing some work with Toolbar, Rebar, etc. and the background drawing was one of the problems. If it still has problems, let me know the application and I will work on it. Thanks, Guy -----Original Message----- From: Bill Medland <medbi01(a)accpac.com> To: wine-devel(a)winehq.com <wine-devel(a)winehq.com> Date: Wednesday, August 15, 2001 11:12 AM Subject: Toolbar background error >Has anyone else noticed this? Is anyone already looking into this? > >Sometime during July something was changed that resulted on my setup >failing to draw the toolbar background properly (it leaves the bottom third >transparent). > >Since I have had previous problems with this setup (due to some sort of gcc >bug) I thought I'd check. > >Bill > > > > >

2 2

RE: Toolbar background error
by Medland, Bill Aug. 15, 2001

Aug. 15, 2001

I am just compiling up today's Wine; it was certainly there yesterday. As far as I can tell it crept in between 20010726 and 20010731 (dates in the WINE cvs itself). I will send you a test executable that shows the problem. Let me know how it appears on yours. Bill > -----Original Message----- > From: Guy L. Albertelli [SMTP:galberte(a)neo.lrun.com] > Sent: Wednesday, August 15, 2001 10:01 AM > To: Bill Medland > Cc: Wine Devel > Subject: Re: Toolbar background error > > Bill, > > Can you try the current CVS and let me know how that works. I have been > doing some work with Toolbar, Rebar, etc. and the background drawing was > one > of the problems. > > If it still has problems, let me know the application and I will work on > it. > > Thanks, > > Guy > -----Original Message----- > From: Bill Medland <medbi01(a)accpac.com> > To: wine-devel(a)winehq.com <wine-devel(a)winehq.com> > Date: Wednesday, August 15, 2001 11:12 AM > Subject: Toolbar background error > > > >Has anyone else noticed this? Is anyone already looking into this? > > > >Sometime during July something was changed that resulted on my setup > >failing to draw the toolbar background properly (it leaves the bottom > third > >transparent). > > > >Since I have had previous problems with this setup (due to some sort of > gcc > >bug) I thought I'd check. > > > >Bill > > > > > > > > > >

1 0

Transparent child windows
by Timo Kujala Aug. 15, 2001

Aug. 15, 2001

Hi, Some time ago I posted a problem with M$ 32-bit terminal server client, as it did not paint it's window. Finally I got some time to look into this a bit more and found out following: The terminal server client creates (among other windows) two child windows, "Input Capture Window" and "Output Painter Window" (in that order). Input capture window is specified as transparent and it is laid over the output painter window so that the actual image is painted in the output painter window and input capture window just receives mouse clicks and keyboard input. The problem is that the input capture window is not really transparent. Output painter window is behind it and therefore output is never seen. (I was able to find this out by moving input capure window away from the view by modifying code in createwindow-call in win.c, but then mouse won't work in terminal server client) Any fixes for this?

1 0

Toolbar background error
by Bill Medland Aug. 15, 2001

Aug. 15, 2001

Has anyone else noticed this? Is anyone already looking into this? Sometime during July something was changed that resulted on my setup failing to draw the toolbar background properly (it leaves the bottom third transparent). Since I have had previous problems with this setup (due to some sort of gcc bug) I thought I'd check. Bill

1 0

Re: printing AND memory
by Richard Canada Aug. 15, 2001

Aug. 15, 2001

> Richard Canada wrote: > >>trace:psdrv:PSDRV_FindPrinterInfo 'Wine PostScript Driver' >>err:psdrv:PSDRV_FindPrinterInfo Error 2 getting PPD file name for >>printer 'Wine PostScript Driver' >>trace:psdrv:PSDRV_CreateDC (WINEPS Wine PostScript Driver LPT1: (nil)) >>trace:psdrv:PSDRV_FindPrinterInfo 'Wine PostScript Driver' >>err:psdrv:PSDRV_FindPrinterInfo Error 2 getting PPD file name for >>printer 'Wine PostScript Driver' >>trace:psdrv:PSDRV_CreateDC (WINEPS Wine PostScript Driver LPT1: (nil)) >>fixme:pthread_kill_other_threads_np >> >> > > It looks like you haven't specified a PPD file for your printer. The > right method for configuring this varies, depending on how you've > configured your printer, so I need to know how you set up your printer. > -- > ======================================================================== > Ian Pilcher ian.pilcher(a)home.com > ======================================================================== This is how I have my printer set up: (snip from my wine config file) [afmfiles] "file<n>" = "/usr/share/fonts/afms/adobe/pagd8a.afm" [psdrv] "ppdfile" = "/windows/wine/TEMP/ADOBE/HP/HP4PLUS6.PPD" [serialports] "Com1" = "/dev/ttyS0" "Com2" = "/dev/ttyS1" "Com3" = "/dev/ttyS2" "Com4" = "/dev/modem" [parallelports] "Lpt1" = "/dev/lp0" [ppdev] ;; key: io-base of the emulated port ;; value : parport-device{,timeout} ;; timeout for auto closing an open device ( not yet implemented) ;"378" = "/dev/parport0" ;"278" = "/dev/parport1" ;"3bc" = "/dev/parport2" [spooler] "FILE:" = "tmp.ps" "LPT1:" = "|lp -ddevelp -tRICHARD" "LPT2:" = "|gs -sDEVICE=bj200 -sOutputFile=/tmp/fred -q -" "LPT3:" = "/dev/lp3" I have set up the win.ini file correctly, here is the file: [devices] Wine PostScript Driver=WINEPS,LPT1: [windows] device=Wine PostScript Driver,WINEPS,LPT1: [PrinterPorts] Wine PostScript Driver=WINEPS,LPT1: BTW, I am using LPRng on my RedHat 7.1 box. I have no local printers, only network printers that I print to through a print server. Any more suggestions, I would appreciate it. Regards, Richard

1 0

wine server
by Mike McCormack Aug. 15, 2001

Aug. 15, 2001

Hi Phillip, The wineserver does the job of the Windows NT kernel in wine. Here's a summary of what i've worked out about the wineserver: * the wineserver is responsible for all system level synchronization of wine processes, and maintaining integrity of handles * the wineserver is the sole repository for all HANDLE data in the wine process group. * wineserver communicates with each wine process thru a socket and shared memory. There is one socket and one shared memory area per wine process. * the main task of wineserver is a loop which polls on all the wine process sockets, and handles timeouts. * the wineserver processes requests one by one (it is a single thread). * each request is triggered by the wine process writing to its socket, and ended when the wineserver writes back to the socket. During the request, the wine process is effectively stopped. * request data may be read to or written from the shared memory, but the shared memory is not used for synchronization. Synchronization is maintained solely by socket reads and writes. * the wineserver should end each request before processing the next * the wineserver must never wait for or depend upon any wine processes. All wine processes must be assumed to be unstable and unreliable. (even if they're not) * the wineserver design is reliable, but rather slow due to all the context switching required by each request. David Howells made an effort to turn it into a Linux kernel module... he hasn't finished yet. hope that's accurate and helpful... Mike ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Unable to use RegisterClass(&WndClass);
by Craig Chandler Aug. 14, 2001

Aug. 14, 2001

when i use the RegisterClass(&WndClass); under wine the call fails. I'm using it to sub class the button class. Does wine not support this? Interdynamics Web Page : http://www.interdynamics.com

2 8

printing AND memory
by Richard Canada Aug. 14, 2001

Aug. 14, 2001

Does anyone know why I am getting an error message about "Insufficient memory" when I try to print from wine? I can see the printer is there, but I cannot print. I am running Lotus Notes 5.0.6. Thanks Richard

3 4

Re: Solaris X86 mmap...
by Alexandre Julliard Aug. 14, 2001

Aug. 14, 2001

Robert Lunnon <bob(a)yarrabee.net.au> writes: > After that point I can't find any reference to this patch, it certainly > hasn't made it into the CVS yet ? > > Does anyone know the outcome of this work, or am I the only Solaris X86 > user out there :-) Last I heard it needed someone to test it on Solaris x86, but nobody ever did. So yes it seems you may be the only user out there... If you tested it and it works for you, please submit it to wine-patches. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Advice please. adding a MODULE_LoadLibraryExA argument
by Alexandre Julliard Aug. 14, 2001

Aug. 14, 2001

"Bill Medland" <medbi01(a)accpac.com> writes: > The way I would prefer would be to add an argument to all the functions in > the recursion and use that to carry the name around. > MODULE_LoadLibraryExA > PE_LoadLibraryExA > ELF_LoadLibraryExA > PE_CreateModule > fixup_imports > > Any objections? This won't work for builtin dlls, you cannot pass an argument into dlopen(). This is not a problem for builtins themselves since they are not searched the same way, but it may break if a builtin imports a native dll. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: SNOOP: How to find out if an DLL entry is a DATA reference?
by Alexandre Julliard Aug. 14, 2001

Aug. 14, 2001

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > However I like to ask if there are other methods of distinguishing DATA and > function references? Could the PE loader perhaps know? Or can we perhaps > protect our snoop entries from being read as data and catch those exceptions? > Any other idea? I don't think there's any way to make snoop 100% reliable, the PE file simply doesn't contain enough information. This is the reason we have to build special tables in the builtin dlls for relay debugging. -- Alexandre Julliard julliard(a)winehq.com

1 0

Advice please. adding a MODULE_LoadLibraryExA argument
by Bill Medland Aug. 14, 2001

Aug. 14, 2001

I'd appreciate advice on this. I am looking at adding the handling of LoadLibraryExA (..LOAD_WITH_ALTERED_SEARCH_PATH) (which we use) and I am wondering about how to carry around the library directory during the recursion on MODULE_LoadLibraryExA. The easiest way is to put it in a static variable (ok, some allocated memory pointed to by a static variable) and depend upon the existing critical sections (which I don't understand particularly) to ensure it is only used by the currently loading tree of DLLS (i.e. set it up after the RtlAcquirePebLock in MODULE_LoadLibraryExA). However I dislike using static variables as a matter of principle. The way I would prefer would be to add an argument to all the functions in the recursion and use that to carry the name around. MODULE_LoadLibraryExA PE_LoadLibraryExA ELF_LoadLibraryExA PE_CreateModule fixup_imports Any objections? Bill

1 0

Solaris X86 mmap...
by Robert Lunnon Aug. 14, 2001

Aug. 14, 2001

On Jan 10 2001 Ulrich Weigand submitted a patch to library/port.c to attempt to fix the linux mmap behaviour dependency for solaris systems. After that point I can't find any reference to this patch, it certainly hasn't made it into the CVS yet ? Does anyone know the outcome of this work, or am I the only Solaris X86 user out there :-)

1 0

SNOOP: How to find out if an DLL entry is a DATA reference?
by Uwe Bonnes Aug. 14, 2001

Aug. 14, 2001

Hallo, e.g. with the MFC libraries the snoop option crashes quite often, while without snoop the programm proceeds some more. Digging deeper for the crash in msdev.exe, I saw that a library has exported DATA entries mixed into the codesegment. Our snoop loader only checks for DATA entries in the PE DATA section and so happyly overwrites data. It seems that most exported DATA entries have a decorated name ending in @A or @B and by handling entries with that ending as DATA, the crash with msdev.exe happens at the same place with or without snoop. Appended patch does this hacky search for DATA entries. However I like to ask if there are other methods of distinguishing DATA and function references? Could the PE loader perhaps know? Or can we perhaps protect our snoop entries from being read as data and catch those exceptions? Any other idea? Bye Changelog: relay32/snoop.c: SNOOP_GetProcAddress Don't snoop on names ending in "@A" and "@B", they seem to be DATA entries. Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing -- Index: wine/relay32/snoop.c =================================================================== RCS file: /home/wine/wine/relay32/snoop.c,v retrieving revision 1.45 diff -u -r1.45 snoop.c --- wine/relay32/snoop.c 24 Jul 2001 21:45:24 -0000 1.45 +++ wine/relay32/snoop.c 13 Aug 2001 19:51:42 -0000 @@ -158,7 +158,7 @@ SNOOP_GetProcAddress(HMODULE hmod,LPCSTR name,DWORD ordinal,FARPROC origfun) { SNOOP_DLL *dll = firstdll; SNOOP_FUN *fun; - int j; + int j,len; IMAGE_SECTION_HEADER *pe_seg = PE_SECTIONS(hmod); if (!TRACE_ON(snoop)) return origfun; @@ -182,7 +182,14 @@ !(pe_seg[j].Characteristics & IMAGE_SCN_CNT_CODE) ) return origfun; - + /* some heuristic to filter out DATA objects + decorated names end like "@A" and "@B" and some more */ + len=strlen(name); + if ((name [len-2] == '@') && ((name[len-1] == 'A') || (name[len-1] == 'B'))) + { + return origfun; + } + while (dll) { if (hmod == dll->hmod) break;

2 1

IShellLinkA_fnSetIconLocation problem with Kid Pix 3?
by Dan Kegel Aug. 13, 2001

Aug. 13, 2001

Kid Pix 3 doesn't install with Wine from cvs (with either August 6th's or today's cvs). The problem appears to be related to shortcut or icon creation, as the installer bombs with alert "Cannot create shortcuts." right after checking for the existence of "Picker.ico". Here is what seems to be the interesting 250-line section of the log, starting with the fnSetIconLocation and ending with the "Cannot create shortcuts". There is an iffy looking line near the bottom I've marked with !!!!!!!!!!!!!. I'd be grateful for any suggestions. Thanks, Dan trace:shell:IShellLinkA_fnSetIconLocation (0x418884bc)->(path=C:\Program Files\Broderbund\Kid Pix Deluxe 3\Picker.ico iicon=0) trace:shell:IShellLinkA_fnQueryInterface (0x418884bc)->( IID: {0000010b-0000-0000-c000-000000000046}) trace:shell:IPersistFile_fnAddRef (0x418884bc)->(count=1) trace:shell:IShellLinkA_fnAddRef (0x418884bc)->(count=1) trace:shell:IShellLinkA_fnQueryInterface -- Interface: (0x405d53fc)->(0x418884c8) 08077c28:Call kernel32.MultiByteToWideChar(00000000,00000000,405d51dc "C:\\Windows\\Desktop\\Shortcut to Kid Pix Deluxe 3.lnk",ffffffff,405d4dc0,00000104) ret=100394e7 08077c28:Ret kernel32.MultiByteToWideChar() retval=00000034 ret=100394e7 trace:shell:IPersistFile_fnSave (0x418884bc)->(L"C:\\Windows\\Desktop\\Shortcut to Kid Pix Deluxe 3.lnk") 08077c28:Call advapi32.RegOpenKeyExA(80000002,40879140 "Software\\Wine\\Wine\\Config\\Wine",00000000,000f003f,405d490c) ret=408563c4 08077c28:Call ntdll.RtlInitAnsiString(405d47dc,40879140 "Software\\Wine\\Wine\\Config\\Wine") ret=407afaa4 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407afaa4 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d47dc,00000000) ret=407afaad 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407afaad 08077c28:Call ntdll.NtOpenKey(405d490c,000f003f,405d47e4) ret=407afac0 trace:reg:NtOpenKey (0x80000002,L"Software\\Wine\\Wine\\Config\\Wine",f003f,0x405d490c) trace:reg:NtOpenKey <- 0x0034 08077c28:Ret ntdll.NtOpenKey() retval=00000000 ret=407afac0 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407afac6 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407afac6 08077c28:Ret advapi32.RegOpenKeyExA() retval=00000000 ret=408563c4 08077c28:Call advapi32.RegQueryValueExA(00000034,4087915f "ShellLinker",00000000,405d4904,405d4c90,405d4908) ret=408563fb trace:reg:RegQueryValueExA (0x34,"ShellLinker",(nil),0x405d4904,0x405d4c90,0x405d4908=260) 08077c28:Call ntdll.RtlInitAnsiString(405d46f4,4087915f "ShellLinker") ret=407b0c79 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407b0c79 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d46f4,00000000) ret=407b0c8e 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407b0c8e 08077c28:Call ntdll.NtQueryValueKey(00000034,4010bbf8,00000002,405d46fc,00000100,405d46f0) ret=407b0cc4 trace:reg:NtQueryValueKey (0x34,L"ShellLinker",2,0x405d46fc,256) 08077c28:Ret ntdll.NtQueryValueKey() retval=00000000 ret=407b0cc4 08077c28:Call kernel32.WideCharToMultiByte(00000000,00000000,405d4708 L"wineshelllink",0000000e,00000000,00000000,00000000,00000000) ret=407b0ddc 08077c28:Ret kernel32.WideCharToMultiByte() retval=0000000e ret=407b0ddc 08077c28:Call kernel32.WideCharToMultiByte(00000000,00000000,405d4708 L"wineshelllink",0000000e,405d4c90,0000000e,00000000,00000000) ret=407b0e1b 08077c28:Ret kernel32.WideCharToMultiByte() retval=0000000e ret=407b0e1b 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407b0ed2 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407b0ed2 08077c28:Ret advapi32.RegQueryValueExA() retval=00000000 ret=408563fb 08077c28:Call advapi32.RegCloseKey(00000034) ret=40856411 08077c28:Call ntdll.NtClose(00000034) ret=407b04e2 08077c28:Ret ntdll.NtClose() retval=00000000 ret=407b04e2 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407b04e8 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407b04e8 08077c28:Ret advapi32.RegCloseKey() retval=00000000 ret=40856411 08077c28:Call kernel32.WideCharToMultiByte(00000000,00000000,405d4dc0 L"C:\\Windows\\Desktop\\Shortcut to Kid Pix Deluxe 3.lnk",ffffffff,405d4c90,00000104,00000000,00000000) ret=40856482 08077c28:Ret kernel32.WideCharToMultiByte() retval=00000034 ret=40856482 08077c28:Call kernel32.GetFullPathNameA(405d4c90 "C:\\Windows\\Desktop\\Shortcut to Kid Pix Deluxe 3.lnk",00000104,405d4b80,00000000) ret=408564b0 trace:string:lstrcpynA (0x405d43dc, "C:\\Windows\\Desktop\\Shortcut to Kid Pix Deluxe 3.lnk", 1024) trace:string:lstrcpynA (0x405d4b80, "C:\\Windows\\Desktop\\Shortcut to Kid Pix Deluxe 3.lnk", 260) 08077c28:Ret kernel32.GetFullPathNameA() retval=00000033 ret=408564b0 trace:shell:SHGetSpecialFolderPathA 0x0000,0x405d4c90,csidl=7,0x0000 08077c28:Call advapi32.RegCreateKeyExA(80000001,4087bb20 "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders",00000000,00000000,00000000,000f003f,00000000,405d4568,405d456c) ret=4085d37e 08077c28:Call ntdll.RtlInitAnsiString(405d443c,4087bb20 "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders") ret=407af91e 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407af91e 08077c28:Call ntdll.RtlInitAnsiString(405d4434,00000000) ret=407af92d 08077c28:Ret ntdll.RtlInitAnsiString() retval=400bf8ac ret=407af92d 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d443c,00000000) ret=407af936 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407af936 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(405d442c,405d4434,00000001) ret=407af94a 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407af94a 08077c28:Call ntdll.NtCreateKey(405d4568,000f003f,405d4444,00000000,405d442c,00000000,405d456c) ret=407af968 trace:reg:NtCreateKey (0x80000001,L"Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders",L"",0,f003f,0x405d4568) trace:reg:NtCreateKey <- 0x0034 08077c28:Ret ntdll.NtCreateKey() retval=00000000 ret=407af968 08077c28:Call ntdll.RtlFreeUnicodeString(405d442c) ret=407af970 08077c28:Ret ntdll.RtlFreeUnicodeString() retval=00000001 ret=407af970 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407af976 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407af976 08077c28:Ret advapi32.RegCreateKeyExA() retval=00000000 ret=4085d37e 08077c28:Call advapi32.RegQueryValueExA(00000034,405d4790 "StartUp",00000000,405d4560,405d4c90,405d4564) ret=4085d3aa trace:reg:RegQueryValueExA (0x34,"StartUp",(nil),0x405d4560,0x405d4c90,0x405d4564=260) 08077c28:Call ntdll.RtlInitAnsiString(405d4374,405d4790 "StartUp") ret=407b0c79 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407b0c79 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d4374,00000000) ret=407b0c8e 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407b0c8e 08077c28:Call ntdll.NtQueryValueKey(00000034,4010bbf8,00000002,405d437c,00000100,405d4370) ret=407b0cc4 trace:reg:NtQueryValueKey (0x34,L"StartUp",2,0x405d437c,256) 08077c28:Ret ntdll.NtQueryValueKey() retval=c0000034 ret=407b0cc4 08077c28:Call ntdll.RtlNtStatusToDosError(c0000034) ret=407b0ed2 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000002 ret=407b0ed2 08077c28:Ret advapi32.RegQueryValueExA() retval=00000002 ret=4085d3aa 08077c28:Call advapi32.RegCloseKey(00000034) ret=4085d3bd 08077c28:Call ntdll.NtClose(00000034) ret=407b04e2 08077c28:Ret ntdll.NtClose() retval=00000000 ret=407b04e2 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407b04e8 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407b04e8 08077c28:Ret advapi32.RegCloseKey() retval=00000000 ret=4085d3bd 08077c28:Call advapi32.RegCreateKeyExA(80000001,4087bac0 "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders",00000000,00000000,00000000,000f003f,00000000,405d4568,405d456c) ret=4085d3e8 08077c28:Call ntdll.RtlInitAnsiString(405d443c,4087bac0 "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders") ret=407af91e 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407af91e 08077c28:Call ntdll.RtlInitAnsiString(405d4434,00000000) ret=407af92d 08077c28:Ret ntdll.RtlInitAnsiString() retval=400bf8ac ret=407af92d 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d443c,00000000) ret=407af936 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407af936 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(405d442c,405d4434,00000001) ret=407af94a 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407af94a 08077c28:Call ntdll.NtCreateKey(405d4568,000f003f,405d4444,00000000,405d442c,00000000,405d456c) ret=407af968 trace:reg:NtCreateKey (0x80000001,L"Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders",L"",0,f003f,0x405d4568) trace:reg:NtCreateKey <- 0x0034 08077c28:Ret ntdll.NtCreateKey() retval=00000000 ret=407af968 08077c28:Call ntdll.RtlFreeUnicodeString(405d442c) ret=407af970 08077c28:Ret ntdll.RtlFreeUnicodeString() retval=00000001 ret=407af970 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407af976 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407af976 08077c28:Ret advapi32.RegCreateKeyExA() retval=00000000 ret=4085d3e8 08077c28:Call advapi32.RegQueryValueExA(00000034,405d4790 "StartUp",00000000,405d4560,405d4c90,405d4564) ret=4085d408 trace:reg:RegQueryValueExA (0x34,"StartUp",(nil),0x405d4560,0x405d4c90,0x405d4564=260) 08077c28:Call ntdll.RtlInitAnsiString(405d4374,405d4790 "StartUp") ret=407b0c79 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407b0c79 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d4374,00000000) ret=407b0c8e 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407b0c8e 08077c28:Call ntdll.NtQueryValueKey(00000034,4010bbf8,00000002,405d437c,00000100,405d4370) ret=407b0cc4 trace:reg:NtQueryValueKey (0x34,L"StartUp",2,0x405d437c,256) 08077c28:Ret ntdll.NtQueryValueKey() retval=00000000 ret=407b0cc4 08077c28:Call kernel32.WideCharToMultiByte(00000000,00000000,405d4388 L"C:\\WINDOWS\\Start Menu\\Programs\\Startup",00000027,00000000,00000000,00000000,00000000) ret=407b0ddc 08077c28:Ret kernel32.WideCharToMultiByte() retval=00000027 ret=407b0ddc 08077c28:Call kernel32.WideCharToMultiByte(00000000,00000000,405d4388 L"C:\\WINDOWS\\Start Menu\\Programs\\Startup",00000027,405d4c90,00000027,00000000,00000000) ret=407b0e1b 08077c28:Ret kernel32.WideCharToMultiByte() retval=00000027 ret=407b0e1b 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407b0ed2 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407b0ed2 08077c28:Ret advapi32.RegQueryValueExA() retval=00000000 ret=4085d408 08077c28:Call advapi32.RegCloseKey(00000034) ret=4085d579 08077c28:Call ntdll.NtClose(00000034) ret=407b04e2 08077c28:Ret ntdll.NtClose() retval=00000000 ret=407b04e2 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407b04e8 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407b04e8 08077c28:Ret advapi32.RegCloseKey() retval=00000000 ret=4085d579 08077c28:Call shlwapi.PathFileExistsA(405d4c90 "C:\\WINDOWS\\Start Menu\\Programs\\Startup") ret=4085d7d6 trace:shell:PathFileExistsA C:\WINDOWS\Start Menu\Programs\Startup 08077c28:Call kernel32.GetFileAttributesA(405d4c90 "C:\\WINDOWS\\Start Menu\\Programs\\Startup") ret=408fd447 trace:string:lstrcpynA (0x405d3bfc, "/home/dank/.wine/fake_windows", 1024) 08077c28:Ret kernel32.GetFileAttributesA() retval=00000010 ret=408fd447 08077c28:Ret shlwapi.PathFileExistsA() retval=00000001 ret=4085d7d6 trace:shell:SHGetSpecialFolderPathA 0x0000,0x405d4c90,csidl=16,0x0000 08077c28:Call advapi32.RegCreateKeyExA(80000001,4087bb20 "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders",00000000,00000000,00000000,000f003f,00000000,405d4568,405d456c) ret=4085d37e 08077c28:Call ntdll.RtlInitAnsiString(405d443c,4087bb20 "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders") ret=407af91e 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407af91e 08077c28:Call ntdll.RtlInitAnsiString(405d4434,00000000) ret=407af92d 08077c28:Ret ntdll.RtlInitAnsiString() retval=400bf8ac ret=407af92d 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d443c,00000000) ret=407af936 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407af936 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(405d442c,405d4434,00000001) ret=407af94a 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407af94a 08077c28:Call ntdll.NtCreateKey(405d4568,000f003f,405d4444,00000000,405d442c,00000000,405d456c) ret=407af968 trace:reg:NtCreateKey (0x80000001,L"Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders",L"",0,f003f,0x405d4568) trace:reg:NtCreateKey <- 0x0034 08077c28:Ret ntdll.NtCreateKey() retval=00000000 ret=407af968 08077c28:Call ntdll.RtlFreeUnicodeString(405d442c) ret=407af970 08077c28:Ret ntdll.RtlFreeUnicodeString() retval=00000001 ret=407af970 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407af976 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407af976 08077c28:Ret advapi32.RegCreateKeyExA() retval=00000000 ret=4085d37e 08077c28:Call advapi32.RegQueryValueExA(00000034,405d4790 "Desktop",00000000,405d4560,405d4c90,405d4564) ret=4085d3aa trace:reg:RegQueryValueExA (0x34,"Desktop",(nil),0x405d4560,0x405d4c90,0x405d4564=260) 08077c28:Call ntdll.RtlInitAnsiString(405d4374,405d4790 "Desktop") ret=407b0c79 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407b0c79 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d4374,00000000) ret=407b0c8e 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407b0c8e 08077c28:Call ntdll.NtQueryValueKey(00000034,4010bbf8,00000002,405d437c,00000100,405d4370) ret=407b0cc4 trace:reg:NtQueryValueKey (0x34,L"Desktop",2,0x405d437c,256) 08077c28:Ret ntdll.NtQueryValueKey() retval=c0000034 ret=407b0cc4 08077c28:Call ntdll.RtlNtStatusToDosError(c0000034) ret=407b0ed2 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000002 ret=407b0ed2 08077c28:Ret advapi32.RegQueryValueExA() retval=00000002 ret=4085d3aa 08077c28:Call advapi32.RegCloseKey(00000034) ret=4085d3bd 08077c28:Call ntdll.NtClose(00000034) ret=407b04e2 08077c28:Ret ntdll.NtClose() retval=00000000 ret=407b04e2 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407b04e8 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407b04e8 08077c28:Ret advapi32.RegCloseKey() retval=00000000 ret=4085d3bd 08077c28:Call advapi32.RegCreateKeyExA(80000001,4087bac0 "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders",00000000,00000000,00000000,000f003f,00000000,405d4568,405d456c) ret=4085d3e8 08077c28:Call ntdll.RtlInitAnsiString(405d443c,4087bac0 "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders") ret=407af91e 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407af91e 08077c28:Call ntdll.RtlInitAnsiString(405d4434,00000000) ret=407af92d 08077c28:Ret ntdll.RtlInitAnsiString() retval=400bf8ac ret=407af92d 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d443c,00000000) ret=407af936 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407af936 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(405d442c,405d4434,00000001) ret=407af94a 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407af94a 08077c28:Call ntdll.NtCreateKey(405d4568,000f003f,405d4444,00000000,405d442c,00000000,405d456c) ret=407af968 trace:reg:NtCreateKey (0x80000001,L"Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders",L"",0,f003f,0x405d4568) trace:reg:NtCreateKey <- 0x0034 08077c28:Ret ntdll.NtCreateKey() retval=00000000 ret=407af968 08077c28:Call ntdll.RtlFreeUnicodeString(405d442c) ret=407af970 08077c28:Ret ntdll.RtlFreeUnicodeString() retval=00000001 ret=407af970 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407af976 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407af976 08077c28:Ret advapi32.RegCreateKeyExA() retval=00000000 ret=4085d3e8 08077c28:Call advapi32.RegQueryValueExA(00000034,405d4790 "Desktop",00000000,405d4560,405d4c90,405d4564) ret=4085d408 trace:reg:RegQueryValueExA (0x34,"Desktop",(nil),0x405d4560,0x405d4c90,0x405d4564=260) 08077c28:Call ntdll.RtlInitAnsiString(405d4374,405d4790 "Desktop") ret=407b0c79 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407b0c79 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d4374,00000000) ret=407b0c8e 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407b0c8e 08077c28:Call ntdll.NtQueryValueKey(00000034,4010bbf8,00000002,405d437c,00000100,405d4370) ret=407b0cc4 trace:reg:NtQueryValueKey (0x34,L"Desktop",2,0x405d437c,256) 08077c28:Ret ntdll.NtQueryValueKey() retval=00000000 ret=407b0cc4 08077c28:Call kernel32.WideCharToMultiByte(00000000,00000000,405d4388 L"C:\\WINDOWS\\Desktop",00000013,00000000,00000000,00000000,00000000) ret=407b0ddc 08077c28:Ret kernel32.WideCharToMultiByte() retval=00000013 ret=407b0ddc 08077c28:Call kernel32.WideCharToMultiByte(00000000,00000000,405d4388 L"C:\\WINDOWS\\Desktop",00000013,405d4c90,00000013,00000000,00000000) ret=407b0e1b 08077c28:Ret kernel32.WideCharToMultiByte() retval=00000013 ret=407b0e1b 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407b0ed2 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407b0ed2 08077c28:Ret advapi32.RegQueryValueExA() retval=00000000 ret=4085d408 08077c28:Call advapi32.RegCloseKey(00000034) ret=4085d579 08077c28:Call ntdll.NtClose(00000034) ret=407b04e2 08077c28:Ret ntdll.NtClose() retval=00000000 ret=407b04e2 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407b04e8 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407b04e8 08077c28:Ret advapi32.RegCloseKey() retval=00000000 ret=4085d579 08077c28:Call shlwapi.PathFileExistsA(405d4c90 "C:\\WINDOWS\\Desktop") ret=4085d7d6 trace:shell:PathFileExistsA C:\WINDOWS\Desktop 08077c28:Call kernel32.GetFileAttributesA(405d4c90 "C:\\WINDOWS\\Desktop") ret=408fd447 trace:string:lstrcpynA (0x405d3bfc, "/home/dank/.wine/fake_windows", 1024) 08077c28:Ret kernel32.GetFileAttributesA() retval=00000010 ret=408fd447 08077c28:Ret shlwapi.PathFileExistsA() retval=00000001 ret=4085d7d6 08077c28:Call kernel32.wine_get_unix_file_name(4187b708 "C:\\Program Files\\Broderbund\\Kid Pix Deluxe 3\\KPRUN.EXE",405d4a70,00000104) ret=4085669d trace:string:lstrcpynA (0x405d4004, "/home/dank/.wine/fake_windows", 1024) trace:string:lstrcpynA (0x405d4a70, "/home/dank/.wine/fake_windows/Program Files/Broderbund/Kid Pix Deluxe 3/KPRUN.EXE", 260) 08077c28:Ret kernel32.wine_get_unix_file_name() retval=00000001 ret=4085669d 08077c28:Call kernel32.wine_get_unix_file_name(41888530 "C:\\Program Files\\Broderbund\\Kid Pix Deluxe 3",405d4960,00000104) ret=4085671c trace:string:lstrcpynA (0x405d4004, "/home/dank/.wine/fake_windows", 1024) trace:string:lstrcpynA (0x405d4960, "/home/dank/.wine/fake_windows/Program Files/Broderbund/Kid Pix Deluxe 3", 260) 08077c28:Ret kernel32.wine_get_unix_file_name() retval=00000001 ret=4085671c 08077c28:Call kernel32.LoadLibraryExA(4188856c "C:\\Program Files\\Broderbund\\Kid Pix Deluxe 3\\Picker.ico",00000000,00000002) ret=40855d46 trace:string:lstrcpynA (0x405d3e70, "/home/dank/.wine/fake_windows", 1024) warn:dosfs:DOSFS_FindUnixName 'Picker.ico' not found in '/home/dank/.wine/fake_windows/Program Files/Broderbund/Kid Pix Deluxe 3' trace:string:lstrcpynA (0x405d3e2c, "/home/dank/.wine/fake_windows", 1024) warn:dosfs:DOSFS_FindUnixName 'Picker.ico' not found in '/home/dank/.wine/fake_windows/Program Files/Broderbund/Kid Pix Deluxe 3' trace:string:lstrcpynA (0x418886ec, "C:\\WINDOWS\\SYSTEM", 260) !!!!!!!!!!!!!!!!!!!! why is it trying to load C:\WINDOWS\SYSTEM?! !!!!!!!!!!!!!!!!! warn:module:MODULE_LoadLibraryExA Failed to load module 'C:\WINDOWS\SYSTEM'; error=0x00000002, 08077c28:Ret kernel32.LoadLibraryExA() retval=00000000 ret=40855d46 trace:shell:ExtractFromEXEDLL LoadLibraryExA (C:\Program Files\Broderbund\Kid Pix Deluxe 3\Picker.ico) failed, error 2 trace:shell:IPersistFile_fnSave linker app='wineshelllink' link='Shortcut to Kid Pix Deluxe 3' mode=desktop path='/home/dank/.wine/fake_windows/Program Files/Broderbund/Kid Pix Deluxe 3/KPRUN.EXE' args=' Main' icon='/tmp/fileUlFDEJ' workdir='/home/dank/.wine/fake_windows/Program Files/Broderbund/Kid Pix Deluxe 3' descr='' fixme:pthread_kill_other_threads_np trace:shell:IPersistFile_fnRelease (0x418884bc)->(count=2) trace:shell:IShellLinkA_fnRelease (0x418884bc)->(count=2) trace:shell:IShellLinkA_fnRelease (0x418884bc)->(count=1) trace:shell:IShellLinkA_fnRelease -- destroying IShellLink(0x418884bc) 08077c28:Call ole32.CoUninitialize() ret=10039541 08077c28:Call kernel32.FreeLibrary(40845000) ret=408b00fc 08077c28:Ret kernel32.FreeLibrary() retval=00000001 ret=408b00fc 08077c28:Ret ole32.CoUninitialize() retval=00000000 ret=10039541 08077c28:Call window proc 0x416979 (hwnd=000001c0,msg=WM_USER+000c,wp=00000000,lp=00000000) 08077c28:Ret window proc 0x416979 (hwnd=000001c0,msg=WM_USER+000c,wp=00000000,lp=00000000) retval=00000000 08077c28:Call kernel32.lstrlenA(0048636c "") ret=00417ef4 08077c28:Ret kernel32.lstrlenA() retval=00000000 ret=00417ef4 08077c28:Call kernel32.lstrcpyA(4185a0e7,0048636c "") ret=0041801e 08077c28:Ret kernel32.lstrcpyA() retval=4185a0e7 ret=0041801e 08077c28:Call kernel32.lstrcpyA(405d6144,40491e32 "MESSAGE_CANNOT_CREATE_ICONS") ret=0041832a 08077c28:Ret kernel32.lstrcpyA() retval=405d6144 ret=0041832a 08077c28:Call kernel32.lstrlenA(4043bcec "Cannot create shortcuts.") ret=0045714a -- "I have seen the future, and it licks itself clean." -- Bucky Katt

1 0

Re: Question about network stuff
by Bobby Bingham Aug. 12, 2001

Aug. 12, 2001

I'm not sure of the answer to your problem (could you be a little more specific than "it basically told me it couldn't access the network.) This isn't the right list for this question. This list is for patches that have been submitted to WINE. You might try the wine-users mailing list, or, if you're really daring, the wine-devel list if no one on wine-users knows Bobby Bingham Microsoft Windows: Made for the internet The Internet: Made for UNIX On Sunday 12 August 2001 02:02 am, you wrote: > Hi there > > (am I even on the right list??) > > I've been trying to get some Internet playable games to work with Wine, > namely everquest. > > I started out by making the mistake of running wine from my home dir (like > wine /win/d/everquest/everquest.exe) and having it download the whole game > from the 'net to my home dir.. I stopped that in a hurry :-) > > When I moved to /win/d/everquest, and tried to do wine ./everquest, it > basically told me it couldn't access the network. > > Why? How do I fix this? > > Thanks a ton, > > Tim

1 0

Re: RFC: Should we use the macros in windowsx.h to fix -DSTRICT w arni ngs?
by Alexandre Julliard Aug. 11, 2001

Aug. 11, 2001

Patrik Stridvall <ps(a)leissner.se> writes: > So to the details of the marshalling API (the unmarshalling API can wait). > 1. Where should we put them? Suggestion: include/wine/messsage.h No, it should be private to the dlls that really need it. We shouldn't add a global Wine-specific interface, we already have too many of that. And please don't go around converting all SendMessage calls to some marshalling API; this should be reserved to the cases where there is really a need. This is why I suggested to add the inline function in the C file directly: if there is a file where there are a lot of WM_COMMANDs with ugly casts, you can add an inline function there. But if there is only one or two, or calls that don't need ugly typecasts (most of them don't), then you definitely don't want to use the inline, just do a normal SendMessage. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: RFC: Should we use the macros in windowsx.h to fix -DSTRICT w arni ngs?
by Patrik Stridvall Aug. 11, 2001

Aug. 11, 2001

> Patrik Stridvall <ps(a)leissner.se> writes: > > > We can just do it like: > > #ifdef __GNUC__ > > extern inline void FORWARD_WM_COMMAND(HWND hwnd, int id, > HWND hwndCtl, UINT > > codeNotify, WNDPROC fn) > > { > > fn(hwnd, WM_COMMAND, MAKEWPARAM(id, codeNotify), (LPARAM) hwnd); > > } > > #else > > #define FORWARD_WM_COMMAND(hwnd, id, hwndCtl, codeNotify, fn) \ > > (void)(fn)((hwnd), WM_COMMAND, > > MAKEWPARAM((UINT)(id),(UINT)(codeNotify)), (LPARAM)(HWND)(hwndCtl)) > > #endif > > > > if you wish. And if you are worried about preprocessor abusing > > Winelib application we could do #if defined(__GNUC__) && > defined(__WINE__) > > instead or use some kind of macro wrap around protection of the > > kind that I proposed that you didn't like. > > If you want to wrap WM_COMMAND, do something like: > > inline void send_wm_command(HWND hwnd, int id, HWND hwndCtl, > UINT codeNotify) > { > SendMessageW(hwnd, WM_COMMAND, MAKEWPARAM(id, codeNotify), > (LPARAM)hwndCtl); > } > > This is a normal function, doing a normal SendMessage call, and it's > perfectly all right with me. And if you want to do a PostMessage then > write a separate post_wm_command() function. Of course this is not a > standard Windows API so you cannot put it in the standard header > files; but you can have it in some dll private headers, or even > directly in the C files that need it. Ironically that was approximately my original idea. But I didn't think you would accept it so I didn't bother investigating further. Then I realized that the windowsx.h macros did what I wanted so choosed that solution instead. But sure we have a marshalling/unmarshalling API of our own, if that is what you want. Unless of course you prefer the hack below for PostMessage (not likely :-). So to the details of the marshalling API (the unmarshalling API can wait). 1. Where should we put them? Suggestion: include/wine/messsage.h 2. What should we call them? Suggestion: {POST,SEND}_WM_COMMAND etc. We really should capitalize the message name because of people doing "grep WM_COMMAND". And not capitalizing the POST/SEND would look silly if the suffix is capitalized. Sure they look like macros but then they could easily be made to be as an alterative implemention like #define SEND_WM_COMMAND(hwnd, id, hwndCtl, codeNotify) \ FORWARD_WM_COMMAND(hwnd, id, hwndCtl, codeNotify, SendMessage) 3. Do you want the macro wrapper (against the FORWARD API) above for the non GNU C case? 4. Should have have {POST,SEND}_WM_COMMAND{A,W} for calling {Post,Send}Message{A,W} or should we always the W variant like in your example above. > > To sum it up: > > 1. The FORWARD_* API and the HANDLE_* API really are normal > functions not > > macros (preprocessor abuses). The fact Micrsoft > implemented them as macros > > because of lack of compiler support for inline functions > or because of > > incompetence is irrelevant, we can do it right in a 100% > compatible way. > > No we can't; SendMessage and PostMessage don't have the same > prototype, so the preprocessor abuse is necessary to avoid > warnings. It seems you are right. PostMessage returns BOOL. Anyway there are not so many PostMessage calls that can be converted. $ find . -name \*.c | xargs grep PostMessage | grep WM_ | wc -l 35 The type compatible ones on the other hand are $ find . -name \*.c | xargs egrep 'Def.*Proc' | grep WM_ | wc -l 33 $ find . -name \*.c | xargs grep SendMessage | grep WM_ | wc -l 420 The Def.*Proc ones doesn't seem of closer examination to require marshalling of parameters so let skip them. Total 420 compared to 35. So we either decide not to use the the FORWARD_ API for such cases or we do: BOOL bResult = (BOOL) FORWARD_WM_COMMAND(/* ... */, (WNDPROC) PostMessageW); The use above is type correct regardless of whether FORWARD_WM_COMMAND is a macro or a inline function. A little ugly yes, but then it isn't nessary to convert the few PostMessage that exists to the FORWARD_* API at all.

1 0

Re: RFC: Should we use the macros in windowsx.h to fix -DSTRICT w arni ngs?
by Alexandre Julliard Aug. 11, 2001

Aug. 11, 2001

Patrik Stridvall <ps(a)leissner.se> writes: > We can just do it like: > #ifdef __GNUC__ > extern inline void FORWARD_WM_COMMAND(HWND hwnd, int id, HWND hwndCtl, UINT > codeNotify, WNDPROC fn) > { > fn(hwnd, WM_COMMAND, MAKEWPARAM(id, codeNotify), (LPARAM) hwnd); > } > #else > #define FORWARD_WM_COMMAND(hwnd, id, hwndCtl, codeNotify, fn) \ > (void)(fn)((hwnd), WM_COMMAND, > MAKEWPARAM((UINT)(id),(UINT)(codeNotify)), (LPARAM)(HWND)(hwndCtl)) > #endif > > if you wish. And if you are worried about preprocessor abusing > Winelib application we could do #if defined(__GNUC__) && defined(__WINE__) > instead or use some kind of macro wrap around protection of the > kind that I proposed that you didn't like. If you want to wrap WM_COMMAND, do something like: inline void send_wm_command(HWND hwnd, int id, HWND hwndCtl, UINT codeNotify) { SendMessageW(hwnd, WM_COMMAND, MAKEWPARAM(id, codeNotify), (LPARAM)hwndCtl); } This is a normal function, doing a normal SendMessage call, and it's perfectly all right with me. And if you want to do a PostMessage then write a separate post_wm_command() function. Of course this is not a standard Windows API so you cannot put it in the standard header files; but you can have it in some dll private headers, or even directly in the C files that need it. > To sum it up: > 1. The FORWARD_* API and the HANDLE_* API really are normal functions not > macros (preprocessor abuses). The fact Micrsoft implemented them as macros > because of lack of compiler support for inline functions or because of > incompetence is irrelevant, we can do it right in a 100% compatible way. No we can't; SendMessage and PostMessage don't have the same prototype, so the preprocessor abuse is necessary to avoid warnings. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: RFC: Should we use the macros in windowsx.h to fix -DSTRICT w arni ngs?
by Patrik Stridvall Aug. 11, 2001

Aug. 11, 2001

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Microsoft introduced the windowsx.h macros for a reason and > > while without inline functions the current implementation > > of the FORWARD_* macros was the best they could do, it > > was at least better than nothing since it at least handled > > the parameter marshalling even if it wasn't 100% type safe. > > I wouldn't rely on Microsoft choices to judge an API design ;-) Point taken. :-) However not everything Microsoft does is bad, eventhough I admit that being sceptical is a good start. > > Another things to think about: > > What is the difference between calling {Set,Get}WindowText > > functions and calling the FORWARD_WM_{GET,SET}TEXT macros? > > It's a matter of taste. Calling a normal function is perfectly all > right; But they are normal functions. It is just not that apparent that they really are. Whether this is by design or by accident I leave unsaid. :-) Anyway, see below. > but I find that using a macro (or worse an inline function > masquerading as a macro) and having to pass it the name of the > function you want to call is ugly and offensive. If you want to call > SendMessage, then call SendMessage, don't hide it inside a macro. It is not hidden in the macro. Which function to call is provided as the last parameter of the macro. > Just because you can do all kinds of abuses of the preprocessor in C > doesn't mean you should. Well actually, the so called abuses of the preprocesor was for 100% compabillity with Winelib applications, if they abuse the fact that FORWARD_* might not always be macros (like doing undef on them). It is possible do it cleaner that the crude example I provide as well. Anyway, with the exception of preprocessor abusing application, which Wine easily can be made not to be. We can just do it like: #ifdef __GNUC__ extern inline void FORWARD_WM_COMMAND(HWND hwnd, int id, HWND hwndCtl, UINT codeNotify, WNDPROC fn) { fn(hwnd, WM_COMMAND, MAKEWPARAM(id, codeNotify), (LPARAM) hwnd); } #else #define FORWARD_WM_COMMAND(hwnd, id, hwndCtl, codeNotify, fn) \ (void)(fn)((hwnd), WM_COMMAND, MAKEWPARAM((UINT)(id),(UINT)(codeNotify)), (LPARAM)(HWND)(hwndCtl)) #endif if you wish. And if you are worried about preprocessor abusing Winelib application we could do #if defined(__GNUC__) && defined(__WINE__) instead or use some kind of macro wrap around protection of the kind that I proposed that you didn't like. Note that the above inline function "abuses" that fact that C autocasts between functions and pointer to functions, but then it standard well documented and often used "abuse", so calling it an abuse isn't really fair (not that you did since my example contained an unnessary &)). To sum it up: 1. The FORWARD_* API and the HANDLE_* API really are normal functions not macros (preprocessor abuses). The fact Micrsoft implemented them as macros because of lack of compiler support for inline functions or because of incompetence is irrelevant, we can do it right in a 100% compatible way. 2. The FORWARD_* API provides marshalling of parameters and the HANDLE_* API provides unmarshalling of parameters. 3. The FORWARD_* API provides type safe sending of parameters and the HANDLE_* API provides type safe recieving of parameters. Note that the fact that marshalling and unmarshalling of parameters are hidden makes that code much more readable and yes, I say it again, the FORWARD_* API and HANDLE_* API really are normal functions, there is no hidden traps for the unwary user. Just a nice wrapper for type safe marshalling and unmarshalling of parameters. PS. We could easily rewrite the HANDLE_* API as inline functions as well, I don't think it gives us anything though. They are good as they are AFAICS. But if you don't like macros, sure I can rewrite them as inline functions well. It just a lot of work to no gain AFAICS. It wouldn't hurt either though.

1 0

Re: RFC: Should we use the macros in windowsx.h to fix -DSTRICT w arni ngs?
by Alexandre Julliard Aug. 10, 2001

Aug. 10, 2001

Patrik Stridvall <ps(a)leissner.se> writes: > Microsoft introduced the windowsx.h macros for a reason and > while without inline functions the current implementation > of the FORWARD_* macros was the best they could do, it > was at least better than nothing since it at least handled > the parameter marshalling even if it wasn't 100% type safe. I wouldn't rely on Microsoft choices to judge an API design ;-) > Another things to think about: > What is the difference between calling {Set,Get}WindowText > functions and calling the FORWARD_WM_{GET,SET}TEXT macros? It's a matter of taste. Calling a normal function is perfectly all right; but I find that using a macro (or worse an inline function masquerading as a macro) and having to pass it the name of the function you want to call is ugly and offensive. If you want to call SendMessage, then call SendMessage, don't hide it inside a macro. Just because you can do all kinds of abuses of the preprocessor in C doesn't mean you should. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: RFC: Should we use the macros in windowsx.h to fix -DSTRICT w arni ngs?
by Patrik Stridvall Aug. 10, 2001

Aug. 10, 2001

> Patrik Stridvall <ps(a)leissner.se> writes: > > > This will give us all the advantages of the "macros" > without any typecasts > > that could > > possibly hide a type error. > > > > What do you say? > > I don't like it. I think windowsx.h should not be used at all in Wine; > it only obfuscates things by making it harder to see what's really > going on. Obfuscates what? The only thing the "macros" do is that it hides the way the parameters are marshalled. That is totally unintresting for almost all Wine developers. Like the Win16/Win32 thunking code you don't have to know how it works, you just call the appropriate functions. The same with the stdcall calling convention most API functions use. You add WINAPI before the function and you don't care how it works. It is the somebody else problem and you trust that they know what they are doing. So please explain what the use of FORWARD_* macros obfuscates for I really can't see it. AFAICS it is much better to use the FORWARD_ macros (especially with my hack to make them truely type safe). They are just a function like any other. Why look up how the parameters are marshalled when you can call a function FORWARD_* that not only does it, but does it in a type safe way. If you call the function with the wrong parameters you are very likely to get type errors. If you marshall the parameters in the wrong way it is almost 100% certain that the compiler will say nothing. Microsoft introduced the windowsx.h macros for a reason and while without inline functions the current implementation of the FORWARD_* macros was the best they could do, it was at least better than nothing since it at least handled the parameter marshalling even if it wasn't 100% type safe. Another things to think about: What is the difference between calling {Set,Get}WindowText functions and calling the FORWARD_WM_{GET,SET}TEXT macros? Answer: No difference at all except that you can easily do a PostMessage instead of a SendMessage if you wish. Of course I'm not suggesting that we should call the FORWARD_WM_{GET,SET}TEXT instead of {Set,Get}WindowText, but in most cases no appropriate functions exists and FORWARD_* macros will at least do the marshalling of parameters and if we implement my version of them also type safe. > Besides, the FORWARD_* macros are not really meant to be > used to send messages, they are meant to help receiving messages, so I > don't think we should abuse them that way. No, that is what the HANDLE_* macros are for. The FORWARD_* macros are for sending (or forwarding) messages. Speaking of which the HANDLE_* macros could find uses in COMCTL32 and other similar DLL:s to provide a type safe receiving of messages. I don't even think we will have to do as a proposed for the FORWARD_* to make them truely type safe.

1 0

Re: RFC: Should we use the macros in windowsx.h to fix -DSTRICT w arni ngs?
by Alexandre Julliard Aug. 10, 2001

Aug. 10, 2001

Patrik Stridvall <ps(a)leissner.se> writes: > This will give us all the advantages of the "macros" without any typecasts > that could > possibly hide a type error. > > What do you say? I don't like it. I think windowsx.h should not be used at all in Wine; it only obfuscates things by making it harder to see what's really going on. Besides, the FORWARD_* macros are not really meant to be used to send messages, they are meant to help receiving messages, so I don't think we should abuse them that way. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: RFC: Should we use the macros in windowsx.h to fix -DSTRICT w arni ngs?
by Patrik Stridvall Aug. 10, 2001

Aug. 10, 2001

> Patrik Stridvall <ps(a)leissner.se> writes: > > > So the question is: > > Should we use the FORWARD_WM_* macros to avoid typecasts > > (or rather avoid visable typecast) or should we not? > > If not how should we fix the problems? > > I think it's better to avoid that. Hiding the typecasts in the macros > doesn't really make things cleaner IMO. This is a case where the API > design forces us to use a typecast, so we might as well make it > explicit. True, but be aware of the macros often use a double type cast like (LPARAM)(HWND). I'm not sure this is really helpful, since I guess it will reveal but a few type error if any at all. Also note that the macros also takes care of MAKEWPARAM and MAKELPARAM stuff so it makes the code a little more readable. Anyway, never mind. We could be a little more clever than the macros permit that if we like. See below. > Note that for the specific case of WM_GET/SETTEXT, it would be much > better to use Get/SetWindowText which will do correct type checks. True. They was just an example. They are a few more with similar problems but they are few (less than 10 IIRC). I guess we can worry about them later. > But > for messages that don't have a corresponding function we have to do > the typecast. As the macros work now, yes. But we could extend the "macros" to be a little more clever than that. Take for example one of the more advanced macros #define FORWARD_WM_LBUTTONDOWN(hwnd, fDoubleClick, x, y, keyFlags, fn) \ (void)(fn)((hwnd), (fDoubleClick) ? WM_LBUTTONDBLCLK : WM_LBUTTONDOWN, (WPARAM)(UINT)(keyFlags), MAKELPARAM((x), (y))) We could quite easily write it like: #define _FORWARD_WM_LBUTTONDOWN(hwnd, fDoubleClick, x, y, keyFlags, fn) \ (void)(fn)((hwnd), (fDoubleClick) ? WM_LBUTTONDBLCLK : WM_LBUTTONDOWN, (WPARAM)(UINT)(keyFlags), MAKELPARAM((x), (y))) #if defined(__WINE__) && defined(__GNUC__) extern inline void _WINE_FORWARD_WM_LBUTTONDOWN(HWND hwnd, BOOL fDoubleClick, int x, int y, UINT keyFlags, WNDPROC *fn) { /* return */ _FORWARD_WM_LBUTTONDOWN(hwnd, fDoubleClick, x, y, keyFlags, *fn); } #define FORWARD_WM_LBUTTONDOWN(hwnd, fDoubleClick, x, y, keyFlags, fn) \ _WINE_FORWARD_WM_LBUTTONDOWN((hwnd), (fDoubleClick), (x), (y), (keyFlags), &(fn)) #else #define FORWARD_WM_LBUTTONDOWN(hwnd, fDoubleClick, x, y, keyFlags, fn) \ _FORWARD_WM_LBUTTONDOWN((hwnd), (fDoubleClick), (x), (y), (keyFlags), (fn)) #endif Or something like that. I'm not even sure the __WINE__ is needed. I not sure that any Winelib application could possibly misuse the macros in such a way that the result is not semantically the same (type warnings/errors excluded of course). Note that it is quite easy to write script that automatically does this to avoid subtle bugs especially since the correct (almost) prototype is already before each macro. Like in the case above: /* void Cls_OnLButtonDown(HWND hwnd, BOOL fDoubleClick, int x, int y, UINT keyFlags) */ This will give us all the advantages of the "macros" without any typecasts that could possibly hide a type error. What do you say? Note that we don't have to implement the solution above right now either. Using the macros as they are will not gain us very much (except possible a cleaner looking code), true. However when we implement the type safe "macros" as described above we will immediately find any and all type errors concerning such code. Anway fixing windowsx.h to look like above will not be very difficult either so there is no real reason to wait is it? PS. As hinted above this will also work with most (all?) Winelib applications that happends to use the windowsx.h macros and enable the finding of subtle type errors in such applications.

1 0

Re: RFC: Should we use the macros in windowsx.h to fix -DSTRICT warni ngs?
by Alexandre Julliard Aug. 10, 2001

Aug. 10, 2001

Patrik Stridvall <ps(a)leissner.se> writes: > So the question is: > Should we use the FORWARD_WM_* macros to avoid typecasts > (or rather avoid visable typecast) or should we not? > If not how should we fix the problems? I think it's better to avoid that. Hiding the typecasts in the macros doesn't really make things cleaner IMO. This is a case where the API design forces us to use a typecast, so we might as well make it explicit. Note that for the specific case of WM_GET/SETTEXT, it would be much better to use Get/SetWindowText which will do correct type checks. But for messages that don't have a corresponding function we have to do the typecast. -- Alexandre Julliard julliard(a)winehq.com

1 0

RFC: Should we use the macros in windowsx.h to fix -DSTRICT warni ngs?
by Patrik Stridvall Aug. 10, 2001

Aug. 10, 2001

This is not primarily a patch it is a RFC. I have experimented a bit with fixing the strict warnings. I have a few patch that I haven't submitted yet partly because I'm not 100% sure how all warnings should be fixed. Anyway, one large class of warnings is the ones cause by the window messaging functions. Like the one below: SendMessageW(lphc->hWndEdit, WM_SETTEXT, 0, (LPARAM)empty_stringW); This one unlike others this one does cause any warning with -DSTRICT because of the ugly cast, but the principle is the same. The only good way to fix this kind of problems that I can see is to use the FORWARD_WM_* macros in include/windowsx.h to write it like: FORWARD_WM_SETTEXT(lphc->hWndEdit, empty_stringW, SendMessageW); This works fine because the FORWARD_WM_SETTEXT macro look like this: #define FORWARD_WM_SETTEXT(hwnd, lpszText, fn) \ (void)(fn)((hwnd), WM_SETTEXT, 0L, (LPARAM)(LPCTSTR)(lpszText)) Actually I lied this special case will not work fine since FORWARD_WM_SETTEXT uses TCHAR and friends. But that is not so important for the general principle. See below. Anyway, in some meaning the macros only hides the casts, but can casts really be avoided? We must cast to {W,L}PARAM at some time mustn't we? And the macros in windowsx.h is not that bad they cast to the correct type before the cast to {W,L}PARAM. This might help to find some bugs. Perhaps rewriting to macros as inline functions might help to? So the question is: Should we use the FORWARD_WM_* macros to avoid typecasts (or rather avoid visable typecast) or should we not? If not how should we fix the problems? And if we decide to use them, is patches like the one below to include/windowsx.h that fixes the TCHAR and friend problem acceptable or should we solve such problems in another way? PS. Alexandre: Feel free to apply the patch below if you agree. ---8<--- * include/windowsx.h: Include files used internally by Wine can't use the types TCHAR and friends. ---8<--- Index: wine/include/windowsx.h =================================================================== RCS file: /home/wine/wine/include/windowsx.h,v retrieving revision 1.7 diff -u -u -r1.7 windowsx.h --- wine/include/windowsx.h 2001/01/10 22:42:35 1.7 +++ wine/include/windowsx.h 2001/08/10 12:43:18 @@ -714,17 +714,37 @@ #define FORWARD_WM_ENABLE(hwnd, fEnable, fn) \ (void)(fn)((hwnd), WM_ENABLE, (WPARAM)(BOOL)(fEnable), 0L) +/* void Cls_OnSetTextA(HWND hwnd, LPCSTR lpszText) */ +#define HANDLE_WM_SETTEXTA(hwnd, wParam, lParam, fn) \ + ((fn)((hwnd), (LPCSTR)(lParam)), 0L) +#define FORWARD_WM_SETTEXTA(hwnd, lpszText, fn) \ + (void)(fn)((hwnd), WM_SETTEXT, 0L, (LPARAM)(LPCSTR)(lpszText)) + +/* void Cls_OnSetTextW(HWND hwnd, LPCWSTR lpszText) */ +#define HANDLE_WM_SETTEXTW(hwnd, wParam, lParam, fn) \ + ((fn)((hwnd), (LPCWSTR)(lParam)), 0L) +#define FORWARD_WM_SETTEXTW(hwnd, lpszText, fn) \ + (void)(fn)((hwnd), WM_SETTEXT, 0L, (LPARAM)(LPCWSTR)(lpszText)) + /* void Cls_OnSetText(HWND hwnd, LPCTSTR lpszText) */ -#define HANDLE_WM_SETTEXT(hwnd, wParam, lParam, fn) \ - ((fn)((hwnd), (LPCTSTR)(lParam)), 0L) -#define FORWARD_WM_SETTEXT(hwnd, lpszText, fn) \ - (void)(fn)((hwnd), WM_SETTEXT, 0L, (LPARAM)(LPCTSTR)(lpszText)) +#define HANDLE_WM_SETTEXT WINELIB_NAME_AW(HANDLE_WM_SETTEXT) +#define FORWARD_WM_SETTEXT WINELIB_NAME_AW(FORWARD_WM_SETTEXT) + +/* INT Cls_OnGetTextA(HWND hwnd, int cchTextMax, LPSTR lpszText) */ +#define HANDLE_WM_GETTEXTA(hwnd, wParam, lParam, fn) \ + (LRESULT)(DWORD)(int)(fn)((hwnd), (int)(wParam), (LPSTR)(lParam)) +#define FORWARD_WM_GETTEXTA(hwnd, cchTextMax, lpszText, fn) \ + (int)(DWORD)(fn)((hwnd), WM_GETTEXT, (WPARAM)(int)(cchTextMax), (LPARAM)(LPSTR)(lpszText)) + +/* INT Cls_OnGetTextW(HWND hwnd, int cchTextMax, LPWSTR lpszText) */ +#define HANDLE_WM_GETTEXTW(hwnd, wParam, lParam, fn) \ + (LRESULT)(DWORD)(int)(fn)((hwnd), (int)(wParam), (LPWSTR)(lParam)) +#define FORWARD_WM_GETTEXTW(hwnd, cchTextMax, lpszText, fn) \ + (int)(DWORD)(fn)((hwnd), WM_GETTEXT, (WPARAM)(int)(cchTextMax), (LPARAM)(LPWSTR)(lpszText)) /* INT Cls_OnGetText(HWND hwnd, int cchTextMax, LPTSTR lpszText) */ -#define HANDLE_WM_GETTEXT(hwnd, wParam, lParam, fn) \ - (LRESULT)(DWORD)(int)(fn)((hwnd), (int)(wParam), (LPTSTR)(lParam)) -#define FORWARD_WM_GETTEXT(hwnd, cchTextMax, lpszText, fn) \ - (int)(DWORD)(fn)((hwnd), WM_GETTEXT, (WPARAM)(int)(cchTextMax), (LPARAM)(LPTSTR)(lpszText)) +#define HANDLE_WM_GETTEXT WINELIB_NAME_AW(HANDLE_WM_GETTEXT) +#define FORWARD_WM_GETTEXT WINELIB_NAME_AW(FORWARD_WM_GETTEXT) /* INT Cls_OnGetTextLength(HWND hwnd) */ #define HANDLE_WM_GETTEXTLENGTH(hwnd, wParam, lParam, fn) \

1 0

wine+mirc /rename confusiion bug
by mdew Aug. 10, 2001

Aug. 10, 2001

make a empty file..place it the mirc dir... /rename y:\fake_windows\mirc\text.txt c:\mirc\text2.txt *** /rename: unable to rename 'y:\fake_windows\mirc\text.txt' to 'c:\mirc\text2.txt' $ ls text* -al -rw-r--r-- 1 mdew mdew 6 Aug 10 22:33 text.txt -rw-r--r-- 1 mdew mdew 6 Aug 10 22:36 text2.txt complains about it...yet it actually does it. -- id: 9DF3262C key fingerprint: B556 04DA CFD9 78DD 9215 A970 8196 FB6D 9DF3 262C

1 0

trouble with fonts (old, old problem)
by Mike McCormack Aug. 10, 2001

Aug. 10, 2001

Hi All, i've got a problem with fonts in Netscape that's been around for a long time, while i've tried several times, unsuccessfully, to fix. When netscape 4.77 first loads, then loads an arbitary page, everything (text, buttons, comboboxes) is rendered incorrectly. If i go to another page, then hit the Back button, the page that was originally rendered incorrectly is now correct. All further renderings are correct for all pages. In my investigations (some time ago), i found that : * font enumeration functions returned different things on the first and second load of the same page. * i could correct the problem by changing the default ansi fixed font to helvetica i suspect that the wine loads extra X11 fonts between the first and second page viewings... but i don't know much about font handling in wine. i'll make some screen shots if anybody is interested. Any ideas? Mike ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Font scaling in PSDRV_EnumDeviceFonts
by Ian Pilcher Aug. 10, 2001

Aug. 10, 2001

Can anyone point me to the Win32 API that ultimately calls the subject function? I'm trying to understand why it scales fonts to a 200 logical unit (I think) character cell. Is this completely arbitrary? Thanks! -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

Re: wineserver.pid
by Alexandre Julliard Aug. 9, 2001

Aug. 9, 2001

Andreas Mohr <a.mohr(a)mailto.de> writes: > Hi all, > > some guy was running several different versions of wineservers for one > account via wrapper scripts. > And of course he had a hell of a hard time figuring out which wineserver to > kill for which application ;-) Why would you want to do that? Just kill the app and it will die on its own (and save everything too). I don't think encouraging people to kill the wineserver is a good idea. -- Alexandre Julliard julliard(a)winehq.com

1 0

winelib application debugging
by Vitaly Kuznetsov Aug. 9, 2001

Aug. 9, 2001

Is there currently any way to debug winelib application? I read winedbg doc, but there are only samples for windows executables. -- Vitaly AKA Vitty mailto: vitty(a)dts.ru NetMail:2:5015/133.41

2 1

Today's CVS hangs on startup
by Ian Pilcher Aug. 9, 2001

Aug. 9, 2001

The good news is that --debugmsg +all actually stops producing anything. Hopefully someone can look at the output below and figure out what's going on. Anyone else seen this? ... 080689c0:trace:dosfs:DOSFS_FindUnixName (/home/pilcher/wine,Eudora\EUDORA.EXE) -> Eudora (EUDORA) 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:heap:HeapFree (403a0000,00000002,403c36c8): returning TRUE 080689c0:trace:dosfs:DOSFS_FindUnixName /home/pilcher/wine/Eudora,EUDORA.EXE 080689c0:trace:heap:HeapAlloc (403a0000,00000002,0000022c): returning 403c36c8 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:dosfs:DOSFS_FindUnixName (/home/pilcher/wine/Eudora,EUDORA.EXE) -> EUDORA.EXE (EUDORA.EXE) 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:heap:HeapFree (403a0000,00000002,403c36c8): returning TRUE 080689c0:trace:dosfs:DOSFS_GetFullName returning /home/pilcher/wine/Eudora/EUDORA.EXE = C:\EUDORA\EUDORA.EXE 080689c0:trace:string:lstrcpynA (0x405f68e8, "C:\\EUDORA\\EUDORA.EXE", 260) 080689c0:trace:string:lstrcpynA (0x405f68ea, "/Eudora/EUDORA.EXE", 258) 080689c0:trace:module:GetModuleFileName16 01cf -> 'C:\Eudora\EUDORA.EXE' 080689c0:trace:heap:HeapAlloc (403a0000,00000002,0000004c): returning 403c3480 080689c0:trace:reg:NtOpenKey (0x80000002,L"Software\\Wine\\Wine\\Config\\AppDefaults",f003f,0x405f6820) 080689c0: open_key( parent=-2147483646, access=000f003f, name=L"Software\\Wine\\Wine\\Config\\AppDefaults" ) Open key ERROR 080689c0: open_key() = OBJECT_NAME_NOT_FOUND { hkey=0 } 080689c0:trace:reg:NtOpenKey <- 0x0000 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"display",(nil),(nil),0x405f68f0,0x405f6818=268) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"display",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"display" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"Managed",(nil),(nil),0x405f68e8,0x405f6814=276) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"Managed",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"Managed" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"Desktop",(nil),(nil),0x405f68e8,0x405f6810=276) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"Desktop",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"Desktop" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"DXGrab",(nil),(nil),0x405f68e8,0x405f680c=276) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"DXGrab",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"DXGrab" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"UseDGA",(nil),(nil),0x405f68e8,0x405f6808=276) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"UseDGA",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"UseDGA" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"ScreenDepth",(nil),(nil),0x405f68e8,0x405f6804=276) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"ScreenDepth",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"ScreenDepth" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"Synchronous",(nil),(nil),0x405f68e8,0x405f6800=276) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"Synchronous",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"Synchronous" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0: close_handle( handle=32 ) 080689c0: close_handle() = 0 { fd=-1 } 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

[Fwd: Re: x11drv port to win32 possible ?]
by Ian Pilcher Aug. 9, 2001

Aug. 9, 2001

Rudi De Vos wrote: > > The intention is to create a dll that exports the winapi graphic > functions for X11: X11DRV_CreateWindow,X11DRV_InitKeyboard,.. > see x11drv.spec. > Someone can correct me if I'm wrong, but I believe that Wine's built-in graphics drivers -- x11drv, ttydrv, and wineps -- interface with Wine's GDI code in a non-standard way. Alexandre has made some changes in this area recently, but I don't believe they've changed that fundamental fact. So to do what you're proposing, you would first have to modify Wine's GDI code to support one of Microsoft's 32-bit graphics driver interfaces. (Different Microsoft 32-bit OSes have different driver interfaces, BTW.) You could then update x11drv to use this interface. As Patrik pointed out, this is really outside the scope of the Wine project, but I do think that it would be valuable. In addition to the reasons you give above, it would be helpful in improving both the Wine driver code and the Wine GDI code. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

RE: x11drv port to win32 possible ?
by Patrik Stridvall Aug. 9, 2001

Aug. 9, 2001

[You know you replied in private? Hmm, it doesn't seem to be private. Including list again, others might be intrested] > Perhaps the subject needed to be > X11drv insite function port to win32 possible ? I'm not sure this new title makes it clearer. But never mind. > A graphic driver would display the full desktop and not a single > application. True. > And wine is not needed to display anything. > This is currently used with the sunpci (intel coprocessor card in the > sparc boxes). > The video driver display the pc-screen as a xwindows or native on a > second monitor. I'm not sure I quite with you, but never mind, see below. > I want to create equivalent functions, but it seems that the functions > (X11DRV_...) make also use of the ntdll, userdll ... > I just want to know if it would be possible to recompile the > x11drv part > against the native dlls ( on win32 ). > Not the full x11drv, but only the functions mentioned in the > x11drv.spec > file. So I would be able to change the functions in win32 source code > and recompile with the X11DRV_.. functions. Possible, perhaps. However to me it just seems like a silly hack to use the X11DRV_ functions for that or at least to use them directly. Anyway, so what you really want to be able to compile Windows source code to a Windows binary that instead of using normal USER/GDI instead uses Wine's version of USER/GDI that using the X11DRV displays the application's Window(s) on a X-Terminal? Hmm. Intresting idea. Well, yes that would be possible to do with Wine, at least in theory. There is a lot a practical problems to be resolved for that to work. Just getting the non-core parts (especially USER/GDI and X11DRV) to compile and link to a DLL with the Windows headers will be an effort by itself. Actually getting it to work will be even worse, The USER (and to a lesser part even GDI) seems, eventhough I guess they can be made not to, to use the Wine server for some things, with means that you will either have to fix that or emulate the Wine server on Windows. It is propably not that hard to emulate it, but quite a lot of work regardless. Then you have the issue of getting the Windows versions of COMCTL32 and COMDLG32 DLL:s and similar DLL:s using your special versions of USER32 and GDI32 and not the Windows ones. I'm not sure Windows can be made to support this at all. It depends on exactly how library loading work. Hmm, perhaps it would be possible to "hook" LoadLibrary somehow. Anyway, I'm sorry to say that it will currently not, with the state Wine is now, be possible to do that without an enormous effort. Despite this I'm happy to say that I think it will be possible some day. However not until past Wine 1.0 or perhaps not even past Wine 1.x. Nice idea though.

1 0

RE: x11drv port to win32 possible ?
by Patrik Stridvall Aug. 9, 2001

Aug. 9, 2001

> Has anyone already try to compile it with VC++. > > Using the win32X11 port from http://sources.redhat.com/win32-x11/ and > microsoft visual C++ 6.0 I was able to compile some parts: tsx11 and > wineclipsrv.exe. > > The intention is to create a dll that exports the winapi graphic > functions for X11: X11DRV_CreateWindow,X11DRV_InitKeyboard,.. > see x11drv.spec. > > 1)If we can compile that dll, can we recompile a win32 app so it > runs on a pc and display on a X-terminal? > 2)Can multiple users run the same app on win95/98 and display on diff > X-terminals? I think what I think you are proposing is currently entirely out of the scope of the Wine project. Wine is currently not designed for this. Compiling some of the non-core DLL:s like COMCTL32, COMDLG32 and others might be meaningful for test purposes, but the core stuff like the is simply not possible and it is not needed since Windows already has its own implementation of them that can used in the testing the non-core DLL:s. In short, what you are proposing is intresting but it has currently little to do with the Wine project. What you want to do is the write a Windows "graphic card" driver that display the result on an X-Terminal. While you certainly can (and are indeed legally allowed to do) use part of the x11drv to do this, I think most of the X11DRV is to high level to be useful. Sure someday when your "graphic card" driver works good we might consider redesigning Wine to use the Windows "graphic card" driver interface, but it will certainly not not be done before Wine 1.0 or even Wine 1.x. Perhaps Wine 2.0 might be a good point to merge such things with Wine, assuming of course that you or somebody else implements such a thing and releases it under an acceptable license (preferably the Wine license, the new one that is).

2 1

x11drv port to win32 possible ?
by Rudi De Vos Aug. 9, 2001

Aug. 9, 2001

HI, Has anyone already try to compile it with VC++. Using the win32X11 port from http://sources.redhat.com/win32-x11/ and microsoft visual C++ 6.0 I was able to compile some parts: tsx11 and wineclipsrv.exe. The intention is to create a dll that exports the winapi graphic functions for X11: X11DRV_CreateWindow,X11DRV_InitKeyboard,.. see x11drv.spec. 1)If we can compile that dll, can we recompile a win32 app so it runs on a pc and display on a X-terminal? 2)Can multiple users run the same app on win95/98 and display on diff X-terminals? thxs Rudi

1 0

x11drv port to win32 possible ?
by Rudi De Vos Aug. 9, 2001

Aug. 9, 2001

HI, Has anyone already try to compile it with VC++. Using the win32X11 port from http://sources.redhat.com/win32-x11/ and microsoft visual C++ 6.0 I was able to compile some parts: tsx11 and wineclipsrv.exe. The intention is to create a dll that exports the winapi graphic functions for X11: X11DRV_CreateWindow,X11DRV_InitKeyboard,.. see x11drv.spec. 1)If we can compile that dll, can we recompile a win32 app so it runs on a pc and display on a X-terminal? 2)Can multiple users run the same app on win95/98 and display on diff X-terminals? thxs Rudi

1 0

Re: Rewrite AFM parsing code
by Dmitry Timoshkov Aug. 9, 2001

Aug. 9, 2001

"Ian Pilcher" <ian.pilcher(a)home.com> wrote: > Log message: > Ian Pilcher <ian.pilcher(a)home.com> > WINEPS: rewrite and separate AFM parsing code (no more [afmfiles]) [...] > +inline static BOOL IsWinANSI(LONG uv) > +{ > + if ((0x0020 <= uv && uv <= 0x007e) || (0x00a0 <= uv && uv <= 0x00ff) || > + (0x2018 <= uv && uv <= 0x201a) || (0x201c <= uv && uv <= 0x201e) || > + (0x2020 <= uv && uv <= 2022)) ^^^^ Shouldn't it be 0x2022? -- Dmitry.

2 1

Re: Remove redundant implementations
by Alexandre Julliard Aug. 9, 2001

Aug. 9, 2001

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Remove redundant implementation of __get_cs,__get_ds,__get_es, > __get_fs,__get_gs,__get_ss,__set_fs,__set_gs. These are here to support compilers that don't have gcc-style inline assembly. This is admittedly a theoretical issue at this point, but there shouldn't be any harm in keeping them around just in case. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Remove redundant implementations
by Alexandre Julliard Aug. 9, 2001

Aug. 9, 2001

"Dmitry Timoshkov" <dmitry(a)baikal.ru> writes: > Perhaps they should be protected from compiling under gcc? Why would you want that? They could conceivably be useful even with gcc in case it decides not to use the inline version. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: CS_PARENTDC with WS_CLIPSIBLINGS
by Alexandre Julliard Aug. 8, 2001

Aug. 8, 2001

Ladislav Sladecek <lsla(a)post.cz> writes: > The function is called like this: > > 0806c1c8:Call GDI.38: ESCAPE(0x0000,0x000d,0x0000,0x00000000,0657:e8f4) ret=0ff7:4428 ds=1207 > > The in_data pointer is null but the code assigns to it, thats why it > crashes. I think that the result should be assigned to the output parameter. Yes of course, stupid typo on my part. Thanks for spotting it. -- Alexandre Julliard julliard(a)winehq.com

1 0

Some strange code in configure.in
by Lionel Ulmer Aug. 8, 2001

Aug. 8, 2001

Hi all, By looking at some guy's config.log, I found out this in configure.in : dnl Check for GLU32 library. AC_CHECK_LIB(GLU,glBegin, X_PRE_LIBS="$X_PRE_LIBS -lGLU" GLU32FILES='$(GLU32FILES)' GLU32_DLL=glu32 ,, $X_LIBS $X_PRE_LIBS -lXext -lX11 -lm $X_EXTRA_LIBS ) My question is why do we test for 'glBegin' in GLU and not something better like, say, 'gluLookAt' ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

Re: CS_PARENTDC with WS_CLIPSIBLINGS
by Alexandre Julliard Aug. 8, 2001

Aug. 8, 2001

Ladislav Sladecek <lsla(a)post.cz> writes: > 2) The real reason for the crash is that the application calls Escape16 with > hdc equal to 0 and function equal to GETPRINTINGOFFSET. I do not understand > why, they did not even start to print. Maybe, this is an undocumented windows > function? After I temporarily disabled Escape16, the application began to > work. It's not supposed to crash even if the hdc is invalid. Do you have a backtrace of the crash? > 4) To fix Escape16, the 16bit printer driver is necessary. I need printing > either. I will try to work on it if you just give me a piece of advice. I think > that two ways are possible: > > A) To use the static table and to modify create_driver to work with it. > > B] To create a 16bit printer driver DLL similarly to the 32bit drivers. The static table is OK, but you'll need to add a number of functions that were done by escapes before (AbortDoc, StartDoc, etc.) And of course there is still the GDI lock issue so I don't know if you can actually print something even if you fix the initialisation. -- Alexandre Julliard julliard(a)winehq.com

2 1

Eliminating [afmfiles] from .wine/config
by Ian Pilcher Aug. 8, 2001

Aug. 8, 2001

Anyone see any reason not to? [afmdirs] has been around for quite a while now. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

Re: CS_PARENTDC with WS_CLIPSIBLINGS
by Alexandre Julliard Aug. 7, 2001

Aug. 7, 2001

Ladislav Sladecek <lsla(a)post.cz> writes: > Maybe the printer driver never gets initialised? (Just a stupid speculation). Not stupid at all, actually the 16-bit driver support is temporarily broken (not that it really worked well before anyway). It shouldn't be too hard to fix, but I haven't had time yet. Volunteers are welcome... -- Alexandre Julliard julliard(a)winehq.com

2 1

Implementing Winsock2 Function
by Nick Bauer Aug. 7, 2001

Aug. 7, 2001

Hello, I was working with Andreas Mohr on a program I was trying to get running under Wine, and he suggested that I email this list and ask for help to get an un-implemented function implemented. My application is a software program used to control our phone system. The error is: Unhandled exception: unimplemented function ws2_32.WSALookupServiceBeginA called in 32-bit code (0x407be056). In 32-bit mode. 0x407be056 (__wine_unimplemented+0x56 [ws2_32.spec.c:40] in WS2_32.DLL): jmp 0x407be050 (__wine_unimplemented+0x50 [ws2_32.spec.c:40] in WS2_32.DLL) 43 void __wine_stub_ws2_32_WPUCompleteOverlappedRequest(void) { __wine_unimplemented("WPUCompleteOverlappedRequest"); } I have tried using the native WS2_32 DLL and then the program no longer crashes, but it looks like its attempting to connect to the server, but never gets connected. I set up iptables to log all packets going to that server out eth0, but it never catches any packets. Any help would be greatly appreciated, as I have no knowledge of coding. Also, I am not on the list, so please include my email on any responses. Thanks a lot, -Nick

1 0

printing with wine
by Ricahrd Canada Aug. 7, 2001

Aug. 7, 2001

Does anybody have complete instructions on how to set up a printer to use in wine? I have tried all of the suggestions with add entries to the wine.conf file, using the internal driver, etc. I cannot seem to get wine to see any printers. I use lprng through a print server, so I do not have any local printers attached. Can anyone help?? Richard

1 0

printing in wine
by richard.canada＠mrlinternational.com Aug. 7, 2001

Aug. 7, 2001

Does anybody have complete instructions on how to set up a printer to use in wine? I have tried all of the suggestions with add entries to the wine.conf file, using the internal driver, etc. I cannot seem to get wine to see any printers. I use lprng through a print server, so I do not have any local printers attached. Can anyone help?? Richard

1 0

AbiWord 0.9 problems even with latest Wine from CVS
by Dan Kegel Aug. 7, 2001

Aug. 7, 2001

The AbiWord win32 0.9 problems I described recently on wine-users with Codeweavers Preview 4 also happen with the latest Wine built from CVS this afternoon. These problems don't happen when run on Windows, nor when running the native Linux version; they therefore appear to be Wine bugs. Details at http://www.kegel.com/wine/abiword0.9/readme.html I stand ready and willing to apply and test patches, but might not have time to write any fixes myself. Thanks, Dan -- "I have seen the future, and it licks itself clean." -- Bucky Katt

2 4

Re: named critical sections
by Andreas Mohr Aug. 7, 2001

Aug. 7, 2001

On Tue, Aug 07, 2001 at 04:15:41PM +0200, Andreas Mohr wrote: > Hi all, > > this patch implements *names* for the most important critical sections. > > I simply grew tired of constantly having to look up the crst addresses > in winedbg whenever there was some crst timeout. > Yeah, I know, that patch is slightly weird/dirty, but it's useful. Yup, this patch is weird: > + TRACE("#1\n"); > + TRACE("#2: %p\n", obj); Alexandre, please apply it without this crap ;-) (hmm, I really thought I had properly checked it) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

Re: CoGetClassObject
by r.maurizzi＠gvs.it Aug. 7, 2001

Aug. 7, 2001

[Notes 5.0.8] > The only error message the installer came up with was a dialog saying > "AddFolderIcon" failed. The same here. > I had also understood that there was now a facility to add programs that > would have installed themselves into the Windows startup menu into the KDE > menu structure. I am running KDE 2.2 from CVS if it matters. But nothing > appeared. Had I understood wrong, or do I need to try to do some > debugging? Maybe not for all the InstallShield versions: it worked for me for the game "I-War" (quite old... DirectX 5 I think), with KDE 2.1 Or it could be that the installer crash doesn't help in getting the icon loaded... :-) I didn't had time to look into this feature. Ciao, Roberto.

3 2

CoGetClassObject
by Daniel Walker Aug. 7, 2001

Aug. 7, 2001

I was thinking of ways to get the CLSCTX_LOCAL_SERVER option working in wine. The only program that uses it , that I know of, is installshield v6 .. I pretty sure some other people are working on this, but I don't know that status. (Anyone care to update me?) There is another problem. It's with the TypeLib information in the IKernel.exe that comes with InstallShield v6. The TypeLib information is encoded somehow, any ideas? I was able to get around that problem because installshield also looks for type information in "ikernel.tlb" . So I was able to create a .tlb that worked. I also used the reaktivate typelib patch so the typelib info gets put into the registry. So the way I understand it is that when CoGetClassObject is called Wine is suppose to , in this case, execute IKernel.exe . Then IKernel.exe will CoRegisterClassObject on all needed objects .. One problem is that the registered class object list isn't shared between the two processes, so we would need to move that list into the wine server (Right?) .. Then we would also need to send an instance of the class object to the Wine server (Yeah??) .. Following that road seems to lead to some messy address translations for DLL's and whatever else.. Since we have complete control over how IKernel.exe is run, how would we get the two processes to share memory? Maybe have IKernel.exe execute in a thread? IKernel.exe doesn't do anything but register it's class objects .. Would it be possible to treat IKernel.exe as a DLL then run CoRegisterClassObject for it? Daniel Walker

8 13

Re: CoGetClassObject
by David.Goodenough＠dga.co.uk Aug. 7, 2001

Aug. 7, 2001

Curiously (on the subject of InstallSheild) I have just successfully installed the latest (5.0.8) Lotus Notes client on a wine system (latest tarball) and the new Lotus installer is InstallSheild based. It ran perfectly EXCEPT that the program would not terminate. The Lotus installer takes over the whole screen, and that went away, but wine never returned to the command line. As far as I could see there were no messages about locks or anything. The only error message the installer came up with was a dialog saying "AddFolderIcon" failed. I had also understood that there was now a facility to add programs that would have installed themselves into the Windows startup menu into the KDE menu structure. I am running KDE 2.2 from CVS if it matters. But nothing appeared. Had I understood wrong, or do I need to try to do some debugging? Ove Kaaven <ovehk(a)ping.uio.no> on 08/07/2001 07:55:41 AM To: Rein Klazes <rklazes(a)xs4all.nl> cc: wine-devel(a)winehq.com (bcc: David Goodenough/DGA/GB) Subject: Re: CoGetClassObject On Tue, 7 Aug 2001, Rein Klazes wrote: > On Tue, 7 Aug 2001 01:12:34 +0200 (CEST), you wrote: > > > > > > > It couldn't get it from the ikernel.exe because I think > > > it's encoded somehow (unicode, MultiByte??). > > > > It doesn't look encoded, it's just different (it's most likely what is > > boasted as the "Typelib 2 Format"). Win2000's stdole32.tlb also uses this > > new format (it has a "SLTG" signature instead of the old "MSFT"). > > > SLTG is the old format, MSFT came later. Wine can (natively) only read > MSFT. Allright, but the most important question remains: who will volunteer to reverse engineer these SLTG typelibs and make Wine able to read them, so I can concentrate on the actual COM marshaling stuff (which is pretty hard enough as it is), so we can finally get those @#&% InstallShields up?

1 0

Re: ownerdrawn button fix
by Alexandre Julliard Aug. 6, 2001

Aug. 6, 2001

Aric Stewart <aric(a)codeweavers.com> writes: > A full fix would be to make sure we never call the paint function > directly. However the only time this seems to actually cause a crash is > with owner drawn. This patch corrected the problem with owner drawn so > that we do not have to retest everything with buttons. This seems to defeat the purpose of having the ODA_* constants. Would it also fix your problem to only do the PAINT_BUTTON when the window is visible? -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: (no subject)
by Alexandre Julliard Aug. 5, 2001

Aug. 5, 2001

Ladislav Sladecek <lsla(a)post.cz> writes: > If you run the binary in the Windows, you will see two properly sized > red rectangles on a white background. If you run the same binary in > Wine, you will see only one large red child but no white parent > background. If either the CS_PARENTDC or WS_CLIPSIBLINGS gets removed > from my example, both Windows and Wine give identical results. Yes, there were a number of problems with the flags handling in GetDCEx. I think the behavior with the current CVS should now be correct in all cases; please give it a try. -- Alexandre Julliard julliard(a)winehq.com

3 3

Just out of interest whats this?
by Robert Laverick Aug. 5, 2001

Aug. 5, 2001

FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock what's this, what's causing it and what needs fixing (I'll give it a look if it's needed) or is it just an old error that dosn't really need fixing (I can run almost everything I want to and the all show this error) just intersted Rob

1 1

Window-position bug?
by davep Aug. 4, 2001

Aug. 4, 2001

Here's one I haven't seen before. Build the 'winemine' application in the programs directory and start it running. Click on the smiley-face button (which redraws the window). Every time I press the button the entire window moves down the screen one pixel. Dave

1 0

Re: wine/dlls/oleaut32 typelib.c
by Dmitry Timoshkov Aug. 4, 2001

Aug. 4, 2001

"Alexandre Julliard" <julliard(a)winehq.com> wrote: > Log message: > Malte Starostik <malte(a)kde.org> > Implemented RegisterTypeLib. > > Patch: http://cvs.winehq.com/patch.py?id=99686240431774649117142 + if (res == S_OK && RegCreateKeyExA(key, "FLAGS", 0, NULL, 0, + KEY_WRITE, NULL, &subKey, NULL) == ERROR_SUCCESS) + { + CHAR buf[20]; + /* FIXME: is %u correct? */ + snprintf(buf, strlen(buf), "%u", attr->wLibFlags); ^^^^^^^^^^^ + if (RegSetValueExA(subKey, NULL, 0, REG_SZ, + buf, lstrlenA(buf) + 1) != ERROR_SUCCESS) + res = E_FAIL; + } I'm sorry, it's late a bit. But anyway, instead of strlen() above should be sizeof(). -- Dmitry.

1 0

Re: PATCH: ITypeInfo::Invoke
by Dmitry Timoshkov Aug. 4, 2001

Aug. 4, 2001

"Marcus Meissner" <marcus(a)jet.franken.de> wrote: > +static void dump_VarType(VARTYPE vt,char *szVarType) { > + /* FIXME : we could have better trace here, depending on the VARTYPE > + * of the variant > + */ > + switch(vt) { > + case VT_UI1: MESSAGE(szVarType, "VT_UI"); break; ^^^^^^^ > + case VT_I2: sprintf(szVarType, "VT_I2"); break; > + case VT_I4: sprintf(szVarType, "VT_I4"); break; Seems to be a typo. Shouldn't it be sprintf instead of MESSAGE? -- Dmitry.

1 0

RE: What is the @ in the function headers
by Patrik Stridvall Aug. 3, 2001

Aug. 3, 2001

> Quick question. What is the @ in a function header supposed > to contain? > Presumably it is the ordinal in the Dll. Well, functions either has an ordinal or a @. If it has a @ it is means that it doesn't matter what the ordinal is, that winebuild can assign any ordinal it likes for the function. > But what if the > same function has > different ordinals in different copies of the Dll? You mean different versions? Anyway, Wine has no support for it, because none is really needed, because any application that tries to access functions by ordinal that doesn't have a fixed ordinal across DLL version is broken even on Windows.

1 0

What is the @ in the function headers
by Bill Medland Aug. 3, 2001

Aug. 3, 2001

Quick question. What is the @ in a function header supposed to contain? Presumably it is the ordinal in the Dll. But what if the same function has different ordinals in different copies of the Dll? Bill

1 0

Re: Dont allow SetSelectorBase to change into an kernel region
by Alexandre Julliard Aug. 3, 2001

Aug. 3, 2001

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > If I only allow to set the selector base when (selector base + selector > limit) is smaller than 0x8000000, the application goes on and lets me read > an eprom plugged into the Galep3 Programmer. Is the appended fix a right > acceptable? No, it's legal to have selectors covering the entire address space. I'm afraid there is no good solution to this kind of problem. What does the app do under NT or with -winver nt40? -- Alexandre Julliard julliard(a)winehq.com

2 1

Some questions about TB_REPLACEBITMAP
by Marco Bizzarri Aug. 3, 2001

Aug. 3, 2001

Hi all. I'm trying to implement the TB_REPLACEBITMAP message in the comctrl32, and I would like to have some advice about the ImageList structure. The TB_REPLACEBITMAP provides (via the hInst, nID pair) the handle to the old bitmap and the handle to the new bitmap, as well as the number of button in the new bitmap. I think I could use the ImageList_Replace to actually replace the bitmaps. However, the ImageList_Replace function requires a number, which is the first bitmap to be replaced. How can I retrieve this information? For what I can see, once a bitmap has been added to the imagelist, no information about is is stored. I'm doing some tests, using a value (like 0) as the bitmap index, but this is of little help, of course. Any help will be appreciated. Bye Marco

1 0

Some questions about TB_REPLACEBITMAP
by Marco Bizzarri Aug. 3, 2001

Aug. 3, 2001

Hi all. I'm trying to implement the TB_REPLACEBITMAP message in the comctrl32, and I would like to have some advice about the ImageList structure. The TB_REPLACEBITMAP provides (via the hInst, nID pair) the handle to the old bitmap and the handle to the new bitmap, as well as the number of button in the new bitmap. I think I could use the ImageList_Replace to actually replace the bitmaps. However, the ImageList_Replace function requires a number, which is the first bitmap to be replaced. How can I retrieve this information? For what I can see, once a bitmap has been added to the imagelist, no information about is is stored. I'm doing some tests, using a value (like 0) as the bitmap index, but this is of little help, of course. Any help will be appreciated. Bye Marco

1 0

Switching threads in winedbg
by Francois Gouget Aug. 3, 2001

Aug. 3, 2001

Is it possible to switch threads in winedbg? I can use 'walk thread' to see a list of the threads of my application but I could not find how to get a backtrace of one of these other threads. It's not in the Wine Developper's Guide and I could not find it from the source. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In a world without fences who needs Gates?

2 1

Dose wine people hate Solaris?
by EriK W Aug. 3, 2001

Aug. 3, 2001

I have posted my question for compiling Wine in solaris x86 for 2 weeks, seems no anybody even has a bit interest. Do you guys hate solaris? :) I checked almost all the documents and faq, except it mentioned wine works with Solaris, there almost have no other info for it at all. Does anybody has even a suggestion for me? pls don't tell me nuke my solaris. :)

5 8

Re: Documenting functions
by Alexandre Julliard Aug. 2, 2001

Aug. 2, 2001

"Bill Medland" <medbi01(a)accpac.com> writes: > Ay, there's the rub. It isn't our function. It';s Microsoft's function. > Now was it Holub or McConnell that complains about functions having weird > behaviour on certain inputs. IMO Microsoft functions need less documentation than internal ones, since there is MSDN and other countless books about Windows. You can assume that people reading your code already know what the various APIs are supposed to do. > The biggest problem, I believe, is the functions that take flags. Bear in > mind that a single DWORD argument used for flags is equivalent to up to 32 > boolean arguments. Documenting the relationship between those is a pain > but it needs to be done if we expect compatibility. This is clearly something that is best documented with code, not with text. You may need pages of text to describe the flags behavior in English, while with code it's usually only a few lines, plus a few comments here and there. This doesn't mean it wouldn't be a good thing to also have the full description in English; but in a separate document, not in the code. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Prevent excessive clipping in SysListView32
by Uwe Bonnes Aug. 2, 2001

Aug. 2, 2001

>>>>> "Medland," == Medland, Bill <Bill.Medland(a)accpac.com> writes: Medland,> I am not very comfortable with this one but strange as it may Medland,> seem it solves the problem. I'd love to know why. Medland,> <<diff13.txt>> Bill Medland (medbi01(a)accpac.com) Prevents Medland,> excessive clipping in SysListView32. Medland,> Medland,>-static inline int perfect_graphics(void) Medland,>+static int perfect_graphics(void) Medland,> { Medland,> static int perfect = -1; Medland,> if (perfect == -1) Medland,> Some C-Expert is requested here, but I suspect that in the old function the variable "perfect" was created in every instantiation of the "perfect_graphics" inlined function. Could you perhaps try to declare the "perfect" outside the inlined function, like static int perfect = -1; static inline int perfect_graphics(void) Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

6 9

Re: Documenting functions
by Alexandre Julliard Aug. 2, 2001

Aug. 2, 2001

Jeremy White <jwhite(a)codeweavers.com> writes: > I would say that I would rather have 100% of the effort a > particular developer *wants* to put in, rather than only > have his/her coding efforts. Absolutely; I'm not going to discourage anybody from writing doc if they feel like it. But I don't want anyone to feel somehow obliged to spend time on the doc if they'd rather be writing code, which I expect is the case with most developers... > However, I think that there should be a standard function > header, with a standard place to put notes and comments > in general about a function. I don't see a need to standardize anything. If you want to add a comment before a function just do it, there is no need for a standard format, plain text works just as well. > I have been trained, and I suspect that many of us have > been trained, to look at a function header for general > tips and tricks before diving into the code. I know > this is sacriledge to you, Alexandre, but there are some > of us who like to quickly look at a function, rather than > always reading the code to understand it completely. I think you misunderstand my position; I'm not opposed to having a comment at the start of the function explaining the general goal and the non-obvious things going on. But if you need more than a couple of paragraphs to do this, then either there are too many non-obvious things going on in your function, or you are wasting space explaining the obvious. I do strongly think that the goal should be to write code that doesn't require documentation in order to be understood. Of course adding a small amount of comments is a good idea; but when you start having more lines of documentation than lines of code, something is very wrong IMO. But this is mainly a matter of personal taste, and except in extreme cases I'm not going to reject code because it has too much (or not enough) documentation. It may happen that some of your beloved horizontal lines get lost during the cvs commit though ;-) -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Documenting functions
by Jeremy White Aug. 2, 2001

Aug. 2, 2001

[Resend due to exim crash; thanks Ove] >> I'd much rather have developers spend their time writing code. Making >> them duplicate the whole MSDN documentation would be a huge waste of >> their time. Our resources are not infinite, and it's much more useful >> to have 100% API coverage with no docs at all than 50% coverage and >> tons of docs. I think this is a dangerous attitude to take. I think that you cannot (and should not) attempt to force volunteer developers to add documentation to code. However, there are some few of us, who don't feel that the job is satisfactorily done until the documentation reflects important things that we've learned. I would say that I would rather have 100% of the effort a particular developer *wants* to put in, rather than only have his/her coding efforts. If I, like Bill, spend 24 hours ripping my hair out to learn some oddball things, I want a place to put those things. I want someone else (or an older version of me) to have a chance to not have to learn those things the hard way. Please don't misunderstand me. I agree that we shouldn't try to replicate MSDN. I'm not even sure we should provide minimal documentation like parameter lists and return values. Further, I agree that where it makes sense, the best place for comments is inline with the relevant code. However, I think that there should be a standard function header, with a standard place to put notes and comments in general about a function. I have been trained, and I suspect that many of us have been trained, to look at a function header for general tips and tricks before diving into the code. I know this is sacriledge to you, Alexandre, but there are some of us who like to quickly look at a function, rather than always reading the code to understand it completely. <in joke> Finally, I think all the code would be dramatically improved, in fact, I bet we'd be at Wine 1.0 by now, if there were nice big horizontal separator lines everywhere. </in joke>

1 0

Re: Documenting functions
by Alexandre Julliard Aug. 2, 2001

Aug. 2, 2001

Francois Gouget <fgouget(a)free.fr> writes: > So I think the functions implemented in Wine should be fully > documented. And the only place to do that is in the code source because > this is the only place where they have a remote chance of staying up to > date (and also where it's most practical to have it). I have to disagree here. Yes it would be nice to have a free Win API documentation, but it definitely doesn't belong inside the Wine source. First it would be a huge bloat in the source; and more importantly the Wine source doesn't define the Windows API, it is defined by Microsoft. > Of course developpers are very well-known for hating to document > stuff so it's going to be pretty hard to get proper documentation. But > we should encourage all Wine developpers to write good documentation for > the functions they implement/fix, not dissuade them to do so. I'd much rather have developers spend their time writing code. Making them duplicate the whole MSDN documentation would be a huge waste of their time. Our resources are not infinite, and it's much more useful to have 100% API coverage with no docs at all than 50% coverage and tons of docs. > Also I agree with you that the strict minimum is to at least document > all the undocumented/weird behaviors. Especially since without some sort > of documentation the next developper may be tempted to remove what looks > like unnecessarily convoluted/obviously wrong code. That should be done with comments inside the code itself. And in many cases it would actually be better to comment the places where the behavior is not right. What I mean is, instead of adding a comment on every line stating "yes this is what Windows does", I'd prefer adding a comment/FIXME to mark the lines that have been written without checking whether Windows really does it this way. -- Alexandre Julliard julliard(a)winehq.com

2 1

Dont allow SetSelectorBase to change into an kernel region
by Uwe Bonnes Aug. 1, 2001

Aug. 1, 2001

Hallo, galep3 crashes with following sequence: 096c7b38:Call KERNEL.189: SETSELECTORLIMIT(0x0d87,0x0000045f) ret=02e7:6fb5 ds=099f 096c7b38:Ret KERNEL.189: SETSELECTORLIMIT() retval=0x0d87 ret=02e7:6fb5 ds=099f 096c7b38:Call KERNEL.187: SETSELECTORBASE(0x0d87,0xc02924e0) ret=02e7:6fc1 ds=099f 096c7b38:Ret KERNEL.187: SETSELECTORBASE() retval=0x0d87 ret=02e7:6fc1 ds=099f ... Unhandled exception: page fault on read access to 0xc0292545 Obviously the application trys to reach some kernel memory. If I only allow to set the selector base when (selector base + selector limit) is smaller than 0x8000000, the application goes on and lets me read an eprom plugged into the Galep3 Programmer. Is the appended fix a right acceptable? Index: wine/memory/selector.c =================================================================== RCS file: /home/wine/wine/memory/selector.c,v retrieving revision 1.39 diff -u -r1.39 selector.c --- wine/memory/selector.c 19 Jul 2001 00:39:10 -0000 1.39 +++ wine/memory/selector.c 1 Aug 2001 17:30:48 -0000 @@ -327,7 +327,12 @@ LDT_ENTRY entry; wine_ldt_get_entry( sel, &entry ); wine_ldt_set_base( &entry, DOSMEM_MapDosToLinear(base) ); - wine_ldt_set_entry( sel, &entry ); + if ((base + wine_ldt_copy.limit[sel >> __AHSHIFT]) > 0x8000000) + { + FIXME("Illegal region base %lx limit %lx\n", base,wine_ldt_copy.limit[sel >> __AHSHIFT]); + } + else + wine_ldt_set_entry( sel, &entry ); return sel; } Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 1

Strange window handle in the trace
by Marco Bizzarri <m.bizzarri＠icube.it> Aug. 1, 2001

Aug. 1, 2001

Hi all. I'm working on a no-windows installation. The system is a RH 6.2 system, upgraded to the latest patches. I've installed XFree4 and KDE 2.1 I'm experiencing an unhandled exception when I try to a VC application. The application works (almost) fine until it opens a selection dialog, with a list on it. As you can see from the trace, it is trying to do an RDW_UpdateRgns with a wndPtr of 0xffff Unhandled exception: page fault on read access to 0x08fd506b in 32-bit code (0x406d1771). In 32-bit mode. Symbol h_errno is invalid Symbol hack_digit is invalid 0x406d1771 (RDW_UpdateRgns+0x3c9 [painting.c:720] in libuser32.so): testb $ 0x10,0x6b(%esi) 720 if( wnd->dwStyle & WS_VISIBLE ) Wine-dbg>bt Backtrace: =>0 0x406d1771 (RDW_UpdateRgns+0x3c9(wndPtr=0xffff, hRgn=0x0, flags=0x180, firstRecursLevel=0x0) [painting.c:720] in libuser32.so) (ebp=405b1bc4) 1 0x406d1787 (RDW_UpdateRgns+0x3df(wndPtr=0x40377824, hRgn=0x0, flags=0x180, firstRecursLevel=0x0) [painting.c:721] in libuser32.so) (ebp=405b1c20) 2 0x406d1787 (RDW_UpdateRgns+0x3df(wndPtr=0x40377538, hRgn=0x0, flags=0x180, firstRecursLevel=0x1) [painting.c:721] in libuser32.so) (ebp=405b1c7c) 3 0x406d1e08 (RedrawWindow+0x38c(hwnd=0x43f0, rectUpdate=0x0, hrgnUpdate=0x0, flags=0x180) [painting.c:982] in libuser32.so) (ebp=405b1cd4) 4 0x406d1f1d (UpdateWindow+0x21(hwnd=0x43f0) [painting.c:1015] in libuser32.so) (ebp=405b1cf0) 5 0x0043df7a (<Debugged process>.EntryPoint+0x13625 in <Debugged process>) (ebp=0046e660) 6 0x00000623 (ebp=000044e4) Just for "fun", I've tryied to add checks for 0xffff, but it crashes when it enters non Wine DLL (actually they are Spread dlls from Farpoint) Any clue? Thanks you all in advance Bye Marco -- Marco Bizzarri - Responsabile Tecnico - Icube S.r.l. Sede: Via Ridolfi 15 - 56124 Pisa (PI), Italia E-mail: m.bizzarri(a)icube.it WWW: www.icube.it Tel: (+39) 050 97 02 07 Fax: (+39) 050 31 36 588

1 0

CloseHandle with 0xffffffff parameter
by Marco Bizzarri Aug. 1, 2001

Aug. 1, 2001

Hi All. While trying to make an application working under wine, I've stumped into the following trace fragment, obtained with --debugmsg +relay: 081612c8:Call kernel32.CreateFileA(405f6454 "c:\\rs\\project\\apitest\\vc\\32\\apitestvc60\\debug\\ret_dll.pdb",80000000,00000001,00000000,00000003,00000080,00000000) ret=404aa001 081612c8:Ret kernel32.CreateFileA() retval=ffffffff ret=404aa001 081612c8:Call kernel32.CloseHandle(ffffffff) ret=404aa0bd 081612c8:Ret kernel32.CloseHandle() retval=00000000 ret=404aa0bd As you can see, the program is trying to open a file, which is not found. An invalid handle (ffffffff) is returned. The program however closes the handle. My question is: is this correct? Should the CloseHandle check to see if it is a correct handle? Thank you all in advance Marco Bizzarri -- Marco Bizzarri - Responsabile Tecnico - Icube S.r.l. Sede: Via Ridolfi 15 - 56124 Pisa (PI), Italia E-mail: m.bizzarri(a)icube.it WWW: www.icube.it Tel: (+39) 050 97 02 07 Fax: (+39) 050 31 36 588

1 0

Documenting functions
by Bill Medland Aug. 1, 2001

Aug. 1, 2001

Getting back to what we are and are not allowed to do.. Suppose I am looking at a low-level function that I believe is only 75%-complete (the most important 75% of course and no disrespect meant to those who have got it that far). One of the problems with it is it is not totally clear EXACTLY what the function should do in some of its more esoteric modes. To me the first task is to define what it should do and that should be part of the documentation of the function. The particular function currently does not have any true documentation within the code; the best documentation of what it does is the code itself, and the best documentation of what it should do is the MSDN description of the function. 1. Should the function be completely defined in its header in the source code (which will probably make the header twice as large as the function) or should the details be put somewhere else. 2. Are we walking into copyright danger if the Wine documentation of the function is clearly based on the MSDN documentation, even if we acknowledge that. 3. Are we interested in that level of documentation? Bill

4 3