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

Re: today's git failed to build for me

by Austin English

On Wed, Mar 30, 2011 at 01:16, Susan Cragin <susancragin(a)earthlink.net> wrote: > I just downloaded today's git and tried to build it. The following are the make errors in the terminal output. Below that, separated by a line, are the installation errors. > > make[1]: Entering directory `/home/susan/wine/dlls/winejack.drv' > gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o audio.o audio.c > audio.c: In function ‘JACK_DriverProc’: > audio.c:2419:50: error: ‘RTLD_NOW’ undeclared (first use in this function) > audio.c:2419:50: note: each undeclared identifier is reported only once for each function it appears in > audio.c:2443:5: warning: implicit declaration of function ‘MessageBoxA’ > audio.c:2443:78: error: ‘MB_OK’ undeclared (first use in this function) > make[1]: *** [audio.o] Error 1 > make[1]: Leaving directory `/home/susan/wine/dlls/winejack.drv' > make: *** [dlls/winejack.drv] Error 2 > > ------------------------------------------ > > make[1]: Entering directory `/home/susan/wine/dlls/winejack.drv' > gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o audio.o audio.c > audio.c: In function ‘JACK_DriverProc’: > audio.c:2419:50: error: ‘RTLD_NOW’ undeclared (first use in this function) > audio.c:2419:50: note: each undeclared identifier is reported only once for each function it appears in > audio.c:2443:5: warning: implicit declaration of function ‘MessageBoxA’ > audio.c:2443:78: error: ‘MB_OK’ undeclared (first use in this function) > make[1]: *** [audio.o] Error 1 > make[1]: Leaving directory `/home/susan/wine/dlls/winejack.drv' > make: *** [install] Error 2 Use http://www.winehq.org/pipermail/wine-patches/2011-March/100389.html or run configure --without-jack. -- -Austin

March 29, 2011

today's git failed to build for me

by Susan Cragin

I just downloaded today's git and tried to build it. The following are the make errors in the terminal output. Below that, separated by a line, are the installation errors. make[1]: Entering directory `/home/susan/wine/dlls/winejack.drv' gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o audio.o audio.c audio.c: In function ‘JACK_DriverProc’: audio.c:2419:50: error: ‘RTLD_NOW’ undeclared (first use in this function) audio.c:2419:50: note: each undeclared identifier is reported only once for each function it appears in audio.c:2443:5: warning: implicit declaration of function ‘MessageBoxA’ audio.c:2443:78: error: ‘MB_OK’ undeclared (first use in this function) make[1]: *** [audio.o] Error 1 make[1]: Leaving directory `/home/susan/wine/dlls/winejack.drv' make: *** [dlls/winejack.drv] Error 2 ------------------------------------------ make[1]: Entering directory `/home/susan/wine/dlls/winejack.drv' gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o audio.o audio.c audio.c: In function ‘JACK_DriverProc’: audio.c:2419:50: error: ‘RTLD_NOW’ undeclared (first use in this function) audio.c:2419:50: note: each undeclared identifier is reported only once for each function it appears in audio.c:2443:5: warning: implicit declaration of function ‘MessageBoxA’ audio.c:2443:78: error: ‘MB_OK’ undeclared (first use in this function) make[1]: *** [audio.o] Error 1 make[1]: Leaving directory `/home/susan/wine/dlls/winejack.drv' make: *** [install] Error 2

March 29, 2011

Re: [PATCH 6/6] d3dx9: Use init function for ID3DXBuffer.

by David Adam

You mix S_OK with D3D_OK. Though they are equivalent, I think it would be better to keep the only D3D_OK notation. A+ David 2011/3/29 Rico Schüller <kgbricola(a)web.de> > --- > dlls/d3dx9_36/core.c | 36 +++++++++++++++++++++++++++--------- > 1 files changed, 27 insertions(+), 9 deletions(-) > > > > > >

March 29, 2011

Re: [PATCH] kernel32: Populate HKLM\HARDWARE\DEVICEMAP\Scsi on Mac OS.

by Charles Davis

On 3/29/11 4:34 AM, Alexandre Julliard wrote: > Charles Davis <cdavis(a)mymail.mines.edu> writes: > >> From: Charles Davis <cdavis(a)mines.edu> >> >> --- >> dlls/kernel32/Makefile.in | 2 +- >> dlls/kernel32/oldconfig.c | 157 +++++++++++++++++++++++++++++++++++++++++++- >> 2 files changed, 154 insertions(+), 5 deletions(-) > > This code needs to be moved to the mountmgr first. OK. How do you propose to do that? The way this is done on Linux, it's probably fine to just build up/tear down an entry for each device that HAL/udev detects, but DiskArbitration only handles disks (and not other types of SCSI devices) on Mac. Chip

March 29, 2011

[RFC] dinput: Length can actually be 0.

by Vincent Pelletier

(Sorry for sending to wine-patches initially, it was intended for wnie-devel.) This fixes force feedback devices slamming for 10ms at full strength, as attack is an absolute value, not a factor of effect level. Daniel Remenak told me that 0-length envelopes (attack and/or fade, not sure which combination) cause the effect to be not played (possibly played with 0- level) on devices using the Linux iforce driver. This is the reason of the comment in the code. But to other drivers, such as hid-ff, this code causes the device to jump as full strength, which was reported (to me directly) for example when playing "Live for Speed"[1] with a steering wheel having strong force feedback (Logitech G27). My question: Is it acceptable to risk some regression for iforce driver (until bug is identified) to fix other devices ? I guess iforce devices also suffer from the too-strong attack/fade effect. [1] http://www.lfs.net (demo available, I didn't try it) --- dlls/dinput/effect_linuxinput.c | 11 +++++------ 1 files changed, 5 insertions(+), 6 deletions(-) diff --git a/dlls/dinput/effect_linuxinput.c b/dlls/dinput/effect_linuxinput.c index fbc5994..0154f49 100644 --- a/dlls/dinput/effect_linuxinput.c +++ b/dlls/dinput/effect_linuxinput.c @@ -606,13 +606,12 @@ static HRESULT WINAPI LinuxInputEffectImpl_SetParameters( else env = NULL; if (peff->lpEnvelope == NULL) { - /* if this type had an envelope, reset it - * note that length can never be zero, so we set it to something minuscule */ + /* if this type had an envelope, reset it */ if (env) { - env->attack_length = 0x10; - env->attack_level = 0x7FFF; - env->fade_length = 0x10; - env->fade_level = 0x7FFF; + env->attack_length = 0; + env->attack_level = 0; + env->fade_length = 0; + env->fade_level = 0; } } else { /* did we get passed an envelope for a type that doesn't even have one? */ -- 1.7.4.1

