kernel32: Correct log on / logon (noun / verb)
Evening Winos, Attached is a patch to correct some winerr messages. Specifically change a noun to a verb, and update the .po files with it. Firstly, could you take a look and point out any obvious errors I may have made? I have marked some of the translations fuzzy because it's not clear if the original translator realised that this should have been the verb and not the noun. A quick look through the translations on Wikipedia suggests that most languages do use different terms for the noun and the verb. https://cs.wikipedia.org/wiki/Login https://de.wikipedia.org/wiki/Login_(Informationstechnik) https://es.wikipedia.org/wiki/Login and so on. Some of these listings seem to use completely different words to the current translation in Wine so I wouldn't dare make a guess. Secondly, what do people think about the use of Can't as opposed to Cannot? I have not made the change in the patch but I'm wondering if people think that this should be done. Can't is informal and as my old English teacher would say, Can't is not a word! It is, but being pedantic cannot is probably the better choice. I assume Windows uses can't seen as it listed in winerror.mc. Thanks all! Ken From 180b6911bbc996df993f3e94f8d9c34da621cfad Mon Sep 17 00:00:00 2001 From: Ken Sharp kennyb...@o2.co.uk Date: Thu, 25 Jul 2013 00:17:15 +0100 Subject: kernel32: Correct logon / log on (noun / verb) --- dlls/kernel32/winerror.mc |6 +++--- po/ar.po |9 ++--- po/bg.po |6 +++--- po/ca.po | 15 --- po/cs.po |6 +++--- po/da.po |9 ++--- po/de.po |9 ++--- po/el.po |6 +++--- po/en.po |6 +++--- po/en_US.po | 12 ++-- po/eo.po |6 +++--- po/es.po | 12 +++- po/fa.po |6 +++--- po/fi.po |9 ++--- po/fr.po | 12 +++- po/he.po |6 +++--- po/hi.po |6 +++--- po/hr.po |6 +++--- po/hu.po |9 ++--- po/it.po |9 ++--- po/ja.po |9 ++--- po/ko.po |9 ++--- po/lt.po |9 ++--- po/ml.po |6 +++--- po/nb_NO.po |9 ++--- po/nl.po |9 ++--- po/or.po |6 +++--- po/pa.po |6 +++--- po/pl.po |9 ++--- po/pt_BR.po |9 ++--- po/pt_PT.po |9 ++--- po/rm.po |6 +++--- po/ro.po |6 +++--- po/ru.po | 12 +++- po/sk.po |6 +++--- po/sl.po |9 ++--- po/sr...@cyrillic.po |6 +++--- po/sr...@latin.po |6 +++--- po/sv.po |6 +++--- po/te.po |6 +++--- po/th.po |6 +++--- po/tr.po |6 +++--- po/uk.po |6 +++--- po/wa.po |6 +++--- po/wine.pot |6 +++--- po/zh_CN.po |6 +++--- po/zh_TW.po |9 ++--- 47 files changed, 209 insertions(+), 154 deletions(-) diff --git a/dlls/kernel32/winerror.mc b/dlls/kernel32/winerror.mc index b96831c..b302e8c 100644 --- a/dlls/kernel32/winerror.mc +++ b/dlls/kernel32/winerror.mc @@ -3441,17 +3441,17 @@ No more bindings. MessageId=1807 SymbolicName=ERROR_NOLOGON_INTERDOMAIN_TRUST_ACCOUNT Language=ENU -Can't logon with inter-domain trust account. +Can't log on with inter-domain trust account. . MessageId=1808 SymbolicName=ERROR_NOLOGON_WORKSTATION_TRUST_ACCOUNT Language=ENU -Can't logon with workstation trust account. +Can't log on with workstation trust account. . MessageId=1809 SymbolicName=ERROR_NOLOGON_SERVER_TRUST_ACCOUNT Language=ENU -Can't logon with server trust account. +Can't log on with server trust account. . MessageId=1810 SymbolicName=ERROR_DOMAIN_TRUST_INCONSISTENT diff --git a/po/ar.po b/po/ar.po index 9789501..7fd04e7 100644 --- a/po/ar.po +++ b/po/ar.po @@ -6328,15 +6328,18 @@ msgid No more bindings.\n msgstr Ùا ÙÙجد ٠رابط إضاÙÙØ©.\n #: winerror.mc:3446 -msgid Can't logon with inter-domain trust account.\n +#, fuzzy +msgid Can't log on with inter-domain trust account.\n msgstr ÙÙ Ùت٠Ù٠٠٠اÙÙÙÙج Ø¥Ù٠اÙرابط اÙداخÙ٠٠ع Øساب Ù ÙØ«ÙÙ.\n #: winerror.mc:3451 -msgid Can't logon with workstation trust account.\n +#, fuzzy +msgid Can't log on with workstation trust account.\n msgstr ÙÙ Ùت٠Ù٠٠٠اÙÙÙÙج Ø¥Ù٠اÙÙ Øطة ٠ع Øساب Ù ÙØ«ÙÙ.\n #: winerror.mc:3456 -msgid Can't logon with server trust
Re: [PATCH 1/6] scrrun: Store reference count inside IFileSystem3 object
On 7/25/2013 16:35, Piotr Caban wrote: --- dlls/scrrun/filesystem.c | 163 +++ 1 file changed, 123 insertions(+), 40 deletions(-) Why do you need this?
Re: [PATCH 1/6] scrrun: Store reference count inside IFileSystem3 object
On 07/25/13 14:36, Nikolay Sivov wrote: On 7/25/2013 16:35, Piotr Caban wrote: --- dlls/scrrun/filesystem.c | 163 +++ 1 file changed, 123 insertions(+), 40 deletions(-) Why do you need this? My bad, I was planning to store some kind of seed inside the object. I'll send a fixed version of these patch series (second patch is also broken). Thanks, Piotr
Re: [PATCH 4/5] d3dx9/tests: Add ID3DXConstantTable struct test.
2013/7/24 Rico Schüller kgbric...@web.de:
---
dlls/d3dx9_36/tests/shader.c | 308
+++
1 file changed, 308 insertions(+)
This is okay, but as a followup can you add some tests with mixed-type
structs? Something like:
struct
{
float f;
int i;
bool b;
};
If you have already written tests of this kind, I'd like to know what
does the compiler do in this case :)
Re: [PATCH 3/5] d3dx9: Add support for structs to ID3DXConstantTable.
2013/7/24 Rico Schüller kgbric...@web.de: --- dlls/d3dx9_36/shader.c | 79 -- 1 file changed, 77 insertions(+), 2 deletions(-) So there was actually a logic (an insane one, but yeah...). Have you found any game actually using this? Annoying question: have you checked if it's the same with newer d3dx9 dlls (e.g. d3dx9_43)? It still looks to me like buggy behavior and it might be that MS fixed that in later d3dx9 versions. This is not blocking the patch of course.
Re: [PATCH] winemac.drv: Advertise some legacy WGL extensions in the GL_EXTENSIONS string. (try 2)
On Jul 24, 2013, at 9:41 PM, Ken Thomases wrote: On Jul 24, 2013, at 9:34 PM, Charles Davis wrote: Try 2: Don't duplicate a constant string; we might need to add more legacy extensions. (Hopefully not. ;) Thanks for making that change. Looks good to me. Actually, on further thought I realize that we shouldn't be advertising WGL_EXT_swap_control unconditionally. It should be controlled by the AllowVerticalSync registry setting / allow_vsync variable. See load_extensions(). If vsync is disallowed, the corresponding functions are left as NULL in the OpenGL function table, so clients may crash if WGL_EXT_swap_control is advertised. Regards, Ken
Re: [PATCH] winemac.drv: Advertise some legacy WGL extensions in the GL_EXTENSIONS string. (try 2)
On Jul 25, 2013, at 9:57 AM, Ken Thomases wrote: If vsync is disallowed, the corresponding functions are left as NULL in the OpenGL function table, so clients may crash if WGL_EXT_swap_control is advertised. Well, this part is wrong. They won't crash because opengl32 protects against that, but still we shouldn't advertise it if support for it is disabled. -Ken
Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds.
I have no opinion on this sort of work-around (it should work afaict, and I haven't found any other places where we currently use toff_t), but did you file a bug with whatever distro has such broken headers?
Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds.
Actually, this will be a problem on libtiff 3.x, where toff_t really is supposed to be 32-bit.
Re: [PATCH] winemac.drv: Advertise some legacy WGL extensions in the GL_EXTENSIONS string. (try 3)
On Jul 25, 2013, at 10:49 AM, Charles Davis wrote: Try 3: Don't advertise WGL_EXT_swap_control if vsync is disabled. Looks good. Thanks, Ken
Re: Need help with debugging a directx9 game crashing
Hi Ken, On Thu, Jul 25, 2013 at 2:33 AM, Ken Thomases k...@codeweavers.com wrote: Hmm. You may need to mark the dummy array as volatile to prevent it from being optimized away. Worth trying. You might also increase the size of the array. You are right, thanks! Increasing the size of the array helps, the minimum working size I found is 588, I've attach the patch and the backtrace to Bug 34125. In my hack, I let: +char dummy[588]; +memset(dummy, 0x55, sizeof(dummy)); +dummy[4] = 0x88; +dummy[5] = 0x77; +dummy[6] = 0x66; +dummy[7] = 0x55; /* why 584 doesn't work? */ And I get a crashing like: Unhandled exception: page fault on read access to 0x55667788 in 32-bit code I've also hack wined3d/directx.c in a similar way, the minimum size is 592: +char dummy[592]; +memset(dummy, 0xee, sizeof(dummy)); +dummy[8] = 0xdd; +dummy[9] = 0xcc; +dummy[10] = 0xbb; +dummy[11] = 0xaa; /* why 584 and 588 doesn't work ? */ The crashing is like: Unhandled exception: page fault on read access to 0xaabbccdd in 32-bit code When combining the d3d9 hack and the wined3d hack, the behavior is the same to d3d9 hack only. I'll see how far I can get from here, also I'm open to any suggestion and appreciate to any help! Thanks again. -- Regards, Qian Hong - http://www.winehq.org
Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds.
I had filed a bug with Gentoo: https://bugs.gentoo.org/show_bug.cgi?id=459820 On Jul 25, 2013 5:31 PM, Vincent Povirk madewokh...@gmail.com wrote: I have no opinion on this sort of work-around (it should work afaict, and I haven't found any other places where we currently use toff_t), but did you file a bug with whatever distro has such broken headers?
Re: Need help with debugging a directx9 game crashing
Hi Qian, On Jul 25, 2013, at 11:53 AM, Qian Hong wrote: On Thu, Jul 25, 2013 at 2:33 AM, Ken Thomases k...@codeweavers.com wrote: Hmm. You may need to mark the dummy array as volatile to prevent it from being optimized away. Worth trying. You might also increase the size of the array. You are right, thanks! Increasing the size of the array helps, the minimum working size I found is 588, I've attach the patch and the backtrace to Bug 34125. In my hack, I let: +char dummy[588]; +memset(dummy, 0x55, sizeof(dummy)); +dummy[4] = 0x88; +dummy[5] = 0x77; +dummy[6] = 0x66; +dummy[7] = 0x55; /* why 584 doesn't work? */ And I get a crashing like: Unhandled exception: page fault on read access to 0x55667788 in 32-bit code I think your Valgrind results are telling us that there's a bug in the game where it's using an uninitialized stack variable. There's still a chance that it's something in Wine that's using the uninitialized variable and passing a garbage value to the game, causing it to crash. I'm not sure if Valgrind would attribute that to Wine for copying the uninitialized variable's value or to the game for using what Wine gave it. I _think_ Valgrind would blame Wine in that case. Since it's blaming the game, I lean toward the bug being in the game. There may not be any solution other than reporting the issue to the game developer. -Ken
Re: Need help with debugging a directx9 game crashing
On Fri, Jul 26, 2013 at 2:52 AM, Ken Thomases k...@codeweavers.com wrote: I think your Valgrind results are telling us that there's a bug in the game where it's using an uninitialized stack variable. There's still a chance that it's something in Wine that's using the uninitialized variable and passing a garbage value to the game, causing it to crash. I'm not sure if Valgrind would attribute that to Wine for copying the uninitialized variable's value or to the game for using what Wine gave it. I _think_ Valgrind would blame Wine in that case. Since it's blaming the game, I lean toward the bug being in the game. There may not be any solution other than reporting the issue to the game developer. Hmm, thanks a lot for the great analysis :) I've just sent a message to someone in the game company, not sure if they care :) -- Regards, Qian Hong - http://www.winehq.org
Re: Need help with debugging a directx9 game crashing
On Jul 25, 2013, at 2:11 PM, Qian Hong wrote: On Fri, Jul 26, 2013 at 2:52 AM, Ken Thomases k...@codeweavers.com wrote: I think your Valgrind results are telling us that there's a bug in the game where it's using an uninitialized stack variable. There's still a chance that it's something in Wine that's using the uninitialized variable and passing a garbage value to the game, causing it to crash. I'm not sure if Valgrind would attribute that to Wine for copying the uninitialized variable's value or to the game for using what Wine gave it. I _think_ Valgrind would blame Wine in that case. Since it's blaming the game, I lean toward the bug being in the game. There may not be any solution other than reporting the issue to the game developer. Hmm, thanks a lot for the great analysis :) I've just sent a message to someone in the game company, not sure if they care :) I suppose another possibility is that Wine is returning a value to the game which is causing it to take a code path it never takes on Windows and it's only this code path which results in the game reading the uninitialized variable. In that case, there's still a game bug, but we may be able to work around it by changing Wine. It's going to be really hard to figure out, though, without cooperation from the game developers. -Ken
Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds.
Vincent Povirk madewokh...@gmail.com wrote: I have no opinion on this sort of work-around (it should work afaict, and I haven't found any other places where we currently use toff_t), but did you file a bug with whatever distro has such broken headers? As far as I can see it's not a distro problem, it's a libtiff bug. Actually, this will be a problem on libtiff 3.x, where toff_t really is supposed to be 32-bit. Yes, it will be broken for libtiff3, I haven't looked yet how to detect a libtiff version at compile and run time, if you know how to do that please let me know. -- Dmitry.
