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

How to expanding environmental variables?
by Austin English July 20, 2009

July 20, 2009

Howdy all, I'm working on a automated test for Photoshop CS 2. As before, I'm trying to do so in a portable way, so it works on various locales/windows versions (or as much as possible). Because of wine/windows differences, I need a portable way to get to the shared documents folder, e.g.,: Windows XP: C:\Documents and Settings\All Users\Shared Documents WIndows Vista: C:\users\Public\Public Documents Wine: C:\users\Public\Documents Windows has several variables for this sort of thing (http://msdn.microsoft.com/en-us/library/ms933062(WinEmbedded.5).aspx) In particular, I need a way to return what %16430% is on the target system. I've tried using cmd.exe to echo it, but it's not expanding it. Does anyone know how I can expand this type of variable? I figured there's probably something in shell32 that can accomplish this, but nothing popped up at me immediately (and I'm about to run, so I wanted to e-mail before I leave). Surely there's an easy way and I'm just overlooking it... Thanks! -- -Austin

6 7

Re: netapi32: Fix a pointer conversion warning on 64-bit
by Juan Lang July 20, 2009

July 20, 2009

Hi André, @@ -577,7 +577,7 @@ static UCHAR NetBTinetResolve(const UCHAR name[NCBNAMSZ], (*cacheEntry)->numAddresses = i; for (i = 0; i < (*cacheEntry)->numAddresses; i++) (*cacheEntry)->addresses[i] = - (DWORD)host->h_addr_list[i]; + (DWORD_PTR)host->h_addr_list[i]; This isn't correct, as the lvalue is still a DWORD, and needs to remain a DWORD. If you like you can check that the length, host->h_length, is the same as sizeof(DWORD), but this is pretty well implied by the use of gethostbyname(): it only returns addresses of type AF_INET. Basically, the warning is a false positive. --Juan

1 0

Re: XkbSetDetectableAutoRepeat not working on some platforms
by F Capela July 20, 2009

July 20, 2009

From: Dmitry Timoshkov <dmitry(a)codeweavers.com> > "F Capela" <fabio.capela(a)yahoo.com> wrote: > > > XkbSetDetectableAutoRepeat is not working correctly on some > > distributions, including Ubuntu 9.04. In practical terms, this > > means programs running under Wine on such distros are unable to > > ignore autorepeat, doing strange things to games that use keyboard > > controls, for example. One way to work around the problem is to > > manually filter out the key release messages, which can be done > > with a few extra lines in dlls/winex11.drv/event.c . My question is, > > should I send a patch enabling this filtering? From what I have seen, > > patches to work around bugs that are clearly outside Wine are usually > > not accepted. > > Have you reported a bug to XOrg and those distros about that? > > -- Dmitry. I have not yet filled a bug with Ubuntu (which is the distro I'm using), I'll do it as soon as I find how, but while searching for information about this issue I saw a bug filled for Gentoo (which I'm not sure if it's still present), and there are two open bugs under bugs.freedesktop.org (http://bugs.freedesktop.org/show_bug.cgi?id=22194 and http://bugs.freedesktop.org/show_bug.cgi?id=22515) about XkbSetDetectableAutoRepeat not working, both filled in june, one reported under Ubuntu and the other for the GIT version. A bit of extra information, the only software I use that seems to be affected is World of Warcraft; the walk animation stutters when using the keyboard to move, and some things that should not auto repeat (jumps, spell casting, etc) do repeat. BTW, the same bug will happen (and be wine's fault) if the X server does not support DetectableAutorepeat, since when it calls XkbSetDetectableAutoRepeat in dlls/winex11.drv/x11drv_main.c, wine does not care about the function's return value or third argument (although I don't think there is any widely used version of the X server that don't support DetectableAutorepeat). Fábio Oliveira Schmidt Capela

1 0

Re: suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch
by James Mckenzie July 20, 2009

July 20, 2009

>On Sun, Jul 19, 2009 at 12:23 PM, Emmanuel Maillard<mahanuu(a)free.fr> wrote: >> But it's an external appplication, your desktop environment, that handle >> *.desktop file; wine just generate them... > >As per the private email I sent. I could see that working if we can >convince Alexandre of the need of an external helper application for >OS X. Keeping the existing winemenubuilder code mostly as is and >having it write xdg menus and associations would be pretty simple. We >could just change a few lines to have it write xdg in >~/Library/Application Support/Wine/WineMenuBuilder > >> So don't choose ~/Applications but : /Applications/Wine or >> let's the user to choose if want an Applications folder in is Homedir. > >The reason for using ~/Applications as opposed to /Applications is >that Wine has no knowledge or real support for multi-user prefixes. >Each .wine being local to the user that creates it will have their own >applications, etc. If we write the menus to /Applications and another >user logs in then they won't be able to run those applications. Another good reason is that /Applications can only be written to by an administrative user using sudo. James McKenzie

1 0

RE: D3D shader assembler (Matteo Bruni)
by Matteo Bruni July 20, 2009

July 20, 2009

2009/7/20 "Luis C. Busquets Pérez" <luis.busquets(a)ilidium.com>: > I read several months ago that the itnetion was to create the assembler > inside the wined3d and then use its functionality inside the diverse d3dx9 > implementations. Has this changed? I think it was Stefan Dösinger sho > proposed it: > > d3dx -> wined3d assembler > the wined3d will be re-usable and the d3dx functions will be extremely easy. > > > Yes, the plan changed in the meantime. Now d3dx8 isn't in Wine anymore (it wasn't used before anyway, the apps using d3dx8 are usually linked against a static version of the library) so the assembler is needed only by d3dx9. The assembler can be put into d3dx9_36 and the other d3dx9_xx dlls can forward to it, as it is for the other d3dx9 functions. DirectX 10 doesn't support anymore assembler shaders, only HLSL one, so no worry from there. That said, maybe a part of the assembler, the bytecode writer, could be useful for the shader compiler. So that part could be moved into wined3d to have it in common between the assembler and the compiler, but this is not something that will happen (if it will happen) soon.

1 0

Re: advapi32: test a combination of CreateServiceA and GetSecurityInfo
by Alexandre Julliard July 20, 2009

July 20, 2009

Stefan Leichter <Stefan.Leichter(a)camline.com> writes: > + /* Wait a while. The following test also does a CreateService for the > + * same servicename and this would result in an ERROR_SERVICE_MARKED_FOR_DELETE > + * error if we do this to quick. Vista seems more picky then the others. > + */ > + Sleep(1000); > + > + svc_handle1 = CreateServiceA(scm_handle, servicename, NULL, SERVICE_ALL_ACCESS, SERVICE_WIN32_SHARE_PROCESS, > + SERVICE_DEMAND_START, SERVICE_ERROR_NORMAL, pathname, NULL, NULL, NULL, NULL, NULL); > + ok(svc_handle1 != NULL, "Could not create the service : %d\n", GetLastError()); > + if (svc_handle1 != NULL) { > + PSID sidOwner, sidGroup; > + PACL dacl, sacl; > + PSECURITY_DESCRIPTOR pSD; > + HRESULT retval = GetSecurityInfo(svc_handle1,SE_SERVICE,DACL_SECURITY_INFORMATION,&sidOwner,&sidGroup,&dacl,&sacl,&pSD); > + todo_wine ok(ERROR_SUCCESS == retval, "Expected GetSecurityInfo to succeed: result %d\n",retval); > + } You could insert that into one of the other tests that already create a service, so that we don't need to have too many Sleeps in there. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: dsound: Fix some pointer conversion warnings on 64-bit
by Alexandre Julliard July 20, 2009

July 20, 2009

André Hentschel <nerv(a)dawncrow.de> writes: > --- a/dlls/dsound/propset.c > +++ b/dlls/dsound/propset.c > @@ -109,7 +109,7 @@ static HRESULT WINAPI IKsBufferPropertySetImpl_Get( > S(prop).Set = *guidPropSet; > S(prop).Id = dwPropID; > S(prop).Flags = 0; /* unused */ > - S(prop).InstanceId = (ULONG)This->dsb->device; > + S(prop).InstanceId = (ULONG_PTR)This->dsb->device; If the destination is a DWORD changing the cast is only hiding the problem. -- Alexandre Julliard julliard(a)winehq.org

1 0

Doing better than barely keeping up with bug reports - Bug Day this Monday (July 20)
by Scott Ritchie July 20, 2009

July 20, 2009

So, briefly: Over the past few months, users have added an average of between 12 and 14 bugs every day. Since June 1st: - 412 total bugs filed - 87 bugs resolved invalid - 227 bugs resolved fixed - 133 bugs confirmed but not resolved (status new) - 292 bugs created but unconfirmed Doing some subtraction that means we have 292 new untriaged bugs, but we triaged or fixed (412-292-87-227-133) = 327 old bugs. So, we're swimming above water, which is good. But at this rate it'll be years before we triage every bug. So, let's do something :) Bug Jam this Monday! One idea that has been tried in the past is to hold regular bug days. We've had a lot of success with them in Ubuntu as a way of organizing non developer volunteers, especially when we focus the event on a particular package. Today's bug day, for instance, tackled over a 100 Synaptic bugs: https://wiki.ubuntu.com/UbuntuBugDay/20090716 I'd like to attempt this in Wine. We tried it once in the past, but no one's organizing it now. Even if it's just me and 2 people testing a handful of bugs in our favorite apps, it'll still sink a good number of bugs and help drain the swamp. I'm picking Monday for bug day for a few reasons - it's both after a new release and after the weekend, so users will have already had time to play their games and see if they're still affected. If there's any sort of success, hopefully this will become a regular event. So, if you're into bug triage, please come and join me in #winehackers this Monday. The purpose of triaging bugs is to ultimately get them fixed, so if you're a developer and would rather work on patches then by all means do that instead. I've created a wiki page for the event here: http://wiki.winehq.org/BugDay When we're done I'll poke bugzilla for some stats and we can see how much of a success the event was. Thanks, Scott Ritchie

4 4

Re: msi: Fix some pointer conversion warnings on 64-bit(try2)
by Mike Kaplinskiy July 20, 2009

July 20, 2009

André Hentschel wrote: > didnt want to change both variables, now its fine > sry for the noise > --- > dlls/msi/join.c | 5 +++-- > dlls/msi/msiquery.c | 4 ++-- > dlls/msi/storages.c | 2 +- > dlls/msi/streams.c | 2 +- > 4 files changed, 7 insertions(+), 6 deletions(-) > > > > + UINT_PTR i > + UINT row_value; Missing a semicolon? ;) Mike.

1 0

XkbSetDetectableAutoRepeat not working on some platforms
by F Capela July 19, 2009

July 19, 2009

XkbSetDetectableAutoRepeat is not working correctly on some distributions, including Ubuntu 9.04. In practical terms, this means programs running under Wine on such distros are unable to ignore autorepeat, doing strange things to games that use keyboard controls, for example. One way to work around the problem is to manually filter out the key release messages, which can be done with a few extra lines in dlls/winex11.drv/event.c . My question is, should I send a patch enabling this filtering? From what I have seen, patches to work around bugs that are clearly outside Wine are usually not accepted. I'm adding the patch inlined in this message for those that might want to look at it; if I feel the patch do have a chance to be accepted I will resend to wine-patches. Fábio Oliveira Schmidt Capela fabio.capela(a)yahoo.com diff --git a/dlls/winex11.drv/event.c b/dlls/winex11.drv/event.c index a965b9f..793b842 100644 --- a/dlls/winex11.drv/event.c +++ b/dlls/winex11.drv/event.c @@ -283,6 +283,13 @@ static enum event_merge_action merge_events( XEvent *prev, XEvent *next ) return MERGE_DISCARD; } break; + case KeyRelease: + if (prev->xany.window == next->xany.window && next->type == KeyPress && next->xkey.time == prev->xkey.time && next->xkey.keycode == prev->xkey.keycode && next->xkey.state == prev->xkey.state) + { + TRACE( "Discarding autorepeat key release for window %lx\n", prev->xany.window ); + return MERGE_DISCARD; + } + break; } return MERGE_HANDLE; }

2 1