wine-devel September 2008

wine-devel@winehq.org

116 participants
274 discussions

Adding Flawfinder to Patchwatcher
by Austin English 09 Sep '08

09 Sep '08

I had a discussion with Dan about adding Flawfinder to the patchwatcher. Currently, it's got some pretty generic errors, but it seems able to test only patches, so we wouldn't be flooded with old nonbugs (or we could set up a blacklist of safe errors). For reference, I've run it on today's git. I'm attaching the full log, as well as a condensed version of the most common errors (1 per error type). Looks like a lot of chances for buffer overflows.. Thoughts? -Austin

15 19

Patchwatcher online
by Dan Kegel 09 Sep '08

09 Sep '08

OK, I've checked in the updated Patchwatcher source http://code.google.com/p/winezeug/source/detail?r=177 and have turned email notifications back on. I also told it to rerun the most recent 11 patches, just to test that it's sending the good patches to http://groups.google.com/group/wine-patches-filtered again. The results page http://kegel.com/wine/patchwatcher/results/ looks nice and green; the blacklist at http://winezeug.googlecode.com/svn/trunk/patchwatcher/blacklist.txt filters out all the tests that tend to fail on my test machine infrequently enough that they show up in the five baseline test runs, but frequently enough that they caused bogus failure reports in the few hundered patches I've processed. It would be *very good* to whittle that blacklist down to zero. I should update http://bugs.winehq.org/show_bug.cgi?id=9916 with a script that runs just the problematic tests over and over again. (Or maybe I should start a new bug, that one is pretty long.)

3 3

Re: ws2_32: ioctlsocket should try to check if argp is valid (try 2)
by Juan Lang 09 Sep '08

09 Sep '08