March 29, 2011

Re: [2/3] winex11.drv: Don't modify current state if glXMakeCurrent fails.

by Roderick Colenbrander

The first part of the patch was fine, the only concern is the error code. Since there is no WGL standard, the error codes thrown by different drivers can be inconsistent :( I'm not sure if it is better to set an error code at all or not. I'm not sure what I would prefer... Roderick On Tue, Mar 29, 2011 at 5:55 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > 2011/3/29 Roderick Colenbrander <thunderbird2k(a)gmail.com>: >> I'm not sure if the only value error wglMakeCurrent should return is >> INVALID_HANDLE. What if glXMakeCurrent fails because of an invalid >> context? The return value may be similar, but don't remember for sure. >> >> Roderick > > Practically speaking it seems to be very dependent on the specific GL > driver used. For example, current Nvidia Windows drivers just accept a > wglMakeCurrent call with a destroyed context (no errors at all), while > I think AMD drivers crash in the same case. I'm not sure I > specifically tested that on glX too, but in general, failing on a > destroyed drawable was the only consistent "edge case" behavior I > found. > >> >> On Tue, Mar 29, 2011 at 7:42 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >>> >>> >>> >>> >>> >> >

March 29, 2011

Re: [3/3] winex11.drv: Make wglMakeCurrent return the correct error when the drawable is invalid.

by Roderick Colenbrander

On Tue, Mar 29, 2011 at 5:58 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > 2011/3/29 Roderick Colenbrander <thunderbird2k(a)gmail.com>: >> The fact that a pixel format is not set on the physDev doesn't >> necessarily mean it is invalid, it just means SetPixelFormat wasn't >> called on it. Though slightly earlier in wglMakeCurrent we already >> catch that situation when compare the pixel format of the context and >> the hdc. > > True, but as you say the check I'm adding doesn't really change the > behavior outside of a different SetLastError() call. Maybe the WARN > message I'm adding could be improved. > >> >> Is there not something better for which we could check? Is the >> drawable of the physDev perhaps something to check for? (I have no >> idea in what state the physDev is after a destroy window; should we be >> able to enter x11drv at all? perhaps this should be handled inside the >> gdi32 code, just a thought) >> > > Checking for the drawable or any other field in the physDev doesn't > seem to be really better. I'm not sure about the feasibility of > handling that on the gdi32 side, I think I gave it a try at some point > but then I resorted to this other approach. But, of course, I may be > failing to see a better solution ;) > >> Roderick >> >> On Tue, Mar 29, 2011 at 7:42 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >>> > I would vote for a more correct way of checking whether we are dealing with an invalid drawable. Perhaps Alexandre has a good suggestion. Roderick

March 29, 2011

Re: [3/3] winex11.drv: Make wglMakeCurrent return the correct error when the drawable is invalid.

by Matteo Bruni

2011/3/29 Roderick Colenbrander <thunderbird2k(a)gmail.com>: > The fact that a pixel format is not set on the physDev doesn't > necessarily mean it is invalid, it just means SetPixelFormat wasn't > called on it. Though slightly earlier in wglMakeCurrent we already > catch that situation when compare the pixel format of the context and > the hdc. True, but as you say the check I'm adding doesn't really change the behavior outside of a different SetLastError() call. Maybe the WARN message I'm adding could be improved. > > Is there not something better for which we could check? Is the > drawable of the physDev perhaps something to check for? (I have no > idea in what state the physDev is after a destroy window; should we be > able to enter x11drv at all? perhaps this should be handled inside the > gdi32 code, just a thought) > Checking for the drawable or any other field in the physDev doesn't seem to be really better. I'm not sure about the feasibility of handling that on the gdi32 side, I think I gave it a try at some point but then I resorted to this other approach. But, of course, I may be failing to see a better solution ;) > Roderick > > On Tue, Mar 29, 2011 at 7:42 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >>

March 29, 2011

Re: [2/3] winex11.drv: Don't modify current state if glXMakeCurrent fails.

by Matteo Bruni

2011/3/29 Roderick Colenbrander <thunderbird2k(a)gmail.com>: > I'm not sure if the only value error wglMakeCurrent should return is > INVALID_HANDLE. What if glXMakeCurrent fails because of an invalid > context? The return value may be similar, but don't remember for sure. > > Roderick Practically speaking it seems to be very dependent on the specific GL driver used. For example, current Nvidia Windows drivers just accept a wglMakeCurrent call with a destroyed context (no errors at all), while I think AMD drivers crash in the same case. I'm not sure I specifically tested that on glX too, but in general, failing on a destroyed drawable was the only consistent "edge case" behavior I found. > > On Tue, Mar 29, 2011 at 7:42 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >> >> >> >> >> >

March 29, 2011

Re: [3/3] winex11.drv: Make wglMakeCurrent return the correct error when the drawable is invalid.

by Roderick Colenbrander

The fact that a pixel format is not set on the physDev doesn't necessarily mean it is invalid, it just means SetPixelFormat wasn't called on it. Though slightly earlier in wglMakeCurrent we already catch that situation when compare the pixel format of the context and the hdc. Is there not something better for which we could check? Is the drawable of the physDev perhaps something to check for? (I have no idea in what state the physDev is after a destroy window; should we be able to enter x11drv at all? perhaps this should be handled inside the gdi32 code, just a thought) Roderick On Tue, Mar 29, 2011 at 7:42 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > > > > >

March 29, 2011

Re: [2/3] winex11.drv: Don't modify current state if glXMakeCurrent fails.

by Roderick Colenbrander

I'm not sure if the only value error wglMakeCurrent should return is INVALID_HANDLE. What if glXMakeCurrent fails because of an invalid context? The return value may be similar, but don't remember for sure. Roderick On Tue, Mar 29, 2011 at 7:42 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > > > > >

March 29, 2011

Re: wldap32: Accept a NULL value in ldap_set_option.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=10187 Your paranoid android. === WNT4WSSP6 (32 bit parse) === parse.c:120: Test failed: ldap_set_optionW failed 0x00000059 === W2KPROSP4 (32 bit parse) === parse.c:120: Test failed: ldap_set_optionW failed 0x00000059

March 29, 2011

Re: mshtml: Fixed node leak in HTMLEventObj

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/mshtml/htmlevent.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) This causes the mshtml:events test to hang for me. -- Alexandre Julliard julliard(a)winehq.org

