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

Error on CVS server: no space left on device
by Paul Chitescu 12 Feb '09

12 Feb '09

Hi! The CVS server cvs.winehq.org is out of disk space: $ cvs -z3 -q up -APd can't create temporary directory /tmp/cvs-serv29410 No space left on device Message is received from remote server. Anyone able to fix it? Regards, Paul Chitescu

3 2

Re: itss: Replace malloc() with HeapAlloc()
by Nikolay Sivov 12 Feb '09

12 Feb '09

Andrew Talbot wrote: > Changelog: > itss: Replace malloc() with HeapAlloc(). > > diff --git a/dlls/itss/lzx.c b/dlls/itss/lzx.c > index b5fdfc7..0ffeeb6 100644 > --- a/dlls/itss/lzx.c > +++ b/dlls/itss/lzx.c > @@ -36,15 +36,17 @@ > ***************************************************************************/ > > #include "lzx.h" > +#include <stdarg.h> > #include <stdio.h> > #include <stdlib.h> > #include <string.h> > > +#include "windef.h" > +#include "winbase.h" > + > /* sized types */ > typedef unsigned char UBYTE; /* 8 bits exactly */ > typedef unsigned short UWORD; /* 16 bits (or more) */ > -typedef unsigned int ULONG; /* 32 bits (or more) */ > -typedef signed int LONG; /* 32 bits (or more) */ > > /* some constants defined by the LZX specification */ > #define LZX_MIN_MATCH (2) > @@ -178,8 +180,8 @@ struct LZXstate *LZXinit(int window) > if (window < 15 || window > 21) return NULL; > > /* allocate state and associated window */ > - pState = malloc(sizeof(struct LZXstate)); > - if (!(pState->window = malloc(wndsize))) > + pState = HeapAlloc(GetProcessHeap(), 0, sizeof(struct LZXstate)); > + if (!(pState->window = HeapAlloc(GetProcessHeap(), 0, wndsize))) > { > free(pState); > return NULL; > Why didn't you replace corresponding free() calls?

4 5

An idea for the appdb
by Luke Benstead 12 Feb '09

12 Feb '09

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.

4 7

Re: An idea for the appdb
by James Mckenzie 11 Feb '09

11 Feb '09

-----Original Message----- >From: alex(a)centroidcafe.com >Sent: Feb 11, 2009 10:59 AM >To: wine-devel(a)winehq.org >Subject: Re: An idea for the appdb > >Sorry .. forgot to reply all. > >Automatic submission of test data could be a very handy tool. Scenario: >User A tries to run an application, it crashes due to bugs in Wine. User A >elects to submit data. Sometime in the future, User B tries to run the same >application under a similar configuration. It crashes also, but User B >being a sly user figures out what DLL overrides, patches, etc. allow this >app to progress past the original crash point. Wine detects this and >collects the information. Now when User C tries to run this app, Wine >displays a message like: "This application has been known to fail under the >current configuration. However, workarounds have been discovered that may >yield greater success. <link to AppDB>" > This would be great, but as previously discussed, who would maintain this information and verify it is correct and proper? Although some features would be 'neet to have' it is best to leave them on the drawing board for now and work on the various bugs that require workarounds. This is because of two limited resources: People and Time. If you have the skills to implement this feature, go ahead and try on a limited database on your home system. You would quickly see that we have about 10,000 applications in the AppDB and there are many versions of Wine. This gives you some starting point of the size of this task. Supporting a few applications would lead to the 'why isn't my wiz-bang application there' and a great deal of discussion, wasting more resources. Of course, if you could produce something that would emulate the "Report to ...." functionality that is in popular use, that would help keep the AppDB and Bugzilla up to date as long as a search capability were added to sweep these systems for pre-existing entries related to the current problem. Just my opinion, but this project is not worth attempting at this point. James McKenzie

5 4

Re: winedos: Replace [c]alloc() with HeapAlloc()
by Andrew Talbot 11 Feb '09

11 Feb '09

Andrew Talbot wrote: Sorry, title should be: winedos: Replace [m|c]alloc() with HeapAlloc() -- Andy.

1 0

Re: An idea for the appdb
by alex＠centroidcafe.com 11 Feb '09

11 Feb '09

