March 2005 - Wine-Devel - list.winehq.org

Wine Debugger

by Cal Pierog

I am trying to write a script which, at one point, needs to run the wine test suite, accomplished with: make -k test Even though this skips over bad tests, it does not prevent the debugger from kicking in every once in a while and asking for user input. I would like this script to be robust enough to run the test suite without user input, even when one of the tests fails badly enough to call the debugger. So, is there any way to disable the debugger so that the script can just continue on errors and not sit at a "Wine-dbg>" prompt? Thanks, Cal Pierog

March 31, 2005

Re: KERNEL: Implement undocumented SetCPGlobal API call

by Troy Rollo

On Wed, 30 Mar 2005 14:10, Dmitry Timoshkov wrote: > "Troy Rollo" <wine(a)troy.rollo.name> wrote: > > > What app does depend on it? > > > > I can't name a specific app that depends on it already (other than > > Windows login management processes), > > I wonder then how did you discover its existence and syntax and how did you > test its real behaviour? It became apparent when looking through the documentation for other API calls that it must exist. I then checked the exports of KERNEL32.DLL and found it there, and traced into it to see what it did. I then checked the return value of GetACP() after calling SetCPGlobal(), and for good measure traced into GetACP() to see what *it* did. I have not tested all *A calls to verify that they all then use the new code page (although I have looked through the relevant parts of the code of some of them), but the fact that the new value is returned by GetACP() means that GetACP() would not be conforming to its documented behaviour if they did not use the new value. To this degree I have assumed a minimal level of competence at Microsoft, and while this is often a precarious assumption I don't see the need to assume the consequent in this case. But by all means if you want to test all the *A functions on Windows to see what happens, be my guest. > > but: > > > > - the call has some fairly obvious uses such that it is not out of the > > question for an app to use it; > > I'd say that an obvious one is SetThreadLocale. Perhaps not - The ACP value appears to be global to the process rather than the thread. The OEMCP (as returned by GetOEMCP) is not. > > - similar API calls to change the OEM code page are documented; > > What are they? Could you list that API calls? SetConsoleCP and SetConsoleOutputCP change the OEM code page used by the console attached to a process. There appears to be no call to change the value returned by GetOEMCP (this is set in KERNEL32.DLL's startup code), however an application that cares would be able to avoid the need for one by calling SetConsoleCP, SetConsoleOutputCP, and SetCPGlobal all with the new OEM code page, and avoiding any call to SetFileApisToOEM. > and this API has enough power to break an app without a notice. 1. Not if the app doesn't use it; and 2. If the app does use it, not unless the app is already broken. > Do you have an evidence that Windows does it in the same way? Other than from reading the disassembly and testing the APIs, no. That would be the "undocumented" part. > No. It's better to change the locale of your system to an appropriate one. That assumes every process is OK working with the same code page. This is not necessarily the case with a server application, which may well be serving clients in multiple regions in a multi-national environment. I know one major bank that has a presence in almost every country in the world that uses three central server farms - one in New York, one in Singapore, and I think the third was in London. A server process running on one of these systems may have to deal with clients using many different code pages, and if the program is written in C or C++ using the C or C++ libraries, then changing the ACP may turn out to be the only reasonable way to deal with this. It may not even be the case with a client application: you may have a software reseller who supports multiple regions and needs to be able to view data in a program that does not use Unicode when that data has come from a client in a region with a different code page; you may have somebody in a business whose native language is not the same as that of the locality they are in who prefers to use most applications in their native language, but needs to use some with the local code page to get access to business data. These are not problems solved by forcing people to make a choice of system code page. Bottom line, it's been exported by at least one Windows KERNEL32.DLL, which it seems to me makes it a reasonable candidate for implementation in WINE provided we know its behaviour, which we do.

March 31, 2005

Regression in comctl32 Treeview (breaks Filezilla, mIRC)

by Hannu Valtonen