March 29, 2011

Re: [PATCH] kernel32: Populate HKLM\HARDWARE\DEVICEMAP\Scsi on Mac OS.

by Alexandre Julliard

Charles Davis <cdavis(a)mymail.mines.edu> writes: > From: Charles Davis <cdavis(a)mines.edu> > > --- > dlls/kernel32/Makefile.in | 2 +- > dlls/kernel32/oldconfig.c | 157 +++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 154 insertions(+), 5 deletions(-) This code needs to be moved to the mountmgr first. -- Alexandre Julliard julliard(a)winehq.org

March 29, 2011

Re: [PATCH 3/4] comdlg32: Add implementation of DllRegisterServer/DllUnregisterServer. (resend)

by Alexandre Julliard

David Hedberg <david.hedberg(a)gmail.com> writes: > @@ -274,3 +277,82 @@ HRESULT WINAPI DllGetClassObject(REFCLSID rclsid, REFIID riid, void **ppv) > > return CLASS_E_CLASSNOTAVAILABLE; > } > + > +/*********************************************************************** > + * Register/Unregister DLL, based on shdocvw/factory.c > + */ You should use the new IRegistrar mechanism instead. -- Alexandre Julliard julliard(a)winehq.org

March 29, 2011

Re: RFC: Remove unimplemented application menus?

by James McKenzie

On 3/28/11 7:23 PM, Austin English wrote: > On Tue, Mar 29, 2011 at 03:20, James McKenzie<jjmckenzie51(a)gmail.com> wrote: >> On 3/28/11 7:19 PM, Austin English wrote: >>> On Tue, Mar 29, 2011 at 03:17, James McKenzie<jjmckenzie51(a)gmail.com> >>> wrote: >>>> On 3/28/11 7:15 PM, Austin English wrote: >>>>> 2011/3/29 James McKenzie<jjmckenzie51(a)gmail.com>: >>>>>> On 3/28/11 9:28 AM, André Hentschel wrote: >>>>>>> Am 28.03.2011 17:27, schrieb James McKenzie: >>>>>>>> 2011/3/27 André Hentschel<nerv(a)dawncrow.de>: >>>>>>>>> Am 27.03.2011 13:50, schrieb Francois Gouget: >>>>>>>>>> Some Wine programs, winefile in particular, have a lot of >>>>>>>>>> unimplemented >>>>>>>>>> menus. That is you can see the menu entry but clicking on it only >>>>>>>>>> gives >>>>>>>>>> you a 'Not yet implemented' error dialog (or does nothing in the >>>>>>>>>> case >>>>>>>>>> of iexplore). For instance just for the first two winefile menus >>>>>>>>>> none >>>>>>>>>> of the following are implemented: >>>>>>>>>> >>>>>>>>>> File -> Print... >>>>>>>>>> File -> Associate... >>>>>>>>>> File -> Search... >>>>>>>>>> File -> Select Files... >>>>>>>>>> Disk -> Share as... >>>>>>>>>> Disk -> Remove Share... >>>>>>>>>> Disk -> Select Drive... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think such a situation is bad: >>>>>>>>>> * Having tons of unimplemented menus looks amateurish. >>>>>>>>>> * It's very confusing. You see tons of menus except over 50% of >>>>>>>>>> them >>>>>>>>>> don't work. So it makes the GUI more complex with no benefit. >>>>>>>>>> * I suspect most of these menus have been unimplemented for years >>>>>>>>>> so there is little hope of seeing them improve any time soon. >>>>>>>>>> * For a number of them it's questionable whether it makes sense to >>>>>>>>>> implement them in Wine at all as they correspond to tasks that >>>>>>>>>> better belong to the native system facilities (Share as for >>>>>>>>>> instance). >>>>>>>>>> * I doubt they serve any significant compatibility purpose. >>>>>>>>>> * In the mean time they generate more work for translators and >>>>>>>>>> translation reviewers. >>>>>>>>>> * It generates more work for anyone checking whether the GUI is >>>>>>>>>> consistent / follows human interface guidelines (wrt. ellipses >>>>>>>>>> for >>>>>>>>>> instance). >>>>>>>>>> >>>>>>>>>> So I propose to simply remove unimplemented menus. When / if >>>>>>>>>> someone >>>>>>>>>> ever decides to implement some of the corresponding functionality, >>>>>>>>>> adding the corresponding code and GUI bits back should not be too >>>>>>>>>> hard. >>>>>>>>>> >>>>>>>>>> Objections? >>>>>>>>>> >>>>>>>>> Good Idea, at least for the year old stub menus (like winefile). >>>>>>>>> For recently added, with hope to see them implemented in the next >>>>>>>>> time >>>>>>>>> (maybe gsoc), we should wait some month (e.g. iexplore) IMO. >>>>>>>>> >>>>>>>> I agree. This was proposed as a GOSC project by one of the people. >>>>>>>> There is a thread on Wine Users about these menus being >>>>>>>> 'unimplemented' and how they should be. Would this be a good item >>>>>>>> for >>>>>>>> a bug report for an Request for Enhancement? >>>>>>> IMHO no, there is no point i think. >>>>>>> PS: is this meant to be also sent to wine-devel? >>>>>>> >>>>>>> >>>>>> Are these features the program should possess or not? These tend to be >>>>>> 'standard' menu items for most Windows programs and the underlying code >>>>>> does >>>>>> lie in Windows, not the individual programs and has since the Windows >>>>>> 3.x >>>>>> days. >>>>> Theoretically they should be there, yes, but it's not really worth the >>>>> effort. >>>>> >>>> At least we could implement some sort of stub to popup a dialog to say >>>> the >>>> function is not implemented in Wine? Does Excel have a Open... and >>>> Save... >>>> menu item (these are also implemented in Windows or is it the program?) >>> Yes, Excel has the dialog, along with most other programs. Winefile >>> itself does not have it implemented. If you want to take the time to >>> stub out the dialogs, be my guest, but few people use winefile as is, >>> and fewer use the full dialogs (I bet most that notice it is broken >>> are just curious if it does work). The effort spent stubbing it would >>> be better spent fixing bugs that break actual applications. >>> >> Austin: >> >> However, this just might be something that AJ will approve. > Sure, that's his call, but I don't see the point in discussing it > without someone volunteering to write the code. > > It's a moot point, I don't use winefile, and I'd rather see it cleaned > up than have tons of stubs that make it look incomplete. However, I'm > not going to take the time to fix it, and am happy to see Francois do > so. Either way is fine with me, and it's not my decision. > > That's all I've got to say here, back to bugzilla for me. > I agree with this statement. Cleaning up poorly written code is always a noble task. James McKenzie

