Hi
some example
ZwQueryDefaultLocale is located in ntoskrnl it call on NtQueryDefaultLocale
it is to get current keyboard name file ntoskrnl/ex/locale.c
in that file it exists all api to get and set the a keyboard.
a keyboard are being loading either from user mode or kmode.
in kmode it is loading by ntoskrnl or win32k depns on the case
which keyboard that is active are set by ntoskrnl not win32k
to get defult or current keyboard is the ntoskrnl jobb not win32k
so on.
so do not change my implement of NtUserGetKeyboardLayoutName
it is correct test in Windows and in ReactOS.
we need using same api as windows and same prototype.
even undocument thing. but what I provide is a start to use it.
but not complete what I did give about NtUser* so change it to 7 param
and use the protoype I gave u. use the x2 and x6 I put in, so we can change
it to same as windows when we got more informations how it works. I do not have
time to dig after any more doc about it.
one more thing
use the Zw* api when u call on ntoskrnl from win32k.
and the keyboard work are split betwin user32.dll, win32k.sys, ntoskrnl.
they doing diffeting thing, but theý are linked toghther like
user32.dll -> win32k.sys -> ntoskrnl.exe
| |
---------------
|
\ /
Keyboard drv
both talk with the keyboard drv
and can loading it depns on the case
all setting are done by ntoskrnl
and win32k is relay those msg when it is need it to ntoskrnl
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
> + if(!*phModule) DPRINT1( "Failed to load %wZ\n", &FullLayoutPath );
> + else DPRINT( "Loaded Keyboard Layout: %wZ\n", &FullLayoutPath );
Code like this might expand incorrectly, which is why it's highly
recommended to use {...}
- Thomas
Hi,
I recently decided to give a hand on the project. So I joined the IRC
channel and asked for ideas of applications I could make for ReactOS,
in order to make it more "complete". Alex Ionescu suggested, among
other ideas, an implementation of MMC.
So, I decided to jump on the idea. However, I have minimal knowledge
of COM programming in C and minimal knowledge of C++. Although, I have
good knowledge of assembly (x86), C in general, as well as VB6.
So, I decided to look at how MMC works. I quickly realized that I
would need to implement some interfaces (like IUnknown, for a simple
one). MingW doesn't seem to handle COM development very well. However,
I read in some places that it could support COM development when doing
pure C programming. I like the idea since I do know C much better than
C++... so I read the following tutorial:
http://www.codeproject.com/com/com_in_c1.asp
That was interesting until I tried to do that with MingW. No succes.
So, I'd like to know if someone managed to do that yet (ie a COM
"component", which implements interfaces).
Thanks,
--
Jacques Mony
Hi all,
After talking to some developers about the recent state of the ReactOS
tree, compiler times and disk space, I've analyzed our tree and found
the following preliminary round of changes that should be made to stay
in line with our policy that ReactOS provides what Windows does, at the
core level. Any extra functionality or applications not provided by
Windows have always been supposed to go into rosapps, as well as test
applications. For testing/regression testing, I actually recommend the
creation of a ros-tests repository, which will contain the tests in
rosapps plus the ones I've mentionned below.
This isn't just about disk space or compiling speed, but also to keep
our tree clean and conformant.
Here's the list:
\base\applications\devmgmt should go into a new folder called "mscutils"
along with similar MSC clones.
\base\applications\getfirefox should be removed.
\base\applications\devmgr should be removed.
\base\applications\downloader should be moved to rosapps.
\base\applications\gettype should be moved to rosapps.
\base\applications\ibrowser should be removed.
\base\applications\imagesoft shoudl be moved to rosapps.
\base\applications\network\roshttpd should be moved to rosapps.
\base\applications\reporterror should be removed.
\base\applications\screenshot should be moved to rosapps.
\base\applications\servman should go into a new folder called "mscutils"
along with similar MSC clones.
\base\applications\shutdown should go to \cmdutils.
\base\applications\sm should be removed.
\base\applications\testsets should go to rosapps.
\base\applications\utils should go to rosapps.
\base\applications\winefiel should to rosapps.
\base\services\dhcpd should go to rosapps.
\drivers\base\debugout should be removed.
\drivers\base\green should go to rosapps.
\drivers\base\ramdrv should go to rosapps.
\drivers\base\test should go to rosapps.
\drivers\filesystems\ext2 should go to rosapps.
\drivers\filesystems\minix should go to rosapps.
\drivers\filesystems\template should go to rosapps.
\drivers\multimedia\avtest should go to rosapps.
\drivers\network\tditest should go to rosapps.
\regtests should go to rosapps.
As well, there has been talk that \tools should become part of RosBE as
-O3, heavily optimized binaries on Windows.
They should stay in the default reactos trunk download, but building
them shouldn't be done on Windows unless the binaries can't be found or
the option has been forced. This will make bug reporting and testing
safer since we'll know the tools are the same ones the developers are
using (at least on Windows, where we can manage this better). I am very
much pushing for this change to happen, as it will make our life easier
for a variety of reasons:
- MSVC or GCC 4.2 -O3 tools decrease build times. A highly optimized
rbuild binary does dependency checking almost twice as fast as a regular
-Os binary.
- Decrease build times since the tools don't have to be rebuilt/cleaned
each time.
- Decrease storage space for developers that want to locally delete the
entire tree.
- Reduce the number of potential problems that outside testers might
have to due to improper building of their tools. The tools Microsoft
releases in the DDK are the same ones they use internally, so any bugs
appear on both versions, and it makes diagnosing a lot easier.
Unfortunately binaries can't be provided for Linux, but since /tools
would stay in the reactos directory, Linux builders would be completely
unaffected (except they wouldn't have the added advantages).
As far as I know, Aleksey, Christoph and Johannes are willing to back
this up and do the necessary changes for the /tools; I'll handle fixing
the .xml files and doing the tree moves.
--
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS
GreatLord told me about a regression that might be caused by one of my
patches.
In fact it was two patches working together:
1.) 25410, win32k: Make NtUserSetFocus accept NULL window.
This patch is correct. Win XP behaves the same way.
2.) 25412, user32.dll: remove focus from window, when it gets disabled
I have tested this and compared results to XP, I am sure it works the
same on XP. On XP when you disable a control you will hear a sound when
trying to use tab / arrow keys after that. Focus is not moved to another
control.
The regression coming from those patches is that on 2nd stage setup
keyboard focus is removed from the Back/Next buttons.
I found one problem in comctl32: When using PropSheet_SetWizButtons()
the appropriate button will be set as defpushbutton, but not recieve
focus. This can be corrected with a small patch, wich would solve most
of the regression.
But it introduces another bug:
On 2nd stage AckPage (2nd page) the focus should be set to username edit
control.
But it would be set to Next button, even if
SetFocus(<usernameeditcontrol>) was called after calling
PropSheet_SetWizButtons()
So I compiled syssetup as an exe to work on XP and tried to find out how
it works on XP.
On XP syssetup behaves the way that I think it should.
More testing gave me the following result: The propsheet sets the focus
automatically to the first editcontrol (maybe other controls, too,
didn't test) that was defined in the resource. It is independed from the
control ID and position of the control. Only thing that is important is
the position at wich the control was defined in the rc file.
So my question: How dows windows know the position of the control inside
the resource? Do we have something like that implemented in ROS?
Any help appreaceated.
Another minor thing: XP displays no focus rect (dotted rect on buttons
that have focus) until a tab / arrow key was used. Then it stays. It's
only a visual enhancement, but it woud be nice to also have this. Does
anyone know how win does this?
BTW: Should I patch comctl32 to fix that regression, or send a patch to
wine? I also have another patch for the updown control that behaves
incorrect with wine code.
And another thing: I first tried to execute syssetup.dll on XP with
rundll32 (rundll32.exe syssetup.dll,InstallWizard), but it said it could
not find InstallWizard. Can someone tell me why it does not work?
Greetings,
Timo
Hi all,
I just wanted to keep you update of the various ReactOS presentations,
lectures and exhibitions that I will be part of to help push ReactOS out
to more people.
Three weeks ago I was at CUSEC, where I demoed ReactOS in front of about
60 people, all software engineering students, mostly. They were very
impressed and I exchanged contact information with 5-6 of them, who hope
to join development eventually (probably this summer).
On Friday, I'm flying over to LA at SCALE 5x (South California Linux
Expo 2007) where Arty will be exhibiting ReactOS and I will be a speaker
to give a lecture on ReactOS and Open Source involvement.
A couple of weeks later, on the 27th, I'm flying over to University of
Waterloo to meet the students in their CS club and other interested
students in Software Engineering/CS to talk about ReactOS, my work, and
also on using ReactOS as an educational tool, possibly to replace their
current NachOS-based curriculum.
In April, on the 11th, I will be flying to Porto Alegre in Brezil, at
the 8th International Free Software Forum, where I will be a lecturer.
Again, I will talk about ReactOS -- although I haven't found a specific
topic yet, since I don't want to re-hash the SOCAL presentation.
I have also been invited to demo ReactOS at a DemoCamp in all of
Montreal, as far as I remember this date is in April as well.
The other date I am aware of is FOSSCON 2007, which will be on the 22nd
of September in San Diego (IIRC). Again, I will probably present about
ReactOS -- definite topic to be determined.
I have also mentionned ReactOS profusely in some personal interviews
which will appear in some Montreal and even worldwide newspapers, as
well as various online sources such as Slyck. My blog entry has recently
motivated a donor to donate 1000$ US to the foundation; I am working
with him to arrange a proper receipt.
I hope that throughout the year, I'll be able to announce more events.
--
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS
>From winddk.h:
#define NTKERNELAPI DECLSPEC_IMPORT
NTKERNELAPI
NTSTATUS
NTAPI
WmiCompleteRequest(
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp,
IN NTSTATUS Status,
IN ULONG BufferUsed,
IN CCHAR PriorityBoost);
In wmilib.c:
NTSTATUS
NTAPI
WmiCompleteRequest(IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp,
IN NTSTATUS Status,
IN ULONG BufferUsed,
IN CCHAR PriorityBoost)
winddk.h should be modified?
This difference (in the three functions) breaks build (also the
windows ddk define this as NTSTATUS only). (If i redefine the
functions in wmilib.c i get a strange bug in gcc:
[CC] drivers\wmi\wmilib.c
drivers\wmi\wmilib.c: In function 'WmiSystemControl':
drivers\wmi\wmilib.c:62: internal compiler error: in
rest_of_handle_final, at final.c:3942
Please submit a full bug report, with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
mingw32-make: *** [obj-i386\drivers\wmi\wmilib.o] Error 1
Best regards,
Logan_V8
Please have a look at that code:
NtGdiCreateCompatibleDC @ 192:
...
hNewDC = DC_AllocDC
<http://www.reactos.org/generated/doxygen/de/dcc/dc_8h.html#a12>(&OrigDC->DriverName
<http://www.reactos.org/generated/doxygen/d9/de9/struct__DC.html#o8>);
if (NULL == hNewDC)
{
DC_UnlockDc(OrigDC);
if (NULL != DisplayDC)
{
NtGdiDeleteObjectApp <http://www.reactos.org/generated/doxygen/d7/de8/subsystems_2win32_2win32k_2…>(DisplayDC);
}
return NULL;
}
NewDC = DC_LockDc( hNewDC );
...
I am not completely sure (GreatLord said it was fine) but i think it
might not be.
Let's think of a condition when process x, thread 0 does try call
NtGdiCreateCompatibleDC and Allocates the DC.
Wouldn't there be the chance of thread 1 to get a lock on the DC (by
guessing it's handle) just after it was created and make DC_LockDC
return NULL?
GDIOBJ_LockObj checks if the ProcessID is the same as
PsGetCurrentProcessId() , but not more.
So I think a second thread might do a timed attack and get a lock on the
just created DC.
