wine-devel

wine-devel@winehq.org

1 participants
84471 discussions

FoxPro 5 Applications
by Rick Romero 29 Nov '01

29 Nov '01

Hello, I've been attempting to get Foxpro 5 applications running for a while now. Actually, I just download from cvs randomly, and see what happens. It's been a while, but I decided to try again in October. At that time, there was an OLE error, but the only other strange occurance was a 'locking' of the screen on a print preview. Since then, this 'locking' is the only issue (though I havn't yet attempted to print). The apps I'm trying are my own, basically just a form is called, the user puts in a date range, and a report is run. You can view the report in the print preview window, close the window, use the scroll button on the mouse to change pages, etc. BUT, if you click on the preview itself, and attempt to scroll down to the bottom of the page, a 'lockup' appears to happen. I've just been waiting around hoping for it to be fixed. Today, for giggles, I decided to run the whole Visual Foxpro development environment. It ran! (BTW, I'm trying to do this all with fake windows, and all I've added is the VFP 5 runtime) BUT, anytime I click in an edit Window, MDI interface, the program acts as if I'm holding the shift key down, and as I move my mouse, all the text gets highlighted. I can't 'turn it off', so if there wasn't any text there, it surely would appear locked. I've changed the config from the fake_windows, to point to my Win2k install, but the behavior is the same. I'm actually getting kind of excited now, because we're a small company, and all we run is Fox5 apps (SBT / Skyline -- well, and a couple Fox2.6 win), and Office 2k. If I can run the development environment in Linux, I can take a real look at using linux desktops, either directly, or via LTSP. I don't get any debug info when the 'shift' occurs, and I'm not sure how to dump enough information to see the 'shift keypress' happen (assuming I could fix the problem myself in a way that doesn't interfere with the programming standards..), can someone point me in the right direction? Thanks for your time. Rick Romero

1 0

Proposed solution for mouse capture problems
by Jukka Heinonen 29 Nov '01

29 Nov '01

Okay, here is my proposal about how to fix broken message handling when mouse capturing is in effect. I would like to get some comments so that I can see that I haven't missed anything essential and because I would like to know whether someone is already working on this... Proposal has three parts, but part number one is the most important one, other two parts just show what would need to be done to make capturing work like described in MSDN documentation. 1. Function process_raw_mouse_message should only determine which window was under mouse and resend message to that window as a cooked message. Everything else (especially separating normal messages from nonclient messages and handling mouse captures) should be moved to process_cooked_mouse_message. Actually, I fail to see why raw messages are needed at all, since function SendInput could do this as well. 2. When requesting queued messages from wineserver, the request should also include the window that is capturing mouse input in the current thread - or this could be stored in the wineserver. If there are queued cooked mouse messages, wineserver considers them as if all child windows of capturing window had the handle of the capturing window. This should prevent problems if application requests messages about a single window. 3. Supporting multi-threaded capture is actually the easiest part, although it might be quite useless (Does any application really require it?). When mouse button is pressed in capturing window, process_cooked_mouse_message sets process-wide flag that states that global capture is in effect. After that, either process_raw_mouse_message or SendInput sees that this flag is set and resends all mouse messages to capturing window until button release message is received, which clears the flag. Function process_cooked_mouse_message needs to eat these messages if target window was not capturing window anymore. Proper locking should make sure that no important messages are lost (mouse move events are not important; we might lose button release event, but only if capture has been stopped manually before that and in that case not delivering button release is likely the best thing to do). -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

Re: [patch] Winsock fixes
by Ove Kaaven 29 Nov '01

29 Nov '01