March 28, 2011

Re: RFC: Remove unimplemented application menus?

by Austin English

On Tue, Mar 29, 2011 at 03:20, James McKenzie <jjmckenzie51(a)gmail.com> wrote: > On 3/28/11 7:19 PM, Austin English wrote: >> >> On Tue, Mar 29, 2011 at 03:17, James McKenzie<jjmckenzie51(a)gmail.com> >> wrote: >>> >>> On 3/28/11 7:15 PM, Austin English wrote: >>>> >>>> 2011/3/29 James McKenzie<jjmckenzie51(a)gmail.com>: >>>>> >>>>> On 3/28/11 9:28 AM, André Hentschel wrote: >>>>>> >>>>>> Am 28.03.2011 17:27, schrieb James McKenzie: >>>>>>> >>>>>>> 2011/3/27 André Hentschel<nerv(a)dawncrow.de>: >>>>>>>> >>>>>>>> Am 27.03.2011 13:50, schrieb Francois Gouget: >>>>>>>>> >>>>>>>>> Some Wine programs, winefile in particular, have a lot of >>>>>>>>> unimplemented >>>>>>>>> menus. That is you can see the menu entry but clicking on it only >>>>>>>>> gives >>>>>>>>> you a 'Not yet implemented' error dialog (or does nothing in the >>>>>>>>> case >>>>>>>>> of iexplore). For instance just for the first two winefile menus >>>>>>>>> none >>>>>>>>> of the following are implemented: >>>>>>>>> >>>>>>>>> File -> Print... >>>>>>>>> File -> Associate... >>>>>>>>> File -> Search... >>>>>>>>> File -> Select Files... >>>>>>>>> Disk -> Share as... >>>>>>>>> Disk -> Remove Share... >>>>>>>>> Disk -> Select Drive... >>>>>>>>> >>>>>>>>> >>>>>>>>> I think such a situation is bad: >>>>>>>>> * Having tons of unimplemented menus looks amateurish. >>>>>>>>> * It's very confusing. You see tons of menus except over 50% of >>>>>>>>> them >>>>>>>>> don't work. So it makes the GUI more complex with no benefit. >>>>>>>>> * I suspect most of these menus have been unimplemented for years >>>>>>>>> so there is little hope of seeing them improve any time soon. >>>>>>>>> * For a number of them it's questionable whether it makes sense to >>>>>>>>> implement them in Wine at all as they correspond to tasks that >>>>>>>>> better belong to the native system facilities (Share as for >>>>>>>>> instance). >>>>>>>>> * I doubt they serve any significant compatibility purpose. >>>>>>>>> * In the mean time they generate more work for translators and >>>>>>>>> translation reviewers. >>>>>>>>> * It generates more work for anyone checking whether the GUI is >>>>>>>>> consistent / follows human interface guidelines (wrt. ellipses >>>>>>>>> for >>>>>>>>> instance). >>>>>>>>> >>>>>>>>> So I propose to simply remove unimplemented menus. When / if >>>>>>>>> someone >>>>>>>>> ever decides to implement some of the corresponding functionality, >>>>>>>>> adding the corresponding code and GUI bits back should not be too >>>>>>>>> hard. >>>>>>>>> >>>>>>>>> Objections? >>>>>>>>> >>>>>>>> Good Idea, at least for the year old stub menus (like winefile). >>>>>>>> For recently added, with hope to see them implemented in the next >>>>>>>> time >>>>>>>> (maybe gsoc), we should wait some month (e.g. iexplore) IMO. >>>>>>>> >>>>>>> I agree. This was proposed as a GOSC project by one of the people. >>>>>>> There is a thread on Wine Users about these menus being >>>>>>> 'unimplemented' and how they should be. Would this be a good item >>>>>>> for >>>>>>> a bug report for an Request for Enhancement? >>>>>> >>>>>> IMHO no, there is no point i think. >>>>>> PS: is this meant to be also sent to wine-devel? >>>>>> >>>>>> >>>>> Are these features the program should possess or not? These tend to be >>>>> 'standard' menu items for most Windows programs and the underlying code >>>>> does >>>>> lie in Windows, not the individual programs and has since the Windows >>>>> 3.x >>>>> days. >>>> >>>> Theoretically they should be there, yes, but it's not really worth the >>>> effort. >>>> >>> At least we could implement some sort of stub to popup a dialog to say >>> the >>> function is not implemented in Wine? Does Excel have a Open... and >>> Save... >>> menu item (these are also implemented in Windows or is it the program?) >> >> Yes, Excel has the dialog, along with most other programs. Winefile >> itself does not have it implemented. If you want to take the time to >> stub out the dialogs, be my guest, but few people use winefile as is, >> and fewer use the full dialogs (I bet most that notice it is broken >> are just curious if it does work). The effort spent stubbing it would >> be better spent fixing bugs that break actual applications. >> > Austin: > > However, this just might be something that AJ will approve. Sure, that's his call, but I don't see the point in discussing it without someone volunteering to write the code. It's a moot point, I don't use winefile, and I'd rather see it cleaned up than have tons of stubs that make it look incomplete. However, I'm not going to take the time to fix it, and am happy to see Francois do so. Either way is fine with me, and it's not my decision. That's all I've got to say here, back to bugzilla for me. -- -Austin

