10 Feb
2007
10 Feb
'07
4:48 p.m.
magnus(a)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.