wine-devel January 2008

wine-devel@winehq.org

126 participants
290 discussions

re: Some more spelling fixes.
by Dan Kegel 04 Jan '08

04 Jan '08

Francois wrote: > I'd say "'coz" is not a typo, but was written that way intentionally to > give a 'slang-ish' tone to the comment by someone who knows full well > the standard spelling. As such it should not be modified. I've seen too many people who aren't even aware of the difference between slang and standard english. So (without looking back at who committed it) I'm tempted to correct that kind of thing, just because it annoys me, and annoyance was my guide for what's worth fixing... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Re: xrandx responds with too many modes.
by Peter Dons Tychsen 04 Jan '08

04 Jan '08

On Thu, 2008-01-03 at 22:46 -0600, Clarence Risher wrote: > I regularly use 640x512 in wine, when that resolution wouldnt be > reported by the driver in windows. Dunno if you consider that a > "normal" resolution. Just out of curiosity, what do you use this for? Whats wrong with the 640 x 480? Why do you need the extra 640x32 pixels? Another way of fixing the problem could be to limit the amount of frequency variants. Not sure if wine can use them for anything useful anyway. Could we report all modes at just 60Hz, or would that be too naughty? This is actually what is done for the desktop implementation, so it might work. This would also be easy to change in xrandx.c as the frequencies are handled separately. /p

2 1

Re: Some more spelling fixes.
by Francois Gouget 04 Jan '08

04 Jan '08