Hi Jeff, + if(sock == INVALID_SOCKET) + skip("Creating the socket failed: %d, skipping test.\n", WSAGetLastError()); skip needs a return too. + ret = ioctlsocket(sock, cmds[i], (u_long *)1); + if(ok(ret == SOCKET_ERROR, "ioctlsocket succeeded unexpectedly\n")) + { I think you mean: ok(ret == SOCKET_ERROR...) if (ret == SOCKET_ERROR) { } although really the if is unnecessary, as you won't cause a crash if the first test fails. --Juan

2 1

Re: ws2_32: ioctlsocket should try to check if argp is valid
by Juan Lang 09 Sep '08

09 Sep '08

Hi Jeff, I have a stylistic complaint about your tests in this patch: + if(sock == INVALID_SOCKET) + { + ok(0, "Creating the socket failed: %d, skipping test\n", WSAGetLastError()); + return; + } If you intend to skip a test, shouldn't you use skip instead? + ret = ioctlsocket(sock, cmds[i], (u_long *)1); + if(ret != SOCKET_ERROR) + ok(0, "ioctlsocket succeeded unexpectedly\n"); + else + { I'm not a fan of the ok(0) approach here. Why not use ok(ret == SOCKET_ERROR) instead? --Juan

2 1

Launching a Linux Executable from a Windows app Running under Wine
by Mike Engelhardt 09 Sep '08

09 Sep '08

I write a Windows application that I want to be useful under Linux & WINE. I want to use xchm to view the help documentation .chm file since WINE doesn't yet properly display this .chm file which was generated with third party tools and includes advanced features. xchm does render the file acceptably and I'll e-mail the .chm file to anyone interested in that. But for the time being, I want to simply launch xchm from my app whenever my app finds itself being run under WINE. What I have is done so far is system() a command with path names of xchm and my .chm file that seem to basically be trying to outsmart WINE outsmarting Windows. Clearly this is an ugly hack and is not a long term solution. Is there a supported/recommended manner of launching an X Window System executable with Linux absolute path arguments from a MS Windows application running under Linux & WINE? --Mike

3 3

[PATCH] Open file in binary mode to work around a windows bug
by Steven Edwards 09 Sep '08

09 Sep '08

-- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

3 5

Re: James Hawkins : netapi32: Fix two failing tests in NT4.
by Kai Blin 09 Sep '08

09 Sep '08

On Wednesday 03 September 2008 14:43:55 Alexandre Julliard wrote: > - ok(ret == NERR_BadUsername, "Adding user with too long username > returned 0x%08x\n", ret); + ok(ret == NERR_BadUsername || > + broken(ret == NERR_PasswordTooShort), /* NT4 */ > + "Adding user with too long username returned 0x%08x\n", ret); > I'd argue that this is not broken, but the only error NT4 returns for bad username/password combinations. At least the comments in the surrounding code should be updated. Sorry for not catching this one earlier, I didn't have that much time for Wine recently. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

1 0

Re: user32.dll: Implementation for LockWorkStation() based on xdg-screensaver
by Steven Edwards 09 Sep '08

09 Sep '08

On Tue, Sep 9, 2008 at 11:25 AM, Paul Chitescu <paulc(a)voip.null.ro> wrote: > Changelog: > user32.dll: Implementation for LockWorkStation() based on > xdg-screensaver > > Thanks to Steven Edwards (winehacker(a)gmail.com) for the idea of > using "xdg-screensaver lock". When I submitted the patch before, Alexandre and I discussed this both on and off list, I think there is another thread somewhere regarding it and I think he wanted it in explorer because of applications running in Desktop mode. I think the right behavior is to send a message to Explorer and if a wine application is not running in desktop mode then to invoke the xdg-screensaver, otherwise we should stub out or load a windows style screensaver in the emulated desktop. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

1 0

Re: user32.dll: Implementation for LockWorkStation() based on xdg-screensaver
by Michael Karcher 09 Sep '08

09 Sep '08

Am Dienstag, den 09.09.2008, 18:25 +0300 schrieb Paul Chitescu: > Known problems: > 1. Although trying to check with access() if /usr/bin/xdg-screensaver is > executable there is no error returned from spawnvp() if exec() eventually > fails after fork() succeeds. Unlikely but possible. I see that as a bug in spawnvp(). You can not do anything about that. But I dislike checking using access, because a) it is a well-known race condition (in this case, it does not seem to matter, as /usr/bin should be writable by root only). b) you sacrifice the possibility to find /usr/local/bin/xdg-screensaver if the utility has been locally added. (more important point). Would removing the access call and just trying to call xdg-screensaver have any negative implication except for not letting the windows application know that locking failed? If not, I would remove the call, as MSDN says that locking can also fail on Windows for various reasons even if LockWorkStation returned TRUE. > 2. No way to disable it - maybe users don't want their screen locked. So what? If a windows process calls LockWorkStation when the user does not want the workstation to be locked, it's a bug in the windows process, except... > 3. Doesn't take into account virtual desktops, and I have no idea what it > should do in that case, just deny access? ... if running in virtual desktop mode. (I suppose you mean "explorer /desktop" and not virtual desktop provided by X Window managers or virtual desktops provided by the linux kernel) As the real right way to implement this call is to SendMessage to explorer.exe, and explorer knows whether it runs in virtual desktop mode, I would suggest that the patch be extended to handle the screensaver start in Wine's explorer process, and just do nothing in the virtual desktop case. Regards, Michael Karcher

1 0

I just found out that when the input content is already GB2312, “wine” automatically mistakes it for unicode
by hawaii.wine wong 09 Sep '08

09 Sep '08

*Hi there, I am a Chinese programmer. I have a problem here with "wine" As we know "wine" is able to convert unicode to GB2312-- but weirdly, I just found out that when the input content is already GB2312, "wine" automatically mistakes it for unicode and therefore attempts to convert it again—and of course it gets a wrong output. **I thought "wine" could recognize GB2312 input and knows this input needs no conversion. Thanks in advance!!*

2 6

← Newer
1
...
16
17
18
19
20
21
22
...
28
Older →

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