Hannu Valtonen wrote: > Hi, > > The following patch: > > ChangeSet ID: 15259 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2005/01/07 09:34:25 > > Modified files: > dlls/comctl32 : treeview.c > Log message: > Crestez Leonard <cleonard(a)go.ro> > Fix bug with Treeview_SelectItem reselecting the same item. > > Patch: http://cvs.winehq.org/patch.py?id=15259 > > Old revision New revision Changes Path > 1.160 1.161 +0 -3 wine/dlls/comctl32/treeview.c > > Breaks Filezilla's (filezilla.sourceforge.net) add new site dialog. The > way to reproduce it is to go to the Site manager and click the "New > site" button. (Doesn't work even with latest CVS) > > Without the check which the patch removes, > > if (prevSelect == newSelect) > return FALSE; > > The dialog goes to an infinite loop. (you can exit it if you just hold > the ESC-key down for long enough) > > I have no idea whether the rationale Leonard provided with his patch is > correct, but it does break Filezilla. > > The binary file for Filezilla can be gotten from: > http://prdownloads.sourceforge.net/filezilla/FileZilla_2_2_10_setup.exe?dow… > > and the source file from: > http://prdownloads.sourceforge.net/filezilla/FileZilla_2_2_10_src.zip?downl… > > > I would appreciate it if some comctl32 messaging guru could step up and > take look at this problem Heh, my friend complained about his mIRC not working either. The same patch breaks mIRC as well. i.e. if you connect then as soon as you're about to join a channel the program freezes completely. Any comctl32 guru want to take a look? - Hannu Valtonen Hannu.Valtonen(a)hut.fi

March 30, 2005

Re: ScrollWindow fix for windows with WS_CLIPCHILDREN style, with tests - version 2

by Rein Klazes

On 29 Mar 2005 21:03:27 +0200, you wrote: > Rein Klazes <wijn(a)wanadoo.nl> writes: > > > windows : scroll.c > > dlls/user/tests : win.c > > > > If ScrollWindowEx is called with SW_SCROLLCHILDREN flags for a window > > with a WS_CLIPCHILDREN style, then do not use the DCX_USESTYLE flag > > option to get a DC for this window. With a couple of regression tests. > > DCX_USESTYLE has other effects, is it really correct to disable them > all? And if so, wouldn't it be better to never use DCX_USESTYLE? Close inspection today shows that you were correct to be concerned, my patch relies on a problem with GetDCEx(): it looks like the DCX_CLIPSIBLINGS flag is always active. You can see this by changing the GetDC( hwnd1) in test_scrollvalidate() to GetDCEx( hwnd1, 0, DCX_CACHE). Under Windows this makes all the tests depending on the WS_CLIPSIBLINGS fail, under Wine those tests still succeed. I cannot use DCX_USESTYLE because there appears not to be something like a DCX_NOCLIPCHILDREN flag. So here is the next attempt, using the meaning of DCX_USESTYLE except where I do not need it. Changelog: windows : scroll.c dlls/user/tests : win.c If ScrollWindowEx do not use the DCX_USESTYLE to get a DC. Instead calculate DCX_CLIPSIBLINGS, DCX_PARENTCLIP and DCX_CLIPCHILDREN. The DCX_CLIPCHILDREN is not used when ScrollWindowEx is called with a SW_SCROLLCHILDREN flag. With a couple of regression tests. Rein.

March 30, 2005

