Re: Remove NoAppDBEntry keyword?
On Mon, Nov 9, 2009 at 12:47 AM, Dan Kegel wrote: > Jerome Leclanche wrote: >> Austin English wrote: >>> Anyone opposed to removing that keyword? >> >> +1 on removing it. >> It would be nice to have a bugzilla filter to replace it, too. >> >> Are we keeping "tasklist" and "tasklet" keywords as well? theres >> barely a dozen very old bugs for both of them. > > I think it'd be fine to remove noappdbentry, tasklist, and tasklet. > > If there are no objections by next weekend, let's go ahead and do it. I've removed the keywords bugbuster, noappdbentry, tasklet, and tasklist from all bugs. Could someone with the appropriate bugzilla permissions please delete the keywords themselves? -- -Austin
Re: wineserver: Fix French manpage
Le 9 avril 2010 13:30, Frédéric Delanoy a écrit : > 2010/4/9 Nicolas Le Cam : >> Hi Frédéric, >> >>>+processus clients se sont terminés. Ceci évite le coût inhérent à l'arrêt >> sont -> soient >> >>>+\fIwineserver\fR dans le chemin système ou quelques autres emplacements >>>vraisemblables. >> "potentiels" or "possibles" suit better. >> > > My understanding was that it looked first in the system path, then > tried in, e.g., the home dir or other > directories. > I guess it looks in a hardcoded list of dirs, or sthg like that. In > that sense, "possibles" does not fit IMO. > "potentiels" or "vraisemblables" could both fit, but I wanted to > insist on the probability for the command > to be there (sthg like P[potentiels] < P[vraisemblables]). > > Frédéric > It tries PATH and BINDIR (and server/wineserver if in a build directory). See http://source.winehq.org/git/wine.git/?a=blob;f=libs/wine/config.c#l480 So 'potentiels' or 'possibles' fit better IMHO. -- Nicolas Le Cam
Re: tools: Add French translation of wineprefixcreate manpage
Le 9 avril 2010 13:23, Frédéric Delanoy a écrit : > Well I thought about putting it in non-infinitive form, but it didn't > sound/feel right to me. > > In fact "N'affiche" would be more like a description, while > "N'afficher" is more an action/modifier/behaviour "alterator" > which seems the purpose of an command-line option IMHO. > > Frédéric > > On Fri, Apr 9, 2010 at 9:25 AM, Nicolas Le Cam wrote: >> Hi Frédéric, >> >>>+N'afficher aucun message de statut. >> It doesn't really matter but as you don't use infinitive form >> elsewhere perhaps "N'affiche" could be better. >> >> Thanks again for your work. >> >> -- >> Nicolas Le Cam >> > What about 'Masque (tous) les messages de statut', that should do the trick. -- Nicolas Le Cam
Re: loader: Fix French translation of wine manpage
Le 9 avril 2010 13:37, Frédéric Delanoy a écrit : > 2010/4/9 Nicolas Le Cam : >> Hi Frédéric, >> >>>+\fIwineserver\fR dans le chemin système ou quelques autres emplacements >>>vraisemblables. >>>[...] >>>+"wine" dans le chemin système ou quelques autres emplacements >>>vraisemblables. >> Even if "likely" literally means "vraisemblable" I think the previous >> use of "potentiel" or even "possible" suits better. > > See my comments in the mail "wineserver: Fix French manpage" >> >>>+n'est spécifiée, le caractère + peut être omis. Notez que les espaces ne >>>sont pas >>>+autorisées dans cette chaîne de caractères. >> Should be "autorisés" > > "espace" is feminine when talking about the typographical sign (cf > http://fr.wikipedia.org/wiki/Espace_typographique). > Now if \t or similar had been relevant in that sentence, it would have > been "caractères d'espacement". Oh didn't know that. Thanks for the explanation. >> >>>+Définit le type de remplacement et l'ordre de chargement des DLL utilisées >>>lors du >>>+processus de chargement d'une DLL. Le comportement par défaut est spécifié >>>dans le >>>+fichier de configuration. Deux types de bibliothèques peuvent actuellement >>>être chargées >>>+dans l'espace d'adressage d'un processus : les DLL natives de >>>+Windows >> Should be "chargés" > > What's loaded? The types or the libraries? I think the latter... It's the "two types of libraries" that can be loaded. -- Nicolas Le Cam
Re: [PATCH 01/10] server: allow polling for no events in set_fd_events
On Thu, Apr 8, 2010 at 8:29 PM, Alexandre Julliard wrote: > Mike Kaplinskiy writes: > >> This won't work for implementing half-closed sockets. If we have only >> the read half is closed, we will get POLLIN/0 recv indefinitely if we >> keep polling (not POLLHUP). If we remove it from the loop, we have to >> keep polling (once in a while, i.e. when an enable_socket_event gets >> through) until we get a POLLHUP/POLLERR which signals the other half >> is closed. On some platforms this won't work, but they will jump to a >> full close automatically (i.e. POLLHUP right away). The problem now is >> that if we receive a shutdown, we will spam FD_CLOSE on every >> successful send. > > I don't see why. If you don't get POLLHUP then you can keep polling, > just don't select for POLLIN once you have seen EOF. The problem with > POLLHUP/POLLERR is that they can't be masked, but POLLIN doesn't have > that issue. > > -- > Alexandre Julliard > julli...@winehq.org > Shoot, I'm sorry I was confusing poll vs FD_*. You're right of course, that would work. The slight problem is that a 0 recv is not necessarily a full POLLHUP (i.e. both halves closed). So on platforms that don't signal POLLHUP/POLLERR when both halves are closed we're going to sit there and do nothing, after the first half of the socket is closed. (Are there any like this still around?) In other words we can get rid of try_event completely. There is also a small issue that even after a full close, windows will let you call send() and succeed but with an erroneous FD_CLOSE right after. I think the best way to deal with it is just to special case it in enable_socket_event to send an error close without polling anything, if for some reason FD_CLOSE is unheld. I'll send patches on Monday. Mike.
Re: new icons
On Fri, 2010-04-09 at 15:50 +0200, wy...@volny.cz wrote: > Hi, this will be just a short note... I noticed some new icons and i > like them! > > W. > There's plenty more to come: http://www.airwebreathe.org.uk/wine-icon/ !
Re: winetricks failed, expecting "system32" where I have "System32" and so on
On Fri, Apr 9, 2010 at 12:50 PM, Dan Kegel wrote: > On Fri, Apr 9, 2010 at 10:44 AM, Roderick Colenbrander > wrote: >> Just something else which is a little related. Does winetricks handle >> SysWow64 already? > > Nope. Waiting for the first bug report or first patch... There actually is a bug report: http://code.google.com/p/winezeug/issues/detail?id=102 It's on my todo list, thanks for the reminder. -- -Austin
Re: winetricks failed, expecting "system32" where I have "System32" and so on
On Fri, Apr 9, 2010 at 10:44 AM, Roderick Colenbrander wrote: > Just something else which is a little related. Does winetricks handle > SysWow64 already? Nope. Waiting for the first bug report or first patch...
Re: winetricks failed, expecting "system32" where I have "System32" and so on
On Fri, Apr 9, 2010 at 7:30 PM, Dan Kegel wrote: > Helge wrote: >> I happen to have Windows/System32. > > Hang on right there. Why? Once I understand that, the rest will be easier. > > Winetricks does handle the case where users renamed windows/fonts to > windows/Fonts, because it was observed happening in the wild > (one can imagine users doing thiis when manually installing fonts). > But this is the first I've heard of a System32 rather than a system32. > - Dan > > > Just something else which is a little related. Does winetricks handle SysWow64 already? Roderick
re: winetricks failed, expecting "system32" where I have "System32" and so on
Helge wrote: > I happen to have Windows/System32. Hang on right there. Why? Once I understand that, the rest will be easier. Winetricks does handle the case where users renamed windows/fonts to windows/Fonts, because it was observed happening in the wild (one can imagine users doing thiis when manually installing fonts). But this is the first I've heard of a System32 rather than a system32. - Dan
Re: winetricks failed, expecting "system32" where I have "System32" and so on
Helge Hafting wrote: > I just tried installing gdiplus using winetricks, on a debian testing > system. > > This failed, as winetricks tried to copy stuff into windows/system32, > where I happen to have Windows/System32. As usual start with a clean Wine prefix 'rm -rf ~/.wine', and try again. -- Dmitry.
Re: winetricks failed, expecting "system32" where I have "System32" and so on
On Fri, Apr 9, 2010 at 8:45 AM, Helge Hafting wrote: > I just tried installing gdiplus using winetricks, on a debian testing > system. > > This failed, as winetricks tried to copy stuff into windows/system32, > where I happen to have Windows/System32. > > I first tried making symlinks windows->Windows and system32->System32. > winetricks would run, but the app using gdiplus.dll now failed to find it. > The file was in Windows/System32 as expected. > > So I removed my links, and used search&replace on winetricks, to replace all > occurences of "windows" and "system32" with captialized versions. Then I ran > winetricks again. The installation succeeded this time too, but the app > could still not find the dll in System32. > > I finally gave up and copied the dll into the directory where the app > is installed. This worked, but is problematic; it will have to be done for > every app that uses this dll. Why did you rename system32? Are you linking your ~/.wine/drive_c to a real windows installation? -- -Austin
new icons
Hi, this will be just a short note... I noticed some new icons and i like them! W.
winetricks failed, expecting "system32" where I have "System32" and so on
I just tried installing gdiplus using winetricks, on a debian testing system. This failed, as winetricks tried to copy stuff into windows/system32, where I happen to have Windows/System32. I first tried making symlinks windows->Windows and system32->System32. winetricks would run, but the app using gdiplus.dll now failed to find it. The file was in Windows/System32 as expected. So I removed my links, and used search&replace on winetricks, to replace all occurences of "windows" and "system32" with captialized versions. Then I ran winetricks again. The installation succeeded this time too, but the app could still not find the dll in System32. I finally gave up and copied the dll into the directory where the app is installed. This worked, but is problematic; it will have to be done for every app that uses this dll. Helge Hafting
Re: kernel32: Add tests for lstrcmpW
André Hentschel wrote:
> +#define TESTMARKER(w) \
> +markerW[2] = w; \
> +ok(!lstrcmpW(markerW,nomarkerW), "expected the character 0x%x to be
> ignored within the string\n", w);
> +
> +static void test_lstrcmpW(void)
> +{
> +static const WCHAR nomarkerW[] = {'t','e','s','t',0};
> +static WCHAR markerW[] = {'t','e','r','s','t',0};
> +
> +todo_wine
> +{
> +TESTMARKER(0x034f);
> +TESTMARKER(0x0378);
What this test is supposed to show? Is there a bug that prevents real world
application not to function properly under Wine? Besides, lstrcmpW() is just
a wrapper for CompareStringW(), and there is a bunch of tests for it already.
Testing explicit unicode values is not useful, Wine uses different unicode
tables than Windows does.
--
Dmitry.
Re: [PATCH 6/7] wined3d: Add an initial fbo_blit_supported implementation.
On 8 April 2010 22:49, Roderick Colenbrander wrote: > + /* Source and/or destination need to be on the GL side */ > + if (src_pool == WINED3DPOOL_SYSTEMMEM || dst_pool == > WINED3DPOOL_SYSTEMMEM) > + return FALSE; ... > + if (!is_identity_fixup(src_format_desc->color_fixup) || > + !is_identity_fixup(dst_format_desc->color_fixup)) > + return FALSE; These weren't in the original function. Perhaps they should but, but as separate patches, please. > + if (!(src_format_desc->format == dst_format_desc->format > + || (is_identity_fixup(src_format_desc->color_fixup) > + && is_identity_fixup(dst_format_desc->color_fixup > + return FALSE; This entire check would be redundant after the is_identity_fixup() checks above.
Re: kernel32: Add tests for lstrcmpW
On 04/09/2010 01:12 PM, André Hentschel wrote:
+#define TESTMARKER(w) \
+markerW[2] = w; \
+ok(!lstrcmpW(markerW,nomarkerW), "expected the character 0x%x to be ignored
within the string\n", w);
Hi André,
lstrcmpW is not implemented on Win95/98/Me so these tests will always
succeed.
You should probably add a lstrcmpW call at the beginning and skip when
not implemented, something like:
SetLastError(0xdeadbeef);
lstrcmpW(markerW, nomarkerW);
if (GetLastError() == ERROR_CALL_NOT_IMPLEMENTED)
{
win_skip("lstrcmpW is not implemented\n");
return;
}
--
Cheers,
Paul.
Re: wineserver: Fix French manpage
2010/4/9 Nicolas Le Cam : > Hi Frédéric, > >>+processus clients se sont terminés. Ceci évite le coût inhérent à l'arrêt > sont -> soient > >>+\fIwineserver\fR dans le chemin système ou quelques autres emplacements >>vraisemblables. > "potentiels" or "possibles" suit better. > My understanding was that it looked first in the system path, then tried in, e.g., the home dir or other directories. I guess it looks in a hardcoded list of dirs, or sthg like that. In that sense, "possibles" does not fit IMO. "potentiels" or "vraisemblables" could both fit, but I wanted to insist on the probability for the command to be there (sthg like P[potentiels] < P[vraisemblables]). Frédéric
Re: tools: Add French translation of wineprefixcreate manpage
Well I thought about putting it in non-infinitive form, but it didn't sound/feel right to me. In fact "N'affiche" would be more like a description, while "N'afficher" is more an action/modifier/behaviour "alterator" which seems the purpose of an command-line option IMHO. Frédéric On Fri, Apr 9, 2010 at 9:25 AM, Nicolas Le Cam wrote: > Hi Frédéric, > >>+N'afficher aucun message de statut. > It doesn't really matter but as you don't use infinitive form > elsewhere perhaps "N'affiche" could be better. > > Thanks again for your work. > > -- > Nicolas Le Cam >
Re: [PATCH] d3dx9_36: Beginning of constants parsing + tests (based on work from Luis Busquets) (try 3) (resend)
> Message du 09/04/10 11:33
> De : "Alexandre Julliard"
> A : "Christian Costa"
> Copie à : wine-devel@winehq.org
> Objet : Re: [PATCH] d3dx9_36: Beginning of constants parsing + tests (based
> on work from Luis Busquets) (try 3) (resend)
>
>
> Christian Costa writes:
>
> > @@ -650,6 +650,29 @@ HRESULT WINAPI D3DXCompileShader(LPCSTR pSrcData,
> > return D3DERR_INVALIDCALL;
> > }
> >
> > +typedef struct ctab_constant ctab_constant;
> > +
> > +struct ctab_constant {
> > + D3DXCONSTANT_DESC desc;
> > + ctab_constant* members;
> > +};
> > +
> > +inline ctab_constant* get_constant(D3DXHANDLE ptr)
> > +{
> > + if (!ptr) return NULL;
> > + return (ctab_constant*)~((UINT_PTR)ptr);
> > +}
> > +
> > +inline D3DXHANDLE get_handle(ctab_constant* ptr)
> > +{
> > + return (D3DXHANDLE)~((UINT_PTR)ptr);
> > +}
> > +
> > +inline BOOL isstring(D3DXHANDLE ptr)
> > +{
> > + return !(((UINT_PTR)ptr) & (1 << (sizeof(UINT_PTR)*8-1)));
> > +}
>
> This is broken, you can't make assumptions about the high bit of pointer
> values. The handle management needs more thought.
>
> --
> Alexandre Julliard
> julli...@winehq.org
>
>
Does a 16-bit index would be suitable ?
Re: tuxradar's map of linux audio
On Fri, Apr 9, 2010 at 12:40 PM, Ben Klein wrote: > On 9 April 2010 20:30, Damjan Jovanovic wrote: >> On Fri, Apr 9, 2010 at 12:04 PM, Dan Kegel wrote: >>> This seemed like a useful overview of how the various layers relate to >>> each other: >>> http://tuxradar.com/content/how-it-works-linux-audio-explained >>> >>> >>> >> >> http://insanecoding.blogspot.com/2009/06/state-of-sound-in-linux-not-so-sorry.html >> is another good one. > > The diagrams there are generally much more representative of the > reality of audio APIs in Linux systems. A few gems: > "As should be obvious, these sound servers today do nothing except add > latency, and should be done away with." > "Compare the insanity that is PulseAudio ..." > > :) > > Whether we like it our not audio servers are the future, they make things a lot easier for users they don't care about the card but only see a microphone, speakers and other input/output devices and don't know how it is wired up. The audio server (or whatever thing you use as a 'router') all takes care of it. Windows Vista/Win7 also use a sound server quite similar to pulseaudio. In Wine, Maarten is busy implementing these new Windows APIs and older winmm (and perhaps dsound) will be layered on top of it which is also what Windows does. The design will use OpenAL and whether that's a good choice is another discussion. Roderick
Re: tuxradar's map of linux audio
On 9 April 2010 20:30, Damjan Jovanovic wrote: > On Fri, Apr 9, 2010 at 12:04 PM, Dan Kegel wrote: >> This seemed like a useful overview of how the various layers relate to >> each other: >> http://tuxradar.com/content/how-it-works-linux-audio-explained >> >> >> > > http://insanecoding.blogspot.com/2009/06/state-of-sound-in-linux-not-so-sorry.html > is another good one. The diagrams there are generally much more representative of the reality of audio APIs in Linux systems. A few gems: "As should be obvious, these sound servers today do nothing except add latency, and should be done away with." "Compare the insanity that is PulseAudio ..." :)
Re: tuxradar's map of linux audio
On Fri, Apr 9, 2010 at 12:04 PM, Dan Kegel wrote: > This seemed like a useful overview of how the various layers relate to > each other: > http://tuxradar.com/content/how-it-works-linux-audio-explained > > > http://insanecoding.blogspot.com/2009/06/state-of-sound-in-linux-not-so-sorry.html is another good one.
Re: tuxradar's map of linux audio
On 9 April 2010 11:04, Dan Kegel wrote: > This seemed like a useful overview of how the various layers relate to > each other: > http://tuxradar.com/content/how-it-works-linux-audio-explained This is somewhat confusing: * PulseAudio is an audio mixer that provides a finer grained control over volume (being able to set it per-application), etc. * GStreamer is not solving the same problem as PulseAudio (PulseAudio is not a multimedia framework). GStreamer adds support for playing, synchronising and encoding audio and video media so is fulfilling a different role in the audio landscape -- you cannot decode ogg files directly through PulseAudio, for example. * The Xine framework is like GStreamer and FFmpeg/MPlayer. AFAICS, this is independant of GStreamer and thus sits on top of PulseAudio, ALSA, Jack, etc. I can't see anything that says that xine-lib calls into GStreamer. * Phonon is an API that abstracts the multimedia frameworks and sits on top of either GStreamer or Xine (or other supported backends), with Xine being the default. - Reece
Re: tuxradar's map of linux audio
On 9 April 2010 20:04, Dan Kegel wrote: > This seemed like a useful overview of how the various layers relate to > each other: > http://tuxradar.com/content/how-it-works-linux-audio-explained A cursory glance does not reveal any mention of libalsa as a valid "sound input", and I'm not sure but I think it falsely implies that jack can't use OSS backend.
tuxradar's map of linux audio
This seemed like a useful overview of how the various layers relate to each other: http://tuxradar.com/content/how-it-works-linux-audio-explained
Re: shlwapi: Skip tests on IE < 6 (try 2)
André Hentschel writes:
> @@ -617,6 +617,12 @@ static void test_UrlGetPart(void)
>dwSize = sizeof szPart;
>szPart[0]='x'; szPart[1]=0;
>res = pUrlGetPartA("hi", szPart, &dwSize, URL_PART_SCHEME, 0);
> +
> + if (res) {
> +win_skip("probably too old IE\n");
> +return;
> + }
There's no reason to skip the whole thing.
--
Alexandre Julliard
julli...@winehq.org
Re: oleaut32: be more explicit with locale dependent parsing of dates
André Hentschel writes: > @@ -7708,7 +7708,7 @@ HRESULT WINAPI VarDateFromStr(OLECHAR* strIn, LCID > lcid, ULONG dwFlags, DATE* pd >break; > > case 0x1B: /* localized DDDTTT */ > - if (!iDate) > + if (PRIMARYLANGID(lcid) != LANG_GERMAN) Obviously you cannot hardcode specific locales like that. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH] d3dx9_36: Beginning of constants parsing + tests (based on work from Luis Busquets) (try 3) (resend)
Christian Costa writes:
> @@ -650,6 +650,29 @@ HRESULT WINAPI D3DXCompileShader(LPCSTR pSrcData,
> return D3DERR_INVALIDCALL;
> }
>
> +typedef struct ctab_constant ctab_constant;
> +
> +struct ctab_constant {
> +D3DXCONSTANT_DESC desc;
> +ctab_constant* members;
> +};
> +
> +inline ctab_constant* get_constant(D3DXHANDLE ptr)
> +{
> +if (!ptr) return NULL;
> +return (ctab_constant*)~((UINT_PTR)ptr);
> +}
> +
> +inline D3DXHANDLE get_handle(ctab_constant* ptr)
> +{
> +return (D3DXHANDLE)~((UINT_PTR)ptr);
> +}
> +
> +inline BOOL isstring(D3DXHANDLE ptr)
> +{
> +return !(((UINT_PTR)ptr) & (1 << (sizeof(UINT_PTR)*8-1)));
> +}
This is broken, you can't make assumptions about the high bit of pointer
values. The handle management needs more thought.
--
Alexandre Julliard
julli...@winehq.org
Re: bt all broken?
On 07/04/10 06:39, Dan Kegel wrote: winedbg's bt all seems broken since sometime between 1.1.40 and now. Has anybody else seen this? If I start a program under debugger control with "./wine winedbg ~/test/my.exe" then I see errors such as "Can't get context for thread 0021 in current process" or backtraces like this: Backtrace: =>0 0xf773d42e uni2cp_low+0x576e() in libwine.so.1 (0x0033f7a8) Backtrace: =>0 0xf773d42e uni2cp_low+0x576e() in libwine.so.1 (0x0033f7a8) 0xf771d42e: jmp 0xf771d423 If a program crashes and invokes the debugger (which I have modified to execute "bt all" instead of "bt" by default), I get a full set of backtraces. I have also been seeing "err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols" on executables and matching PDB files generated by the Intel Compiler. It seems that MSVC generated executables and PDBs work fine. That problem has been around for quite a while, certainly before 1.1.40
Re: tools: Add French translation of wineprefixcreate manpage
Hi Frédéric, >+N'afficher aucun message de statut. It doesn't really matter but as you don't use infinitive form elsewhere perhaps "N'affiche" could be better. Thanks again for your work. -- Nicolas Le Cam
Re: wineserver: Fix French manpage
Hi Frédéric, >+processus clients se sont terminés. Ceci évite le coût inhérent à l'arrêt sont -> soient >+\fIwineserver\fR dans le chemin système ou quelques autres emplacements >vraisemblables. "potentiels" or "possibles" suit better. -- Nicolas Le Cam
Re: loader: Fix French translation of wine manpage
Hi Frédéric, >+\fIwineserver\fR dans le chemin système ou quelques autres emplacements >vraisemblables. >[...] >+"wine" dans le chemin système ou quelques autres emplacements vraisemblables. Even if "likely" literally means "vraisemblable" I think the previous use of "potentiel" or even "possible" suits better. >+n'est spécifiée, le caractère + peut être omis. Notez que les espaces ne sont >pas >+autorisées dans cette chaîne de caractères. Should be "autorisés" >+Définit le type de remplacement et l'ordre de chargement des DLL utilisées >lors du >+processus de chargement d'une DLL. Le comportement par défaut est spécifié >dans le >+fichier de configuration. Deux types de bibliothèques peuvent actuellement >être chargées >+dans l'espace d'adressage d'un processus : les DLL natives de >+Windows Should be "chargés" Thanks for your work. -- Nicolas Le Cam
