wine-devel September 2009

wine-devel@winehq.org

103 participants
239 discussions

Re: cppcheck Sept 18
by James Mckenzie 20 Sep '09

20 Sep '09

>[/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (possible >error) Array index out of bounds > >This one is a false positive, it uses FIELD_OFFSET(cs_t, ca[5]), >and it found an array: >int ca[5]; > Actually, if this is a zero offset array, this is out of bounds. It might be better to extend ca by one and eliminate the possibility of the overflow and it only uses one more int worth of space... James McKenzie

1 0

porting winetricks to windows
by Dan Kegel 20 Sep '09

20 Sep '09

Part of my http://wiki.winehq.org/UnitTestSuites effort is to make it easy to write scripts that automate the building of windows apps on wine or windows interchangably. After a while of writing special purpose tool-install-scripts that would work on either wine or windows, I realized that I really just wanted winetricks to be my tool install script, and that it should run on windows. i.e. if you want firefox on windows or wine, you should be able to do "sh winetricks -q firefox" and have it appear. Likewise, if you happen to need the Windows 7 SDK for something you're building, you should be able to say "sh winetricks -q psdkwin7" and have it appear, no questions asked. (Assuming on windows that you have cygwin installed, of course.) So I'm starting to make that happen. Firefox works, psdkwin7 is not quite working, and lots of verbs that run windows apps still need their paths converted, but it shouldn't be hard to get your favorite verb working in both OS's now.

4 5

Re: Add dxdiag help message box
by Brian Nguyen 19 Sep '09

19 Sep '09

Hm, okay. I just wanted to test the waters here; I'll rework this to use a function that loads a string from a resource file. Does the help message itself look okay? I just used the message provided by the native dxdiag app, but I could rework it if there are issues with copyright or wine conventions. On Thu, Sep 17, 2009 at 6:34 AM, Henri Verbeet <hverbeet@...<http://www.nabble.com/user/SendEmail.jtp?type=post&post=25500104&i=0>> wrote: > 2009/9/17 Brian Nguyen <*mtxcoll*@...<http://www.nabble.com/user/SendEmail.jtp?type=post&post=25500104&i=1>>: >> +/* Thread-safe function for converting to wide char strings at runtime */ >> +LPWSTR PrintWide(LPWSTR buf, size_t len, const char *s) >> +{ >> + size_t i; >> + for (i = 0; i < len && *s != '\0'; i++, s++) { >> + buf[i] = *s; >> + } >> + return buf; >> +} > That doesn't do what you want, you should use MultiByteToWideChar() to > convert to WCHAR. However, I don't think you want to hardcode the > strings in the first place, you should load them from the resources so > they can be translated. Also, functions like that which are only used > in the current file should be static. Thanks for taking this on! -- -Austin -- Brian Nguyen mtxcoll(a)gmail.com

3 7

Fwd: Wine in Tango
by Reece Dunn 19 Sep '09

19 Sep '09

---------- Forwarded message ---------- From: Reece Dunn <msclrhd(a)googlemail.com> Date: 2009/9/19 Subject: Re: Wine in Tango To: Henri Verbeet <hverbeet(a)gmail.com> 2009/9/19 Henri Verbeet <hverbeet(a)gmail.com>: > 2009/9/19 Joel Holdsworth <joel(a)airwebreathe.org.uk>: >> On Sat, 2009-09-19 at 21:43 +0200, Henri Verbeet wrote: >>> 2009/9/19 Vitaliy Margolen <wine-devel(a)kievinfo.com>: >>> > - The European stop sign is not known/used in US. It has no meaning to most >>> > people. >>> Actually, assuming you mean >>> http://www.airwebreathe.org.uk/wine-icon/oic_hand-48.png, that's not a >>> stop sign in Europe either. It generally means "no entry", and I was >>> under the impression it's used in that way in the US as well. Not that >>> that makes it any more appropriate as an "error" sign. (Doesn't gnome >>> use that one as well though? I guess that would at least make it >>> recognizable to some people.) >> >> It's the dialog error icon from the Tango base set. Does that carry any >> weight? maybe... maybe not. It seemed clear enough to me though. >> > Possibly, consistency is generally a good thing. I can't say I pay a > whole lot of attention to the icons in messageboxes, but I could see > how this one wouldn't be entirely clear on its own to a new user. The > color red probably does more to convey the message "error" than the > sign. The error icon needs to be recognisable as well (aside from colour) for people with red-green colour blindness. A no entry sign doesn't really make sense here (although, it is the correct image from a tango perspective). Tango does have an unofficial (X) 'traditional' version (ref: http://commons.wikimedia.org/wiki/Tango_icons), so it would probably be better to use that instead. Not sure what the Oxygen icon looks like. ==== On the whole, these icons are a major improvement. Well done. Q: For the small 16x16 icons, why do some have the wine glass and some don't (for the ones that have a wine glass on the larger versions)? - Reece

1 0

Re: [(try 3) 3/3] opengl32/tests: Improve test for wglMakeCurrent.
by Paul Vriens 19 Sep '09

19 Sep '09

On 09/19/2009 12:29 PM, Rico Schüller wrote: > --- > dlls/opengl32/tests/opengl.c | 10 ++++++++++ > 1 files changed, 10 insertions(+), 0 deletions(-) > > > > ------------------------------------------------------------------------ > > + ret = wglMakeCurrent( NULL, NULL ); + ok( !ret, "wglMakeCurrent failed\n" ); shouldn't that message read "wglMakeCurrent succeeded" ? If you are testing the last error it's usually a good idea to set the last error before the call (aka "SetLastError(0xdeadbeef)"). -- Cheers, Paul.

4 4

Re: winex11: add alternative header
by Steven Edwards 19 Sep '09

19 Sep '09

2009/9/18 André Hentschel <nerv(a)dawncrow.de>: > this is my first patch to autoconf-stuff, please tell me if i did something wrong > see also Bug 20070 I expect It should actually not look like the following > #ifdef HAVE_X11_EXTENSIONS_XF86VMODE_H > #include <X11/extensions/xf86vmode.h> > +#elif defined (HAVE_X11_EXTENSIONS_XF86VMPROTO_H) > +#include <X11/extensions/xf86vmproto.h> > #endif and instead like this: #ifdef HAVE_X11_EXTENSIONS_XF86VMODE_H #include <X11/extensions/xf86vmode.h> #endif #ifdef HAVE_X11_EXTENSIONS_XF86VMPROTO_H #include <X11/extensions/xf86vmproto.h> #endif Thanks -- 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

2 2

[bugzilla] donate to sponsoring bug
by sacchi antonio 19 Sep '09

19 Sep '09

This idea was born because I'm not a developer but I want to help Wine, this is not a perfect idea, help me to make it better! Maybe this button will appear only on very few bugs/projects (2-3 max?) and money could go directly to Wine and after bug/project will be released/fixed money could go to people. Now Alexandre decides if a patch will be included or not, so I think he will have the task of deciding also money issue. Sorry for my english.. S.A. 2009/9/16 Tom Wickline <twickline(a)gmail.com>: > Hello, > > You could have the money go into the general WPF or WCF "Wine Conference > Fund" > But the problem is if say I donate $50.00 who's to say the bug I donate to > will be resolved > any time soon? Paypal only allows refunds up to 60 days, so how would you go > about a refund > if the bug wasn't fixed in say a year or more? > > I think it would be hard to keep everyone happy, because as soon as people > donate to a bug > their going to expect something in return. And a refund most likely if the > bug isn't fixed. > > Tom > > 2009/9/16 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se> >> >> I suppose that this only will appear on some bugs and disregarding that >> people might put off fixing bugs waiting for it to become a "pay-bug". >> Who's going to get the money? It seems quite common that people share >> credit on fixing bugs, should we burden Alexandre with the task of deciding >> that? >> Wouldn't this rather be on "projects", than bugs? The bug mentioned feels >> more like a "project". >> >> //Nicklas >> >> -----Original Message----- >> From: wine-devel-bounces(a)winehq.org on behalf of sacchi antonio >> Sent: Wed 2009-09-16 11:47 >> To: wine-devel(a)winehq.org >> Subject: [bugzilla] donate to sponsoring bug >> >> hello all. >> I'm new here but I'd like to suggest something, >> what do you think about this? >> http://img29.imageshack.us/img29/2940/wined.png >> >> Maybe it will be good for old/hard bugs? >> >> Thanks >> >> >> > > > > -- > http://www.wine-reviews.net/ > http://bordeauxgroup.com/ >

3 2

Add jscript component to Bugzilla?
by Ken Sharp 19 Sep '09

19 Sep '09

Any chance someone could add a jscript component to Bugzilla? It's used a decent amount to warrant it...

1 1

Re: [Bug 19523] winmm: Multiple waveOutOpen calls on single device supported by Windows, not Wine
by Ken Thomases 19 Sep '09

19 Sep '09

Taking this conversation out of the bug, since it seems I opened the bug in error and it should be closed. On Sep 19, 2009, at 2:29 AM, wine-bugs(a)winehq.org wrote: > http://bugs.winehq.org/show_bug.cgi?id=19523 > > --- Comment #3 from Eric Pouech <eric.pouech(a)orange.fr> 2009-09-19 > 02:28:51 --- > of course, there is... OK, in that case: a) that's good to know; and b) thanks for setting me straight. I might quibble with "of course", though. ;) > let's take the wave out driver interface as example: > > DWORD WINAPI wodMessage(UINT wDevID, UINT wMsg, DWORD_PTR dwUser, > DWORD_PTR dwParam1, DWORD_PTR dwParam2); > > in case wMsg in WODM_OPEN, dwUser is expected to be a pointer to a > DWORD, that > the driver is supposed to filled with a unique instance ID (to > identify the > stream) > > in other (subsequent) messages, winmm passes in dwUser the unique ID > defined by > the driver at WODM_OPEN time > > winmm correctly supports this scheme (see MMDRV_Open in dlls/winmm/ > lolvldrv.c) No offense, but looking at MMDRV_Open, it's clear as mud to me that dwDriverInstance has this meaning and corresponds to dwUser. Is there any documentation of the low-level driver interface? > but, none of the wine drivers correctly initialize the dwUser while > processing > the various XXXX_OPEN messages Does that mean this functionality is untested? Thanks again, Ken

3 3

Re: [(try 3) 1/3] wined3d: Don't call wglMakeCurrent(NULL, NULL) in context_set_current() if the current context is NULL.
by Rico Schüller 19 Sep '09

19 Sep '09

Am 19.09.2009 12:29, schrieb Rico Schüller: > Hi, > > this patch series fixes a bug which happens on windows with wined3d. > There a second call to wglMakeCurrent(NULL, NULL) fails, which will in > one case result in an early return in context_set_current(), which > doesn't set the the current context to NULL in such a case, but frees > the variable. So on the next call to context_set_current() (e.g. from > WineD3D_CreateFakeGLContext()) the memory in old->... could be some > other random memory and the app could crash. > > try 3 improvements: > - try 2 had the wrong test patch (3/3), so this time with the correct one > > try 2 improvements: > - moved the check from winex11.drv to gdi32 (because we don't need any > X11 functionality) > - order of patches changed > > The first patch fixes the behaviour in wined3d. The second one adds > the fix in gdi32 to change the behaviour to the one on xp. The third > patch adds a test case to opengl32/tests. > > Cheers > Rico > > --- > dlls/wined3d/context.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > > ------------------------------------------------------------------------ > > > I have to add some more tests. I'll resend a better version of the patch set. Cheers Rico

1 0

← Newer
1
...
9
10
11
12
13
14
15
...
24
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 2009