February 2009 - Wine-Devel - list.winehq.org

Re: imm32: Make space for a 64bit pointer in the IMM window.

by Michael Stefaniuc

Aric Stewart wrote: > I am not a 64 bit expert but i do not think this is going to work. > > ddk/imm.h is a Microsoft header so IMEs and programs compiled with the > original header will not have the expanded space. They will as the Microsoft header has the exact same change as I did in this patch. It's not directly in imm.h but in immdev.h; our imm.h header would need to be split for "full compatibility" with the Microsoft DDK headers but that's something for an other patch. bye michael > To fix this properly (I assume you are trying to support 64 bit) is that > we will probibly have to store a handle instead of a pointer in the LONG > value. The IME is expecting a HIMC in that value. > > Which leads to a more general question. What is the suggested way to > generate handles like that? Working toward 64 bit means that everywhere > that we are using pointers as LONG handles is going to have problems. > > -aric > > Michael Stefaniuc wrote: >> --- >> Next try at fixing this problem. I didn't find any other place where >> IMMGWL_IMC is used and the window classes are not my area of expertise. >> >> >> >> dlls/imm32/imm.c | 2 +- >> dlls/winex11.drv/ime.c | 2 +- >> include/ddk/imm.h | 2 +- >> 3 files changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/dlls/imm32/imm.c b/dlls/imm32/imm.c >> index 14178c3..bb50e5e 100644 >> --- a/dlls/imm32/imm.c >> +++ b/dlls/imm32/imm.c >> @@ -2291,7 +2291,7 @@ BOOL WINAPI ImmSetOpenStatus(HIMC hIMC, BOOL fOpen) >> data->imeWnd = CreateWindowExW( WS_EX_TOOLWINDOW, >> data->immKbd->imeClassName, NULL, WS_POPUP, 0, 0, >> 1, 1, 0, >> 0, data->immKbd->hIME, 0); >> - SetWindowLongW(data->imeWnd, IMMGWL_IMC, (LONG)data); >> + SetWindowLongPtrW(data->imeWnd, IMMGWL_IMC, (LONG_PTR)data); >> IMM_GetThreadData()->hwndDefault = data->imeWnd; >> } >> >> diff --git a/dlls/winex11.drv/ime.c b/dlls/winex11.drv/ime.c >> index 87d4faa..6d083d1 100644 >> --- a/dlls/winex11.drv/ime.c >> +++ b/dlls/winex11.drv/ime.c >> @@ -1326,7 +1326,7 @@ static LRESULT WINAPI IME_WindowProc(HWND hwnd, >> UINT msg, WPARAM wParam, >> * messages. >> */ >> >> - hIMC = (HIMC)GetWindowLongW(hwnd,IMMGWL_IMC); >> + hIMC = (HIMC)GetWindowLongPtrW(hwnd,IMMGWL_IMC); >> if (!hIMC) >> hIMC = RealIMC(FROM_X11); >> >> diff --git a/include/ddk/imm.h b/include/ddk/imm.h >> index 6e4d42f..bc9617e 100644 >> --- a/include/ddk/imm.h >> +++ b/include/ddk/imm.h >> @@ -114,7 +114,7 @@ HIMCC WINAPI ImmReSizeIMCC(HIMCC, DWORD); >> DWORD WINAPI ImmGetIMCCSize(HIMCC); >> >> #define IMMGWL_IMC 0 >> -#define IMMGWL_PRIVATE (sizeof(LONG)) >> +#define IMMGWL_PRIVATE (sizeof(LONG_PTR)) >> >> /* IME Property bits */ >> #define IME_PROP_END_UNLOAD 0x0001 >> >> >> ------------------------------------------------------------------------ >> >>

Feb. 11, 2009

Re: imm32: Make space for a 64bit pointer in the IMM window.

by Aric Stewart

