Hello Dmitry,
Dmitry Timoshkov writes:
> >> fixme:string:GetLocaleInfoA 'SLANGUAGE' is not defined for your
> >> language (041F).
> >> Please define it in dlls/kernel/nls/YourLanguage.nls
> >> and submit patch for inclusion into the next Wine release.
>
> Looking into wine/dlls/kernel/nls directory, you could notice that
> 041f is an identifier for Turkish locale (trk.nls), and it of course
> don't define SLANGUAGE. So, the message is true. You should in this
> case either define it as suggested by the message above, or try to find,
> why your locale has such a strange detected value.
Yes, I know, that the message is true. I was just wondering, why it
was appearing with your patch and not before. I even added some bogus
values (because I do not know the right ones) to check if the real
problem would disappear with that, but it did not help.
> >Furthermore, the Toolbar-Icons in the file open/save dialog disappear,
> >when running with native shell and commdlg libraries.
>
> Perhaps it is an effect of the wrong detected locale.
No, the icons are still missing, even with values placed in the *.nls
files (and changing wine/dlls/kernel/locale_rc.rc to include the
missing languages).
> >Looking at your patch, I am not sure, if there should really be two
> >different search algorithms for FindResource and
> >FindResourceEx.
>
> My tests show that their behaviour is really different.
ok.
> I carefully readed all microsoft's documentation related to LoadString,
> FindResource, FindResourceEx, including this page (you already pointed
> out to it in the direct mail to me after my first patch).
Sorry, I did not know, if it was that one.
> However,
> I decided to write small test program to verify what documentation says
> with actual windows behaviour (you know, it is always helpful to not
> trust to ms' docs). The results were included in my patch. Anyone
> could either write own tests, or to use my ones (included with patch)
> and try to figure out some things that I didn't manage to.
Sure, I just wanted, that you do not break working applications, which
your patch did for me. I experimented a little bit with your test
program (under Wine and Windows 95) and was astonished, that Windows
returns LANG_NEUTRAL, SUBLANG_NEUTRAL with LoadStingA and
FindResourceA, even if the locale is set to another value and if there
is a resource for that locale in the executable. Your are right, the
document, I had pointed you too explains it in a different way.
> Anyway, could you please send to the traces +relay,+resource,+string?
> You could add some additional channels or even add your own messages
> and comments. I'll try to understand with your help what is going wrong.
The problems seems to be, that the application loads trys to access
some resource like this:
(FindResourceExA+0x37(hModule=0x30600000, type=0x2, name=0x1c85,
lang=0x0) [resource.c:349]) (ebp=406d3a80)
That is, it does explicitely request the default resource (the library
at 0x30600000 just contains german resources and it would load a
different library with another locale). Now with your patch, in
RES_FindResource2() we would call PE_FindResourceExW, since lang is
not 0xffff, but 0. I do not understand the rest completely, but that
resource is only found, if GetResDirEntryW is called with the
allowdefault flag set to true, which does not happen with your patch.
Also, I am not sure about the right patch. Currently you are using
0xfff to flag the situation, when PE_FindResourceW and (not ..ExW)
should be called. Maybe, we should use the value 0 here?
Greetings,
Peter
--
Peter Ganten
[EMAIL PROTECTED]
