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

Re: An idea for the appdb
by alex＠centroidcafe.com Feb. 11, 2009

Feb. 11, 2009

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 Feb. 11, 2009

Feb. 11, 2009

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 Feb. 11, 2009

Feb. 11, 2009

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 Feb. 11, 2009

Feb. 11, 2009

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 Feb. 11, 2009

Feb. 11, 2009

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

Re: crypt32(1/4): Add chain debugging channel for debugging certificate chaining errors
by Alexandre Julliard Feb. 11, 2009

Feb. 11, 2009

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

1 0

Re: gdiplus: add a drawing test for GdipFillRectangleI
by Nikolay Sivov Feb. 10, 2009

Feb. 10, 2009

Vincent Povirk wrote: > This is a very simple drawing test that I've created to establish a precedent for drawing tests in gdiplus. > > Gdiplus currently has no tests that draw things and then check what was drawn. I've added some functions that should make this easy. It's important to get this right the first time so any feedback will be most appreciated. > As for me I'm not against it if it'll work stably, but will this really help? It's much easier to check this visually, comparing with native output. These pixel-by-pixel tests should use current bpp depth for 'relaxation' when we start draw gradients for example...That's will add another complexity. Maybe it makes sense to add an antialiasing drawing tests to find out a closer algorithm for line drawing with different SmoothingModes...

2 3

Re: imagicos
by James Mckenzie Feb. 10, 2009

Feb. 10, 2009

Jeremy White <jwhite(a)winehq.org> wrote: > >EA Durbin wrote: >> I just saw this linux distribution on distrowatch. They claim to be able >> to run all microsoft products. Interesting. > >Just for the record, these folks are customers of ours. > Thank you for the clarification of your relationship with this company. > >It is my belief that their distribution of CrossOver complies with all >of the terms of the LGPL; we try to make sure of that for our customers. > I even believe that money they make as a result of their windows >compatibility will, albeit fairly indirectly, support Wine development. > This is very true. Hopefully, the legal folks have taken a look at how they are utilizing your product. I, for one, don't like to see one company's efforts usurped by another. > >Obviously, I like it when folks can celebrate the contributions of >everyone to Wine, and to all the FOSS products that go into something >like a Linux distribution. But Free Software means that folks are also >free to market as they see fit :-/. > I have warned folks against 'Free' software due to support concerns. I use Crossover because CodeWeavers is an ongoing concern. I advise folks to work with Wine, with the cavet that it is FOSS and that support is only available through the Wine Forums or Wine Mailing Lists. I also warn them that a problem they encounter may or may not be corrected. The same is true of most commercial software, but there is available telephone support (if you pay for it.) Again, I like where Wine is moving and the advances in just the last year. Also, I do support those companies that attempt to commercialize products, like RedHat and CodeWeavers. Please continue to do the great things that will move Wine forward. James McKenzie

1 0

Re: Fixing AppDB once and for all
by James Mckenzie Feb. 10, 2009

Feb. 10, 2009

Zachary Goldberg <zgold(a)bluesata.com> >Sent: Feb 3, 2009 10:44 AM >To: Wine Devel <wine-devel(a)winehq.org> >Cc: Jeremy Newman <jnewman(a)codeweavers.com> >Subject: Fixing AppDB once and for all > >All, >Lets (arbitrarily) set a time for the chat at: > >When: 11PM UTC (6PM EST) 2/6/09 (Friday) >Where: #winehackers > This would be too early for people on the West Coast of the United States by about three hours. No time will be satisfactory for all people who work on this project. What I feel is necessary at this point is to collect who lives in what time zone so that we incovience as few people as possible. Since this would be Saturday in Asia, this time may work for the majority of the people on this list. Also, will there be a transcript of the discussion and where will it be placed since this has a major impact on the functionality of the Applications Database. James McKenzie

9 15

imagicos
by EA Durbin Feb. 10, 2009

Feb. 10, 2009

