February 2007 - Wine-devel - list.winehq.org

What does it mean if doing WINEDEBUG=+relay fixes a bug?
by Misha Koshelev 19 Feb '07

19 Feb '07

Hi, I am trying to debug bug #7484 but am having some problems as simply doing a WINEDEBUG=+relay causes this bug to be fixed, thus making it difficult for me to track it down (WINEDEBUG=+listview or WINEDEBUG= +snoop do not have this effect of fixing it). If there is something that the fact that this bug is fixed by +relay suggests, I would love to know. Thanks a lot Misha

2 1

Re: [wineconsole][dialog] Fix inversion in work Up-down control (Option Dialog)
by Dmitry Timoshkov 19 Feb '07

19 Feb '07

"Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: > struct dialog_info* di; > unsigned idc; > + unsigned nMaxHistUD = 500; > > switch (msg) > { > @@ -66,6 +67,8 @@ static INT_PTR WINAPI WCUSER_OptionDlgPr > di = (struct dialog_info*)((PROPSHEETPAGEA*)lParam)->lParam; > di->hDlg = hDlg; > SetWindowLongPtr(hDlg, DWLP_USER, (LONG_PTR)di); > + > + SendMessage(GetDlgItem(hDlg,IDC_OPT_HIST_SIZE_UD), UDM_SETRANGE, (WPARAM) 0, MAKELONG (nMaxHistUD, 0)); There is no need for (WPARAM) cast. Better use MAKELPARAM to construct an lParam instead of MAKELONG. Simple MAKELPARAM(500, 0) works just fine without introducing a new variable. -- Dmitry.

1 0

Re: [start][start] Output with console encoding
by Dmitry Timoshkov 19 Feb '07

19 Feb '07

"Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: > @@ -33,7 +33,20 @@ > static void output(const char *message) > { > DWORD count; > - WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), message, strlen(message), &count, NULL); > + WCHAR *bufW; > + char *bufC; > + int len = strlen(message); > + bufW = calloc(len+1,sizeof(WCHAR)); > + bufC = calloc(len+1,sizeof(CHAR)); Please do not use calloc/malloc calls in the Wine code, use win32 API HeapAlloc instead. > + MultiByteToWideChar( CP_ACP, 0, message, len, bufW, len ); > + WideCharToMultiByte( GetConsoleOutputCP(), 0, bufW, len, bufC, len, NULL, NULL ); > + bufC[len] = '\0'; Please refer to other parts of Wine code how to properly allocate space for this kind of a conversion. -- Dmitry.

1 0

Re: Make wineprefixcreate put wordpad.exe where XP does; fixes bug 5627
by Dan Kegel 19 Feb '07

19 Feb '07

[reposting to right list. Maybe I should break down and subscribe to wine-devel so I can just hit 'reply'...] Detlef wrote: >The Idea sounds good, but your Patch is wrong for every >system in the World, that does not use English as locale: Oh, right. Well, at least I'm enthusiastic, if not wise :-) I guess the way to fix this right would be to create IDS_PROGRAM_FILES_ACCESSORIES analogous to IDS_PROGRAM_FILES; that would let us localize the path in shell32.dll, and setupapi.dll could handle it just like it does IDS_PROGRAM_FILES already (it translates the %16422% into the localized Program Files directory name). Then maybe get rid of the need to create the directores in wineprefixcreate by modifying create_fake_dll in setupapi/fakedll.c to create the directories if they don't exist. Lotta trouble to go through just to support broken-ish apps that need to know where wordpad is, but maybe I'll see about doing it if nobody else fixes this.

1 0

-ansi, -pedantic warnings and errors on
by Joris Huizer 19 Feb '07

19 Feb '07

Hello, I was looking at the result of configuring with -ansi, -pedantic flags. It gives loads of warnings (not all relevant - also complaining about 'long long' not being ansi) and indicates unnamed unions, among other things. Could someone confirm my idea that unnamed unions must all be dealt with? Am hoping to fix those if I get it to compile thus far; At this point, it complains about include/wine/unicode.h which has the combination 'extern' and 'inline', which it doesn't like. Getting rid of that, with -Dinline=__inline__, helps it get a bit further Next it complains about is libs/wine/string.c, which implements several functions that are also implemented in include/wine/unicode.h. These are again the 'extern inline' functions. As most headers have 'static inline' instead of 'extern inline', with the advantage of not having to duplicate the functions. I'm hoping this is an allowed fix, it gets compiling further anyway ____________________________________________________________________________________ Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097

3 4

Mouse not warping properly in full screen mode
by Raf Geens 18 Feb '07

18 Feb '07

Hi, I'm new to Wine and DirectX development, but I've dug around a bit in the Wine source code to get Determinance, a sword-fighting game to work. I've submitted an entry for it to the application database. The main problem I had was with strange mouse behaviour in full screen mode. The player can rotate his character by holding down the right mouse button and moving the mouse. In Windows, this allows you to turn as much as you want. In Wine, the rotation stops at a certain point. You can't see the cursor, but I'm fairly certain the point at which movement stops is when the cursor hits the edge of the screen. When this has happened and you return to the main menu, it can occur that for example the cursor can't reach the top part of the screen anymore. It's as if an invisible rectangle that keeps the cursor inside the screen has moved. In such a case, moving the cursor all the way to the bottom and back up again restores normal behaviour. I've isolated the problem to the following line in dlls/dinput/mouse.c : This->need_warp = (pt.x || pt.y) && dwCoop & DISCL_EXCLUSIVE; Changing it to This->need_warp = TRUE; as a quick test makes the mouse behave correctly. I've read about the mouse warping hack over here: http://www.kernel-traffic.com/wine/wn20040618_227.html#2 . Inserting a TRACE statement displaying the variables in that line of code revealed that: - it is only executed in full screen mode, and not in windowed mode - dwCoop is DISCL_NOWINKEY , causing the expression to evaluate to false. So it seems the DISCL_EXCLUSIVE constraint is too restrictive. Reading about the meanings of the dwCoop values at msdn ( http://tinyurl.com/2lmgbw ), I'm guessing the Determinance developers might not have entirely been following the rules. However, it works properly on Windows. Would it be acceptable to drop the DISCL_EXCLUSIVE constraint? Raf Geens

3 2

Lost KOI8-U.
by Anatoly Lyutin 18 Feb '07

18 Feb '07

2 1

Re: resend : gdi32:WidenPath partial implementation
by James Hawkins 18 Feb '07

18 Feb '07

On 2/18/07, Laurent Vromman <laurent(a)vromman.org> wrote: > Changelog : > - Add a partial implementation for the function gd32:WidenPath > > It is the second time I send this patch. It seems it was forgotten the > previous time. I am sorry for that. > > > If this patch needs to be improved, please let me know, I'll try to do it. > > Laurent Vromman > > > > > diff --git a/dlls/gdi32/path.c b/dlls/gdi32/path.c > index 306ed37..d9ccbb3 100644 > --- a/dlls/gdi32/path.c > +++ b/dlls/gdi32/path.c > @@ -1823,6 +1823,14 @@ BOOL WINAPI StrokePath(HDC hdc) > /******************************************************************* > * WidenPath [GDI32.@] > * > + * Redefines the current path as the area that would be painted if the path were stroked using the pen currently selected into the given device context. > + * > + * PARAMS > + * hdc [I] Handle to a device context that contains a closed path. > + * > + * RETURNS > + * Success: TRUE. The path is updated with the new computed path. > + * Failure: FALSE. > * You copied this documentation word-for-word from msdn, which is not allowed. -- James Hawkins

1 0

generic.ppd does not appear in the build dir - cannot print
by Michael [Plouj] Ploujnikov 18 Feb '07

18 Feb '07

With a recent update to Wine 0.9.31, my printing issue [1] has changed in some way that actually generated some meaningful error messages being printed. I don't know if this is indeed the same issue or not. However, here are the messages that I started getting: $ wine notepad Couldn't find PPD file '/home/plouj/apps/build_dir/dlls/wineps.drv/generic.ppd', expect a crash now! err:commdlg:PRINTDLG_ChangePrinterW DocumentProperties fails on L"our old printer" Couldn't find PPD file '/home/plouj/apps/build_dir/dlls/wineps.drv/generic.ppd', expect a crash now! err:commdlg:PRINTDLG_ChangePrinterW DocumentProperties fails on L"our old printer" fixme:commdlg:PRINTDLG_UpdatePrintDlgW No lpdm ptr? fixme:commdlg:PRINTDLG_WMCommandW Update printdlg was not successful! fixme:commdlg:PRINTDLG_UpdatePrintDlgW No lpdm ptr? fixme:commdlg:PRINTDLG_WMCommandW Update printdlg was not successful! fixme:commdlg:PRINTDLG_UpdatePrintDlgW No lpdm ptr? fixme:commdlg:PRINTDLG_WMCommandW Update printdlg was not successful! fixme:commdlg:PRINTDLG_UpdatePrintDlgW No lpdm ptr? fixme:commdlg:PRINTDLG_WMCommandW Update printdlg was not successful! Couldn't find PPD file '/home/plouj/apps/build_dir/dlls/wineps.drv/generic.ppd', expect a crash now! err:commdlg:PRINTDLG_ChangePrinterW DocumentProperties fails on L"our old printer" fixme:commdlg:PRINTDLG_UpdatePrintDlgW No lpdm ptr? fixme:commdlg:PRINTDLG_WMCommandW Update printdlg was not successful! Note: my Wine source is checked out from git into ~/apps/wine-git . However, I execute ./configure && make inside ~/apps/build_dir to separate the source from the build files. I also run Wine by executing ~/apps/build_dir/wine . After some playing around I realized that generic.pdd resides in my Wine source checkout directory: $ file ~/apps/wine-git/dlls/wineps.drv/generic.ppd /home/plouj/apps/wine-git/dlls/wineps.drv/generic.ppd: PPD file, ve but not inside the build directory: ls ~/apps/build_dir/dlls/wineps.drv/*.ppd ls: cannot access /home/plouj/apps/build_dir/dlls/wineps.drv/*.ppd: No such file or directory After simply copying generic.pdd to my build directory I was able to print without (absolutely any) errors or warning messages. After finding a quick solution I'm wondering what, a person like me, who builds (and runs) wine in a directory parallel to the source, should do in this case? Should I just live with this hack-ish copying of the .ppd file? Is my usage case not 'popular' enough to warrant a fix? Is this how Autotools is supposed to be used to install generic.ppd? Why didn't the older versions of Wine [2] have this issue? The Makefile doesn't look promising to me: install install-lib:: $(DESTDIR)$(datadir)/wine $(INSTALL_DATA) $(SRCDIR)/generic.ppd $(DESTDIR)$(datadir)/wine/generic.ppd The way I understand this is that generic.ppd is meant to reside in the source directory and the install directory only. This probably means that Autotools won't put it in the build directory. References [1] - http://www.winehq.org/pipermail/wine-devel/2007-January/053606.html [2] - As you can see I've been successfully printing with a non-free application running under Wine since around 0.9.9: http://appdb.winehq.org/appview.php?iVersionId=4498 -- Libre Software: http://www.gnu.org/philosophy/free-sw.html

2 1

RE: [start][start] Output with console encoding
by Vitaliy Margolen 18 Feb '07

18 Feb '07

> Changelog: > Fix output console to output with console encoding. > static void output(const char *message) > Index: programs/start/start.c > =================================================================== > RCS file: /home/wine/wine/programs/start/start.c,v > retrieving revision 1.5 > diff -u -p -u -r1.5 start.c > --- programs/start/start.c 23 May 2006 12:49:22 -0000 1.5 > +++ programs/start/start.c 30 Jan 2007 09:47:52 -0000 > @@ -33,7 +33,20 @@ > { > DWORD count; > - WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), message, strlen(message), &count, NULL); > + WCHAR *bufW; > + char *bufC; > + int len = strlen(message); > + bufW = calloc(len+1,sizeof(WCHAR)); > + bufC = calloc(len+1,sizeof(CHAR)); > + > + MultiByteToWideChar( CP_ACP, 0, message, len, bufW, len ); > + WideCharToMultiByte( GetConsoleOutputCP(), 0, bufW, len, bufC, len, NULL, NULL ); > + bufC[len] = '\0'; > + > + WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), bufC, len, &count, NULL); > + > + free(bufW); > + free(bufC); > } This is not correct. This function and everything else, using it should be rewritten as unicode, not ansi. Also you should use HeapAlloc/HeapFree. Vitaliy.

1 0