March 2011 - Wine-Devel - list.winehq.org

Re: wine 1.3.16: wrc compiler and LANGUAGE

by Jerome Leclanche

I don't think SUBLANG_FRENCH is valid in rc files. Have you tried SUBLANG_NEUTRAL? J. Leclanche On Wed, Mar 23, 2011 at 9:54 AM, Gilles Depeyrot <gsd(a)dolphin.fr> wrote: > Hi, > > I am testing compiling an application that uses winelib with 1.3.16 > (currently compiled with 1.2.2). > > I have an issue with the resource compiler (wrc) which doesn't understand > the LANGUAGE line. When I compile resource files, I get errors resembling: > > file.rc:22:21: Error: syntax error > > The corresponding line in the file is: > > LANGUAGE LANG_FRENCH, SUBLANG_FRENCH > > If I comment the line, the compilation succeeds. > > Best regards, > Gilles > > >

March 23, 2011

Re: [1/4] wined3d/context: Track the number of render targets in FBO entries.

by Adam Martinson

On 03/22/2011 01:33 PM, Henri Verbeet wrote: > How much of a real difference does this patch make, after you > avoid the redundant lookups? (I.e., after the second patch in this > series.) In that case the additional reduction in context_apply_fbo_state() CPU time from the 1st patch is only about 10%.

March 23, 2011

Re: [GSoC] Merge winecfg and Control Panel

by David Laight

On Wed, Mar 23, 2011 at 01:31:09PM -0700, Scott Ritchie wrote: > On 03/23/2011 07:15 AM, Dan Kegel wrote: > > Also... it would be nice if there were a central commandline > > way of changing wine settings, kind of like 'net' is a central > > way of manipulating networking. > > > > I've been thinking that winecfg should have a commandline > > interface, too, and making it accept winetricks settings > > directly. Something like that would also make a good soc project. > > > > > > I remember proposing this idea long ago as I would have found it useful > for front end user interfaces. It is worth remembering that an elf program's 'main' can be in a shared object! This mightmake it easier to write a stub binary that effectively make a .so executable. Sort of depends on what the guy way tring to do... David -- David Laight: david(a)l8s.co.uk

March 23, 2011

[GSoC] Implementing missing DirectInput8 features

by Lucas Zawacki

Hello, I'm Lucas Fialho Zawacki a Computer Science undergrad at UFRGS university in Brazil. I'm very interested in working with Wine for the Google Summer of Code and have decided to approach the implementation of DirectInput8 missing features. I'm a long time Wine user, but I'd never looked at it from a developer point of view, so for the past few days I have been reading Wine's developer documentation and familiarizing myself with it's architecture and with the parts I intend to work on. At the moment, I don't have a clear understanding of how the implementation should be done so I'm reading a lot of material about dinput and dinput8 and building some documentation to help me. After some polishing I hope to be able to contribute it to Wine too. A little word about me. I've been using the C programming language for almost three years, so I'm very familiar with it. For the last two years I've worked on a research project as a C/C++ programmer, implementing a decision system for a F180 Small Size League Robot Soccer Team (see http://small-size.informatik.uni-bremen.de/) and http://code.google.com/p/robopet/ . I'm a heavy Linux user and I'm very comfortable with it's tools used for programming. That's it. I'm eager to get your feedback about this. My proposal will be ready in a few days. -- http://www.twitter.com/lfzawacki http://www.linesocode.wordpress.com

March 23, 2011

Re: [GSoC] Merge winecfg and Control Panel

by Scott Ritchie

On 03/23/2011 07:15 AM, Dan Kegel wrote: > Also... it would be nice if there were a central commandline > way of changing wine settings, kind of like 'net' is a central > way of manipulating networking. > > I've been thinking that winecfg should have a commandline > interface, too, and making it accept winetricks settings > directly. Something like that would also make a good soc project. > > I remember proposing this idea long ago as I would have found it useful for front end user interfaces. It's what lead to the creation of the python-wine library by Christian Dannie Stroggard, which is a part of the vineyard project now. I suggest anyone having this need/considering implementing this give that a look. -Scott Ritchie

