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

Setting working directories for applications?
by Igor Tarasov April 14, 2009

April 14, 2009

Hello. This might be a known issue, but anyway: Some windows applications need that shortcut (launcher) have working directory set, and that working directory sometimes different from where the .exe is located. In Linux, with gnome and kde it is not a big problem, since .desktop launchers in these DE support Path attribute. But this becomes a problem with systems that don't support this out of box. As good as I am aware, XFCE have this problem - it's launchers ignore path attribute. Also, AFAIK, there are similar problems with mac version. There might be problems in other desctop enviroments, but I am not aware of these. Currently the only way to lauch such applications is either to use terminal and cd to working directory and then run application, or create custom bash launcher, which is too complicated for not experienced users (I mean not to reproduce it step-by-step, but to solve it by themselves). Is there anything that could be done in this area? -- Igor

7 9

Re: Setting working directories for applications?
by James Mckenzie April 14, 2009

April 14, 2009

Damjan Jovanovic <damjan.jov(a)gmail.com> wrote on April 14th: > >On Sun, Apr 12, 2009 at 8:29 AM, Igor Tarasov <tarasov.igor(a)gmail.com> wrote: > >Do our .desktop files even work on Mac? > I don't think the Aqua specification allows for .desktop files, but .lnk files are connected to the Winehelper application and they do work. If the .desktop files require a specific launcher, it may be possible to get them to work on a Mac. James McKenzie

1 0

FYI -- Dragon Naturally Speaking running a bit better today.
by Susan Cragin April 14, 2009

April 14, 2009

Dragon Naturally Speaking crashes after prolonged use, but the amount of time one can use it before it crashes crept up about 2 minutes, using today's git. Today I dictated for about 14 minutes until it crashed. That's progress. Susan

2 1

Re: [2/2] secur32/tests: Fix GetUserNameEx() tests (try 2)
by Paul Vriens April 14, 2009

April 14, 2009

Ge van Geldorp wrote: > Try 2: use win_skip() instead of skip() > > Changelog: > secur32/tests: Fix GetUserNameEx() tests > > --- > dlls/secur32/tests/secur32.c | 44 > +++++++++++++++++++++--------------------- > 1 files changed, 22 insertions(+), 22 deletions(-) > > > > > > ------------------------------------------------------------------------ > > Hi Ge, Why did you remove: - if (0) /* Crashes on Windows */ - rc = pGetUserNameExW(NameSamCompatible, NULL, NULL); - The point of these additions was to show/document that Windows crashes when called like this. -- Cheers, Paul.

4 5

[RFC] mountmgr.sys: keep track of local disks when requested in winecfg
by Ben Klein April 14, 2009

April 14, 2009

I submitted this to wine-patches a while ago and haven't seen it go in. I'm confident it is correct and proper, but I'd like some feedback (which I've also asked for before) from more experienced devs. The problem is that when you set a drive to "Local disk" in winecfg, the setting isn't remembered/stored and instead it reverts to the "autodetect" method. I traced the problem to mountmgr.c, where define_unix_drive (ultimately called when changes are made to the winecfg "Drives" tab) has no case for the DRIVE_FIXED/DEVICE_HARDDISK_VOL/"Local disk" option (which is already in query_unix_drive) and it reverts to DEVICE_UNKNOWN which is handled as an "autodetect" and no registry entry is stored. The patch below fixes this, so setting "Local disk" in winecfg creates a registry entry that sets the drive type to "hd", which is then correctly reported by query_unix_drive. There is a bug report for this problem. http://bugs.winehq.org/show_bug.cgi?id=17618 diff --git a/dlls/mountmgr.sys/mountmgr.c b/dlls/mountmgr.sys/mountmgr.c index 00112b9..d2b1515 100644 --- a/dlls/mountmgr.sys/mountmgr.c +++ b/dlls/mountmgr.sys/mountmgr.c @@ -264,6 +264,7 @@ static NTSTATUS define_unix_drive( const void *in_buff, SIZE_T insize ) case DRIVE_REMOTE: type = DEVICE_NETWORK; break; case DRIVE_CDROM: type = DEVICE_CDROM; break; case DRIVE_RAMDISK: type = DEVICE_RAMDISK; break; + case DRIVE_FIXED: type = DEVICE_HARDDISK_VOL; break; } return add_dos_device( letter - 'a', NULL, device, mount_point, type ); } -- 1.6.1.3

1 0

Re: try3 [1/3] kernel32/tests: Add tests for GetVolumeInformationA and QueryDosDevice
by Paul Vriens April 14, 2009

April 14, 2009

