wine-devel April 2009

wine-devel@winehq.org

118 participants
279 discussions

Setting working directories for applications?
by Igor Tarasov 14 Apr '09

14 Apr '09

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 14 Apr '09

14 Apr '09

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 14 Apr '09

14 Apr '09

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 14 Apr '09

14 Apr '09

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 14 Apr '09

14 Apr '09

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 14 Apr '09

14 Apr '09

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 14 Apr '09

14 Apr '09

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 13 Apr '09

13 Apr '09

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 13 Apr '09

13 Apr '09

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 13 Apr '09

13 Apr '09

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

← Newer
1
...
15
16
17
18
19
20
21
...
28
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel April 2009