March 28, 2011

Re: RFC: Remove unimplemented application menus?

by James McKenzie

On 3/28/11 7:19 PM, Austin English wrote: > On Tue, Mar 29, 2011 at 03:17, James McKenzie<jjmckenzie51(a)gmail.com> wrote: >> On 3/28/11 7:15 PM, Austin English wrote: >>> 2011/3/29 James McKenzie<jjmckenzie51(a)gmail.com>: >>>> On 3/28/11 9:28 AM, André Hentschel wrote: >>>>> Am 28.03.2011 17:27, schrieb James McKenzie: >>>>>> 2011/3/27 André Hentschel<nerv(a)dawncrow.de>: >>>>>>> Am 27.03.2011 13:50, schrieb Francois Gouget: >>>>>>>> Some Wine programs, winefile in particular, have a lot of >>>>>>>> unimplemented >>>>>>>> menus. That is you can see the menu entry but clicking on it only >>>>>>>> gives >>>>>>>> you a 'Not yet implemented' error dialog (or does nothing in the case >>>>>>>> of iexplore). For instance just for the first two winefile menus none >>>>>>>> of the following are implemented: >>>>>>>> >>>>>>>> File -> Print... >>>>>>>> File -> Associate... >>>>>>>> File -> Search... >>>>>>>> File -> Select Files... >>>>>>>> Disk -> Share as... >>>>>>>> Disk -> Remove Share... >>>>>>>> Disk -> Select Drive... >>>>>>>> >>>>>>>> >>>>>>>> I think such a situation is bad: >>>>>>>> * Having tons of unimplemented menus looks amateurish. >>>>>>>> * It's very confusing. You see tons of menus except over 50% of them >>>>>>>> don't work. So it makes the GUI more complex with no benefit. >>>>>>>> * I suspect most of these menus have been unimplemented for years >>>>>>>> so there is little hope of seeing them improve any time soon. >>>>>>>> * For a number of them it's questionable whether it makes sense to >>>>>>>> implement them in Wine at all as they correspond to tasks that >>>>>>>> better belong to the native system facilities (Share as for >>>>>>>> instance). >>>>>>>> * I doubt they serve any significant compatibility purpose. >>>>>>>> * In the mean time they generate more work for translators and >>>>>>>> translation reviewers. >>>>>>>> * It generates more work for anyone checking whether the GUI is >>>>>>>> consistent / follows human interface guidelines (wrt. ellipses for >>>>>>>> instance). >>>>>>>> >>>>>>>> So I propose to simply remove unimplemented menus. When / if someone >>>>>>>> ever decides to implement some of the corresponding functionality, >>>>>>>> adding the corresponding code and GUI bits back should not be too >>>>>>>> hard. >>>>>>>> >>>>>>>> Objections? >>>>>>>> >>>>>>> Good Idea, at least for the year old stub menus (like winefile). >>>>>>> For recently added, with hope to see them implemented in the next time >>>>>>> (maybe gsoc), we should wait some month (e.g. iexplore) IMO. >>>>>>> >>>>>> I agree. This was proposed as a GOSC project by one of the people. >>>>>> There is a thread on Wine Users about these menus being >>>>>> 'unimplemented' and how they should be. Would this be a good item for >>>>>> a bug report for an Request for Enhancement? >>>>> IMHO no, there is no point i think. >>>>> PS: is this meant to be also sent to wine-devel? >>>>> >>>>> >>>> Are these features the program should possess or not? These tend to be >>>> 'standard' menu items for most Windows programs and the underlying code >>>> does >>>> lie in Windows, not the individual programs and has since the Windows 3.x >>>> days. >>> Theoretically they should be there, yes, but it's not really worth the >>> effort. >>> >> At least we could implement some sort of stub to popup a dialog to say the >> function is not implemented in Wine? Does Excel have a Open... and Save... >> menu item (these are also implemented in Windows or is it the program?) > Yes, Excel has the dialog, along with most other programs. Winefile > itself does not have it implemented. If you want to take the time to > stub out the dialogs, be my guest, but few people use winefile as is, > and fewer use the full dialogs (I bet most that notice it is broken > are just curious if it does work). The effort spent stubbing it would > be better spent fixing bugs that break actual applications. > Austin: However, this just might be something that AJ will approve. James McKenzie