March 23, 2011

Re: [GSoC] Merge winecfg and Control Panel

by Jerome Leclanche

Winetricks uses the registry. It creates temporary .reg files and feeds them to regedit. J. Leclanche On Wed, Mar 23, 2011 at 6:15 PM, Tony Zhang <niu.tony.c.zhang(a)gmail.com> wrote: > Now I see what you meant. That really is a nice feature to do something like > "winecfg vd=1024x768". > I'll see if I can understand how winetricks accomplish that. > > > On Wed, Mar 23, 2011 at 1:05 PM, Dan Kegel <dank(a)kegel.com> wrote: >> >> Winetricks is a simple script that adds a few mssing things to wine, e.g. >> it's how most people install ms dlls or .net on wine. It also provides a >> simple commandline way to change a few settings. For instance, winetricks >> vd=1024x768 sets a 1024x768 virtual desktop... it'd be nice if one could >> instead do winecfg vd=1024x768 or something like that. >> >> See also http://winetricks.org. > > > >

March 23, 2011

Re: [GSoC] Merge winecfg and Control Panel

by Tony Zhang

Now I see what you meant. That really is a nice feature to do something like "winecfg vd=1024x768". I'll see if I can understand how winetricks accomplish that. On Wed, Mar 23, 2011 at 1:05 PM, Dan Kegel <dank(a)kegel.com> wrote: > Winetricks is a simple script that adds a few mssing things to wine, e.g. > it's how most people install ms dlls or .net on wine. It also provides a > simple commandline way to change a few settings. For instance, winetricks > vd=1024x768 sets a 1024x768 virtual desktop... it'd be nice if one could > instead do winecfg vd=1024x768 or something like that. > > See also http://winetricks.org. >

March 23, 2011

Re: [GSoC] Merge winecfg and Control Panel

by Dan Kegel

Winetricks is a simple script that adds a few mssing things to wine, e.g. it's how most people install ms dlls or .net on wine. It also provides a simple commandline way to change a few settings. For instance, winetricks vd=1024x768 sets a 1024x768 virtual desktop... it'd be nice if one could instead do winecfg vd=1024x768 or something like that. See also http://winetricks.org. On Mar 23, 2011 10:36 AM, "Tony Zhang" <niu.tony.c.zhang(a)gmail.com> wrote: Dear Dan, I agree that it would be nice to have a command-line interface for wine settings cause I have run into situations that I have to configure wine before going into X. So is it possible to first group/rearrange winecfg functions into certain libraries and then let the GUI (control panel) and the CLI all interact with the corresponding libraries? About winetricks, I do not know much about it. What exactly do you mean by "winetricks settings"? -- Tony (Chi Zhang) On Wed, Mar 23, 2011 at 9:15 AM, Dan Kegel <dank(a)kegel.com> wrote: > > Also... it would be nice i...

March 23, 2011

Re: Wine compatibility

by Juan Lang

> What I meant as 'clean start' is that they could drop all hacks in 64bit > environment. I wonder if that happened. Speculating whether MS would have done this is probably not a very useful exercise. Still, I'd say it's exceedingly improbable: 1. The cost of reviewing all the code for what might be a hack is high, and what's the benefit? Less code to maintain can't be an answer, because the 32-bit versions of Windows still need the hacks. 2. Apps written for 64-bit Windows aren't created in a vacuum: they're probably ported from a 32-bit codebase first, or 32-bit and 64-bit versions are co-developed. The same, possibly erroneous assumptions that a 32-bit application might make would therefore need to be maintained in a 64-bit version. A better place to ask questions like these might be http://blogs.msdn.com/b/oldnewthing/ --Juan

March 23, 2011

Re: Wine compatibility

by Austin English

