about commit 25758 is wrong

Hi
The commit 25758 are complete wrong, more I looking at more foualt I found

we are not longer windows comptable with the keyboard with this commit.
it mean win32k syscall does not longer working as it should do in windows.
and it also fuckup loading process of the keyboard.

example ntoskrnl is setting which defualt keyboard that should be in use and so
on. in current change it does ignore ntoskrnl setting. and when ntoskrnl trying
set it will mess up the keyboard loading.

the protype for NtUserLoadKeyboardLayoutEx look like this what I can figout
HKL STDCALL NtUserLoadKeyboardLayoutEx( IN HANDLE Handle, x2, x3, x4, IN HWINSTA
pProcessWindowStation, x6, IN INT Flags);

But x2 and x6 are not in use.
I have not figout x3,x4 yet

[Saveliy Tretiakov]

[e-mail] пишет:
> Hi
> The commit 25758 are complete wrong,

Hi! Your revert was wrong.
> we are not longer windows comptable with the keyboard with this commit.

We are fully windows compatible. This commit is compatible with all the 
apis documented in msdn.
I have a test application in the tree that shows my code is 100% working 
and compatible. What do you have?
> it mean win32k syscall does not longer working as it should do in windows.

Do you really know how it should work on windows? I'm sure you don't.
This syscall is not public api. It is not documented and there isn't any 
application that uses it. It is used internally by windows components.
We don't need to keep it windows-compatible because there is no 
applications to be compatible with.
James Tabor did some research on how this syscall work and he told me we 
don't have to do it that way.
> and it also fuckup loading process of the keyboard.

Huh? Where?
> example ntoskrnl is setting which defualt keyboard that should be in use and so
> on. in current change it does ignore ntoskrnl setting. and when ntoskrnl trying
> set it will mess up the keyboard loading.

Really? Can you point me a place in ntoskrnl where it is done? I 
searched through ntoskrnl code and found nothing.
> the protype for NtUserLoadKeyboardLayoutEx look like this what I can figout
> HKL STDCALL NtUserLoadKeyboardLayoutEx( IN HANDLE Handle, x2, x3, x4, IN HWINSTA
> pProcessWindowStation, x6, IN INT Flags);

This is not enough. I refuse to implement undocumented stuff without 
proper documentation.
And as I said above, we don't have to implement it.

If nobody objects, I will recommit my code tomorrow.

[Saveliy Tretiakov]

[e-mail] пишет:
> Hi
> The commit 25758 are complete wrong,

Hi! Your revert was wrong.
> we are not longer windows comptable with the keyboard with this commit.

We are fully windows compatible. This commit is compatible with all the
apis documented in msdn.
I have a test application in the tree that shows my code is 100% working
and compatible. What do you have?
> it mean win32k syscall does not longer working as it should do in windows.

Do you really know how it should work on windows? I'm sure you don't.
This syscall is not public api. It is not documented and there isn't any
application that uses it. It is used internally by windows components.
We don't need to keep it windows-compatible because there is no
applications to be compatible with.
James Tabor did some research on how this syscall work and he told me we
don't have to do it that way.
> and it also fuckup loading process of the keyboard.

Huh? Where?
> example ntoskrnl is setting which defualt keyboard that should be in use and so
> on. in current change it does ignore ntoskrnl setting. and when ntoskrnl trying
> set it will mess up the keyboard loading.

Really? Can you point me a place in ntoskrnl where it is done? I
searched through ntoskrnl code and found nothing.
> the protype for NtUserLoadKeyboardLayoutEx look like this what I can figout
> HKL STDCALL NtUserLoadKeyboardLayoutEx( IN HANDLE Handle, x2, x3, x4, IN HWINSTA
> pProcessWindowStation, x6, IN INT Flags);

This is not enough. I refuse to implement undocumented stuff without
proper documentation.
And as I said above, we don't have to implement it.

If nobody objects, I will recommit my code tomorrow.

[James Tabor]

Hi!
[e-mail] wrote:
> Hi
> The commit 25758 are complete wrong, more I looking at more foualt I found
>
> we are not longer windows comptable with the keyboard with this commit.
> it mean win32k syscall does not longer working as it should do in windows.
> and it also fuckup loading process of the keyboard.

We are trying to make it compatible.
> example ntoskrnl is setting which defualt keyboard that should be in use and so
> on. in current change it does ignore ntoskrnl setting. and when ntoskrnl trying
> set it will mess up the keyboard loading.
>
> the protype for NtUserLoadKeyboardLayoutEx look like this what I can figout
> HKL STDCALL NtUserLoadKeyboardLayoutEx( IN HANDLE Handle, x2, x3, x4, IN HWINSTA
> pProcessWindowStation, x6, IN INT Flags);

That proto is B.S. Need to do your research better. Start using root Hooks to figure
out what is being sent. I spent the whole last part of the summer figuring this keyboard
loading thingy. I had everything done but that offset arg. Looking through the Api logs,
there it is. The api monitors I use are trash and my hook crashes just about every
10 mins with out a log being made. Seeing this mail thread make me sick.

Simply! I did the research already!
> But x2 and x6 are not in use.
> I have not figout x3,x4 yet

I worked last night and part of the day,,,, watching this all from work!
Amazing!
James