March 28, 2011

Re: RFC: Remove unimplemented application menus?

by Austin English

On Tue, Mar 29, 2011 at 03:17, James McKenzie <jjmckenzie51(a)gmail.com> wrote: > On 3/28/11 7:15 PM, Austin English wrote: >> >> 2011/3/29 James McKenzie<jjmckenzie51(a)gmail.com>: >>> >>> On 3/28/11 9:28 AM, André Hentschel wrote: >>>> >>>> Am 28.03.2011 17:27, schrieb James McKenzie: >>>>> >>>>> 2011/3/27 André Hentschel<nerv(a)dawncrow.de>: >>>>>> >>>>>> Am 27.03.2011 13:50, schrieb Francois Gouget: >>>>>>> >>>>>>> Some Wine programs, winefile in particular, have a lot of >>>>>>> unimplemented >>>>>>> menus. That is you can see the menu entry but clicking on it only >>>>>>> gives >>>>>>> you a 'Not yet implemented' error dialog (or does nothing in the case >>>>>>> of iexplore). For instance just for the first two winefile menus none >>>>>>> of the following are implemented: >>>>>>> >>>>>>> File -> Print... >>>>>>> File -> Associate... >>>>>>> File -> Search... >>>>>>> File -> Select Files... >>>>>>> Disk -> Share as... >>>>>>> Disk -> Remove Share... >>>>>>> Disk -> Select Drive... >>>>>>> >>>>>>> >>>>>>> I think such a situation is bad: >>>>>>> * Having tons of unimplemented menus looks amateurish. >>>>>>> * It's very confusing. You see tons of menus except over 50% of them >>>>>>> don't work. So it makes the GUI more complex with no benefit. >>>>>>> * I suspect most of these menus have been unimplemented for years >>>>>>> so there is little hope of seeing them improve any time soon. >>>>>>> * For a number of them it's questionable whether it makes sense to >>>>>>> implement them in Wine at all as they correspond to tasks that >>>>>>> better belong to the native system facilities (Share as for >>>>>>> instance). >>>>>>> * I doubt they serve any significant compatibility purpose. >>>>>>> * In the mean time they generate more work for translators and >>>>>>> translation reviewers. >>>>>>> * It generates more work for anyone checking whether the GUI is >>>>>>> consistent / follows human interface guidelines (wrt. ellipses for >>>>>>> instance). >>>>>>> >>>>>>> So I propose to simply remove unimplemented menus. When / if someone >>>>>>> ever decides to implement some of the corresponding functionality, >>>>>>> adding the corresponding code and GUI bits back should not be too >>>>>>> hard. >>>>>>> >>>>>>> Objections? >>>>>>> >>>>>> Good Idea, at least for the year old stub menus (like winefile). >>>>>> For recently added, with hope to see them implemented in the next time >>>>>> (maybe gsoc), we should wait some month (e.g. iexplore) IMO. >>>>>> >>>>> I agree. This was proposed as a GOSC project by one of the people. >>>>> There is a thread on Wine Users about these menus being >>>>> 'unimplemented' and how they should be. Would this be a good item for >>>>> a bug report for an Request for Enhancement? >>>> >>>> IMHO no, there is no point i think. >>>> PS: is this meant to be also sent to wine-devel? >>>> >>>> >>> Are these features the program should possess or not? These tend to be >>> 'standard' menu items for most Windows programs and the underlying code >>> does >>> lie in Windows, not the individual programs and has since the Windows 3.x >>> days. >> >> Theoretically they should be there, yes, but it's not really worth the >> effort. >> > At least we could implement some sort of stub to popup a dialog to say the > function is not implemented in Wine? Does Excel have a Open... and Save... > menu item (these are also implemented in Windows or is it the program?) Yes, Excel has the dialog, along with most other programs. Winefile itself does not have it implemented. If you want to take the time to stub out the dialogs, be my guest, but few people use winefile as is, and fewer use the full dialogs (I bet most that notice it is broken are just curious if it does work). The effort spent stubbing it would be better spent fixing bugs that break actual applications. -- -Austin

March 28, 2011

Re: RFC: Remove unimplemented application menus?

by James McKenzie

