Re: [ros-dev] about commit 25758 is wrong

Thomas :
ZwQueryDefaultLocale  is located in ntoskrnl
and it is call on NtQueryDefaultLocale check by my self

let us take a look at NtUserGetKeyboardLayoutName
1. it return a keyboard name the keyboard name is
    the current active Keyboard LCID

to optain it we can use ZwQueryDefaultLocale
(check reactos code in ntoskrnl how it works)
so let us use ZwQueryDefaultLocale  to optain the
current activate keyboard with follow call
ZwQueryDefaultLocale(FALSE, &LocaleId);

what happen then let us take a look at ZwQueryDefaultLocale
if (UserProfile)
    *DefaultLocaleId = PsDefaultThreadLocaleId;
else
     *DefaultLocaleId = PsDefaultSystemLocaleId;

return DefaultLocaleId;

etiher we get current threed local or local system keyboard LCID with this call
depns on it is current user or not. depns what we whant.

so it is a correct impement to use it.

now we can check other thing as well
please check how it works in ntoskrnl in ex/local.c then we can talk how it
works.

[Saveliy Tretiakov]

You are wrong.
NtQueryDefaultLocale returns _default_ locale, not current thread's 
locale. Same with NtSetDefaultLocale.
This value is stored in registry! And it is the same for all threads in 
the system. Current locale may differ for different threads.
One thread may have US locale activated and another may have RU locale 
at the same time, while default locale may be set to DE, no matter.

Default thread's locale != current thread's locale.
> so do not change my implement of NtUserGetKeyboardLayoutName
> it is correct test in Windows and in ReactOS.

Your implementation of NtUserGetKeyboardLayoutName is a HACK. My code is 
correct.

[e-mail] пишет:
> Thomas :
> ZwQueryDefaultLocale  is located in ntoskrnl
> and it is call on NtQueryDefaultLocale check by my self
>
> let us take a look at NtUserGetKeyboardLayoutName
> it return a keyboard name the keyboard name is
>  the current active Keyboard LCID
>
> to optain it we can use ZwQueryDefaultLocale
> (check reactos code in ntoskrnl how it works)
> so let us use ZwQueryDefaultLocale  to optain the
> current activate keyboard with follow call
> ZwQueryDefaultLocale(FALSE, &LocaleId);
>
> what happen then let us take a look at ZwQueryDefaultLocale
> if (UserProfile)
>     *DefaultLocaleId = PsDefaultThreadLocaleId;
> else
>      *DefaultLocaleId = PsDefaultSystemLocaleId;
>
> return DefaultLocaleId;
>
> etiher we get current threed local or local system keyboard LCID with this call
> depns on it is current user or not. depns what we whant.
>
> so it is a correct impement to use it.
>
> now we can check other thing as well
> please check how it works in ntoskrnl in ex/local.c then we can talk how it
> works.
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Sylvain Petreolle]

--- Saveliy Tretiakov [e-mail] a écrit :
> You are wrong.
> NtQueryDefaultLocale returns _default_ locale, not current thread's 
> locale. Same with NtSetDefaultLocale.
> This value is stored in registry! And it is the same for all threads in 
> the system. Current locale may differ for different threads.
> One thread may have US locale activated and another may have RU locale 
> at the same time, while default locale may be set to DE, no matter.
>
> Default thread's locale != current thread's locale.
> > so do not change my implement of NtUserGetKeyboardLayoutName
> > it is correct test in Windows and in ReactOS.
>
> Your implementation of NtUserGetKeyboardLayoutName is a HACK. My code is 
> correct.

... and returns US when its configured as FR.
beeing a hack or nope, his implementation works.

Kind regards,
Sylvain Petreolle (aka Usurp)
--- --- --- --- --- --- --- --- --- --- --- --- ---
Run your favorite Windows apps with free ReactOS : http://www.reactos.org
Listen to non-DRMised Music: http://www.jamendo.com

[Saveliy Tretiakov]

Sylvain Petreolle пишет:
> beeing a hack or nope, his implementation works.

My implementation works too, and it works correct.

[James Tabor]

Saveliy Tretiakov wrote:
> Sylvain Petreolle пишет:
> > beeing a hack or nope, his implementation works.
>
> My implementation works too, and it works correct.

Yes, It's correct. When the keyboard was loaded at init or just another one
added. The name was already saved for the user.

BOOL
STDCALL
NtUserGetKeyboardLayoutName(
    LPWSTR lpszName)
{
    BOOL ret = FALSE;
    PKBL pKbl;

UserEnterShared();

_SEH_TRY
    {
       ProbeForWrite(lpszName, 9*sizeof(WCHAR), 1);
       pKbl = PsGetCurrentThreadWin32Thread()->KeyboardLayout;
       RtlCopyMemory(lpszName,  pKbl->Name, 9*sizeof(WCHAR));
       ret = TRUE;
    }
    _SEH_HANDLE
    {
       SetLastNtError(_SEH_GetExceptionCode());
       ret = FALSE;
    }
    _SEH_END;

UserLeave();
    return ret;
}

Okay,,,, We have to assume the current thread active keyboard (KLF_ACTIVATE)
is thread->KeyboardLayout.

Remember this is a multi-threaded thingy too. If we unload a keyboard, it will
need to sweep all the threads under that winstation. I think the current thread
holds the winstation. So,, it would be easy to sweep for a specific group of
threads.

WinStation0                  WinStation1
/=======================\          /===========\
|                       |          |           |
| [Display1] [Display2] |          | [Disply3] |
|                       |          |           |
=======================/          ===========/
             ^                            ^
            ps/2                         usb
             |                            |
             |                            |
         [Ru kb0 ]                    [Ru kb1 ]
              __________________________/
                           |
                      One kbdru.dll

(Note, assume ps/2 mouse associated with WinSta0 and usb mouse for WinSta1)

In this example we may need to add another item to the KBL structure or bring back
the previouse KBL structure for each thread again.

Thanks,
James

[Saveliy Tretiakov]

James Tabor пишет:
> Remember this is a multi-threaded thingy too. If we unload a keyboard, it will
> need to sweep all the threads under that winstation. I think the current thread
> holds the winstation. So,, it would be easy to sweep for a specific group of
> threads.

In windows, when one thread unloads layout used by other threads, it is 
not removed from system and can be still used.
It only gets marked as unloaded and dissapears from 
GetKeyboardLayoutList. That's why I added RefCount  to KBL.

[James Tabor]

Saveliy Tretiakov wrote:
> James Tabor пишет:
> > Remember this is a multi-threaded thingy too. If we unload a keyboard, it will
> > need to sweep all the threads under that winstation. I think the current thread
> > holds the winstation. So,, it would be easy to sweep for a specific group of
> > threads.
>
> In windows, when one thread unloads layout used by other threads, it is 
> not removed from system and can be still used.
> It only gets marked as unloaded and dissapears from 
> GetKeyboardLayoutList. That's why I added RefCount  to KBL.

Oh good! I did see that 8^)
James