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

Re: wine-devel digest, Vol 1 #445 - 9 msgs

by Francois Gouget

On Thu, 30 Aug 2001, Robert Lunnon wrote: > 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 believe that the problem is that SOCK_STREAM==1 SOCK_DGRAM==2 on windows and linux. So WSOCK32_socket assumed that the type parameter does not need any conversion, which seems to be wrong on Solaris. Try the attached patch. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.

Aug. 30, 2001

Re: [PATCH] DestroyWindow16

by eric pouech

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

Aug. 30, 2001

Problems with WM_PAINT and threads

by Ove Kaaven

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?

Aug. 30, 2001

Re: wine-devel digest, Vol 1 #445 - 9 msgs

by Robert Lunnon

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

Aug. 30, 2001

Re: BUG with wine/dlls/ntdll/string.c:_ultoa() ???!!??

by Uwe Bonnes

>>>>> "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 ----------

Aug. 30, 2001

Re: Mouse Events

by Brad Campbell

Brad Campbell wrote: > > 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.. This is probably a more correct patch as it only changes the Pos variables when it's a buttonpress and the absolute flag is set. Because the message in event.c that sends this refers to the getcoords function for it's position data, then the position data is guaranteed to be absolute thus I added the absolute flag to the message sent, this should not affect anything else.. You will have to excuse the logic in input.c as I'm working from a beginners guide to C. I'm a PASCAL programmer by nature.. Thanks for any input.. --- windows/input.c.orig Wed Aug 29 22:44:47 2001 +++ windows/input.c Thu Aug 30 15:13:08 2001 @@ -187,6 +187,12 @@ } } + if (!(mi->dwFlags & MOUSEEVENTF_MOVE) && (mi->dwFlags & MOUSEEVENTF_ABSOLUTE)) + { + PosX = mi->dx; + PosY = mi->dy; + } + if (mi->dwFlags & MOUSEEVENTF_MOVE) { queue_raw_hardware_message( WM_MOUSEMOVE, keystate, 0, PosX, PosY, --- windows/x11drv/event.c.orig Thu Aug 30 15:14:28 2001 +++ windows/x11drv/event.c Thu Aug 30 14:52:15 2001 @@ -477,7 +477,7 @@ break; } - X11DRV_SendEvent( statusCodes[buttonNum], pt.x, pt.y, + X11DRV_SendEvent( statusCodes[buttonNum] | MOUSEEVENTF_ABSOLUTE, pt.x, pt.y, keystate, wData, event->time - X11DRV_server_startticks, hWnd); } -- Brad.... /"\ Save the Forests \ / ASCII RIBBON CAMPAIGN Burn a Greenie. X AGAINST HTML MAIL / \

Aug. 30, 2001

Comment from IBM developer re FS register corruption

by Jeremy White

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.

Aug. 30, 2001

Re: Powerdvd running under linux

by Bobby Bingham

I'd say zilch. If the chipset isn't supported by linux, there's no way wine/wineX can use any advanced features of it because wine uses what linux/X have to offer, which isn't support for this chipset. I don't know what kind of performance it would get without hardware acceleration. Bobby Bingham On Wednesday 29 August 2001 09:37 pm, you wrote: > 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

Aug. 30, 2001

Re: Powerdvd running under linux

by Francois Gouget

On Thu, 30 Aug 2001, Robert Lowery wrote: > 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? Before the chipset is supported by Linux? Zero. Once XFree86 provides XVideo support for your chipset (or even better, the newer brand of XVideo, the one that also include motion compensation, I don't remember the name), then you may get hardware acceleration in Wine. But I think that currently DDraw does not support hardware acceleration for these things. So it will probably require some work on Wine too. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.

Aug. 30, 2001

Powerdvd running under linux

by Robert Lowery

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

Aug. 30, 2001

Re: ./configure file in cvs

by Andreas Mohr

On Wed, Aug 29, 2001 at 02:47:48PM +0200, Gioele Barabucci wrote: > 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. I'd say this is because the Wine CVS is a hybrid of developer and end user code base. "Normal" projects are so mature that you can easily split them into an "end user" and a "developer" section, i.e.: deb/rpm and CVS. Not so with Wine. Due to the rapid development nature of the project, it's beneficial even for end users to get latest CVS sometimes. And end users normally don't have auto* installed, that's for sure. (they're even struggling way too much with missing devel headers already !!) And besides, it's mentioned in the README file like that (./configure), so there shouldn't be *any* confusion ;-) (yeah, RTFM still does apply, and it probably always will) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Aug. 29, 2001

Re: ./configure file in cvs

by Marcus Meissner

On Wed, Aug 29, 2001 at 02:47:48PM +0200, Gioele Barabucci wrote: > 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. It is for convienence, so not all users need to have autoconf and autoheader. We are not using automake and libtool. Ciao, Marcus

Aug. 29, 2001

Mouse Events

by Brad Campbell

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 / \

Aug. 29, 2001

./configure file in cvs

by Gioele Barabucci

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>

Aug. 29, 2001

Re:Call for Volunteers (Re: Newbie work?)

by Francois Gouget

On Wed, 29 Aug 2001, Eric Pouech wrote: > > 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. True. Btw, I'm currently working on the winsock headers :-) The goal is to: - make winsock.h independent from config.h (because one should not need all sorts of autoconf checks when using Winelib) - make winsock.h compatible with the msvcrt headers (which they currently are not, very unfortunately) And as I was working on this I found other issues. Some of them have been resolved and I sent patches already. Status / todo: - because winsock.h and winsock2.h were relying on the Unix headers they were quite incomplete. So I have been adding the missing items and it seems complete enough now. - the new winsocks.h will have a USE_WS_PREFIX feature similar to that of the msvcrt headers. - it's sometimes a bit hard to get them to work with both the Unix C headers and the msvcrt ones, especially when it comes to u_{char,short,...} types and select, FD_XXX. But it seems to work now - the ws_sockaddr_ipx structure is wrong, it does not match what is in windows. Also most of our code seems to assume that the Unix sockaddr_xxx and the windows sockaddr_xxx have the same binary layout. Except for ipx but there what does not help is all these checks are done all other the place in HAVE_IPX ifdefs. So I'm going to try and clean this up, but this is not yet done. - Alexandre pointed out to me that it might also be a good idea to reorganize wsock32, winsock and ws2_32. Specifically winsock should go with wsock32 since they both implement the winsock 1 API. And all 16 bit code would then be removed from ws2_32. - Also, we could try to implement wsock32 entirely by calling ws2_32, and not use sockets at all anymore. This would actually help me as the current situation (wsock32 uses both the Unix socket headers and ws2_32) causes me some trouble. The main problem seems to be WsControl... My other big project is a revision of the command line parsing, and I intended to post a patch for review yesterday but I broke the code at the last minute and did not find any time to look at what went wrong. > > 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. My interest in pedump is mostly as a tool I could use in winemaker to find out which dlls are imported by a dll or an executable, so that I can know what I should link the winelib version with. If this works it would be a first step. Later I guess I could do something ala specmaker / call it to generate a librarie's spec file. But this is for much later. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

Aug. 29, 2001

Re:Call for Volunteers (Re: Newbie work?)

by Eric Pouech

> 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

Aug. 29, 2001

Re: Newbie work?

by Gerard Patel

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

Aug. 29, 2001

Re: Crash in latest version

by Gerard Patel

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

Aug. 29, 2001

Re: Crash in latest version

by Alexandre Julliard

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

Aug. 29, 2001

Re: Crash in latest version

by Gerard Patel

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:

Aug. 29, 2001

Call for Volunteers (Re: Newbie work?)

by Francois Gouget

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

Aug. 28, 2001

Re: Newbie work?

by Bobby Bingham

A couple months ago, Francois Gouget posted a call for volunteers. You can read it at http://www.integrita.com/cgi-local/lwgate.pl/WINE-DEVEL/archives/2001-05/Su… I belienve that some of it has been done, but a lot of it should still need done. On Tuesday 28 August 2001 06:25 pm, 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? > > Daniel Sabo

Aug. 28, 2001

Re: Crash in latest version

by Alexandre Julliard

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

Aug. 28, 2001

Newbie work?

by Daniel Sabo

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

Aug. 28, 2001

Crash in latest version

by Uwe Bonnes

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 --

Aug. 28, 2001

Crash in latest version

by Uwe Bonnes

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 --

Aug. 28, 2001

Re: Codeweavers announces CrossOver plugin

by Jeremy White

> > I talk about our business model here: > http://www/products/crossover/the_real_dirt.php#j er... http://www.codeweavers.com/products/crossover/the_real_dirt.php#j > > I plead my case to the Linux users here: > http://www/products/crossover/the_real_dirt.php#d > um... http://www.codeweavers.com/products/crossover/the_real_dirt.php#d I'm shocked, shocked, I say, to find out that the whole world doesn't use codeweavers.com as their default domain <g>. Jer

Aug. 28, 2001

Re: Codeweavers announces CrossOver plugin

by Jeremy White

Thanks, Marcus. Yes, we've formally shipped the end user version of CrossOver. Man, it proved to be much more work than I ever expected. Before I say anything further, I wanted to thank any and all Wine authors (that I haven't thanked already; I refuse to do it twice <g>) for all of the great work on Wine. Second, I believe that what we are doing is a Good Thing (TM) for both Wine and (hopefully) CodeWeavers. If anyone wanted to review what we're trying to do and kibitz on it (privately to me is fine), I'd appreciate the input. I talk about our business model here: http://www/products/crossover/the_real_dirt.php#j I plead my case to the Linux users here: http://www/products/crossover/the_real_dirt.php#d Thanks, Jeremy I would Marcus Meissner wrote: > 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 > >

Aug. 28, 2001

Codeweavers announces CrossOver plugin

by Marcus Meissner

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

Aug. 28, 2001

Wine in the press

by Eric Pouech

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

Aug. 28, 2001

Re: strange code

by Alexandre Julliard

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

Aug. 27, 2001

strange code

by Andreas Mohr

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/

Aug. 27, 2001

Re: help me with WIN95 value of version16()

by Ladislav Sladecek

On Mo, 27 Aug 2001, Francois Gouget wrote: > 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. > It would probably help if we had a few volunters willing to act as Win > 3.x testers or "compile servers" for Win16 test applications. Or if > someone could provide a Wine developper with a Win16 compiler / Windows > 3.x license. I am a proud owner of Microsoft Visual C++ version 1.52 which I received together with C++ 4.00 as a bonus several years ago. So, if someone needs to compile something, I am ready to help. I am also going to make backups of all that ancient stuff (win 3.1, 3.11, Borland C++) soon. Ladislav Sladecek

Aug. 27, 2001

Re: help me with WIN95 value of version16()

by Gerard Patel

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

Aug. 27, 2001

Re: help me with WIN95 value of version16()

by Francois Gouget

On Mon, 27 Aug 2001 lawson_whitney(a)juno.com wrote: > On Sun, 26 Aug 2001, Francois Gouget wrote: > > > On Sun, 26 Aug 2001, Ladislav Sladecek 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. > > Would anyone be able to compile this application and make it > > available to people on the links, either by emailing it if it is really > > small or via some website (I can provide space if necessary). > > He did attach a binary. I could uuencode it and mail it to you if your > mailer don't do mime or something? That seems improbable though, maybe > you just didn't notice? ??? It's there, I just missed it when I read the email. I just jumped right on the source and tried to compile it (which did not work out of the box since I was using a 32bit compiler). Ok, it returns 0x5f03 here. In ControlPanel/System Win95 says: Microsoft Windows 95 4.00.950a IE 4.0.72.2106.8 -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

Aug. 27, 2001

Re: help me with WIN95 value of version16()

by lawson_whitney＠juno.com

On Sun, 26 Aug 2001, Francois Gouget wrote: > On Sun, 26 Aug 2001, Ladislav Sladecek 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. > Would anyone be able to compile this application and make it > available to people on the links, either by emailing it if it is really > small or via some website (I can provide space if necessary). He did attach a binary. I could uuencode it and mail it to you if your mailer don't do mime or something? That seems improbable though, maybe you just didn't notice? > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > "Lotto: A tax on people who are bad at math." -- unknown > "Windows: Microsoft's tax on computer illiterates." -- WE7U > > > 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.

Aug. 27, 2001

Re: help me with WIN95 value of version16()

by Francois Gouget

On Mon, 27 Aug 2001, Gerard Patel wrote: [...] > 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 Yes, I think I read something about that at the time. IIRC, MS messed up with GetVersion16. They documented HIWORD(GetVersion16()) as returning the major version number when it was in fact in the lower version number or vice-versa. Because of that when they switched to Win95 they wanted the new version number to be greater than the old, no matter how you read it, hence the 3.95: 0x5f03: 3.95 > 3.1 and 95.3 > 1.3 0x0304: 4.3 > 3.1 and 3.4 > 1.3 0x0004: 4.0 would not do since 0.4 < 1.3 Now, why would we have a version with 3.95 and another with 3.4? Is it a Win95 vs Win95 OSR2 issue? Localization should not affect this (though everything is possible). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

Aug. 27, 2001

Re: propably simple

by Andreas Mohr

On Mon, Aug 20, 2001 at 04:26:01PM -0600, Ibrahim Hamouda wrote: > 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 Hmm, ODBC. Wine supports the ODBC DLL, but you'll have to have a working Linux ODBC library, too. (--debugmsg +odbc) And I'm not even sure this applies here at all. Run wine --debugmsg +relay,+odbc,+text,+string MyPrg.exe &>/tmp/wine.log and check why this error occurs. > on the linux box I've already setup the MSSQL alias in the client > connectivity utility of the sql server. > I'll appreciate an answer so I can get some sleep, I'm literaly working > on that for three days. Sorry, slightly late. (vacation) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany "Point is, nothing here is unfamiliar or unexpected. How long does it take before there's general recognition that Microsoft software has no business on the Internet? - Dennis E. Powell re: Code Red

Aug. 27, 2001

Re: help me with WIN95 value of version16()

by Gerard Patel

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

Aug. 27, 2001

Re: keyboard problem

by Stefan Leichter

Ove Kaaven wrote: > > On Sun, 26 Aug 2001, Stefan Leichter wrote: > > > Does anyone know why the message becomes changed? > > If I remember right, a keyboard message must be changed to a syskey > message when one of these conditions are true: > > - the ALT key is pressed > - a menu is being navigated (the system menu in particular) > - the active/focused window is minimized (an icon) > > May be others, but I don't think so. Which do you think applies? The first and the second one are not the case. I'm not sure about the third one. The program is running in fullscreen mode but only if i use the --desktop option. In --managed mode and without mode specified there is no screen output. The program does not show anything like a screen or window (something that has a title bar or a border). How can i check which of the last two cases wine thing it is true? Bye Stefan

Aug. 27, 2001

Re: keyboard problem

by Gerard Patel

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

Aug. 27, 2001

Re: help me with WIN95 value of version16()

by Francois Gouget

On Sun, 26 Aug 2001, Ladislav Sladecek 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. Would anyone be able to compile this application and make it available to people on the links, either by emailing it if it is really small or via some website (I can provide space if necessary). I think we have a big problem here which is that 16bit environments are getting pretty rare. This means that: - almost no-one can check the behavior of an application or API in Windows 3.1 - even fewer persons can compile test applications when we need to test a Win16 API on Win32 OSes. It would probably help if we had a few volunters willing to act as Win 3.x testers or "compile servers" for Win16 test applications. Or if someone could provide a Wine developper with a Win16 compiler / Windows 3.x license. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

Aug. 27, 2001

Re: keyboard problem

by Daniel Sabo

As per the Platform SDK: "The WM_SYSKEYDOWN message is posted to the window with the keyboard focus when the user presses the F10 key or holds down the alt key and then presses another key. It also occurs when now windows has the keyboard focus; in this case, the WM_SYSKEYDOWN message is send to the active window" 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; } ...

Aug. 27, 2001

help me with WIN95 value of version16()

by Ladislav Sladecek

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

Aug. 26, 2001

Re: keyboard problem

by Ove Kaaven

On Sun, 26 Aug 2001, Stefan Leichter wrote: > Does anyone know why the message becomes changed? If I remember right, a keyboard message must be changed to a syskey message when one of these conditions are true: - the ALT key is pressed - a menu is being navigated (the system menu in particular) - the active/focused window is minimized (an icon) May be others, but I don't think so. Which do you think applies?

Aug. 26, 2001

keyboard problem

by Stefan Leichter

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

Aug. 26, 2001

Re: undefined symbol send

by lawson_whitney＠juno.com

On Fri, 24 Aug 2001 lawson_whitney(a)juno.com wrote: > 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]$ Never mind. I guess it was a hardware glitch. The relative humidity is back down to 85, and that error doesn't happen any more. Sure is easy to build junk hardware with GenuineIntel inside. 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.

Aug. 25, 2001

__ws_select

by Robert Lunnon

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

Aug. 25, 2001

undefined symbol send

by lawson_whitney＠juno.com

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.

Aug. 25, 2001

Re: ICQ 2000b

by Daniel Walker

Have you done anything with NtrDllGetClassObject()? Daniel Walker Marcus Meissner wrote: > > On Fri, Aug 24, 2001 at 11:47:39AM -0700, Daniel Walker wrote: > > > > 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? > > Yes. > > I am using following, wrong patch: >

Aug. 24, 2001