On 3/28/11 7:15 PM, Austin English wrote: > 2011/3/29 James McKenzie<jjmckenzie51(a)gmail.com>: >> On 3/28/11 9:28 AM, André Hentschel wrote: >>> Am 28.03.2011 17:27, schrieb James McKenzie: >>>> 2011/3/27 André Hentschel<nerv(a)dawncrow.de>: >>>>> Am 27.03.2011 13:50, schrieb Francois Gouget: >>>>>> Some Wine programs, winefile in particular, have a lot of unimplemented >>>>>> menus. That is you can see the menu entry but clicking on it only gives >>>>>> you a 'Not yet implemented' error dialog (or does nothing in the case >>>>>> of iexplore). For instance just for the first two winefile menus none >>>>>> of the following are implemented: >>>>>> >>>>>> File -> Print... >>>>>> File -> Associate... >>>>>> File -> Search... >>>>>> File -> Select Files... >>>>>> Disk -> Share as... >>>>>> Disk -> Remove Share... >>>>>> Disk -> Select Drive... >>>>>> >>>>>> >>>>>> I think such a situation is bad: >>>>>> * Having tons of unimplemented menus looks amateurish. >>>>>> * It's very confusing. You see tons of menus except over 50% of them >>>>>> don't work. So it makes the GUI more complex with no benefit. >>>>>> * I suspect most of these menus have been unimplemented for years >>>>>> so there is little hope of seeing them improve any time soon. >>>>>> * For a number of them it's questionable whether it makes sense to >>>>>> implement them in Wine at all as they correspond to tasks that >>>>>> better belong to the native system facilities (Share as for >>>>>> instance). >>>>>> * I doubt they serve any significant compatibility purpose. >>>>>> * In the mean time they generate more work for translators and >>>>>> translation reviewers. >>>>>> * It generates more work for anyone checking whether the GUI is >>>>>> consistent / follows human interface guidelines (wrt. ellipses for >>>>>> instance). >>>>>> >>>>>> So I propose to simply remove unimplemented menus. When / if someone >>>>>> ever decides to implement some of the corresponding functionality, >>>>>> adding the corresponding code and GUI bits back should not be too hard. >>>>>> >>>>>> Objections? >>>>>> >>>>> Good Idea, at least for the year old stub menus (like winefile). >>>>> For recently added, with hope to see them implemented in the next time >>>>> (maybe gsoc), we should wait some month (e.g. iexplore) IMO. >>>>> >>>> I agree. This was proposed as a GOSC project by one of the people. >>>> There is a thread on Wine Users about these menus being >>>> 'unimplemented' and how they should be. Would this be a good item for >>>> a bug report for an Request for Enhancement? >>> IMHO no, there is no point i think. >>> PS: is this meant to be also sent to wine-devel? >>> >>> >> Are these features the program should possess or not? These tend to be >> 'standard' menu items for most Windows programs and the underlying code does >> lie in Windows, not the individual programs and has since the Windows 3.x >> days. > Theoretically they should be there, yes, but it's not really worth the effort. > At least we could implement some sort of stub to popup a dialog to say the function is not implemented in Wine? Does Excel have a Open... and Save... menu item (these are also implemented in Windows or is it the program?) James McKenzie

March 28, 2011

Re: RFC: Remove unimplemented application menus?

by Austin English

2011/3/29 James McKenzie <jjmckenzie51(a)gmail.com>: > On 3/28/11 9:28 AM, André Hentschel wrote: >> >> Am 28.03.2011 17:27, schrieb James McKenzie: >>> >>> 2011/3/27 André Hentschel<nerv(a)dawncrow.de>: >>>> >>>> Am 27.03.2011 13:50, schrieb Francois Gouget: >>>>> >>>>> Some Wine programs, winefile in particular, have a lot of unimplemented >>>>> menus. That is you can see the menu entry but clicking on it only gives >>>>> you a 'Not yet implemented' error dialog (or does nothing in the case >>>>> of iexplore). For instance just for the first two winefile menus none >>>>> of the following are implemented: >>>>> >>>>> File -> Print... >>>>> File -> Associate... >>>>> File -> Search... >>>>> File -> Select Files... >>>>> Disk -> Share as... >>>>> Disk -> Remove Share... >>>>> Disk -> Select Drive... >>>>> >>>>> >>>>> I think such a situation is bad: >>>>> * Having tons of unimplemented menus looks amateurish. >>>>> * It's very confusing. You see tons of menus except over 50% of them >>>>> don't work. So it makes the GUI more complex with no benefit. >>>>> * I suspect most of these menus have been unimplemented for years >>>>> so there is little hope of seeing them improve any time soon. >>>>> * For a number of them it's questionable whether it makes sense to >>>>> implement them in Wine at all as they correspond to tasks that >>>>> better belong to the native system facilities (Share as for >>>>> instance). >>>>> * I doubt they serve any significant compatibility purpose. >>>>> * In the mean time they generate more work for translators and >>>>> translation reviewers. >>>>> * It generates more work for anyone checking whether the GUI is >>>>> consistent / follows human interface guidelines (wrt. ellipses for >>>>> instance). >>>>> >>>>> So I propose to simply remove unimplemented menus. When / if someone >>>>> ever decides to implement some of the corresponding functionality, >>>>> adding the corresponding code and GUI bits back should not be too hard. >>>>> >>>>> Objections? >>>>> >>>> Good Idea, at least for the year old stub menus (like winefile). >>>> For recently added, with hope to see them implemented in the next time >>>> (maybe gsoc), we should wait some month (e.g. iexplore) IMO. >>>> >>> I agree. This was proposed as a GOSC project by one of the people. >>> There is a thread on Wine Users about these menus being >>> 'unimplemented' and how they should be. Would this be a good item for >>> a bug report for an Request for Enhancement? >> >> IMHO no, there is no point i think. >> PS: is this meant to be also sent to wine-devel? >> >> > Are these features the program should possess or not? These tend to be > 'standard' menu items for most Windows programs and the underlying code does > lie in Windows, not the individual programs and has since the Windows 3.x > days. Theoretically they should be there, yes, but it's not really worth the effort. -- -Austin

March 28, 2011

Re: RFC: Remove unimplemented application menus?

by James McKenzie

