magnus@itkonsult-olsen.com пишет:
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.