On Wed, 28 Nov 2001, Paul Rupe wrote: > I have found two bugs in dlls/winsock/socket.c. One I posted about a > few days ago in wine.devel. WS_accept calls WS_getpeername but passes > it the Unix file descriptor rather than the Windows socket handle. A > simple one-line change takes care of that. That's Francois's fault, when he split out the sockaddr_xxx conversions. > The second problem is more subtle, and I'm not sure if my solution is > enough. In WINSOCK_DoAsyncEvent there is a loop that dispatches all > events currently available on the socket. The problem is the order, it > simply calls them in increasing order by FD_xxx values. Since FD_READ > is numerically smaller than FD_CONNECT, a socket that has both events > will fire the read event before the connect. When that happens, the app > gets a read event before it thinks it's connected and ignores it. > Ideally, the loop should post them in the order in which they occurred, > but does wine keep track of that? Instead, I changed the loop so that > it checks FD_CONNECT and FD_CLOSE before FD_READ and FD_WRITE. I'm not > sure if the order I chose is the optimal one, but the app I was testing > (Xnews) works every time now. It'd seem to me that FD_CLOSE should be dispatched last, not first... Anyway, now that Alexandre moved the window message queues away from the wine clients and into the wineserver, these event message dispatches could also be done in the wineserver (where the winsock events are generated), instead of using the service thread callback WINSOCK_DoAsyncEvent. Alexandre wants to phase out the service thread anyway, so he probably won't oppose this. Any volunteers for that?

1 0

New Idea
by Matt Q 29 Nov '01

29 Nov '01

I don't know if this is the right news group for this but what the heck... This is a new idea I had. It strikes me that it would be better if wine some how customised it's self to a single users software/configuration... I'd heard that sometimes when one thing is fixed it sometimes breaks another... This wouldn't be a problem if the thing that would hypothetically get broken wasn't installed on the end users machine... so theoretically if you had some way of sending a patch to an end user which corrected the problem at hand it would be good... so what if every time wine crashed it popped up a window and if the user wished it it would send it's very verbose out put to some kind of a bug reporting system (repository)... and in return search the repository for a patch for this particular problem... (using the verbose output).... there is a chance that the patch might break something else but in that case there is a chance that it might find another patch to fix the whole situation... they have a system like this under M$ Win and netscape except that they rely on periodic updates to take care of the problem... but who is to say that every computer is built the Same and has the Same sofware so that the Same super patch will fix every one's computer... Note 1... If M$ screws anyone on rights to this idea they can claim next logical step kind of like one step shopping... Note 2... Basically the only two weakness of the system would be One the inablility to match the output with a patch... but with a decent database program should that be problem? and Two having enough programers to right mini patches..... I'm writing from memory but I think there are 300 developers.... wouldn't that be enough..... just a thought though so take it with a grain of salt... p.s. what brought this to mind back when I was following the wine project much more closely, 2-3 years ago, when it was almost the only way to run windows programs under linux, I'd heard that many of the problems could be fixed by just a tweak here or there and mabey a few lines of code changed... still don't know much C so I doubt I'll be much help as a developer if you want to get back with me over this : ) ICQ# 135184436 turtleislow

1 0

Re: x11ddraw fix
by Glenn Schrader 28 Nov '01

28 Nov '01