I am not a 64 bit expert but i do not think this is going to work. ddk/imm.h is a Microsoft header so IMEs and programs compiled with the original header will not have the expanded space. To fix this properly (I assume you are trying to support 64 bit) is that we will probibly have to store a handle instead of a pointer in the LONG value. The IME is expecting a HIMC in that value. Which leads to a more general question. What is the suggested way to generate handles like that? Working toward 64 bit means that everywhere that we are using pointers as LONG handles is going to have problems. -aric Michael Stefaniuc wrote: > --- > Next try at fixing this problem. I didn't find any other place where > IMMGWL_IMC is used and the window classes are not my area of expertise. > > > > dlls/imm32/imm.c | 2 +- > dlls/winex11.drv/ime.c | 2 +- > include/ddk/imm.h | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/dlls/imm32/imm.c b/dlls/imm32/imm.c > index 14178c3..bb50e5e 100644 > --- a/dlls/imm32/imm.c > +++ b/dlls/imm32/imm.c > @@ -2291,7 +2291,7 @@ BOOL WINAPI ImmSetOpenStatus(HIMC hIMC, BOOL fOpen) > data->imeWnd = CreateWindowExW( WS_EX_TOOLWINDOW, > data->immKbd->imeClassName, NULL, WS_POPUP, 0, 0, 1, 1, 0, > 0, data->immKbd->hIME, 0); > - SetWindowLongW(data->imeWnd, IMMGWL_IMC, (LONG)data); > + SetWindowLongPtrW(data->imeWnd, IMMGWL_IMC, (LONG_PTR)data); > IMM_GetThreadData()->hwndDefault = data->imeWnd; > } > > diff --git a/dlls/winex11.drv/ime.c b/dlls/winex11.drv/ime.c > index 87d4faa..6d083d1 100644 > --- a/dlls/winex11.drv/ime.c > +++ b/dlls/winex11.drv/ime.c > @@ -1326,7 +1326,7 @@ static LRESULT WINAPI IME_WindowProc(HWND hwnd, UINT msg, WPARAM wParam, > * messages. > */ > > - hIMC = (HIMC)GetWindowLongW(hwnd,IMMGWL_IMC); > + hIMC = (HIMC)GetWindowLongPtrW(hwnd,IMMGWL_IMC); > if (!hIMC) > hIMC = RealIMC(FROM_X11); > > diff --git a/include/ddk/imm.h b/include/ddk/imm.h > index 6e4d42f..bc9617e 100644 > --- a/include/ddk/imm.h > +++ b/include/ddk/imm.h > @@ -114,7 +114,7 @@ HIMCC WINAPI ImmReSizeIMCC(HIMCC, DWORD); > DWORD WINAPI ImmGetIMCCSize(HIMCC); > > #define IMMGWL_IMC 0 > -#define IMMGWL_PRIVATE (sizeof(LONG)) > +#define IMMGWL_PRIVATE (sizeof(LONG_PTR)) > > /* IME Property bits */ > #define IME_PROP_END_UNLOAD 0x0001 > > > ------------------------------------------------------------------------ > >

Feb. 11, 2009

Re: An idea for the appdb

by Ben Klein