2011/3/23 Adam Kłobukowski <adamklobukowski(a)gmail.com>: > On 23.03.2011 16:01, James McKenzie wrote: >> >> On 3/23/11, Adam Kłobukowski<adamklobukowski(a)gmail.com> wrote: >>> >>> Hello >>> >>> I have a question for Wine developers, not 100% related to development, >>> so: please excuse me for wasting your time. >>> >>> Officially sated, Wine wants to be 'bug-by-bug' implementation of >>> Windows APIs. On the other hand, it is known that all (?) version of >>> Windows contain 'hacks' to make important and not well behaving >>> applications work (mostly workarounds for application bugs). This >>> 'hacks' work by detecting that a faulty app is running, and turning >>> special 'hack' mode for such app. Because of this, black box testing >>> often used by Wine developers will not detect such workarounds, and >>> applications that (seem to) work perfectly well under Windows, will not >>> work under Wine. >>> >> And some programs that worked 'just fine' under WindowsXP will not in >> any other version due to the internal hacks. >> >>> Is there a solution for this? What is Wine devs position on this matter? >> >> Sure. We look at the interaction between the program and the Windows >> API (this is how true Black Box testing is done), implement a test >> case and then build code to the test case. >> >>> >>> Side question: Windows could make a 'clean start' with 64 bit >>> environment, did they? >> >> If that happened, there would have not been any version of Windows >> with 64 bitness for about twenty years. Microsoft 'extended' their >> code to work in a 64 bit environment. This is common with existing 32 >> bit code to extend it to 64 bits. > > What I meant as 'clean start' is that they could drop all hacks in 64bit > environment. I wonder if that happened. Looking at the results from the wine test suite on 64-bit, I'd say no. -- -Austin

March 23, 2011

Re: Wine compatibility

by Adam Kłobukowski

On 23.03.2011 16:01, James McKenzie wrote: > On 3/23/11, Adam Kłobukowski<adamklobukowski(a)gmail.com> wrote: >> Hello >> >> I have a question for Wine developers, not 100% related to development, >> so: please excuse me for wasting your time. >> >> Officially sated, Wine wants to be 'bug-by-bug' implementation of >> Windows APIs. On the other hand, it is known that all (?) version of >> Windows contain 'hacks' to make important and not well behaving >> applications work (mostly workarounds for application bugs). This >> 'hacks' work by detecting that a faulty app is running, and turning >> special 'hack' mode for such app. Because of this, black box testing >> often used by Wine developers will not detect such workarounds, and >> applications that (seem to) work perfectly well under Windows, will not >> work under Wine. >> > And some programs that worked 'just fine' under WindowsXP will not in > any other version due to the internal hacks. > >> Is there a solution for this? What is Wine devs position on this matter? > > Sure. We look at the interaction between the program and the Windows > API (this is how true Black Box testing is done), implement a test > case and then build code to the test case. > >> >> Side question: Windows could make a 'clean start' with 64 bit >> environment, did they? > > If that happened, there would have not been any version of Windows > with 64 bitness for about twenty years. Microsoft 'extended' their > code to work in a 64 bit environment. This is common with existing 32 > bit code to extend it to 64 bits. What I meant as 'clean start' is that they could drop all hacks in 64bit environment. I wonder if that happened. Adam Klobukowski

March 23, 2011

Re: [GSoC] Merge winecfg and Control Panel

by Tony Zhang

Dear Dan, I agree that it would be nice to have a command-line interface for wine settings cause I have run into situations that I have to configure wine before going into X. So is it possible to first group/rearrange winecfg functions into certain libraries and then let the GUI (control panel) and the CLI all interact with the corresponding libraries? About winetricks, I do not know much about it. What exactly do you mean by "winetricks settings"? -- Tony (Chi Zhang) On Wed, Mar 23, 2011 at 9:15 AM, Dan Kegel <dank(a)kegel.com> wrote: > Also... it would be nice if there were a central commandline > way of changing wine settings, kind of like 'net' is a central > way of manipulating networking. > > I've been thinking that winecfg should have a commandline > interface, too, and making it accept winetricks settings > directly. Something like that would also make a good soc project. >