Guy Albertelli wrote: > Enhance QueryDosDevice test for attempting to return all devices. > Add tests for GetVolumeInformationA testing the different root dir formats. > --- > dlls/kernel32/tests/volume.c | 132 +++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 129 insertions(+), 3 deletions(-) > > > > ------------------------------------------------------------------------ > > You're leaking memory here (although it's just a test we try to have these as clean as possible): + buffer = HeapAlloc( GetProcessHeap(), 0, buflen ); + ret = QueryDosDeviceA( NULL, buffer, buflen ); + ok(ret && GetLastError() != ERROR_INSUFFICIENT_BUFFER, + "QueryDosDevice buffer to small\n"); + if (GetLastError() == ERROR_INSUFFICIENT_BUFFER) return; Could you also change the skip()'s into win_skip()'s: + if (!pGetVolumeInformationA) { + skip("GetVolumeInformationA not found\n"); + return; + } + if (!pGetVolumeNameForVolumeMountPointA) { + skip("GetVolumeNameForVolumeMountPointA not found\n"); + return; + } That way they will only be skipped on Windows if the functions are not present. If the functions are not present on Wine (for whatever reason) a win_skip will show a failure on wine. -- Cheers, Paul.

1 0

unsubscribe
by Rich Gilson April 14, 2009

April 14, 2009

Michael Stefaniuc wrote: > --- > dlls/opengl32/wgl.c | 8 ++++---- > 1 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/dlls/opengl32/wgl.c b/dlls/opengl32/wgl.c > index b73cf60..34f7f07 100644 > --- a/dlls/opengl32/wgl.c > +++ b/dlls/opengl32/wgl.c > @@ -102,8 +102,8 @@ typedef struct wine_glcontext { > > void enter_gl(void) > { > - Wine_GLContext *curctx = (Wine_GLContext *) NtCurrentTeb()->glContext; > - > + Wine_GLContext *curctx = NtCurrentTeb()->glContext; > + > if (curctx && curctx->do_escape) > { > enum x11drv_escape_codes escape = X11DRV_SYNC_PIXMAP; > @@ -230,8 +230,8 @@ PROC WINAPI wglGetProcAddress(LPCSTR lpszProc) { > > /* After that, search in the thunks to find the real name of the extension */ > ext.name = lpszProc; > - ext_ret = (const OpenGL_extension *) bsearch(&ext, extension_registry, > - extension_registry_size, sizeof(OpenGL_extension), compar); > + ext_ret = bsearch(&ext, extension_registry, extension_registry_size, > + sizeof(OpenGL_extension), compar); > > /* If nothing was found, we are looking for a WGL extension or an unknown GL extension. */ > if (ext_ret == NULL) { >

1 0

do ERR messages imply bugs?
by Vincent Povirk April 13, 2009

April 13, 2009

Chris Ahrendt filed a few bugs recently for "err" messages encountered during test runs (17997 and 17998 at least). Vitaliy claims they are invalid. In order to explain clearly why they are invalid, I looked up the official definition of ERR in the Wine Developer's Guide: "Messages in this class indicate serious errors in Wine, such as as conditions that should never happen by design." (http://www.winehq.org/docs/winedev-guide/debugging) This goes against my preconceived notion. Bad developer's guide, bad. To my even greater astonishment, all the ERR messages I've added fit this description. Bad past self, bad. The consensus (or so I thought) seems to be that ERR messages are simply for debugging and can safely be ignored as long as nothing is going wrong in a running program (in this case, as long as the tests are not failing). "Serious errors" sounds like something that should be worth investigating, even without visible failures. How do we resolve this discrepancy? Vincent Povirk

7 23

Re: tools/wine.inf: create Microsoft Shared/TextConv directory
by Austin English April 13, 2009

April 13, 2009

On Sun, Mar 22, 2009 at 11:40 AM, Austin English <austinenglish(a)gmail.com> wrote: > Needed by a few different installers. Now comes by default in XP SP3 > and up (verified name on a German locale, doesn't seem to be English > specific). > > Fixes bug 17257. > > -- > -Austin > Anything wrong with this one? -- -Austin

1 0

Re: [1/1]msctf/test: test Enableing and Disabling Language Profiles
by Detlef Riekenberg April 13, 2009

April 13, 2009

On Fr, 2009-04-10 at 07:55 -0500, Aric Stewart wrote: > +static void test_Disable(void) ... > + trace("Disabling\n"); ... > + ok(SUCCEEDED(hr),"Failed to enable text service\n"); With greetings from Copy & Paste -- By by ... Detlef

1 0