Re: [PATCH] attrib: Move implementation from cmd.exe to the standalone command
On Wed, Aug 24, 2011 at 08:20, Christian Costa wrote: > -- > > I added a stub last year to make an installer work but didn't know the > command existed as a builtin in cmd.exe until Frédéric Delanoy told me. So > here is a patch that takes what's in cmd.exe and move it to the standalone > command. Some few code was taken from xcopy. > --- > programs/attrib/Makefile.in | 4 + > programs/attrib/attrib.c | 190 > +-- > programs/attrib/attrib.h | 28 ++ > programs/attrib/attrib.rc | 49 +++ > programs/cmd/builtins.c | 83 --- > programs/cmd/cmd.rc | 2 > programs/cmd/wcmd.h | 94 ++--- > programs/cmd/wcmdmain.c | 4 - > 8 files changed, 309 insertions(+), 145 deletions(-) > create mode 100644 programs/attrib/attrib.h > create mode 100644 programs/attrib/attrib.rc Most translatable strings (except those in dialogs) have been moved to/adapted for use in po files. You have to regenerate the po files using "make depend && make" in maintainer mode (./configure --enable-maintainer-mode). Frédéric
Re: gdi32: Add a buch of CreateScalableFontResource() tests. Resend.
GOUJON Alexandre wrote: > On 08/24/2011 03:42 AM, Dmitry Timoshkov wrote: > > It's pretty disappointing to see no any reaction except the (answered) > > question above in a month. > > > Do you know AJ has been on vacation for two weeks ? > That you're not the only developer ? > That AJ has tons of patch to read and comment ? That doesn't explain why the test case (!) sent one month ago has not been accepted and has stalled in the pending state while many other patches have been committed before and after the two weeks vacation time. I'd guess that's because my mailing address no more ends with @codeweavers.com but that's a pure speculation on my part. Nevertheless that doesn't look very nice. > You should at least resend it or ask that @ #winehackers If you would read the subject you'd notice that it's already a resend. Besides how asking on wine-devel (several times already) does make a boost in comparison to asking on irc? > And don't be disappointed, life's disappointing but whining won't change > anything. Thank you very much for the useless comment on a public ml. -- Dmitry.
Re: gdi32: Add a buch of CreateScalableFontResource() tests. Resend.
On 08/24/2011 03:42 AM, Dmitry Timoshkov wrote: It's pretty disappointing to see no any reaction except the (answered) question above in a month. Do you know AJ has been on vacation for two weeks ? That you're not the only developer ? That AJ has tons of patch to read and comment ? You should at least resend it or ask that @ #winehackers And don't be disappointed, life's disappointing but whining won't change anything.
Re: gdi32: Add a buch of CreateScalableFontResource() tests. Resend.
Dmitry Timoshkov wrote: > > Alexandre Julliard wrote: > > > > > > + > > > > +/* @makedep: wine_test.ttf */ > > > > +wine_test.ttf RCDATA wine_test.ttf > > > > > > How was this file created? > > > > It was created with fontforge. Here it is in a .sfd format just in case. > > Is there anything else that prevents accepting this test case? It's pretty disappointing to see no any reaction except the (answered) question above in a month. -- Dmitry.
Re: tools/winegcc: support a trailing / in paths to winebuild
On Tue, Aug 23, 2011 at 11:20 AM, David Laight wrote: > On Mon, Aug 22, 2011 at 07:13:42PM +0200, Bernhard Loos wrote: >> On Mon, Aug 22, 2011 at 7:02 PM, Jerome Leclanche wrote: >> > That's to be fixed in bash-completion, not winegcc... >> >> Uhm, what's wrong with bash-completation? -B takes a directory as an >> argument so bash adds a slash during autocomplete, that's ok. >> gcc itself can also deal with a trailing / for -B, it's kinda >> suprising, if this breaks in winegcc. > > bash has 'broken' many things by doing that. > Traditionally directory paths wouldn't be expected to have a trailing '/'. > > David > > -- > David Laight: da...@l8s.co.uk > Well, everything else accepts a trailing slash now, so tradition isn't a good argument here. It's higly surprising and non-obviouls to get magic behavior for ./tools/winebuild but not for ./tools/winebuild/ , especially if gcc itself doesn't distinguish between them.
Re: André Hentschel : po: German translations added and updated.
Am 23.08.2011 22:57, schrieb Francois Gouget: > > On Mon, 22 Aug 2011, Alexandre Julliard wrote: > >> Module: wine >> Branch: master >> Commit: aeb9f621292dec7a6366209106468da8d0371684 >> URL: >> http://source.winehq.org/git/wine.git/?a=commit;h=aeb9f621292dec7a6366209106468da8d0371684 > > I think the string below should really be translated. It's displayed in > winecfg -> Desktop Integration tab, in the 'Item' list more precisely. > This is where one can decide what color or font to use for each of the > GUI elements. And actually all the items around "Message Box Text" are > translated. > >> msgid "Message Box Text" >> -msgstr "" >> +msgstr "Message Box Text" That's understandable, but yeah a proper translation is better. > There's also another translation that I think is wrong: > >> #: wordpad.rc:88 >> -#, fuzzy >> msgid "&Pale yellow\tCtrl+2" >> msgstr "&PostIt-Notiz\tStrg+2" > > This used to be 'PostThat Yellow' which was a word play on PostIt. > However 'Pale Yellow' is much clearer and the German translation does > not look like a color name at all currently. So I think it's best not to > continue with the bad pun (besides otherwise you would probably need to > change it to 'PostIt[tm]...' anyway). That truely should be done right(TM) and i'll use what a famous online dictonary suggests. > Everything else looks good (to a non-German speaking guy). I just sent a patch that takes the above issues into account. Thx for the hints. -- Best Regards, André Hentschel
Re: André Hentschel : po: German translations added and updated.
On Mon, 22 Aug 2011, Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: aeb9f621292dec7a6366209106468da8d0371684 > URL: > http://source.winehq.org/git/wine.git/?a=commit;h=aeb9f621292dec7a6366209106468da8d0371684 I think the string below should really be translated. It's displayed in winecfg -> Desktop Integration tab, in the 'Item' list more precisely. This is where one can decide what color or font to use for each of the GUI elements. And actually all the items around "Message Box Text" are translated. > msgid "Message Box Text" > -msgstr "" > +msgstr "Message Box Text" There's also another translation that I think is wrong: > #: wordpad.rc:88 > -#, fuzzy > msgid "&Pale yellow\tCtrl+2" > msgstr "&PostIt-Notiz\tStrg+2" This used to be 'PostThat Yellow' which was a word play on PostIt. However 'Pale Yellow' is much clearer and the German translation does not look like a color name at all currently. So I think it's best not to continue with the bad pun (besides otherwise you would probably need to change it to 'PostIt[tm]...' anyway). Everything else looks good (to a non-German speaking guy). -- Francois Gouget http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.
Re: kernel32: Fix writing to a pipe in WriteConsoleW().
Le 03/08/2011 18:07, Francois Gouget a écrit : WriteFile() checks if the handle corresponds to the console and if it does invokes WriteConsoleA(). This barely escaped an infinite loop but messed up the string encoding as CP_UNIXCP is usually different from CP_ACP. --- I noticed this issue while testing the net.exe tool. After making it use WineConsole() I was getting the following outputs: $ wine net stop Spécifie le service à arrêter. $ ./wine net stop | cat Sp├®cifie le service ├á arr├¬ter. It turns out that it's because we only get through the WineConsoleW() -> WriteFile() -> WriteConsoleA() loop in the second case. could you elaborate a bit more. in case of wine ... | cat, the standard output should be a pipe not a console so writeconsoleW is supposed to fail so it would make more sense to simply let WriteConsoleW fail when is_console_handle(hConsoleOutput) is FALSE ? (similar functions as WriteConsoleA, ReadConsoleA/W should be protected the same way) A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
Summer is ending, you can't procrastinate any more, come to Wineconf!
So summer holidays are rapidly ending, and before you know it, Wineconf will be upon us - just 5 more weeks until Wineconf! The full details, including the hotel information, is available here: http://wiki.winehq.org/WineConf2011 For those of you that have asked for sponsorship, I'm trying to come to a 'final' set of requests so I can figure out how best to divvy up the funds we have available. I hope to have that info soon. If you're interested in coming, but can't afford it, please write to me privately to see if we can help. Hope to see you there! Cheers, Jeremy p.s. I promise to try to keep most discussion on the http://www.winehq.org/mailman/listinfo/wineconf mailing list, which you should join now if you're at all interested in Wineconf.
Re: [5/5] ddraw: Emulate a 24 bit depth format without stencil or padding
On 23 August 2011 11:48, Stefan Dösinger wrote: > 3) Advertise both X8D24 versions if X8D24 is supported. > Change ddraw_surface_init to make sure we don't have to convert back from > the wined3d format. Then, once device_parent_create_depth_stencil is gone, > we'll never convert wined3d depth formats to ddraw formats and we can > support both X8D24 versions in ddraw without having two versions in wined3d. > That's probably the one you want anyway. > The ddraw format is already wrong. It claims to be 3 byte without padding, > but as the test shows it actually has 1 padding byte. I think at the heart > of this issue is that driver vendors couldn't agree how to represent a 3 > byte depth with one byte padding format in a DDPIXELFORMAT structure. > Sure, but we can try to limit the damage somewhat.
Re: [3/7] msi: Don't create a temporary copy of the package. (try 2)
On Tue, Aug 23, 2011 at 3:13 PM, Joris Huizer wrote: > On 08/23/2011 11:45 AM, Hans Leidekker wrote: > >> +if (!strcmpiW( package, unsquashed )) >> > > I'm confused about the last part of the function. > I think if the comparison between 'package' and 'unsquashed' fails, you > want to return an error, > but the return value 'r' will be ERROR_SUCCESS at that point, and isn't > updated. > Hello, The function strcmpiW returns 0 when the strings are equal, and non-zero when they are different (< 0 if first is smaller, > 0 if first is larger, lexicographically speaking). The condition checks if the strings match, not if the function failed (string comparison cannot "fail"). Cheers, Octavian
Re: Hebrew: update
On 8/23/11 8:38 AM, Francois Gouget wrote: [...] Wineconsole does not support Hebrew or Arabic script out of the box, there are several fonts that should be installed in order to enable that, AFAIK Arabic displayed in the right order but the letters are not joined, I can check that and get back to you. Is there a bug report for this? (I did not see one in a cursory search) If a bug is made/found I would be very interested in being CC'ed on that. Doing the RTL work in WINE is something I am very much enjoying. -aric
Re: Hebrew: update
On Tue, Aug 23, 2011 at 4:38 PM, Francois Gouget wrote: > On Tue, 23 Aug 2011, Yaron Shahrabani wrote: > [...] > >> Wineconsole does not support Hebrew or Arabic script out of the box, >> there are several fonts that should be installed in order to enable >> that, AFAIK Arabic displayed in the right order but the letters are >> not joined, I can check that and get back to you. > > Is there a bug report for this? (I did not see one in a cursory search) Paul Vriens helped me with this one, and if I remember correctly he also opened a bug... > > > > [...] > > It looks like Virtaal needs fixing then. I did not find where one can > report bugs against it so I don't know if this issue is already known to > its developpers. In the meantime I find that emacs (with or without a > special editing more) is nice for editing PO files but I don't know how > well it works with RTL languages. Just like wine they have bigger issues to deal with thus they are not adding any new dialogs until all the trivial bugs are fixed (In the previous version it took more than a minute to load, Poedit takes about 4-5 seconds). When you want to use TM tools and make sure you enrich your TM cache while translating, you better not use apps such as emacs, I translate many apps, translating the same sentence over and over again is a complete waste of time. So I get all my former translations as suggestions (Alongside TM suggestions from Google Translator, Microsoft Translator and Open-Tran.eu), this procedure helps me to get into proportion when translating and looking at the same term from different angles, its like having someone proofreading your work while working although using a human proofreader which have different views than you do can definitely improve the translation quality. > > > >> I look at comments but sometimes when I have many strings to translate >> I don't have much time to stop and read each and every one of them, it >> takes a lot of my (precious) time so for the sake of efficiency I let >> myself ignore some of them, so do other Hebrew translators, > > Well, for Wine it must be quick since it does not have any translator > or developper comment so far. I was not talking about wine, its becoming a habit, when you translate a large amount of apps you look at the comments only if you think that the current translation might be misleading to the user, unfortunately I can't make all the developers add comments whether the string is displayed in CLI/GUI or both and frankly it could be nice but it doesn't worth all the efforts, sometimes I prefer digging into the app and trying to look at the general idea of it myself and then translate, sometimes I skip because this is a real time consumer... Just like developers have their own tips and tricks, so do translators, sadly not all of them but the tools are gradually improving yet still nothing can replace a professional human translator. Hope I made things straight. Kind regards, Yaron Shahrabani. > > > -- > Francois Gouget http://fgouget.free.fr/ > "Only wimps use tape backup: _real_ men just upload their important stuff on > ftp, and let the rest of the world mirror it ;)" -- Linus Torvalds >
Re: Hebrew: update
On Tue, 23 Aug 2011, Yaron Shahrabani wrote: [...] > > > Since we have certain RTL issues with the Linux kernel (Hebrew is > > > displayed in reverse) we discourage the translators to translate > > > strings that would probably appear there > > > > How does the Linux kernel get involved? Using Wine on the Linux console > > would be quite unusual. Usually it is run in a Gnome terminal, and Xterm > > or some other GUI equivalent. Don't these do their own handling of text > > independently from the Linux kernel? > Most terminal emulators doesn't support RTL besides MLTerm. Ok, that makes more sense. > Wineconsole does not support Hebrew or Arabic script out of the box, > there are several fonts that should be installed in order to enable > that, AFAIK Arabic displayed in the right order but the letters are > not joined, I can check that and get back to you. Is there a bug report for this? (I did not see one in a cursory search) [...] > > The translator comments will be preserved through the updates. > I'm translating using Virtaal, meaning I can't add comments while > translating and I guess other translators as well, It looks like Virtaal needs fixing then. I did not find where one can report bugs against it so I don't know if this issue is already known to its developpers. In the meantime I find that emacs (with or without a special editing more) is nice for editing PO files but I don't know how well it works with RTL languages. > I look at comments but sometimes when I have many strings to translate > I don't have much time to stop and read each and every one of them, it > takes a lot of my (precious) time so for the sake of efficiency I let > myself ignore some of them, so do other Hebrew translators, Well, for Wine it must be quick since it does not have any translator or developper comment so far. -- Francois Gouget http://fgouget.free.fr/ "Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" -- Linus Torvalds
Re: Hebrew: update
On Tue, 23 Aug 2011, Yaron Shahrabani wrote:
[...]
> > On Tue, 23 Aug 2011, Yaron Shahrabani wrote:
> >
> > > On Mon, Aug 22, 2011 at 3:25 PM, Francois Gouget wrote:
> > > >
> > > > > #: crypt32.rc:182
> > > > > msgid "KeyID="
> > > > > -msgstr ""
> > > > > +msgstr "KeyID="
> > > >
> > > > I think you should really translate 'KeyID' In French it was translated
> > > > to 'ID de clé'. So assuming there is a Hebrew word for 'key' then this
> > > > would not remain as is.
> > > This appears in a certificate, it is much more useful to the user than
> > > the Hebrew tern (מזהה מפתח)...
> >
> > It's in a resource file which usually means the author (Juan Lang in
> > this case) expects it to be translated. If it's not meant to be
> > translated then it should either be removed from the resource file or
> > marked as not needing translation (I have a patch for that, maybe I'll
> > send it tomorrow).
>
> I'm not translating so things will be translated, I also have to make
> sure that the user experience is somewhat natural and pleasing,
> translating this string is mostly confusing.
Juan, what's your take on this. I initially thought that this was
essentially part of the same set as 'Surname', 'Organizational Unit',
'State or Province', etc for which it's clear that translation is
needed. But apparently 'KeyID=' and the others next to it ('Certificate
Issuer', 'Certificate Serial Number=', etc.) are used in a slightly
different context. Should they not be translated?
How can one test this in practice?
--
Francois Gouget http://fgouget.free.fr/
Stolen from an Internet user:
"f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"
Re: [7/7] msi/tests: Clean up local packages.
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=13580
Your paranoid android.
=== WNT4WSSP6 (32 bit install) ===
install.c:5997: Test failed: Per-user icon file isn't where it's expected
(C:\WINNT\Profiles\Default User\Application
Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)
Re: [3/7] msi: Don't create a temporary copy of the package. (try 2)
Just an implementation detail I noticed:
On 08/23/2011 11:45 AM, Hans Leidekker wrote:
+
+static UINT get_registered_local_package( const WCHAR *product, const WCHAR
*package, WCHAR *localfile )
+{
+MSIINSTALLCONTEXT context;
+HKEY product_key, props_key;
+WCHAR *registered_package = NULL, unsquashed[GUID_SIZE];
+UINT r = ERROR_FUNCTION_FAILED;
+
+r = msi_locate_product( product,&context );
+if (r != ERROR_SUCCESS)
+return r;
+
+r = MSIREG_OpenProductKey( product, NULL, context,&product_key, FALSE );
+if (r != ERROR_SUCCESS)
+return r;
+
+r = MSIREG_OpenInstallProps( product, context, NULL,&props_key, FALSE );
+if (r != ERROR_SUCCESS)
+{
+RegCloseKey( product_key );
+return r;
+}
+registered_package = msi_reg_get_val_str( product_key,
INSTALLPROPERTY_PACKAGECODEW );
+if (!registered_package)
+goto done;
+
+unsquash_guid( registered_package, unsquashed );
+if (!strcmpiW( package, unsquashed ))
+{
+WCHAR *filename = msi_reg_get_val_str( props_key,
INSTALLPROPERTY_LOCALPACKAGEW );
+strcpyW( localfile, filename );
+msi_free( filename );
+r = ERROR_SUCCESS;
+}
+done:
+msi_free( registered_package );
+RegCloseKey( props_key );
+RegCloseKey( product_key );
+return r;
+}
+
I'm confused about the last part of the function.
I think if the comparison between 'package' and 'unsquashed' fails, you
want to return an error,
but the return value 'r' will be ERROR_SUCCESS at that point, and isn't
updated.
HTH,
Joris
Re: [6/7] msi: Remove icons when the product is uninstalled.
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=13579
Your paranoid android.
=== WNT4WSSP6 (32 bit install) ===
install.c:5979: Test failed: Per-user icon file isn't where it's expected
(C:\WINNT\Profiles\Default User\Application
Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)
Re: Hebrew: update
On Tue, Aug 23, 2011 at 12:43 PM, Francois Gouget wrote:
>
> Did you really mean not to CC wine-devel?
Right sorry...
>
>
> On Tue, 23 Aug 2011, Yaron Shahrabani wrote:
>
> > On Mon, Aug 22, 2011 at 3:25 PM, Francois Gouget wrote:
> > >
> > > > #: crypt32.rc:182
> > > > msgid "KeyID="
> > > > -msgstr ""
> > > > +msgstr "KeyID="
> > >
> > > I think you should really translate 'KeyID' In French it was translated
> > > to 'ID de clé'. So assuming there is a Hebrew word for 'key' then this
> > > would not remain as is.
> > This appears in a certificate, it is much more useful to the user than
> > the Hebrew tern (מזהה מפתח)...
>
> It's in a resource file which usually means the author (Juan Lang in
> this case) expects it to be translated. If it's not meant to be
> translated then it should either be removed from the resource file or
> marked as not needing translation (I have a patch for that, maybe I'll
> send it tomorrow).
I'm not translating so things will be translated, I also have to make
sure that the user experience is somewhat natural and pleasing,
translating this string is mostly confusing.
>
>
>
> > > > -"\t/i {package|productcode} [property]\n"
> > > > -"\t/package {package|productcode} [property]\n"
> > > > +"\t/i {package|product_code} [property]\n"
> > > > +"\t/package {package|product_code} [property]\n"
> > >
> > > Ideally you should translate the user-replaceable strings like 'package'
> > > and 'productcode'. But option names such as '/package' should remain as
> > > is of course.
> > Since we have certain RTL issues with the Linux kernel (Hebrew is
> > displayed in reverse) we discourage the translators to translate
> > strings that would probably appear there
> > >
> > >
> > > > msgid "DirectX Diagnostic Tool"
> > > > -msgstr ""
> > > > +msgstr "DirectX Diagnostic Tool"
> > >
> > > This is sort of a product name os it's always a bit dicey. Still,
> > > wouldn't it be better if 'Diagnostic Tool' was translated? At
> > > non-English speakers would understand what the purpose of the tool it.
> > Wasn't quite sure if it appears in a console or GUI, can you tell?
>
> It is displayed in a message box (so GUI).
Great, I will fix this in my next commit, for now it is perfectly fine...
>
>
> > Since we have certain RTL issues with the Linux kernel (Hebrew is
> > displayed in reverse) we discourage the translators to translate
> > strings that would probably appear there
>
> How does the Linux kernel get involved? Using Wine on the Linux console
> would be quite unusual. Usually it is run in a Gnome terminal, and Xterm
> or some other GUI equivalent. Don't these do their own handling of text
> independently from the Linux kernel?
Most terminal emulators doesn't support RTL besides MLTerm.
Wineconsole does not support Hebrew or Arabic script out of the box,
there are several fonts that should be installed in order to enable
that, AFAIK Arabic displayed in the right order but the letters are
not joined, I can check that and get back to you.
>
>
> [...]
> > > > -msgstr "%s : File Not Found\n"
> > > > +msgstr "%s: File Not Found\n"
> > > [...a lot more...]
> > >
> > > These are not translated and do not have their place in a PO file. They
> > > will prevent future translators working on this file from knowing what
> > > has been translated.
> >
> > They better not work on this... I need this to remain untranslated
> > until the Hebrew bugs in the Linux kernel will be fixed.
>
> In that case you should add translator comments indicating that the
> string should remain untranslated for the time being. A translator
> comment is a '#' followed by a space, but adding a second space so it
> lines up with the others makes it nicer. For instance:
>
> # DO NOT TRANSLATE: needs RTL fixes to the Linux kernel
> #: cmd.rc:280
> msgid "%s: File Not Found\n"
> msgstr ""
>
>
> The translator comments will be preserved through the updates.
I'm translating using Virtaal, meaning I can't add comments while
translating and I guess other translators as well, I look at comments
but sometimes when I have many strings to translate I don't have much
time to stop and read each and every one of them, it takes a lot of my
(precious) time so for the sake of efficiency I let myself ignore some
of them, so do other Hebrew translators, But most of us do understand
that if a string is copied as-is it shouldn't be translated (Sort of
convention if you like).
It may seem odd but Hebrew, although a private case of Arabic is still
not handled the best way it should in computing, there are still many
nasty bugs so we do our best to give the Hebrew user the best
experience but its still not perfect as we want it to be and we value
the efforts of the developers that do help us but we understand if
they have no interest and it is fine by us besides I realize there are
much more important things to develop so we just leave it aside and
deal with what we can deal with our given tools.
Kind regards,
Yaron Shahrabani.
>
>
>
Re: [7/7] msi/tests: Clean up local packages.
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=13576
Your paranoid android.
=== WNT4WSSP6 (32 bit install) ===
install.c:5997: Test failed: Per-user icon file isn't where it's expected
(C:\WINNT\Profiles\Default User\Application
Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)
=== WXPPROSP3 (32 bit install) ===
Timeout
Re: [6/7] msi: Remove icons when the product is uninstalled.
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=13575
Your paranoid android.
=== WNT4WSSP6 (32 bit install) ===
install.c:5979: Test failed: Per-user icon file isn't where it's expected
(C:\WINNT\Profiles\Default User\Application
Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)
Re: [PATCH 2/4] shell32: Register standard known folders on initialization.
Mariusz Pluciński writes:
> +for(i=0; i < sizeof(CSIDL_Data)/sizeof(CSIDL_Data[0]); ++i)
> +{
> +if(!CSIDL_Data[i].szValueName)
> +{
> +FIXME("known folder %d has no value name, ignoring\n", i);
> +continue;
> +}
> +
> +/* FIXME: remove this check after fixing all known folders
> definitions */
> +if(is_knownfolder_registered(CSIDL_Data[i].id))
> +{
> +FIXME("known folder %d already registered, ignoring\n", i);
> +continue;
> +}
It's pretty annoying to see these fixmes on every prefix update. You
don't need them anyway, what needs to be done is clear from the code.
--
Alexandre Julliard
julli...@winehq.org
Re: [5/5] ddraw: Emulate a 24 bit depth format without stencil or padding
Am 23.08.2011 um 00:53 schrieb Henri Verbeet: > On 23 August 2011 00:38, Stefan Dösinger wrote: >>> How is WINED3DFMT_D24_UNORM different from WINED3DFMT_X8D24_UNORM? >> It has a different application-visible ddraw format. > I'm not sure that really justifies adding duplicate formats in > wined3d. I see 3 alternatives: 1) Just change the ddraw pixelformat for X8D24. That would be covered by test results from some Windows HW(Radeon 9000M, WinXP), but we might break some games 2) Leave the status quo and blame bug 22434 on the app. That would be covered by test results from another Windows machine(Radeon X1600, WinXP) 3) Advertise both X8D24 versions if X8D24 is supported. Change ddraw_surface_init to make sure we don't have to convert back from the wined3d format. Then, once device_parent_create_depth_stencil is gone, we'll never convert wined3d depth formats to ddraw formats and we can support both X8D24 versions in ddraw without having two versions in wined3d. > Also, calling this D24_UNORM violates wined3d format naming > conventions. D24_UNORM would be a 3 byte format without padding. The ddraw format is already wrong. It claims to be 3 byte without padding, but as the test shows it actually has 1 padding byte. I think at the heart of this issue is that driver vendors couldn't agree how to represent a 3 byte depth with one byte padding format in a DDPIXELFORMAT structure. PGP.sig Description: Signierter Teil der Nachricht
Re: tools/winegcc: support a trailing / in paths to winebuild
On Mon, Aug 22, 2011 at 07:13:42PM +0200, Bernhard Loos wrote: > On Mon, Aug 22, 2011 at 7:02 PM, Jerome Leclanche wrote: > > That's to be fixed in bash-completion, not winegcc... > > Uhm, what's wrong with bash-completation? -B takes a directory as an > argument so bash adds a slash during autocomplete, that's ok. > gcc itself can also deal with a trailing / for -B, it's kinda > suprising, if this breaks in winegcc. bash has 'broken' many things by doing that. Traditionally directory paths wouldn't be expected to have a trailing '/'. David -- David Laight: da...@l8s.co.uk
