Ros-dev February 2007

ros-dev@reactos.org

23 participants
37 discussions

Re: [ros-dev] about commit 25758 is wrong
by magnus＠itkonsult-olsen.com 10 Feb '07

10 Feb '07

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

3 2

about commit 25758 is wrong
by magnus＠itkonsult-olsen.com 10 Feb '07

10 Feb '07

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

3 3

Re: [ros-dev] [ros-diffs] [tretiakov] 25758: Add multiple keyboard layout support. Implemented NtUserLoadKeyboardLayoutEx, NtUserActivateKeyboardLayout, NtUserGetKeyboardLayoutList, NtUserGetKeyboardLayoutName.
by Thomas Weidenmueller 10 Feb '07

10 Feb '07

> + 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

2 1

COM development with MingW for ReactOS
by Jacques Mony 10 Feb '07

10 Feb '07

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

1 0

Tree Cleanup
by Alex Ionescu 07 Feb '07

07 Feb '07

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

5 5

regression on 2nd stage setup
by Timo Kreuzer 07 Feb '07

07 Feb '07

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

1 0

My ReactOS PR Efforts
by Alex Ionescu 06 Feb '07

06 Feb '07

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

2 1

Re: [ros-dev] [ros-diffs] [tkreuzer] 25726: Make LoadCursorIconImage() find shared icons, even if they don't have the desired width/height. Now expl orer doesn't leak icons / bitmaps anymore. fixes bug 1554 See issue #1554 for more details.
by Murphy, Ged (Bolton) 05 Feb '07

05 Feb '07

tkreuzer(a)svn.reactos.org wrote: > + FreeResource(hResource); FreeResource is deprecated

2 1

Wmi declarations in wmilib stub
by Felipe Villarroel 04 Feb '07

04 Feb '07

>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

1 0

Security problem in NtGdiCreateCompatibleDC?
by Timo Kreuzer 03 Feb '07

03 Feb '07

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.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev February 2007