Re: Fwd: Wine install fails on Gentoo with `SYS_sigaction' undeclared

by Jonathan Duncan

On Sat, 26 Mar 2005, Phil Krylov wrote: > Hi, > >> I am using Gentoo with a linux kernel of 2.6.10 on a dual-Xeon 3.2ghz >> 64-bit system. > > I am using Gentoo with 2.6.10 on 32-bit Athlon XP and don't have this problem, > so I suppose it must be something with 64-bitness. > > -- Ph. > Makes sense. Thanks. Jonathan

March 30, 2005

Re: MSVCRT: implement _chsize

by Alexandre Julliard

Hans Leidekker <hans(a)it.vu.nl> writes: > int _chsize(int fd, long size) > { > - FIXME("(fd=%d, size=%ld): stub\n", fd, size); > - return -1; > + DWORD cur, pos; > + HANDLE handle; > + BOOL ret = FALSE; > + > + TRACE("(fd=%d, size=%ld)\n", fd, size); > + > + LOCK_FILES(); > + > + handle = msvcrt_fdtoh(fd); > + if (handle != INVALID_HANDLE_VALUE) > + { > + /* save the current file pointer */ > + cur = SetFilePointer(handle, 0, NULL, FILE_CURRENT); > + if (cur != INVALID_SET_FILE_POINTER) > + { > + pos = SetFilePointer(handle, size, NULL, FILE_BEGIN); > + if (pos != INVALID_SET_FILE_POINTER) > + ret = SetEndOfFile(handle); > + > + /* restore the file pointer */ > + pos = SetFilePointer(handle, cur, NULL, FILE_BEGIN); > + } > + } > + > + UNLOCK_FILES(); > + return ret ? 0 : -1; > } SetFilePointer can return INVALID_SET_FILE_POINTER on success if the current pointer is 0xffffffff, you have to check last error in that case. Also you need to set errno on failure. It may be easier to use _lseek instead of SetFilePointer as it takes care of all that already. -- Alexandre Julliard julliard(a)winehq.org

March 30, 2005

Re: advapi32: increase robustness for incorrect api usage

by Alexandre Julliard

Michael Jung <mjung(a)iss.tu-darmstadt.de> writes: > When a context is released, the corresponding heap based struct variable is > zero'ed before being released. When the CryptDestroyHash function is called, > the corresponding context is checked if it was already being zero'ed out. > Note that a heap location is read, which has already been released. However, > this only happens in case of incorrect api usage. This is not guaranteed to > work, but it should be more robust. > > I suspect that windows does it in a similar way. Looking at the actual values > of HCRYPTHASH variables shows that those are addresses in WinXP SP2. > Considering this, I think that the only 100% clean way to implement this > behaviour would be to have a list of currently existing hash and key objects > in the context, which then would be marked invalid when the context is > released. I don't think there's any need to go that far, and I doubt Windows does either. The usual way to handle that is to store a magic number in the struct and clear it on destroy; this is more robust than simply zeroing the pointer since even if the block gets reused it's very unlikely that the proper magic number would get restored. -- Alexandre Julliard julliard(a)winehq.org

March 30, 2005

Re: winetest: ask for a tag

by Robert Shearman

Ferenc Wagner wrote: >ChangeLog: Ask for a tag if one was not given on the command line. > >This patch depends on sizeof(int)==sizeof(char*) for >returning the buffer address from the dialog. If it should >be done differently, please tell me how. > > Use DialogBoxParam. Rob

March 30, 2005

Re: MSVCRT: implement _chsize

by Dmitry Timoshkov

"Hans Leidekker" <hans(a)it.vu.nl> wrote: > int _chsize(int fd, long size) > { > - FIXME("(fd=%d, size=%ld): stub\n", fd, size); > - return -1; > + DWORD cur, pos; > + HANDLE handle; > + BOOL ret = FALSE; > + > + TRACE("(fd=%d, size=%ld)\n", fd, size); > + > + LOCK_FILES(); > + > + handle = msvcrt_fdtoh(fd); > + if (handle == INVALID_HANDLE_VALUE) goto exit; > + > + /* save the current file pointer */ > + cur = SetFilePointer(handle, 0, NULL, FILE_CURRENT); > + if (cur == INVALID_SET_FILE_POINTER) goto exit; > + > + pos = SetFilePointer(handle, size, NULL, FILE_BEGIN); > + if (pos == INVALID_SET_FILE_POINTER) goto restore; > + > + ret = SetEndOfFile(handle); > + > +restore: > + /* restore the file pointer */ > + pos = SetFilePointer(handle, cur, NULL, FILE_BEGIN); > + > +exit: > + if (ret == FALSE) > + { UNLOCK_FILES(); return -1; } > + else > + { UNLOCK_FILES(); return 0; } > } This a pure coding style comment, just ignore it if you are not agree. In order to avoid goto's (absolutely not needed here IMO) and doubled UNLOCK_FILES(): LOCK_FILES(); handle = msvcrt_fdtoh(fd); if (handle != INVALID_HANDLE_VALUE) { /* save the current file pointer */ cur = SetFilePointer(handle, 0, NULL, FILE_CURRENT); if (cur != INVALID_SET_FILE_POINTER) { pos = SetFilePointer(handle, size, NULL, FILE_BEGIN); if (pos != INVALID_SET_FILE_POINTER) ret = SetEndOfFile(handle); /* restore the file pointer */ pos = SetFilePointer(handle, cur, NULL, FILE_BEGIN); } } UNLOCK_FILES(); return ret ? 0 : -1; -- Dmitry.

March 30, 2005

Re: Regression: origin6 crashes with 20050310 (20050211 works)

by Tobias Burnus

Hello, Tobias Burnus wrote: > I try to run a freshly installed Origin6.0 with 20050310, but it shows > only the splash window and crashes then. Using the previous release > 20050211 it runs just fine. I tracked it down to http://www.winehq.org/hypermail/wine-cvs/2005/02/0506.html Modified files: dlls/user : edit.c Log message: Lauri Tulmin <tulmin(a)gmail.com> Implemented !ES_AUTO[HV]SCROLL. http://cvs.winehq.org/patch.py?id=16323 With that patch, it shows quickly the border of the splash window and crashes then, without it does not crash. (Though there seem to be another bug, preventing it from running: It opens the main window and no more happens [100%]. I'll later try to find the patch causing that one.) Tobias

March 30, 2005