Sorry .. forgot to reply all. On Wed, 11 Feb 2009 18:08:47 +0200, Gert van den Berg <wine-devel(a)mohag.net> wrote: > On Wed, Feb 11, 2009 at 2:24 PM, Luke Benstead <kazade(a)gmail.com> wrote: >> 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). >> > Wine transmitting every application I run to someone else would be > rather worrying... > > It should rather be opt-in. Such as "Wine has detected that it is the > first time you run this application, do you want to check AppDb for > more information (Yes/No/Ask again/Never ask for any application)" It > must be easy to disable globally as well... It might have some other > uses as well such as "A newer version of the application works > better", etc. > > I might be handy to allow automatic submission of test data to AppDb > (which IMHO might be more useful than just retrieving...), which > should automatically include the Wine executables' checksums + > version, distro info (if accessible from lsb-release, parts of the > uname output & kernel checksum, which might be used to detect the > distro), kernel version, cpu architecture, X server name and version, > graphics driver name and version, DLL overrides, etc. This might help > modified wine versions and the level of tweaks to be detected by AppDb > automatically. (There should be a very specific opt-in process for > this data's submission though, such as letting the user manually > upload a file with this data and fully disclosing the file's contents) > This kind of data can be handy for bug reports as well. > Automatic submission of test data could be a very handy tool. Scenario: User A tries to run an application, it crashes due to bugs in Wine. User A elects to submit data. Sometime in the future, User B tries to run the same application under a similar configuration. It crashes also, but User B being a sly user figures out what DLL overrides, patches, etc. allow this app to progress past the original crash point. Wine detects this and collects the information. Now when User C tries to run this app, Wine displays a message like: "This application has been known to fail under the current configuration. However, workarounds have been discovered that may yield greater success. <link to AppDB>" That would be pretty sweet, no? -Alex Corrado

2 1

Re: ntdll: add a warning about running wine as root (resend)
by James Mckenzie 11 Feb '09

11 Feb '09

Alexandre Julliard <julliard(a)winehq.org> wrote: >Sent: Feb 9, 2009 7:53 AM >To: James Mckenzie <jjmckenzie51(a)earthlink.net> >Cc: Austin English <austinenglish(a)gmail.com>, wine-devel(a)winehq.org >Subject: Re: ntdll: add a warning about running wine as root (resend) > >James Mckenzie <jjmckenzie51(a)earthlink.net> writes: > >> New wine installation: >> >> su (no dash so root's environment is not picked up) >> wine notepad >> install various programs and use them. >> exit > >This shouldn't hurt anything. Please specify the exact platform and show >us the exact commands you are using, or better file a bug with that >info. > It does not hurt anything but Wine's reputation. I don't know, but the phrase "I would rather be run over rather than run down" does apply here. In other words, we should be getting positive responses to user experiences, rather than dealing with newbies having to delete their .wine directories because they ran Wine as root without setting to the root environment. Fortunately, I run a Mac and running as root is disabled and it is a lengthy process to enable that user, which I did to attempt to get around a problem that running as root did not fix. I agree that user education is key, educating some folks is hard. James McKenzie

13 30

Re: An idea for the appdb
by Tim Schwartz 11 Feb '09

11 Feb '09

On Wed, Feb 11, 2009 at 8:58 AM, <wine-devel-request(a)winehq.org> wrote: > Send wine-devel mailing list submissions to > wine-devel(a)winehq.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.winehq.org/mailman/listinfo/wine-devel > or, via email, send a message with subject or body 'help' to > wine-devel-request(a)winehq.org > > You can reach the person managing the list at > wine-devel-owner(a)winehq.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of wine-devel digest..." > > > Message: 2 > Date: Wed, 11 Feb 2009 23:57:48 +1100 > From: Ben Klein <shacklein(a)gmail.com> > Subject: Re: An idea for the appdb > To: Luke Benstead <kazade(a)gmail.com> > Cc: Wine Devel <wine-devel(a)winehq.org> > Message-ID: > <d7e40be30902110457t3d84c396ibfd264aead12d6e9(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > 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. What about packaging the latest appdb information with each release? Tim Schwartz Sanity Internet tim(a)sanityinternet.com

1 0

Re: ntdll: add a warning about running wine as root (resend)
by James Mckenzie 11 Feb '09

11 Feb '09

Steve Brown <sbrown7(a)umbc.edu> wrote: > >On Tue, 10 Feb 2009, Vitaliy Margolen wrote: > >> Ben Klein wrote: >>> This is not a problem with Wine, this is OpenSUSE breaking the >>> environment when sudo is called. Remember, Wine is not the only X11 >>> app out there. Others will need $DISPLAY working! >> This is something called security.... > >No, the whole point of using sudo is that it removes the necessity of >anyone other than root knowing the root password. If OpenSuSE's default >config requires anyone that needs elevated privileges to know the root >password, it is broken. Using a properly configured sudo, the non-root >users are allowed to execute a (possibly limited) number of commands with >root privileges, but authenticating using their OWN password. > The password method of invoking sudo depends on the UNIX release and the security policy in effect. I've used SUDOUSERS to set who has access to this, used a special password. It is not good security policy to use root's password, unless login as root is completely disabled, as it is with the Mac (it takes six steps to enable root login and Apple advises that this is not necessary.) However, under no circumstances, should a non-admin user run any Wine application as a super-user through this method. It causes problems as files are created with root's credentials and this causes confusion with some new users. Experts (supposedly) know how to fix this. Running Wine as root should bring up a warning message, in Windows format (that is with the warning icon) advising users that they are running Wine as root and that applications installed and files created will not be available to all users (as they would be in some versions of Windows(TM)). I think this is the purpose of the original request. I do support this as a one-time only warning. Permission to run Wine applications as sudo should remain disabled as some users know of this function and use it to get around running and having root's information. James McKenzie

1 0

Re: imm32: Make space for a 64bit pointer in the IMM window.
by Aric Stewart 11 Feb '09

11 Feb '09

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

2 2