I just saw this linux distribution on distrowatch. They claim to be able to run all microsoft products. Interesting. http://www.imagicos.com/ http://www.imagicos.com/microsoft.html _________________________________________________________________ Windows Live™: E-mail. Chat. Share. Get more ways to connect. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_allup_explore_022009

13 21

Re: [PATCH] gdi32: handle failure in __wine_make_gdi_object_system (Coverity)
by Alexandre Julliard Feb. 10, 2009

Feb. 10, 2009

Marcus Meissner <marcus(a)jet.franken.de> writes: > @@ -445,6 +445,11 @@ static const struct DefaultFontInfo default_fonts[] = > void CDECL __wine_make_gdi_object_system( HGDIOBJ handle, BOOL set) > { > GDIOBJHDR *ptr = GDI_GetObjPtr( handle, 0 ); > + > + if (!ptr) { > + ERR("System object for handle %p not found.\n", handle); > + return; > + } That shouldn't happen, it's an internal function and the caller is supposed to pass a valid handle. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: mshtml/tests: Better check for installed Gecko.
by Alexandre Julliard Feb. 10, 2009

Feb. 10, 2009

Jacek Caban <jacek(a)codeweavers.com> writes: > @@ -4199,9 +4199,8 @@ static void run_domtest(const char *str, domtest_t test) > } > > hres = IHTMLDocument2_get_body(doc, &body); > - ok(hres == S_OK, "get_body failed: %08x\n", hres); > - > - if(body) { > + if(hres != E_UNEXPECTED) { > + ok(hres == S_OK, "get_body failed: %08x\n", hres); > IHTMLElement_Release(body); We've been through this before, there needs to be at least one failure if mshtml is non-functional because Gecko is missing. I'd suggest to remove the Gecko install workaround and have the test force the install in all cases, it's not useful to run the tests without Gecko anyway. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: spoolss: Implement EnumPorts [try 2]
by Alexandre Julliard Feb. 10, 2009

Feb. 10, 2009

Detlef Riekenberg <wine.dev(a)web.de> writes: > Synced to current git. It doesn't work here: ../../../tools/runtest -q -P wine -M winspool.drv -T ../../.. -p winspool.drv_test.exe.so info.c && touch info.ok info.c:505: Test failed: got 1 with 127 (expected '0' with ERROR_INVALID_PARAMETER) make: *** [info.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] winegcc: Free the temporary string arrays (Coverity)
by Alexandre Julliard Feb. 10, 2009

Feb. 10, 2009

Marcus Meissner <marcus(a)jet.franken.de> writes: > Hi, > > This fixes CID 883, 882, 881, 880, 879, 878, 877, > which are all basically missing strarray_free(arr)s. winegcc is a short-lived program, there's no reason to care about memory leaks. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [try2] dinput: joydevs[id].name (EVIOCGNAME) is product name, joydevs[id].device is a path
by Ben Klein Feb. 10, 2009

Feb. 10, 2009

2009/2/10 Vincent Pelletier <plr.vincent(a)gmail.com>: > On Tue, Feb 10, 2009 at 8:51 AM, Ben Klein <shacklein(a)gmail.com> wrote: >> You're taking out the strcpy into device, and replacing it with a >> strcpy into instance_name. What value will the device field hold? > > Err... strcpy from instance_name to the other struct. It's strcpy(out, in). > It's wine which is providing the windows program with names. OK, disregard everything I said ... ever ;) Well, at least about the strcpy. Sorry, must be my dyslexia playing tricks on me again. Oh, and can you try to hit "Reply to all" so it goes back to the mailing list too?

1 0

Re: dinput: joydevs[id].name (EVIOCGNAME) is product name, joydevs[id].device is a path
by Vitaliy Margolen Feb. 10, 2009

Feb. 10, 2009

Vincent Pelletier wrote: > joydevs[id].name value comes from EVIOCGNAME iotcl, and is the product name. > > I think joystick device path qualifies as a "Friendly name for the instance" > (as defined for tszInstanceName on MSDN). > > If not, please tell me and I will extend the patch to generate a "Joystick %i" > name, or maybe put joydevs[id].name in both fields. > > - strcpy(lpddi->tszInstanceName, joydevs[id].name); > - strcpy(lpddi->tszProductName, joydevs[id].device); > + strcpy(lpddi->tszInstanceName, joydevs[id].device); > + strcpy(lpddi->tszProductName, joydevs[id].name); No this is not entirely correct. Native doesn't return any device paths. But it does return proper joystick name: Wine: Instance: Logitech Logitech Dual Action ProductName: /dev/input/event7 Win XP: Instance: Logitech Dual Action USB ProductName: Logitech Dual Action USB Another joystick: Wine: Instance: Logitech Logitech MOMO Racing ProductName: /dev/input/event7 Win XP: Instance: Logitech MOMO Racing USB ProductName: Logitech MOMO Racing USB So I'd suggest copying name into both places. I think some applications looking for particular information there. And append "evdev?" at the end so we can tell how it's handled. Vitaliy.

3 3

Re: ntdll: add a warning about running wine as root (resend)
by James Mckenzie Feb. 10, 2009

Feb. 10, 2009

Alexandre Julliard <julliard(a)winehq.org> wrote: >Sent: Feb 9, 2009 7:26 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: > >> Second, the problem is that newbies, figuring that their favorite >> program will not run as an ordinary user, gets a wiff that root has >> more privileges, will attempt run as root totally hosing their Wine >> directory. This then starts the 'you should not run Wine as root' >> mantra on Wine-Users. This then causes the newbie to question why did >> I go to Linux/Wine when I had a perfectly running Windows system? > >Please explain how running as root will screw their Wine directory. If >that's really true, surely it should be fixed instead of simply throwing >out a warning and proceeding. New wine installation: su (no dash so root's environment is not picked up) wine notepad install various programs and use them. exit User logs in a second time after learning how to properly use Wine. Attempt to do anything with Wine in user space. Cannot do due to permissions problems. The solution: sudo rm -rf .wine User now upset because everything they did is gone. Yes, there are legit reasons to run as root, one of them is the now famous ICMP 'Ping' unavailability issue in Linux. Experts know about this and how to work around it. Newbies, used to Windows and how it works, just figure that this is restricted to administrators, and switch to root to get around it. The proper command, as I have learned through years of UNIX administration, is 'su -' but newbies don't know this and most just use 'su'. Thus, the need for the warning. Experts tend to know what they are doing, newbies don't for the most part. And yes, I borked many a system as a newbie and as an expert (building kernels for RedHat/Fedora for my Thinkpad. James McKenzie

10 12

Regression in 1.1.14 for Athena Visual Studio
by Erich Hoover Feb. 9, 2009

Feb. 9, 2009

In Wine 1.1.14 Athena Visual Studio fails to build Fortran applications and returns with an error, doing a git bisect gives this result: ---- ebe4a9e321800fbe6d2004a640cd276a28d15c38 is first bad commit commit ebe4a9e321800fbe6d2004a640cd276a28d15c38 Author: Dan Kegel <dank(a)kegel.com> Date: Sun Jan 18 19:19:46 2009 -0800 msvcrt: Remove CRs earlier in ascii mode. :040000 040000 44cfaec7cd552af4c92f220ad34a06d864eff79d 685d15aa69a9e0f91e0d4cbc933191a29837dce9 M dlls ---- However, removing this patch from the latest git doesn't do enough - Athena instead hangs indefinitely trying to build. I guessed that it would also be necessary to remove the related patch "msvcrt: Remove CRs earlier in ascii mode in fseek, too.": http://source.winehq.org/git/wine.git/?a=blob;f=dlls/msvcrt/file.c;hb=7f3c7… Fortunately, that did the trick and got things working again. I don't have a lot of free time right now, but if there's some information I can give that will help in fixing this issue then please let me know and I will do my best to provide it. A 15 day trial of Athena is available, this error can be reproduced by attempting to build any sample in the "Curve Fitting Models" folder.

2 1

Re: ntdll: add a warning about running wine as root (resend)
by James Mckenzie Feb. 9, 2009

Feb. 9, 2009

Aurimas Fišeras <aurimas(a)gmail.com> wrote: >Sent: Feb 9, 2009 7:45 AM >To: James Mckenzie <jjmckenzie51(a)earthlink.net> >Cc: wine-devel(a)winehq.org >Subject: Re: ntdll: add a warning about running wine as root (resend) > >James Mckenzie wrote: >> Alexandre Julliard <julliard(a)winehq.org> wrote: >>[...] >> New wine installation: >> >> su (no dash so root's environment is not picked up) >> wine notepad >> install various programs and use them. >> exit >> >> User logs in a second time after learning how to properly use Wine. >> Attempt to do anything with Wine in user space. Cannot do due to permissions problems. >> >> The solution: >> >> sudo rm -rf .wine >No, the solution is >sudo chown -R user:user .wine Correct. However, this is not being given as the solution. Also, if the user is on an alternate wine prefix this would change to: sudo chown -R <username>:users $WINEPREFIX Is this in the FAQ somewhere? James McKenzie

3 2

[try2] dinput: joydevs[id].name (EVIOCGNAME) is product name, joydevs[id].device is a path
by Vincent Pelletier Feb. 9, 2009

Feb. 9, 2009

Le Saturday 07 February 2009 14:16:15 Vincent Pelletier, vous avez écrit : > If not, please tell me and I will extend the patch to generate a "Joystick > %i" name, or maybe put joydevs[id].name in both fields. Same patch as first proposed on wine-devel, no reaction so I guess it's correct. -- Vincent Pelletier

2 2

Re: comctl32/tests: [try 2] Make the test dpi and Theme aware: use SM_CYSIZE
by Paul Vriens Feb. 9, 2009

Feb. 9, 2009

Detlef Riekenberg wrote: > try 2: without the check for win9x > > > The status test failed on installations with 120 dpi. > > After a lot of "try and error" from 72 to 144 dpi with > different formula for the min height, different results on my machine > and a failing XP machine at 96dpi, I found the reason: > > The minimal height depends on the appearance setting > "[In]Active Title Bar", which is SM_CYSIZE. > > The test now pass on win98se, win2k and Wine with a different height > for the title bar (tested from 18 to 30). > > To reduce the test log size, I moved the dump of the current tested > font name from a trace to the ok. > > > Why is MS so stupid and use BYTE in ENUMLOGFONTEXA and > WCHAR in ENUMLOGFONTEXW for the strings in wingdi.h, > while MSDN document them as TCHAR? > > > > > ------------------------------------------------------------------------ > > Hi Detlef, This patch introduced a lot of failures on specifically some XP and W2K3 boxes. Could you have a look? -- Cheers, Paul.

2 1

Re: ntdll: add a warning about running wine as root (resend)
by James Mckenzie Feb. 9, 2009

Feb. 9, 2009

Michael Stefaniuc <mstefani(a)redhat.com> wrote: >Sent: Feb 9, 2009 7:39 AM >To: James Mckenzie <jjmckenzie51(a)earthlink.net> >Cc: wine-devel(a)winehq.org >Subject: Re: ntdll: add a warning about running wine as root (resend) > >> sudo rm -rf .wine >Solution is sudo chmod -R $username.$groupname .wine > Correct. However, this is not the solution given on Wine Users. >> User now upset because everything they did is gone. >Not if you do it right. > I agree, but some users are very sensitive and are worse that a colicy baby. The problem is that we should not need to direct users to run as root to perform any function. Some Linux distributions restrict network functions, such as ICMP, to only root. This is sillines in my opinion and actually employs poor security practices. However, a new that receives a message like the following "You must be an Administrator to run this program" when attempting to run a program in Wine will think "Administrator == root" and try to run the program as root. The program does not run, and they are futher frustrated. Also, some new users think, incorrectly, that running Wine as root will give them more permissions. It does not and should not. Again, the warning should address this. What I don't want to see, and I agree with AJ, is the disablement of running Wine as the root user. There are situations where this is necessary. A short notification message is all that is necessary and Austin's change does exactly that. James McKenzie

1 0

Re: ntdll: add a warning about running wine as root (resend)
by James Mckenzie Feb. 9, 2009

Feb. 9, 2009

Chris Howe <mrmessiah(a)gmail.com> wrote: >Sent: Feb 9, 2009 8:06 AM >To: wine-devel(a)winehq.org >Subject: Re: ntdll: add a warning about running wine as root (resend) > >It would seem to me that the right place for this to go would be >not in Wine itself but in the likes of Crossover and Cedega - the >"distributions" and value added apps built around Wine. > >I can't reconcile in my head the case where you have a newbie >running the latest GIT of Wine needing this kind of thing at all. > Newbies don't run GITs, they download a prebuild version of Wine from a repository. Thus, this 'fix' would not appear to them until the release of 1.1.15 at the earliest. >Either they want the power and compatibility of the latest GIT >version, and all that that entails, including the potential for doing >things they didn't intend if they run it as root, or they want some >newbie friendly environment that seizes back the reins a little >and stops them doing that. > All versions of Wine that I've run into have the ability to run as root. This is inherent as a part of any UNIX program. What we are discussing is that running as root may make your system vulnerable and may cause problems later when Wine is run in user space. My example is that a user logs in and installs a program as root because they were told that it 'runs better' as root. When it is discovered to not be true, the user then attempts to run in user space only to be advised they have no access to the program. The solution given is to remove the user space Wine directories and to start over. The user gets upset, sometimes with implied violence, and then abandons Wine. What happens is that this user gets on other areas and talks bad about Wine. Thus, Wine gets another black eye to overcome. The idea is to warn users that problems may be encountered if they run Wine as root. If they continue on, it is on them. A message box or warning on the screen, shown one time, is all most newbies need to come back to the forum and ask how to do something. Experts will charge on and if they mess up their system, they know how to fix it. James McKenzie

2 1

Fwd: EVE online losing its Linux Client
by Andrew Fenn Feb. 9, 2009

Feb. 9, 2009

On Mon, Feb 9, 2009 at 2:22 PM, James Mckenzie <jjmckenzie51(a)earthlink.net> wrote: > Since there is not a great Wine audience for the Mac, the Eve Online Mac client should not be abandoned just for that reason. The real reason may be that there is not a great deal of demand for an on-line game interface for the Mac. Most Mac users loath having to use X11 for any purpose, and a game tops the list. I'm pretty sure they're not abandoning the mac client which has shown growth compared to the Linux client.

1 0

Re: ntdll: add a warning about running wine as root (resend)
by James Mckenzie Feb. 9, 2009

Feb. 9, 2009

David Gerard <dgerard(a)gmail.com> wrote: >Sent: Feb 9, 2009 7:45 AM >To: wine-devel(a)winehq.org >Subject: Re: ntdll: add a warning about running wine as root (resend) > >2009/2/9 James Mckenzie <jjmckenzie51(a)earthlink.net>: > >> Thus, the need for the warning. Experts tend to know what they are doing, newbies don't for the >>most part. And yes, I borked many a system as a newbie and as an expert (building kernels for >>RedHat/Fedora for my Thinkpad. > > >Yep. The problem is that newbies are coming from Windows - (a) where >the answer to inability to do something is to try again as >administrator (b) which sometimes takes precautions to keep you from >shooting your foot off. Which is why most establishments have disabled users from having access to Administrator level functions. > >Solutions: > >1. Get better newbies. (Strikes me as unlikely.) I agree and the situation is getting worse rather than better. We have to be able to gently guide newbies from causing harm to themselves. Sort of like handing a new soldier an unloaded weapon and telling them it is. This is what the warning should do. If a newbie carries on, then they 'have been warned' and they cannot blame Wine for causing harm to their system. >2. Something to help stop them shooting their foot off that won't >hamper those who really want to do this. > Again, the one-time warning should suffice. This can set a Registry value so the warning will not display again in that WINEPREFIX. Experts will just ignore the message whereas newbies might just heed it and stop. Then again, some won't. James McKenzie

1 0