2009/2/11 Luke Benstead <kazade(a)gmail.com>: > 2009/2/11 Ben Klein <shacklein(a)gmail.com>: >> 2009/2/11 Luke Benstead <kazade(a)gmail.com>: >>> My idea is that the appdb should allow for people to associate a list >>> of checksums with an application version. For example, WoW might have >>> the checksum for the setup program and the game's executable, >>> associated with the appdb entry. The other extension to the appdb >>> would be to allow a way to programmatically retrieve information on an >>> application's rating etc. by going to a certain address (e.g. >>> http://appdb.winehq.org/getAppInfoFromChecksum.php?checksum=ac2b3f5928cba...) >>> which would return the info in XML or some other format. >> >> You've clearly put quite some thought into this, which is highly >> commendable. However, I would personally be against such a move, as it >> would put a lot of extra load on AppDB (in terms of network >> bandwidth). I'm also not too keen about something that retrieves data >> from the net every time you run an app. It's too easy for people to >> mistake it for spyware. > > Hmm.. I see your point. However would it really use that much > bandwidth? I mean, any sane implementation of the functionality I > described would only display the dialog the first time that > application was used. Retrieving a tiny xml file is surely less > bandwidth than browsing the appdb for the application (granted it will > happen more often than people browsing the site but I still don't > think it's masses of bandwidth). I can also see what you mean about > spyware, but other apps retrieve stuff from the web if there is a > connection (CDDB, and album covers are two examples). A request to AppDB would be at least once per user, application version and Wine version combination. Given the number of people using Wine, this would almost certainly be a massive load increase on AppDB, it would repeat roughly every 2 weeks (when new releases come out), and possibly even bring AppDB down as a worst-case scenario.

Feb. 11, 2009

Re: crypt32(1/4): Add chain debugging channel for debugging certificate chaining errors

by Alexandre Julliard

Juan Lang <juan.lang(a)gmail.com> writes: > +static void dump_element(PCCERT_CONTEXT cert) > +{ > + LPWSTR name = NULL; > + DWORD len, i; > + > + TRACE_(chain)("%p\n", cert); > + len = CertGetNameStringW(cert, CERT_NAME_SIMPLE_DISPLAY_TYPE, > + CERT_NAME_ISSUER_FLAG, NULL, NULL, 0); > + name = CryptMemAlloc(len * sizeof(WCHAR)); > + if (name) > + { > + CertGetNameStringW(cert, CERT_NAME_SIMPLE_DISPLAY_TYPE, > + CERT_NAME_ISSUER_FLAG, NULL, name, len); > + TRACE_(chain)("issued by %s\n", debugstr_w(name)); > + CryptMemFree(name); > + } > + len = CertGetNameStringW(cert, CERT_NAME_SIMPLE_DISPLAY_TYPE, 0, NULL, > + NULL, 0); > + name = CryptMemAlloc(len * sizeof(WCHAR)); > + if (name) > + { > + CertGetNameStringW(cert, CERT_NAME_SIMPLE_DISPLAY_TYPE, 0, NULL, > + name, len); > + TRACE_(chain)("issued to %s\n", debugstr_w(name)); > + CryptMemFree(name); > + } You probably don't want to do all this work unless tracing is enabled. -- Alexandre Julliard julliard(a)winehq.org

Feb. 11, 2009

Re: An idea for the appdb

by Luke Benstead

2009/2/11 Ben Klein <shacklein(a)gmail.com>: > 2009/2/11 Luke Benstead <kazade(a)gmail.com>: >> Hi all, >> >> I was thinking earlier it would be quite nice if when I double clicked >> a Windows app in GNOME it would display a nice dialog saying something >> like "This Windows application may not run correctly as it is >> currently rated Silver. Please report any bugs to the Wine project. >> Continue | Cancel". Obviously this kind of functionality is not a job >> for Wine, but for the distro. Still, it got me thinking how this kind >> of functionality might be achieved. > > There's been quite a bit of discussion along these lines recently. > Unfortunately, AppDB simply isn't reliable enough for this type of > dependence. With any luck, that will change when the recently > discussed redesign of test data submissions is set up, but it'd still > take a long time for sensible data to become reasonably usable. > >> My idea is that the appdb should allow for people to associate a list >> of checksums with an application version. For example, WoW might have >> the checksum for the setup program and the game's executable, >> associated with the appdb entry. The other extension to the appdb >> would be to allow a way to programmatically retrieve information on an >> application's rating etc. by going to a certain address (e.g. >> http://appdb.winehq.org/getAppInfoFromChecksum.php?checksum=ac2b3f5928cba...) >> which would return the info in XML or some other format. > > You've clearly put quite some thought into this, which is highly > commendable. However, I would personally be against such a move, as it > would put a lot of extra load on AppDB (in terms of network > bandwidth). I'm also not too keen about something that retrieves data > from the net every time you run an app. It's too easy for people to > mistake it for spyware. Hmm.. I see your point. However would it really use that much bandwidth? I mean, any sane implementation of the functionality I described would only display the dialog the first time that application was used. Retrieving a tiny xml file is surely less bandwidth than browsing the appdb for the application (granted it will happen more often than people browsing the site but I still don't think it's masses of bandwidth). I can also see what you mean about spyware, but other apps retrieve stuff from the web if there is a connection (CDDB, and album covers are two examples). > Another problem with a system like this is that ratings change > depending not only on application version (which you've addressed) but > also on Wine version. Platinum apps could become Garbage for one > version (and yes, it has happened). Since AppDB test results tend to > be few and far between on version numbers, it's not really useful for > an automated "how well will this work?" system. It would have to > calculate some sort of "best fit" (which will certainly be completely > wrong on occasion), or just ignore the missing data. > > And finally, just like with the other suggestions for using the AppDB > data elsewhere, this system does not take patches into account. Some > apps require patches that completely break others (the Worms > Armageddon ddraw hack and CoD hack come to mind here). Unfortunately, > there's no sensible way to account for patched Wine in this sort of > automated system. > > It is not a bad idea to give the user some sort of feedback on how > well they should expect their app to run, but unfortunately it's > virtually impossible to account for every possibility (patches and > broken wineprefixes being the biggest problems). > You're right, it's a shame the data can't be more frequent and reliable, I just thought it would be nice to be able to probe the appdb for this information easily. :) Luke.

Feb. 11, 2009

Re: Fully automated bisecting with "git bisect run" [LWN.net]

by Darragh Bailey

On Wed, Feb 11, 2009 at 10:42:14AM +0100, Uwe Bonnes wrote: > >>>>> "Ben" == Ben Klein <shacklein(a)gmail.com> writes: > > Ben> 2009/2/11 nn <saturn_systems(a)yahoo.com>: > >> Fully automated bisecting with "git bisect run" [LWN.net] > >> http://lwn.net/SubscriberLink/317154/5dec0c8146e58b61/ > >> > >> Would this be useful to add to the instructions on the wine wiki. > >> > Ben> If I understand this correctly, this is only useful when the > Ben> regression is something that can be tested without human > Ben> interaction. This makes it virtually useless for Wine, as most > Ben> regressions involve loss of functionality some application. > > Ben> However, it could theoretically be useful for regressions that > Ben> cause a complete crash of the application early on. Would it be any > Ben> faster? Probably not. Fewer commands to type, since you wouldn't > Ben> need to run "git bisect bad" or "git bisect good" every time you > Ben> test the app. > > It should work it there is a test in the test suite too Comments to the article suggest that it gets significantly more complex if you have 'toxic' patches in the tree. i.e. a patch that breaks your test but is a different bug. You test needs to catch this and return a different code to tell git to skip that revision. -- Darragh "Nothing is foolproof to a sufficiently talented fool."

Feb. 11, 2009

Re: An idea for the appdb

by Ben Klein

2009/2/11 Luke Benstead <kazade(a)gmail.com>: > Hi all, > > I was thinking earlier it would be quite nice if when I double clicked > a Windows app in GNOME it would display a nice dialog saying something > like "This Windows application may not run correctly as it is > currently rated Silver. Please report any bugs to the Wine project. > Continue | Cancel". Obviously this kind of functionality is not a job > for Wine, but for the distro. Still, it got me thinking how this kind > of functionality might be achieved. There's been quite a bit of discussion along these lines recently. Unfortunately, AppDB simply isn't reliable enough for this type of dependence. With any luck, that will change when the recently discussed redesign of test data submissions is set up, but it'd still take a long time for sensible data to become reasonably usable. > My idea is that the appdb should allow for people to associate a list > of checksums with an application version. For example, WoW might have > the checksum for the setup program and the game's executable, > associated with the appdb entry. The other extension to the appdb > would be to allow a way to programmatically retrieve information on an > application's rating etc. by going to a certain address (e.g. > http://appdb.winehq.org/getAppInfoFromChecksum.php?checksum=ac2b3f5928cba...) > which would return the info in XML or some other format. You've clearly put quite some thought into this, which is highly commendable. However, I would personally be against such a move, as it would put a lot of extra load on AppDB (in terms of network bandwidth). I'm also not too keen about something that retrieves data from the net every time you run an app. It's too easy for people to mistake it for spyware. Another problem with a system like this is that ratings change depending not only on application version (which you've addressed) but also on Wine version. Platinum apps could become Garbage for one version (and yes, it has happened). Since AppDB test results tend to be few and far between on version numbers, it's not really useful for an automated "how well will this work?" system. It would have to calculate some sort of "best fit" (which will certainly be completely wrong on occasion), or just ignore the missing data. And finally, just like with the other suggestions for using the AppDB data elsewhere, this system does not take patches into account. Some apps require patches that completely break others (the Worms Armageddon ddraw hack and CoD hack come to mind here). Unfortunately, there's no sensible way to account for patched Wine in this sort of automated system. It is not a bad idea to give the user some sort of feedback on how well they should expect their app to run, but unfortunately it's virtually impossible to account for every possibility (patches and broken wineprefixes being the biggest problems).

Feb. 11, 2009

An idea for the appdb

by Luke Benstead

Hi all, I was thinking earlier it would be quite nice if when I double clicked a Windows app in GNOME it would display a nice dialog saying something like "This Windows application may not run correctly as it is currently rated Silver. Please report any bugs to the Wine project. Continue | Cancel". Obviously this kind of functionality is not a job for Wine, but for the distro. Still, it got me thinking how this kind of functionality might be achieved. My idea is that the appdb should allow for people to associate a list of checksums with an application version. For example, WoW might have the checksum for the setup program and the game's executable, associated with the appdb entry. The other extension to the appdb would be to allow a way to programmatically retrieve information on an application's rating etc. by going to a certain address (e.g. http://appdb.winehq.org/getAppInfoFromChecksum.php?checksum=ac2b3f5928cba...) which would return the info in XML or some other format. So what do you guys think? Perhaps some of this functionality exists and I don't know about it :) Luke.

Feb. 11, 2009

Re: Fully automated bisecting with "git bisect run" [LWN.net]

by Uwe Bonnes

>>>>> "Ben" == Ben Klein <shacklein(a)gmail.com> writes: Ben> 2009/2/11 nn <saturn_systems(a)yahoo.com>: >> Fully automated bisecting with "git bisect run" [LWN.net] >> http://lwn.net/SubscriberLink/317154/5dec0c8146e58b61/ >> >> Would this be useful to add to the instructions on the wine wiki. >> Ben> If I understand this correctly, this is only useful when the Ben> regression is something that can be tested without human Ben> interaction. This makes it virtually useless for Wine, as most Ben> regressions involve loss of functionality some application. Ben> However, it could theoretically be useful for regressions that Ben> cause a complete crash of the application early on. Would it be any Ben> faster? Probably not. Fewer commands to type, since you wouldn't Ben> need to run "git bisect bad" or "git bisect good" every time you Ben> test the app. It should work it there is a test in the test suite too -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Feb. 11, 2009

Re: ntdll: add a warning about running wine as root (resend)

by Alexandre Julliard

Vincent Povirk <madewokherd+8cd9(a)gmail.com> writes: >> To abstract what you're saying here, you're suggesting to extend the >> wineprefix ownership test to include $HOME when $WINEPREFIX is not set >> and $HOME/.wine does not exist? >> >> That doesn't sounds like a bad idea to me. But I'm not so sure about >> specifically testing on UID=0 or SUDO_USER. > This specifically covers the one case that is broken for people who > maybe can't be expected to know any better: running wine for the first > time using sudo on ubuntu. I don't know why else $HOME would not be > owned by you, but I've been assuming we want Wine to function in those > cases (otherwise, we'd have added this test when we added the original > ownership test, right?). No we don't want Wine to function in those cases, and it is part of the ownership test already. -- Alexandre Julliard julliard(a)winehq.org

Feb. 11, 2009