March 23, 2011

Re: [GSoC] Merge winecfg and Control Panel

by Tony Zhang

Dear Owen, Thank you for pointing me to those information. I'll take a look at those and try to figure out the process of making control panel applets. Unfortunately, I have no background in Windows programming, but I do want to get some through this project. -- Tony (Chi Zhang) On Wed, Mar 23, 2011 at 6:34 AM, Owen Rudge <owen(a)owenrudge.net> wrote: > Hi Tony, > > > I have briefly walked through Owen Rudge's code of splitting out the >> Desktop Integration tab into its own control panel, but have no luck in >> getting a decent understanding of it. So I'm hoping some of you can >> point me to some documents that related to this task so I can have an >> overall understanding of the challenges of this task. >> > > Actually creating a new control panel applet is a fairly straightforward > task. You can look at the existing control panels (appwiz.cpl, inetcpl.cpl) > to get an idea of what's involved, or consult MSDN for more information ( > http://tinyurl.com/6yu7cw4) If you've not got a background in Windows > programming already, it may of course take a little longer to figure > everything out. > > More complicated is actually working out how to split up winecfg > effectively, and how to do so in a way that doesn't result in unnecessary > code duplication, otherwise you'll likely find it difficult to actually get > your code into the project. > > I would say that there's certainly potential for a project here, if you can > flesh it out - I do think a unified control panel containing all of Wine's > configuration options would be a good thing, rather than the current > situation where options are scattered between the control panel, winecfg, > etc. The key will be figuring out what you want to do, how you're going to > achieve it, and making sure it will be acceptable to the wider Wine > community. > > Regards, > > -- > Owen Rudge > http://www.owenrudge.net/ >

March 23, 2011

Re: [1/2] uxtheme: Add OpenThemeDataEx (try 2)

by Dmitry Timoshkov

André Hentschel <nerv(a)dawncrow.de> wrote: > Applied Dmitry's suggestions > -HTHEME WINAPI OpenThemeData(HWND hwnd, LPCWSTR pszClassList) > +HTHEME WINAPI OpenThemeDataEx(HWND hwnd, LPCWSTR classlist, DWORD flags) > { > - WCHAR szAppBuff[256]; > - WCHAR szClassBuff[256]; > - LPCWSTR pszAppName; > - LPCWSTR pszUseClassList; > + WCHAR appbuff[256]; > + WCHAR classbuff[256]; > + LPCWSTR appname; > + LPCWSTR useclasslist; > HTHEME hTheme = NULL; You are changing too much. Just use lowercase named variables for new code, not touching existing ones. > - TRACE("(%p,%s)\n", hwnd, debugstr_w(pszClassList)); > + TRACE("(%p,%s, %u)\n", hwnd, debugstr_w(classlist), flags); flags above is still printed in decimal. > + > + if(flags) > + FIXME("unhandled Flags: %x\n", flags); -- Dmitry.

March 23, 2011

Re: Wine compatibility

by James McKenzie

On 3/23/11, Adam Kłobukowski <adamklobukowski(a)gmail.com> wrote: > Hello > > I have a question for Wine developers, not 100% related to development, > so: please excuse me for wasting your time. > > Officially sated, Wine wants to be 'bug-by-bug' implementation of > Windows APIs. On the other hand, it is known that all (?) version of > Windows contain 'hacks' to make important and not well behaving > applications work (mostly workarounds for application bugs). This > 'hacks' work by detecting that a faulty app is running, and turning > special 'hack' mode for such app. Because of this, black box testing > often used by Wine developers will not detect such workarounds, and > applications that (seem to) work perfectly well under Windows, will not > work under Wine. > And some programs that worked 'just fine' under WindowsXP will not in any other version due to the internal hacks. > Is there a solution for this? What is Wine devs position on this matter? Sure. We look at the interaction between the program and the Windows API (this is how true Black Box testing is done), implement a test case and then build code to the test case. > > Side question: Windows could make a 'clean start' with 64 bit > environment, did they? If that happened, there would have not been any version of Windows with 64 bitness for about twenty years. Microsoft 'extended' their code to work in a 64 bit environment. This is common with existing 32 bit code to extend it to 64 bits. James McKenzie

March 23, 2011

Re: Wine compatibility

by Juan Lang

> Is there a solution for this? Sure: black-box reverse engineer how MS is detecting the apps and enabling the hacks, create test cases showing that they exist, and implement them ourselves. --Juan

March 23, 2011

re: [GSoC] Merge winecfg and Control Panel

by Dan Kegel

Also... it would be nice if there were a central commandline way of changing wine settings, kind of like 'net' is a central way of manipulating networking. I've been thinking that winecfg should have a commandline interface, too, and making it accept winetricks settings directly. Something like that would also make a good soc project.

March 23, 2011

Re: [GSoC] Merge winecfg and Control Panel

by Owen Rudge

Hi Tony, > I have briefly walked through Owen Rudge's code of splitting out the > Desktop Integration tab into its own control panel, but have no luck in > getting a decent understanding of it. So I'm hoping some of you can > point me to some documents that related to this task so I can have an > overall understanding of the challenges of this task. Actually creating a new control panel applet is a fairly straightforward task. You can look at the existing control panels (appwiz.cpl, inetcpl.cpl) to get an idea of what's involved, or consult MSDN for more information (http://tinyurl.com/6yu7cw4) If you've not got a background in Windows programming already, it may of course take a little longer to figure everything out. More complicated is actually working out how to split up winecfg effectively, and how to do so in a way that doesn't result in unnecessary code duplication, otherwise you'll likely find it difficult to actually get your code into the project. I would say that there's certainly potential for a project here, if you can flesh it out - I do think a unified control panel containing all of Wine's configuration options would be a good thing, rather than the current situation where options are scattered between the control panel, winecfg, etc. The key will be figuring out what you want to do, how you're going to achieve it, and making sure it will be acceptable to the wider Wine community. Regards, -- Owen Rudge http://www.owenrudge.net/

March 23, 2011

Re: [PATCH 03/15] d3dx9: Use size of variable instead of type.

by Nikolay Sivov

On 3/23/2011 13:49, Rico Schüller wrote: > --- > dlls/d3dx9_36/effect.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > len = MultiByteToWideChar(CP_ACP, 0, srcfile, -1, NULL, 0); > - srcfileW = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, len * sizeof(WCHAR)); > + srcfileW = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, len * sizeof(*srcfileW)); > MultiByteToWideChar(CP_ACP, 0, srcfile, -1, srcfileW, len); No need to zero, if it will be filled with next call. This could a subject of next patch of course.

March 23, 2011

Re: [PATCH 2/4] comdlg32: Add stub implementation of the Common Item dialogs.

by Nikolay Sivov

On 3/23/2011 00:43, David Hedberg wrote: > >> By the way, IFileSaveDialog is based on IFileDialog, and you add >> IFileDialog2 too. It's a bit messy, >> does target class object that will use FileDialogImpl really respond to >> IFileDialog2? >> > I'm not completely sure I understand the question, but the same thing > goes for the IFileOpenDialog. Yeah, I didn't mean to distinguish them, IFileSaveDialog was as an example. > I just rechecked on Windows 7, and both > the IFileSaveDialog and the IFileOpenDialog can be successfully > queried for the IFileDialog2 interface. There are tests for that in > the test patch I sent, sort of, although the E_NOINTERFACE case is > merely marked as broken for the sake of Vista. Ok, fine then. It's also better to get rid of casts like: > +static HRESULT WINAPI IFileOpenDialog_fnSetFileTypeIndex(IFileOpenDialog *iface, UINT iFileType) > +{ > + FileDialogImpl *This = impl_from_IFileOpenDialog(iface); > + return IFileDialog2_SetFileTypeIndex((IFileDialog2*)This, iFileType); > +} > + and use &This->IFileDialog2_iface.