> - /* test has been removed 'coz MMSYSERR_BASE is 0, and gcc did emit > + /* test has been removed because MMSYSERR_BASE is 0, and gcc did emit I'd say "'coz" is not a typo, but was written that way intentionally to give a 'slang-ish' tone to the comment by someone who knows full well the standard spelling. As such it should not be modified. > - /* wmd must be inserted in list before sending opening the driver, coz' it > + /* wmd must be inserted in list before sending opening the driver, because it This one however should have its spelling fixed to "'coz". -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

1 0

Re: d3dx implementation senseless?
by Peter Dons Tychsen 04 Jan '08

04 Jan '08

I do not think patents which are blocking your ability to use the DLLs in Wine. It is your Windows license. I believe that if you have a Windows license for your machine, you are free to use Windows or its DLLs. This includes all the "free" downloads from their web-pages. I think, if you do not have a license for that machine, you are in violation of the license, which is illegal. I am not sure i got all the details right but you can probably find more on their web-page. If i understand it correctly, it of course means that there are no really free downloads on their web-page, as they all rely on a purchase of Windows. This makes the "free" download kind of expensive. For Wine it means that anything the user has to D/L from their homepage is a no-no. /p On Fri, 2008-01-04 at 13:46 +0100, tony.wasserka(a)freenet.de wrote: > Hi, > I enjoyed the current wine development of the D3DX libraries and also tried to implement an interface. > However, while testing it I noticed that Wine seems to fully support everything when it has a native > d3dx9.dll (though it even was able to run one of my games without any dll...). So I was asking myself > if there's even a reason to implement anything other than the inlined functions of D3DX, when we only > lose performance and development time with it. Also, what would we do at functions like > D3DXCreateTextureFromFile which supports 9 file formats? Would we implement e.g. a BMP file > loader ourselves or would we use a 3rd party library for that? Are there any patents regarding the > DX specific file formats (.x/.dds)? Don't misunderstand me, I'd also like to help out at D3DX, but I > really think we'd be better off by removing everything of D3DX but the inlined stuff. > Best regards, > Tony Wasserka > > > (PS: if one argues that we need the implementation for WineLib, I _think_ it'd be enough to just > stub all functions so that the program compiles fine and then use the native dll again) > > > > > > > > > > > > >

1 0

Re: French LTEXT correction
by Jonathan Ernst 04 Jan '08

04 Jan '08

On ven, 2008-01-04 at 11:24 +0100, Vincent Hardy wrote: > Regedit displays "Rechercher::". Now Regedit displays "Rechercher :" and > so on... It doesn't here (?). Furthermore in French ":" should be preceded by an unbreakable space (like it's the case now) and not a normal space.

1 0

xrandx responds with too many modes.
by Peter Dons Tychsen 04 Jan '08

04 Jan '08

The xrandx X11 extension is very handy. Using it for wine makes great sense. But... the extension also enumerates a whopping amount of modes. Each resolution has a multitude of frequencies and bit-depth variants. Some applications are simply not prepared for that magnitude of information when they call EnumDisplaySettings() (user32) or EnumDisplayModes (ddraw). When using "normal" windows, only a few modes are returned. I know its not a bug, as it could happen on Windows if someone published a driver which implemented tons of silly and crooked modes. Would it be acceptable to insert a filter in xrandx.c (X11-drv), which only allowed "normal" windows resolutions to be enumerated? Does anyone need those awkward ones? The filter would look allot like the one in desktop.c (X11-drv) which is currently used by the desktop mode. I already fixed a portion of the bugs caused by this, as there was a natural limitation which should be set by EnumDisplayModes() which was not honored. I sent in patch for this already. So at least now we can play the classic "Grand Theft Auto".... Thanks, /p

3 2

d3dx implementation senseless?
by tony.wasserka＠freenet.de 04 Jan '08

04 Jan '08

Hi, I enjoyed the current wine development of the D3DX libraries and also tried to implement an interface. However, while testing it I noticed that Wine seems to fully support everything when it has a native d3dx9.dll (though it even was able to run one of my games without any dll...). So I was asking myself if there's even a reason to implement anything other than the inlined functions of D3DX, when we only lose performance and development time with it. Also, what would we do at functions like D3DXCreateTextureFromFile which supports 9 file formats? Would we implement e.g. a BMP file loader ourselves or would we use a 3rd party library for that? Are there any patents regarding the DX specific file formats (.x/.dds)? Don't misunderstand me, I'd also like to help out at D3DX, but I really think we'd be better off by removing everything of D3DX but the inlined stuff. Best regards, Tony Wasserka (PS: if one argues that we need the implementation for WineLib, I _think_ it'd be enough to just stub all functions so that the program compiles fine and then use the native dll again)

2 1

Re: mshtml #4: Includes clean up. (fixed)
by Alexandre Julliard 04 Jan '08

04 Jan '08

Jacek Caban <jacek(a)codeweavers.com> writes: > diff --git a/dlls/mshtml/install.c b/dlls/mshtml/install.c > index 731af60..2437797 100644 > --- a/dlls/mshtml/install.c > +++ b/dlls/mshtml/install.c > @@ -18,33 +18,23 @@ > > #include "config.h" > > -#include <stdarg.h> > +#include "mshtml_private.h" > +#include "resource.h" > + > #include <fcntl.h> > #ifdef HAVE_UNISTD_H > # include <unistd.h> > #endif It's not a good idea to include Unix headers after the Windows ones, that can create trouble. I have to admit I'm not a big fan of that sort of one include to rule them all approach, I think it's better to have each file maintain control over what it includes and in which order. The global mshtml_private.h header should only include the stuff it itself depends on, not every single header that any source file may want to use. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] ddraw: Return a nullpointer as lpSurface in Lock() if the rect is invalid.
by H. Verbeet 04 Jan '08

04 Jan '08

On 03/01/2008, Günther Brammer <GBrammer(a)gmx.de> wrote: > + ok(!locked_desc.lpSurface, "IDirectDrawSurface_Lock did not set lpSurface in the surface desc\n"); > That isn't the clearest message. It should probably say it didn't set lpSurface to NULL.

1 0

USER32 - SPI_GETMOUSE missing a default value.
by Peter Dons Tychsen 04 Jan '08

04 Jan '08

I have an app which is bailing out because it cannot get valid data from SPI_GETMOUSE - and indeed this reg key does not exist. The key should be in "Control Panel\\Colors" under CURRENT_USER. There are similar values in the "Control Panel" folder in the registry. Is there a reason this value is not initialized ? If i want to fix it, then: 1) Where is the best place to initialize values like these? I presume its during boot, where the mouse values should be read? 2) Should i get the mouse data from X11 or just simulate something? /p

2 1

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