On 3/28/11 9:28 AM, André Hentschel wrote: > Am 28.03.2011 17:27, schrieb James McKenzie: >> 2011/3/27 André Hentschel<nerv(a)dawncrow.de>: >>> Am 27.03.2011 13:50, schrieb Francois Gouget: >>>> Some Wine programs, winefile in particular, have a lot of unimplemented >>>> menus. That is you can see the menu entry but clicking on it only gives >>>> you a 'Not yet implemented' error dialog (or does nothing in the case >>>> of iexplore). For instance just for the first two winefile menus none >>>> of the following are implemented: >>>> >>>> File -> Print... >>>> File -> Associate... >>>> File -> Search... >>>> File -> Select Files... >>>> Disk -> Share as... >>>> Disk -> Remove Share... >>>> Disk -> Select Drive... >>>> >>>> >>>> I think such a situation is bad: >>>> * Having tons of unimplemented menus looks amateurish. >>>> * It's very confusing. You see tons of menus except over 50% of them >>>> don't work. So it makes the GUI more complex with no benefit. >>>> * I suspect most of these menus have been unimplemented for years >>>> so there is little hope of seeing them improve any time soon. >>>> * For a number of them it's questionable whether it makes sense to >>>> implement them in Wine at all as they correspond to tasks that >>>> better belong to the native system facilities (Share as for >>>> instance). >>>> * I doubt they serve any significant compatibility purpose. >>>> * In the mean time they generate more work for translators and >>>> translation reviewers. >>>> * It generates more work for anyone checking whether the GUI is >>>> consistent / follows human interface guidelines (wrt. ellipses for >>>> instance). >>>> >>>> So I propose to simply remove unimplemented menus. When / if someone >>>> ever decides to implement some of the corresponding functionality, >>>> adding the corresponding code and GUI bits back should not be too hard. >>>> >>>> Objections? >>>> >>> Good Idea, at least for the year old stub menus (like winefile). >>> For recently added, with hope to see them implemented in the next time (maybe gsoc), we should wait some month (e.g. iexplore) IMO. >>> >> I agree. This was proposed as a GOSC project by one of the people. >> There is a thread on Wine Users about these menus being >> 'unimplemented' and how they should be. Would this be a good item for >> a bug report for an Request for Enhancement? > IMHO no, there is no point i think. > PS: is this meant to be also sent to wine-devel? > > Are these features the program should possess or not? These tend to be 'standard' menu items for most Windows programs and the underlying code does lie in Windows, not the individual programs and has since the Windows 3.x days. Sorry, but I hit the reply button and not reply to all when I responded to you. My apologies. James McKenzie

March 28, 2011

[GSoC] Message mode pipes proposal

by Bryan Donlan

Hi, all, >From the GSoC project ideas page, I became interested in the proposal for implementing message-based pipes (see bug: http://bugs.winehq.org/show_bug.cgi?id=17195) The most recent patches to the bug cited above appear to use a separate socketpair for each message sent down the pipe, and must make potentially multiple wineserver calls for each interaction with the pipe. This will clearly begin to have problems once a large number of file descriptors are in the air. While a discussion on #winehackers suggested that implementing message-based pipes efficiently and safely entirely in userspace would be quite difficult, I feel that implementing a _correct_ implementation (regardless of efficiency) would be a practical goal. After creating a correct implementation, work could then be done to improve performance. First, a bit about me: I am a computer science student at the University of Massachusetts, heading into my senior year. I have had a lot of experience with Linux development, somewhat less on the Windows side. I am fluent in English and Japanese, although I doubt Japanese language experience would be helpful for this project :) In previous summer internships I have developed code for interprocess communication; in one instance, I wrote a ring buffer synchronization protocol to transfer data from a Windows user-space program to a real-time process running in kernel-mode (hosted via a third-party Windows real-time HAL). I propose the following overall plan: * First, I will prepare a comprehensive test suite for message-based pipes. Benchmarks would also be prepared to help determine whether optimization is necessary. This will likely borrow from the tests already posted to the bug I linked above. * I will write a wineserver-internal implementation of message-based pipes. That is, all NtReadFile/NtWriteFile() requests would be completely redirected to wineserver; there would be no attempt to expose a file descriptor for the client process to access directly. Wineserver in turn would simply manage a simple, in-memory queue of messages. Although this is unscalable and has a lot of context switch and copying overhead, it is simple, and would allow programs making light usage of message-based pipes to work. It also provides a clear place to hook on a new, faster protocol that requires a custom NtReadFile/NtWriteFile. After this point, I will begin work on optimizing the implementation. Some ideas on how to do this might include: * Implement the pipe using a ring buffer in shared memory. Client processes can then directly access the pipe buffer to pass data without wineserver's involvement. This has the downside that a user-mode process can inadvertently corrupt the pipe's state; this may be acceptable if the effects can be limited to a trashed pipe buffer, instead of crashing unrelated processes. * Implement the pipe using a ring buffer in shared memory, but expose only a read-only file descriptor to client processes. This avoids the corruption issues, but writes must be managed by the server and will incur overhead. * Implement the pipe as a single server-managed socketpair over which shared memory backing files are passed with SCM_RIGHTS, plus a lock (possibly implemented in shared memory using futexes, or by flock on a /dev/shm file). Clients acquire the lock, then MSG_PEEK the socketpair to retrieve an anonymous (unlinked immediately after creation) shared memory file descriptor. The shared memory buffer holds a count of remaining bytes, plus the actual message data. Clients then perform a normal recvmsg() to dequeue the message if they successfully retrieved the entire message. This approach is complex, and it is unclear what the performance impacts of having so many files being thrown around would be. However, it does avoid the context-switch costs and wineserver load that are a problem in the implementations currently on the bug tracker. * Implement a Linux kernel module to implement message-based pipe semantics natively. Although quite efficient, this will only apply to Linux, and may introduce difficulty keeping up with Linux kernel changes in the future. It is also unclear whether distributions and/or upstream Linux maintainers will welcome this approach. I will likely end up trying out several of these approaches and comparing actual performance results. Finally, if time allows, I will also investigate integration with samba, in order to support connecting to named pipes on remote servers. I would appreciate any comments on this proposal prior to actual submission. Thanks, Bryan Donlan

March 28, 2011

Re: [PATCH 4/6] mshtml/tests: Added IDocObjectService interface

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=10180 Your paranoid android. === WXPPROSP3 (32 bit htmldoc) === TestLauncher.c:89: Test failed: Can't open test executable C:\winetest\mshtml_test.exe, error 32

March 28, 2011

Re: wininet: Port numbers are unsigned (more)

by André Hentschel

Am 28.03.2011 22:37, schrieb Dan McDonald: > On 03/28/2011 01:40 PM, André Hentschel wrote: >> - static const WCHAR percentD[] = {'%','d',0}; >> + static const WCHAR percentD[] = {'%','u',0}; > > Variable name change may be in order here. > > Dan > > true, thx. -- Best Regards, André Hentschel

March 28, 2011