March 23, 2011

wine 1.3.16: wrc compiler and LANGUAGE

by Gilles Depeyrot

Hi, I am testing compiling an application that uses winelib with 1.3.16 (currently compiled with 1.2.2). I have an issue with the resource compiler (wrc) which doesn't understand the LANGUAGE line. When I compile resource files, I get errors resembling: file.rc:22:21: Error: syntax error The corresponding line in the file is: LANGUAGE LANG_FRENCH, SUBLANG_FRENCH If I comment the line, the compilation succeeds. Best regards, Gilles

March 23, 2011

Wine compatibility

by Adam Kłobukowski

Hello I have a question for Wine developers, not 100% related to development, so: please excuse me for wasting your time. Officially sated, Wine wants to be 'bug-by-bug' implementation of Windows APIs. On the other hand, it is known that all (?) version of Windows contain 'hacks' to make important and not well behaving applications work (mostly workarounds for application bugs). This 'hacks' work by detecting that a faulty app is running, and turning special 'hack' mode for such app. Because of this, black box testing often used by Wine developers will not detect such workarounds, and applications that (seem to) work perfectly well under Windows, will not work under Wine. Is there a solution for this? What is Wine devs position on this matter? Side question: Windows could make a 'clean start' with 64 bit environment, did they? Thank you for your time. Adam Klobukowski

March 23, 2011

[GSoC] Merge winecfg and Control Panel

by Tony Zhang

Hi everyone, I am a senior student double majoring in Computer Science and Math at Northern Illinois University (currently applying the CS Master Program at NIU) and I would like to participate in merging winecfg and control panel through the Google Summer of Code program. I have used wine since wine 0.9 and 'm now using wine 1.3. I like the idea that all config tools should be grouped and managed at one place, and it would be nice to have them similar to the classical windows control panel (like the control panel in wine 1.3). About my programming background, I believe I know (and love) C the best. I have not had any internships before, but I'm currently working as an undergraduate Research Assistant at NIU. It is a Proton Computed Tomography (Proton CT) project and the main language in use is C, so I do have some experience of using C in a large-scale project. I have briefly walked through Owen Rudge's code of splitting out the Desktop Integration tab into its own control panel, but have no luck in getting a decent understanding of it. So I'm hoping some of you can point me to some documents that related to this task so I can have an overall understanding of the challenges of this task. Sincerely, -- Tony (Chi Zhang)

March 23, 2011

Re: Question

by Andrew Green

There are no teams in gsoc. Each person has to work individually on the project they choose. How it works is that the organisation pick projects it approves of. Then these projects are sent to google. Google takes into account various factors to decide how many projects get selected. On Mar 23, 2011 12:24 AM, "Sanket Patel" <sanketpatel.com(a)gmail.com> wrote: > > How Teams Are Formed in Google Summer Of Code For Any Project. > Is It Formed By Organization Or Google ? > > -- > " Live 2 Love and Love 2 Live " > > >

March 22, 2011

Re: [PATCH 2/4] comdlg32: Add stub implementation of the Common Item dialogs.

by David Hedberg

>> On Mon, Mar 21, 2011 at 14:55, Nikolay Sivov<bunglehead(a)gmail.com> wrote: > > I think it is, it makes it clear that dialogue instance is about save or > open, not both. > Ok, I'll change that. > By the way, IFileSaveDialog is based on IFileDialog, and you add > IFileDialog2 too. It's a bit messy, > does target class object that will use FileDialogImpl really respond to > IFileDialog2? > I'm not completely sure I understand the question, but the same thing goes for the IFileOpenDialog. I just rechecked on Windows 7, and both the IFileSaveDialog and the IFileOpenDialog can be successfully queried for the IFileDialog2 interface. There are tests for that in the test patch I sent, sort of, although the E_NOINTERFACE case is merely marked as broken for the sake of Vista.

March 22, 2011