Ove Kaaven wrote: > On Mon, 12 Nov 2001, geschrader wrote: > > Your reasoning makes sense but with your patch I get the following error: > > > > X Error of failed request: XF86DGADirectNotActivated > > Major opcode of failed request: 138 (XFree86-DGA) > > Minor opcode of failed request: 26 (XDGACreateColormap) > > Serial number of failed request: 3691 > > Current serial number in output stream: 3951 > > > > I'm not sure how to interpret this. Documentation for DGA seems to be > > pretty non-existant. Is this complaining that the CreateColormap failed > > because DGA wasn't activated or that DGA wasn't activated because > > of the colormap failure? > It's probably the former. I'm guessing that you need to create the > colormap on the same display that XDGAOpenFrameBuffer and XDGASetMode was > done on (those are currently done on thread_display(), you'll probably > have to change them too, then?) The two attached patches seem to do the job. Thanks for the hints. --- Glenn Schrader ------------------------------------------------------------------------ Index: dga2.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/dga2.c,v retrieving revision 1.5 diff -u -r1.5 dga2.c --- dga2.c 2001/09/11 00:32:33 1.5 +++ dga2.c 2001/11/20 22:13:32 @@ -102,7 +102,7 @@ { LPDDRAWI_DIRECTDRAW_LCL ddlocal = data->lpDD->lpExclusiveOwner; DWORD vram; - Display *display = thread_display(); + Display *display = gdi_display; data->ddRVal = DD_OK; if (data->dwModeIndex) { @@ -174,7 +174,7 @@ static DWORD PASCAL X11DRV_XF86DGA2_CreatePalette(LPDDHAL_CREATEPALETTEDATA data) { - Display *display = thread_display(); + Display *display = gdi_display; data->lpDDPalette->u1.dwReserved1 = TSXDGACreateColormap(display, DefaultScreen(display), dga_dev, AllocAll); if (data->lpColorTable) X11DRV_DDHAL_SetPalEntries(data->lpDDPalette->u1.dwReserved1, 0, 256, @@ -185,7 +185,7 @@ static DWORD PASCAL X11DRV_XF86DGA2_Flip(LPDDHAL_FLIPDATA data) { - Display *display = thread_display(); + Display *display = gdi_display; if (data->lpSurfCurr == X11DRV_DD_Primary) { DWORD ofs = data->lpSurfCurr->lpGbl->fpVidMem - dga_mem.fpStart; TSXDGASetViewport(display, DefaultScreen(display), @@ -199,7 +199,7 @@ static DWORD PASCAL X11DRV_XF86DGA2_SetPalette(LPDDHAL_SETPALETTEDATA data) { - Display *display = thread_display(); + Display *display = gdi_display; if ((data->lpDDSurface == X11DRV_DD_Primary) && data->lpDDPalette && data->lpDDPalette->u1.dwReserved1) { TSXDGAInstallColormap(display, DefaultScreen(display), data->lpDDPalette->u1.dwReserved1); Index: x11ddraw.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/x11ddraw.c,v retrieving revision 1.12 diff -u -r1.12 x11ddraw.c --- x11ddraw.c 2001/08/27 19:04:18 1.12 +++ x11ddraw.c 2001/11/20 22:13:42 @@ -49,7 +49,7 @@ static LRESULT WINAPI GrabWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) { - Display *display = thread_display(); + Display *display = gdi_display; if(message != X11DRV_DD_GrabMessage) return CallWindowProcA(X11DRV_DD_GrabOldProcedure, hWnd, message, wParam, lParam); @@ -81,7 +81,7 @@ if(grab) { Window window = X11DRV_get_whole_window(GetFocus()); if(window) - XSetInputFocus(thread_display(), window, RevertToParent, CurrentTime); + XSetInputFocus(gdi_display, window, RevertToParent, CurrentTime); } if(!X11DRV_DD_GrabMessage)

2 4

Re: PATCH: xterm support for wineconsole
by eric pouech 28 Nov '01

28 Nov '01

Marcus Meissner wrote: > > Hi, > > This patch adds a XTERM backend to wineconsole. > > Some problems: > - In full screen text applications (like IDA), the cursor shows sometimes > up in the wrong spot. > - Scrolling does not work yet (so winedbg doesn't really work). > - Uses config.h. I still have some questions... from a technical point of view, what didn't you use an ncurse (for example) lib to handle the TERM issues ? the old code you grabbed doesn't work correctly for all TERM configurations... rewriting everythind isn't the solution IMO from a more usage point of view, it seemed that TERM support for wineconsole was more intended for supporting an existing UNIX console (like when starting a command line tool and use the current TERM for interacting with it), which would mean in wineconsole case passing to wineconsole the handles of current TERM. furthermore, how to you plan to choose, when starting wineconsole, from the Win32 and the xterm backend ? in other words, I'm more in favor of : - Win32 backend for normal usage - reusing current UNIX console when run in TERM mode (and not xterm), and with the support of text mode lib (like ncurses) A+

2 2

(no subject)
by Ryan C. Stallings 28 Nov '01

28 Nov '01

Hello all, I am new to the wine scene and would like to try my hand at a little wine hacking. Are there any bugs out there that would be easy for a newbie to fix while letting me learn a bit about the inner workings of wine? I have read all the material about getting started developing, but I am just lacking a bit of direction on what to work on :) Thanks for your help, ryan

4 3

fix triggers crash
by Michael Stefaniuc 28 Nov '01

28 Nov '01

Hello! I found a bug in ImageList_Merge (the count of the images in the imagelist wasn't set) and the trivial fix Index: imagelist.c =================================================================== RCS file: /home/wine/wine/dlls/comctl32/imagelist.c,v retrieving revision 1.43 diff -u -r1.43 imagelist.c --- imagelist.c 2001/09/10 23:09:04 1.43 +++ imagelist.c 2001/11/26 22:37:31 @@ -1918,6 +1918,7 @@ DeleteDC (hdcSrcImage); DeleteDC (hdcDstImage); + himlDst->cCurImage = 1; } return himlDst; =================================================================== triggers with FreeSolitaire (got it from tucows.com) following error (with crash): X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 53 (X_CreatePixmap) Serial number of failed request: 19761 Current serial number in output stream: 19852 This happens with the cvs code from today and I'm pretty shure that it worked perfectly with the cvs code from two days before. And without the patch above the error dosn't get triggered. This seems strange because the error seems to occur in x11drv.StretchBlt and ImageList_Merge dosn't call StretchBlt. To reproduce the crash start FreeSolitaire with the patch above applied, select a solitaire game and start dragging a card around and wine will crash. With --debugmsg +relay it takes sometimes longer to trigger the bug, just release the card I try dragging an other card (i never needed to release the second card yet, wine crashed before). I've attached the last 1000 lines of relay output, hope that helps. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.de Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 1

Re: Another pack4 issue (fwd)
by Francois Gouget 27 Nov '01

27 Nov '01

On Thu, 22 Nov 2001, Dmitry Timoshkov wrote: > "Francois Gouget" <fgouget(a)free.fr> wrote: > > > After the recent patch sent by Dmitry Timoshkov I checked for other > > similar issues. AFAICS, at this time there is only one place where a > > pack4 is really necessary. > > Well, I don't know why you are so sure. My testing revealed the following > differences in structure sizes between Wine and Windows: Well, I had just performed a search on 'pshpck4.h' and checked that against Wine's headers to see whether there would be a difference. Your method seems much more thorough. I am a bit surprised that we have so many differences. We should see tons of crashes... (maybe that's good news) [...] > What is really fun, that usage of FILETIME instead of LARGE_INTEGER leads > to differences in size of structures. That's very strange. It would be good to understand why because this should not happen. diff -u cvs/hq/wine/dlls/advapi32/registry.c wine/dlls/advapi32/registry.c --- cvs/hq/wine/dlls/advapi32/registry.c Mon Jul 23 22:19:41 2001 +++ wine/dlls/advapi32/registry.c Thu Nov 22 17:52:05 2001 @@ -287,7 +287,7 @@ DWORD len = info->NameLength / sizeof(WCHAR); DWORD cls_len = info->ClassLength / sizeof(WCHAR); - if (ft) *ft = info->LastWriteTime; + if (ft) *ft = *(FILETIME *)&info->LastWriteTime; This cast should not be necessary. Both sides are FILETIMEs. --- cvs/hq/wine/dlls/ntdll/reg.c Thu Nov 8 16:15:30 2001 +++ wine/dlls/ntdll/reg.c Thu Nov 22 17:45:36 2001 @@ -161,9 +161,9 @@ WCHAR *class_ptr = (WCHAR *)((char *)name_ptr + name_size); int class_size = server_data_size(req) - sizeof(WCHAR) - name_size; int fixed_size; - FILETIME modif; + LARGE_INTEGER modif; - RtlSecondsSince1970ToTime( req->modif, &modif ); + RtlSecondsSince1970ToTime( req->modif, (FILETIME *)&modif ); Here I don't understant why you changed modif to a LARGE_INTEGER since RtlSecondsSince1970ToTime takes a FILETIME* switch(info_class) { diff -u cvs/hq/wine/include/commctrl.h wine/include/commctrl.h --- cvs/hq/wine/include/commctrl.h Wed Aug 8 17:37:12 2001 +++ wine/include/commctrl.h Thu Nov 22 16:50:13 2001 @@ -744,6 +744,8 @@ LPARAM lParam; INT iImage; INT iOrder; + UINT type; + LPVOID pvFilter; } HDITEMA, *LPHDITEMA; I don't see these two fields on Windows. Same thing for the W version. That's with the VC 6 headers. @@ -2959,9 +2958,11 @@ typedef struct { DWORD cb; - BYTE DeviceName[32]; - BYTE DeviceString[128]; + CHAR DeviceName[32]; + CHAR DeviceString[128]; DWORD StateFlags; + CHAR DeviceID[128]; + CHAR DeviceKey[128]; } DISPLAY_DEVICEA,*PDISPLAY_DEVICEA,*LPDISPLAY_DEVICEA; Hmm, no. It is 'BYTE' on Windows. And I don't see the two extra fields either. diff -u cvs/hq/wine/include/winnt.h wine/include/winnt.h --- cvs/hq/wine/include/winnt.h Mon Aug 13 00:51:56 2001 +++ wine/include/winnt.h Thu Nov 22 18:00:57 2001 @@ -396,8 +396,6 @@ typedef a *P##a, *LP##a #endif /*STRICT*/ - -#include "pshpack1.h" /* Defines */ /* Argument 1 passed to the DllEntryProc. */ @@ -576,6 +574,8 @@ DWORD Cr0NpxState; } FLOATING_SAVE_AREA, *PFLOATING_SAVE_AREA; +#define MAXIMUM_SUPPORTED_EXTENSION 512 + typedef struct _CONTEXT86 { DWORD ContextFlags; @@ -612,6 +612,8 @@ DWORD EFlags; DWORD Esp; DWORD SegSs; + + BYTE ExtendedRegisters[MAXIMUM_SUPPORTED_EXTENSION]; } CONTEXT86; I don't have this field in CONTEXT86, but it is there in CONTEXT. It seems that it's our definition of CONTEXT which is wrong: typedef CONTEXT86 CONTEXT; @@ -2923,11 +2923,15 @@ WORD Reserved; } IMAGE_BOUND_FORWARDER_REF, *PIMAGE_BOUND_FORWARDER_REF; +#include "pshpack2.h" + typedef struct _IMAGE_BASE_RELOCATION { DWORD VirtualAddress; DWORD SizeOfBlock; +#ifdef __WINE__ WORD TypeOffset[1]; +#endif } IMAGE_BASE_RELOCATION,*PIMAGE_BASE_RELOCATION; Do we handle this correctly in the code? I.e. is there APIs where the application gives us a pointer to a struct without the field and we write to it? I wonder how this is supposed to work. +#include "pshpack4.h" typedef struct _LUID_AND_ATTRIBUTES { LUID Luid; DWORD Attributes; } LUID_AND_ATTRIBUTES; +#include "poppack.h" Is this really necessary? LUID is 8 bytes so the DWORD should be aligned just fine with or without the pack4... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.

3 4

SetActiveWindow problem
by bperkins＠netspace.org 27 Nov '01

27 Nov '01

Sorry, I'm new to wine hacking, so bear with me. I was playing around a bit the other day trying to see if the tahni deskmate worked at all. I tried to run the installer (tahnisetup.exe available at tahni.com). It would run, and then crash with a stack overflow. I've attached the sequence in a backtrace that was repeated many times at the bottom. It's wine-20011108, BTW. Since I don't have the source to tahnisetup it made things a bit tricky to decipher. My guess was(is) that the program is trying to the window as active, which sends a message to the program. It sees that it's not active, so it again tries to set it as be active, which eventually causes a stack overflow. My awful hack was to just put a sanity counter in SetActiveWindow and return true after being called a certain number of times. This seems to work, as in it causes to program to get farther (it gets stuck on something else). Presumably one could check if it was being called recursively. I realize that this isn't really useful info, but I was curious to see if I was right about this, or if anyone had an insight. Am I right or did I just get lucky with the hack? 25246 0x0040266f (tahnisetup.exe..text+0x166f in E:\tahnisetup.exe) (ebp=437e6444) 25247 0x407c3a67 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=437e6468) 25248 0x407c3af2 (WINPROC_CallWndProc+0x82(proc=0x4025b8, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:173] in libuser32.so) (ebp=437e6498) 25249 0x407c95ca (CallWindowProcA+0x4a(func=0x4025b8, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:2623] in libuser32.so) (ebp=437e64cc) 25250 0x4097b54c (FILEDLG_CallWindowProc+0x54(lfs=0x40400dbc, wMsg=0x6, wParam=0x0, lParam=0x10026) [filedlg.c:294] in libcomdlg32.so) (ebp=437e64f4) 25251 0x4097d944 (FileOpenDlgProc+0x78(hWnd=0x1002f, wMsg=0x6, wParam=0x0, lParam=0x10026) [filedlg.c:1440] in libcomdlg32.so) (ebp=437e651c) 25252 0x407c3a67 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=437e6540) 25253 0x407c3af2 (WINPROC_CallWndProc+0x82(proc=0x4097d8cc, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:173] in libuser32.so) (ebp=437e6570) 25254 0x407c91f4 (WINPROC_CallProc32WTo32A+0x80(func=0x4097d8cc, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:2435] in libuser32.so) (ebp=437e6598) 25255 0x407c972b (CallWindowProcW+0xab(func=0x430c0984, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:2675] in libuser32.so) (ebp=437e65cc) 25256 0x4079f744 (DefDlgProcW+0x48(hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [defdlg.c:389] in libuser32.so) (ebp=437e65f8) 25257 0x407c3a67 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=437e661c) 25258 0x407c3af2 (WINPROC_CallWndProc+0x82(proc=0x4079f6fc, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:173] in libuser32.so) (ebp=437e664c) 25259 0x407c9152 (WINPROC_CallProc32ATo32W+0x7e(func=0x4079f6fc, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:2412] in libuser32.so) (ebp=437e6674) 25260 0x407c9647 (CallWindowProcA+0xc7(func=0x430c0259, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:2643] in libuser32.so) (ebp=437e66a8) 25261 0x4076957e (call_window_proc+0xf2(hwnd=0x1002f, msg=0x6, wparam=0x0, lparam=0x10026, unicode=0x0) [message.c:1146] in libuser32.so) (ebp=437e6704) 25262 0x4076a1af (SendMessageTimeoutA+0xdf(hwnd=0x1002f, msg=0x6, wparam=0x0, lparam=0x10026, flags=0x0, timeout=0xffffffff, res_ptr=0x437e6788) [message.c:1577] in libuser32.so) (ebp=437e6764) 25263 0x4076a317 (SendMessageA+0x37(hwnd=0x1002f, msg=0x6, wparam=0x0, lparam=0x10026) [message.c:1622] in libuser32.so) (ebp=437e6798) 25264 0x407c2e92 (WINPOS_SetActiveWindow+0x196(hWnd=0x10026, fMouse=0x0, fChangeFocus=0x1) [winpos.c:1282] in libuser32.so) (ebp=437e67f0) 25265 0x407c229a (SetForegroundWindow+0x7a(hwnd=0x10026) [winpos.c:781] in libuser32.so) (ebp=437e680c) -- "Only CmdrTaco can save us now" -- The Register Brian Perkins bperkins(a)netspace.org

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel