February 2008 - Wine-Devel - list.winehq.org

cabinet: Include wine/port.h for strcasecmp().

by Kirill K. Smirnov

>The rules are as follows: > * For case insensitive comparisons of 'windows strings', a Windows > function must be used (stricmp() or similar). and >In this case, KERNEL32 lstrcmpiA() would be more appropriate. In >general, using stricmp() in Win32 code should be discouraged since it >may cause unnecessary dependency on MSVCRT. Wine lstrcmpi is broken (bug #10767). There are cases GLIBC strcasecmp and Windows lstrcmpi handle correctly but wine not. Should we fix this first? -- Kirill

Feb. 3, 2008

Re: Resend patch from Norbert

by Vitaliy Margolen

Rico Schüller wrote: > Hi, > > I only resend a patch because it isn't in the todays git and the author > didn't answer for a while. > > Cheers > Rico > > > ------------------------------------------------------------------------ > > > - memcpy(pRect, &This->updateStateBlock->scissorRect, sizeof(pRect)); > + memcpy(pRect, &This->updateStateBlock->scissorRect, sizeof(RECT)); To avoid such problems in the future one should use something like: *pRect = This->updateStateBlock->scissorRect; Doing a quick search through wined3d I've found number of places with memcpy instead of simple assignment of one struct to another struct. This is a good janitorial task to get rid of memcpy where simple assignment will work. Vitaliy.

Feb. 2, 2008

Re: winex11.drv: Use bitwise NOT not logical NOT

by Andrew Talbot

Vitaliy Margolen wrote: > Marcus Meissner wrote: >> On Sat, Feb 02, 2008 at 05:43:27PM +0000, Andrew Talbot wrote: > Correct. What all that meant, is if app asks for something, but the value > is > 0, switch to default mode. > Yes. I wrongly mistook it to be a case of setting one group of flags in accordance with another. I should have looked more carefully. > Also Andrew, have you actually ran tests to check of they still pass? Of > course you need to run them in interactive mode: > export WINETEST_INTERACTIVE=1 > No, I'm guilty again. Thanks for the advice. -- Andy.

Feb. 2, 2008

Re: winex11.drv: Use bitwise NOT not logical NOT

by Andrew Talbot

Marcus Meissner wrote: > I do not think this is right, def_mode is a boolean and we actually check > for not-0-being of various struct members. > > Ciao, Marcus Hi Marcus, You are correct. I should have studied the code more carefully. Thanks, -- Andy.

Feb. 2, 2008

Re: winex11.drv: Use bitwise NOT not logical NOT

by Vitaliy Margolen

Marcus Meissner wrote: > On Sat, Feb 02, 2008 at 05:43:27PM +0000, Andrew Talbot wrote: >> Changelog: >> winex11.drv: Use bitwise NOT not logical NOT. >> >> diff --git a/dlls/winex11.drv/settings.c b/dlls/winex11.drv/settings.c >> index d68b674..2cd36c7 100644 >> --- a/dlls/winex11.drv/settings.c >> +++ b/dlls/winex11.drv/settings.c >> @@ -369,10 +369,10 @@ LONG X11DRV_ChangeDisplaySettingsEx( LPCWSTR devname, LPDEVMODEW devmode, >> devmode->dmBitsPerPel,devmode->dmDisplayFrequency, handler_name); >> >> dwBpp = devmode->dmBitsPerPel; >> - if (devmode->dmFields & DM_BITSPERPEL) def_mode &= !dwBpp; >> - if (devmode->dmFields & DM_PELSWIDTH) def_mode &= !devmode->dmPelsWidth; >> - if (devmode->dmFields & DM_PELSHEIGHT) def_mode &= !devmode->dmPelsHeight; >> - if (devmode->dmFields & DM_DISPLAYFREQUENCY) def_mode &= !devmode->dmDisplayFrequency; >> + if (devmode->dmFields & DM_BITSPERPEL) def_mode &= ~dwBpp; >> + if (devmode->dmFields & DM_PELSWIDTH) def_mode &= ~devmode->dmPelsWidth; >> + if (devmode->dmFields & DM_PELSHEIGHT) def_mode &= ~devmode->dmPelsHeight; >> + if (devmode->dmFields & DM_DISPLAYFREQUENCY) def_mode &= ~devmode->dmDisplayFrequency; > > I do not think this is right, def_mode is a boolean and we actually check for > not-0-being of various struct members. > Correct. What all that meant, is if app asks for something, but the value is 0, switch to default mode. Also Andrew, have you actually ran tests to check of they still pass? Of course you need to run them in interactive mode: export WINETEST_INTERACTIVE=1 Vitaliy.

Feb. 2, 2008

Re: winex11.drv: Use bitwise NOT not logical NOT

by Marcus Meissner

On Sat, Feb 02, 2008 at 05:43:27PM +0000, Andrew Talbot wrote: > Changelog: > winex11.drv: Use bitwise NOT not logical NOT. > > diff --git a/dlls/winex11.drv/settings.c b/dlls/winex11.drv/settings.c > index d68b674..2cd36c7 100644 > --- a/dlls/winex11.drv/settings.c > +++ b/dlls/winex11.drv/settings.c > @@ -369,10 +369,10 @@ LONG X11DRV_ChangeDisplaySettingsEx( LPCWSTR devname, LPDEVMODEW devmode, > devmode->dmBitsPerPel,devmode->dmDisplayFrequency, handler_name); > > dwBpp = devmode->dmBitsPerPel; > - if (devmode->dmFields & DM_BITSPERPEL) def_mode &= !dwBpp; > - if (devmode->dmFields & DM_PELSWIDTH) def_mode &= !devmode->dmPelsWidth; > - if (devmode->dmFields & DM_PELSHEIGHT) def_mode &= !devmode->dmPelsHeight; > - if (devmode->dmFields & DM_DISPLAYFREQUENCY) def_mode &= !devmode->dmDisplayFrequency; > + if (devmode->dmFields & DM_BITSPERPEL) def_mode &= ~dwBpp; > + if (devmode->dmFields & DM_PELSWIDTH) def_mode &= ~devmode->dmPelsWidth; > + if (devmode->dmFields & DM_PELSHEIGHT) def_mode &= ~devmode->dmPelsHeight; > + if (devmode->dmFields & DM_DISPLAYFREQUENCY) def_mode &= ~devmode->dmDisplayFrequency; I do not think this is right, def_mode is a boolean and we actually check for not-0-being of various struct members. Ciao, Marcus

Feb. 2, 2008

Re: cabinet: Include wine/port.h for strcasecmp().

by Bang Jun-young

On 2/1/08, Francois Gouget <fgouget(a)free.fr> wrote: > The rules are as follows: > > * For case insensitive comparisons of 'windows strings', a Windows > function must be used (stricmp() or similar). In this case, KERNEL32 lstrcmpiA() would be more appropriate. In general, using stricmp() in Win32 code should be discouraged since it may cause unnecessary dependency on MSVCRT. BTW, isn't there any documentation for Wine hackers WRT this?

Feb. 1, 2008

Re: What's needed to make gdb work again?

by Eric Pouech

Maarten Lankhorst a écrit : > Hi folks, > > I've been trying some debugging with kdbg (Graphical kde debugger), but > it fails on wine because it can't attach to a process. > > While it is of course possible to use WINEDEBUG flags, I want to be able > to use a full debugger, and not just deduce from logs what happened, but > rather be able to see the corresponding lines of source as well. so > would it be possible to make gdb work with winedbg again, and perhaps > make it understand threads this time? > > Cheers, > Maarten. > > > > > ??? winedbg works winedbg --gdb works kdbg works as well (look at the tips on the wine doc about setting up kdbg with winedbg and the gdb proxy...). it however requires a patch for the proxy that i'm about to send for newer gdb versions A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

Feb. 1, 2008

Re: test.winehq.org

by Francois Gouget

On Thu, 31 Jan 2008, Reece Dunn wrote: [...] > Also, the security tests (the previous one) have two output lines, e.g.: > > security: 18 tests executed (0 marked as todo, 0 failures), 0 skipped. > security: 944 tests executed (0 marked as todo, 0 failures), 1 skipped. Yes, this typically happens when one does tests in a child process. This is wrong because it breaks 'make xxx.ok'. The reason is that the parent process does not know whether some tests failed in the child process or not, and thus it will return 0. Make will thus think that everything went well and so 'make xxx.ok' will succeed eventhough it should have failed. Alexandre relies on 'make test' to give him a reliable result so this may/will cause him not to notice new test failures introduced by a patch if they happen in a child process. In dlls/kernel32/tests/debugger.c I have code that passes data from the child process back to the parent so the tests can be done in the parent, specifically to avoid this problem. But maybe we should have a general mechanism to deal with this. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.

Feb. 1, 2008

Re: cabinet: Include wine/port.h for strcasecmp().

by Francois Gouget

"Bang Jun-young" <junyoung(a)mogua.com> wrote: >> > cabinet: Include wine/port.h for strcasecmp(). >> >> If a Wine DLL uses strcasecmp() then it's a bug. It should >> use an appropriate kernel32 API instead. > > I know, but it's too late. The tree is already contaminated with such > functions and quite a number of other unnecessary Wine-specific APIs > which shouldn't have been in the first place. The situation is not all that bad. I count only 158 references to strcasecmp(). So reviewing and fixing those that are wrong seems quite feasible and would make a good janitorial task. The rules are as follows: * For case insensitive comparisons of 'windows strings', a Windows function must be used (stricmp() or similar). * For case insensitive comparisons of 'Unix strings', that is of strings coming from the Unix world such as Unix filenames, then using strcasecmp() is fine. However, in the Unix world it's not very common to want to do case insensitive comparisons. * Comparing a 'windows string' with a unix one is out altogether (whether case insensitive or not) because they may not even be in the same encoding. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

Feb. 1, 2008

Re: Review comparing Wine and Vista for running games

by Jeff Latimer

Bang Jun-young wrote: > I think this kind of a silly game doesn't help Wine as much... > It may not be a help but like they say "there's not such thing as bad publicity". A lot more people hear of Wine is better than not hearing about it.

Feb. 1, 2008

Re: cabinet: Include wine/port.h for strcasecmp().

by Dmitry Timoshkov

"Bang Jun-young" <junyoung(a)mogua.com> wrote: >> > cabinet: Include wine/port.h for strcasecmp(). >> >> If a Wine DLL uses strcasecmp() then it's a bug. It should >> use an appropriate kernel32 API instead. > > I know, but it's too late. The tree is already contaminated with such > functions and quite a number of other unnecessary Wine-specific APIs > which shouldn't have been in the first place. It doesn't mean that instead of replacing them you can simply make an impression that it's OK to just hide the bug. -- Dmitry.

Feb. 1, 2008

Re: test.winehq.org

by Paul Vriens

Stefan Leichter wrote: > Hello, > > i just noticed that the test results for advapi32:service tests are not > available for the last build (http://test.winehq.org/data/200801301937/) It > looks like the parser did not create the files. > > Can someone familar with this stuff have a look? > > Thanks Stefan > > > I don't think it has something to do with the testsuite but rather with some oddity of the webserver/browser. When you click on the service test for http://test.winehq.org/data/200801301937/2003_fg-win2003es/advapi32:service… you get an empty page. When you however go to the directory http://test.winehq.org/data/200801301937/2003_fg-win2003es/ you will see that the file is there. But I can't download it though. When I now look at the test.winehq.org server itself: pvriens(a)wine:/home/winehq/opt/winetest/data/200801301937/2003_fg-win2003es$ more advapi32\:service.txt service.c:941: Test failed: expected error ERROR_INVALID_ADDRESS, got 122 service: 196 tests executed (0 marked as todo, 1 failure), 0 skipped. -- Cheers, Paul.

Feb. 1, 2008

Re: test.winehq.org

by Paul Vriens

Reece Dunn wrote: > On 31/01/2008, Stefan Leichter <Stefan.Leichter(a)camline.com> wrote: >> Hello, >> >> i just noticed that the test results for advapi32:service tests are not >> available for the last build (http://test.winehq.org/data/200801301937/) It >> looks like the parser did not create the files. >> >> Can someone familar with this stuff have a look? > > I noticed during the run on my Vista machine that the passed, failed, > todo line for one of the tests outputted to the console. I don't know > for which test it was though. > > Also, the security tests (the previous one) have two output lines, e.g.: > > security: 18 tests executed (0 marked as todo, 0 failures), 0 skipped. > security: 944 tests executed (0 marked as todo, 0 failures), 1 skipped. > > - Reece > > > Multiple lines of output like that is common and taken care of by the framework. AFAIK this usually happens when childprocesses/threads product output information like that. -- Cheers, Paul.

Feb. 1, 2008

Re: cabinet: Include wine/port.h for strcasecmp().

by Dmitry Timoshkov

"Bang Jun-young" <junyoung(a)mogua.com> wrote > cabinet: Include wine/port.h for strcasecmp(). If a Wine DLL uses strcasecmp() then it's a bug. It should use an appropriate kernel32 API instead. -- Dmitry.

Feb. 1, 2008

Re: Review comparing Wine and Vista for running games

by Bang Jun-young

To prove Wine is better than Vista: 1. Find a number of games that don't work with Vista but work fine with Wine. 2. Write a blog. 3. Everybody knows that Vista sucks. Now a Vista user gets upset with the results, so he will: 1. Find a ton of games and apps that don't work with Wine but work fine with Vista. 2. Write a blog. 3. Everybody knows that Wine sucks much more. I think this kind of a silly game doesn't help Wine as much... On 2/1/08, Dan Kegel <dank06(a)kegel.com> wrote: > http://wastingtimewithmikeandari.wordpress.com/2008/01/31/linux-has-better-… > > It'd be nice if we ran those games properly, but still, > at least we didn't lock the system. > > >

Feb. 1, 2008