- Ros-dev - ReactOS.org

Re: [ros-dev] [NTDLL/LDR] - Fix a few bugs (wrong variable usage, wrong variable initialization) which led to incorrect snapping of import address table.
by Minas Abrahamyan 30 Mar '11

30 Mar '11

Hi Alexey, Since you are still working on these LdrXXX functions then you maybe find possibility to add there some code to prevent them trapping into infinite cycle (bug 5881: http://www.reactos.org/bugzilla/show_bug.cgi?id=5881 ) While booted up with RAM 25 or 24 MB ROS kernel falls into infinite cycle there, but being booted up with 15 Mbs ROS stalls and and hangs up. To test it is enough to run it on any VM with 24Mb of RAM. What occurs there is infinite recursive calls, in form of LdrpLoadModule ->calls LdrFixupImports -> LdrpGetOrLoadModule -> LdrpLoadModule and so forth. (detailed bt is in bug 5881 description). Maybe ROS kernel doesn't check memory availability, something like XXXMalloc returning NULL or so. Thanks! -M.A. On Wed, Mar 23, 2011 at 4:25 PM, <fireball(a)svn.reactos.org> wrote: > Author: fireball > Date: Wed Mar 23 12:25:53 2011 > New Revision: 51123 > > URL: http://svn.reactos.org/svn/reactos?rev=51123&view=rev > Log: > [NTDLL/LDR] > - Fix a few bugs (wrong variable usage, wrong variable initialization) which led to incorrect snapping of import address table. > - Wrap LdrpSnapThunk() invocations into SEH. > > Modified: > trunk/reactos/dll/ntdll/ldr/ldrpe.c > > Modified: trunk/reactos/dll/ntdll/ldr/ldrpe.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/ntdll/ldr/ldrpe.c?rev=…

2 2

SSPI and Interactive logon GSOC Proposal
by Samuel serapion 30 Mar '11

30 Mar '11

Hello fellow ReactOS developers and users, Most of you might know me from IRC as encoded. I am a Computer Science student at the Polytechnic University of Puerto Rico. Although at times not the best IRC citizen, I've always had the best intentions for ReactOS at heart. The following is my proposal/plan outline for Implementing SSPI and secure authentication mechanisms for ReactOS, including Interactive Logon. First, some definitions: Security Support Provider Interface (SSPI) allows applications to use various security models available on a computer or network without changing the interface to the security system. SSPI does not establish logon credentials because that is generally a privileged operation handled by the operating system(LSA). Windows Challenge/Response (NTLM) is the authentication protocol used on systems running Windows. NTLM credentials are based on data obtained during the interactive logon process and consist of a domain name, a user name, and a one-way hash of the user's password. NTLM uses an encrypted challenge/response protocol to authenticate a user without sending the user's password over the wire(in case there is a wire). Instead, the system requesting authentication must perform a calculation that proves it has access to the secured NTLM credentials. Secure Channel, also known as Schannel, is a security support provider (SSP) that contains a set of security protocols that provide identity authentication and secure, private communication through encryption. Mainly SSL and TLS, with a variety of cipher options. Primary goals: - Utilize wine secur32 as starting point for implementing SSPI. - NTLM Security Support Provider (SSP) -- Authentication -- feature flags -- SignMessage -- VerifyMessage -- EncryptMessage -- DecryptMessage - Small, low footprint, maintainable code - Implement create credentials/logon/authentication in LSA -- LogonUser -- LsaConnectUntrusted -- others, as necessary. - Separate secur32 and schannel(wine has them unified) Secondary goals: - implement SSL/TLS/ptc SSP (using 3rd party libs) -- GnuTLS, OpenSSL are huge and have many dependencies -- secur32 is (theoretically) loaded and used by many system dlls, would be very bad if it is a performance/memory hog. -- Need to severely trim them down or use alternatives. - run extensive tests/fix other system code paths that have been dormant/stubs why wine secur32 is bad: - Wine is a *nix program so its ok for them to use dlopen(gnutls.so)... and use the system native library but we cant. - Uses fork() to call a program in winbind(samba extra) package! - if we want to use gnutls and such in reactos the following problems occur: -- too many dependencies -- problems running in native mode(lsa) -- big footprint -- too much code/hard to maintain - Wine's implementation of schannel loads GnuTLS, and is barely functional. - wine winhttp and wininet don't use schannel, and instead use OpenSSL directly to implement SSL and TLS. This can lead to confusing differences in certificate verification between applications. Ideally, schannel would use crypt32 for certificate chain verification, and winhttp and wininet would use schannel. (fixme later) -- good news is, wine crypt32 is relatively good and feature complete (at least seems that way).

3 2

GSoC: Kernel-Mode Test Suite
by Thomas Faber 30 Mar '11

30 Mar '11

Hi, I guess I don't have to introduce myself all that much anymore ;) Please see [1] if you disagree. I plan to submit a GSoC project proposal concerning the kernel-mode test suite, and would like to discuss a few key points to better shape the project idea and its timeline. Because of the broadness of the subject, I'm posting here to reach as many ears (er... eyes) as possible, hoping for feedback from people working on several different areas of ROS. My "state of mind" is currently the following regarding the project: Basic key points (I hope everyone agrees; please tell me if I'm wrong :p) - follow Winetest "feeling" - syntax for writing tests should be almost identical; like current kmtests demonstrate - tests should be startable individually from a command line launcher and follow Winetest behavior in that regard, so that an integration with Testman is made easy - code should be CMake and MSVC/WDK compatible from the beginning Ideas I deem useful (would appreciate any comments) - include buffer overrun checks, much like DPH (DPH can't be used for this though, can it?), using e.g. a guard/noaccess page behind each buffer. See [2] for a userland example; I'm working on a kernel-mode one - inspired by Winetest's broken(), one could make tests Windows-version specific. Something like [but better thought-out in syntax] ok(win2k3sp1(ret == 0) | win7x64sp1(ret == 1), ...) This would help compare different versions of Windows and much facilitate future kernel-target switching Questions - as there are ... many... kernel-mode functions, it is unfeasible to write tests for all during the project. My idea would be to create some very thorough sample tests, then focus on the most critical functions. "If there's time", thinly covering a more broad area might also be very useful (as extending existing tests is probably deemed easier than creating new ones by people later on). I have no doubt there's enough to do, ;) but would be interested to hear if you agree with the general strategy and what you think those "critical" areas might be. So what do you guys think? Excited for your input. Thanks. :) Regards, Tom [1] Hi! I'm Thomas, 23, from Germany, currently studying Computer Engineering in Berlin. I've been hanging out on IRC as ThFabba for some time now and submitted some hopefully-not-totally-useless patches ;) I'm interested in.... oh well, pretty much all parts of ROS. *g* Nice to meet you! [2] http://www.reactos.org/paste/index.php/8697/

2 1

Request for apply to GSoC 2011
by Fabio Cristini 30 Mar '11

30 Mar '11

Good day to all, my name is Fabio Cristini. I work as a software designer and developer in Italy, I'm a student in Software Engineering and I would like to apply for a React OS project proposal. I especially like the idea of implementing an SSH Service for Windows, and I hope I can do it for you (I like to develop an OpenSSH clone). Please let me know if you may be intrested. Fabio Cristini Italian, English +1 UTC fcristini(a)gmail.com (not registered yet) if you can contact me in private, I can give you more details and my full contact informations. Many thanks Time Commitment I can work at this project about 20 hours a week Optional (But Suggested) SSH Service for Windows http://www.reactos.org/wiki/Google_Summer_of_Code_2011_Ideas#SSH_Service Legal Requirements Students are required to affirm that the following is true. I hereby swear that I have not used nor seen the source code to any version of the Windows operating system nor any Microsoft product that may be related to the proposed project that is under a license incompatible with contribution to ReactOS, including but not limited to the leaked Windows 2000 source code and the Windows Research Kernel.

2 1

INTRODUCING MYSELF TO THE ROS COMMUNITY.
by Armaan 30 Mar '11

30 Mar '11

Hello friends, I am Syed Armani, i am a 3rd year computer science student at DCE ,NCR, INDIA Email: dce3062(a)gmail.com IRC: #armaan Jabber: syedarmani(a)jabber.org *ABOUT ME:* I have experience of - c/c++ - GUI development with c++. - python - java - lua - NETWORK PROTOCOLS - NETWORK PROGRAMMING - xhtml/css/javascript - Assembly (mid level 8085 n 8086) - BASH scripting. - VIRTUALIZATION, WORKING OF HYPERVISORS AND LIBVERT. - PHP - MYSQL - DEEP LEVEL LINUX OS - BASH SCRIPTING - LAMP/WAMP - WEB 2.0 - Android apps development I have a personality of a creative explorer and i always seek knowledge. I consider experience as a very very important thing. My wish is to take part in the development process of react os. Regards Syed Armani

2 1

Re: [ros-dev] unanswered gsoc mails
by Ged Murphy 30 Mar '11

30 Mar '11

Thanks for that guys, it's really helpful.... From: Ged Murphy [mailto:gedmurphy@gmail.com] Sent: 29 March 2011 11:22 To: 'ReactOS Development List' Subject: unanswered gsoc mails I've noticed there are quite a few emails to ros-dev regarding GSoC participation with no replies. Can someone reply to these in my absence, I won't be around for a few more days yet. As usual, I'm contactable by email and msn. Ged.

1 0

unanswered gsoc mails
by Gerard Murphy 29 Mar '11

29 Mar '11

I've noticed there are quite a few emails to ros-dev regarding GSoC participation with no replies. Can someone reply to these in my absence, I won't be around for a few more days yet. As usual, I'm contactable by email and msn. Ged.

1 0

Merging liveCD and Install CD
by Andrew Green 29 Mar '11

29 Mar '11

I have been thinking about what will be needed for my gsoc proposal. Merging the live cd and install cd of React OS is one of the goals. Though the file structure is different on the install and live cd. The install cd has all the React OS files in a cab file. While live cd has everything in a folder. I do understand the differences are larger than this. Though this has a large duplication of files. I assume having the files in folders is the best solution because the live cd needs access to the files directly. I was wondering what peoples preferred methods would be. People mentioned various things on irc. like extracting from the cab file on the fly, or installing the cab to ram disk and so on. I was wondering what peoples views is on what they would want. Feel free to say your preferences. I may not choose the best solution in my proposal because I will only have 3 or 4 weeks to work on that part. I personally don't think loosing the 100mb of saved space from the cab is a bad thing. It will still fit on 1 cd(i'm guessing 150-200mb) and is better than burning 2 cds(1 for live and 1 for install). Any comments or advice are much appreciated.

3 4

Re: [ros-dev] MP/UP HAL issues
by Love Nystrom 29 Mar '11

29 Mar '11

> > ---------- Forwarded message ---------- > From: Olaf Siejka <caemyr(a)gmail.com> > To: ReactOS Development List <ros-dev(a)reactos.org> > Date: Sun, 27 Mar 2011 14:35:18 +0200 > Subject: Re: [ros-dev] MP/UP HAL issues > "but *compile time* is not even 10% as important as *run time*." > > I think Love that you do not imagine what is the impact of buildtime in our > project. As ReactOS is not getting smaller, increased buildtime is simply > slowing down development pace by a considerable margin. It might be a worthy > tradeoff for a project with production version already, but not in our case. > Reaching over 10 minutes of buildtime requires really top of the line > hardware, not to mention dedicating whole host system to this task. For > average team member, it takes not 10 but even over 30-40 minutes to do a > full build. Time that is often so precious to spare. > Yes, Olaf, I *do* consider the impact of build time. It used to take me ~30 min to do a full build. This made me abandon the RAD "trial-and-error" rebuild paradigm, and return to the old-fashioned way of "running the code in my head" a number of times before doing another build. Now I have a faster machine and a full build takes ~10-15 min, but I still stick with the old-fashioned way of coding with those build times. As for time spared, consider this, You may save 2-5 min build time, but that time is paid for by millions of users, over and over and over again... *That* is what I mean. WBR // Love

1 0

Re: [ros-dev] MP/UP HAL issues
by Love Nystrom 29 Mar '11

29 Mar '11

> > ---------- Forwarded message ---------- > From: Timo Kreuzer <timo.kreuzer(a)web.de> > Subject: Re: [ros-dev] MP/UP HAL issues > > Am 26.03.2011 11:45, schrieb Love Nystrom: > To me, performance is *everything* .. > I gladly spend a *week* to gain significant performance, > especially if it also makes the code clearer and more readable! > > And what if it makes the code harder to read and maintain or if its likely > to introduce bugs later? Performance is great, but you need to be > reasonable. Saving a few clock cycles, saving you a microsecond per minute > runtime is not worth downgrading code quality. Its not even worth massively > increasing build time. > Ah.. Yes, *code clarity* (and proper comments) is of course a primary. We all know the headache of fixing code we wrote a year ago and didn't take the time to make stringent and/or comment properly. Btw. when I mention performance improvements, I meant in the order of at least > 5-10%. We all know that's never achieved by a cpl of asm tweaks, always by improved algorithms. As for Win7 I can't tell either way, since I don't have it.. Just a general note that apps that would fit well in 3MB RAM if written properly, now seem to hog up at least 30MB wherever it comes from, and runtime has gone the same way. C# + .NET issue perhaps? Or just incompetent newbie programmers running amok? Dropping single core processor support sound like a bad idea to me. > > Tell that MS, they did that with Windows Vista already. > I tried telling MS a lot of things.. Like fixing some of their bugs that *still live* since the days of NT4 at least. All I I ever got was a blatant "Won't Fix". So.. F them! Also I wasn't even talking about dropping the up kernel, I suggested > compiling it in a different manner, that would not allow inlining spinlock > functions as its done currently, but would cause them to be called. The > function would be linked as UP or SMP depending on whether we are using UP > or SMP kernel (can be done at link time or even at runtime). > I understand. > This way we save us the complete MP kernel build time (almost 2 minutes on > my machine). > Well.. as I said.. personally I don't give a hoot about another 2 minutes build time. > IMO it would also make it easier to maintain the SMP kernel. > Now *that* (code clarity and maintainability) is a more important issue IMO. In my book, that usually means using *the same code* with *minor* precomp switches. WBR // Love > >

1 0

Re: [ros-dev] MP/UP HAL issues
by Love Nystrom 27 Mar '11

27 Mar '11

> > ---------- Forwarded message ---------- > From: Timo Kreuzer <timo.kreuzer(a)web.de>\ > [abbreviated] > > I'm against wasting precious compile time for an MP hal that doesn't even > work. And I would actually like to have the kernel being compiled the same > way. I bet the performance improvements of inlining some spinlock code are > really neglectable. > I hate being a spoilsport, especially on an issue that may have gone stale already, but *compile time* is not even 10% as important as *run time*. I dunno about the particulars in this case, it's just a general priority opinion. To me, performance is *everything* .. I gladly spend a *week* to gain significant performance, especially if it also makes the code clearer and more readable! Is it just I who think that software is getting slower and slower and bigger and bigger these days? And I mean particularly the goo gaa that comes out of Redmond these days :-/ But as everybody in the world seems to play "Follow John" with Microsoft, users are left with software where they have to go for a coffe break after giving a command before their multicore superduper computers even give a burp, because programmers care less about runtime than compile time these days :( Blame the RAD frenzy for that! I'd even go as far as dropping UP support completely and hotpatching > spinlock functions. > Dropping single core processor support sound like a bad idea to me. W.B.R. // Love

4 3

[GSOC]GUI first stage installer
by Andrew Green 26 Mar '11

26 Mar '11

I'm looking to put in a proposal for gui 1st stage installer. I've asked around a bit on IRC who would be the mentor. Though no one seems to know. If anyone could point me in the right direction that would be great. I was thinking of how it would be implemented. I know the gui mostly exists in svn. so that simplifies that. I was thinking that the parts of the project would be setting it up so that as much code is shared between text-mode installer and gui installer. 1st stage gui installer should be able to run in windows as well as ros(this could simplify the install when using windows and make it easy to test the installer) Also fixing the functions that are used. As it seems at the moment disk drives are not appearing as devices. I have been unable to find an api that creates partitions. I thought this would be good rather than manipulating the disk directly as it may provide the ability to create partitions for any file system as long as a driver exists. Making it more flexible. I am also rather excited about this project as the skills that I gain from this could be used to make the disk manager, and other disk utilities. Any comments would be much appreciated.

3 4

Re: [ros-dev] [ros-diffs] [rharabien] 51135: [PSDK] Import strsafe.h from mingw-w64. It's more complete compared to our headers [DDK] Import ntstrsafe.h from mingw-w64 (converted from strsafe.h). It's more complete compared...
by Aleksey Bragin 26 Mar '11

26 Mar '11

We use SIZE_T throughout the kernel, so I don't understand why change a couple of places (out of thousands) to size_t ? Is there an incompatibility between strsafe headers and that type? Then it would need fixing instead. Also not sure if that was on purpose, but you also removed null- termination in ex/init.c, but it's not mentioned in the commit message. WBR, Aleksey Bragin. On Mar 26, 2011, at 12:42 AM, rharabien(a)svn.reactos.org wrote: > Author: rharabien > Date: Fri Mar 25 21:42:48 2011 > New Revision: 51135 > > URL: http://svn.reactos.org/svn/reactos?rev=51135&view=rev > Log: > [PSDK] > Import strsafe.h from mingw-w64. It's more complete compared to our > headers > > [DDK] > Import ntstrsafe.h from mingw-w64 (converted from strsafe.h). It's > more complete compared to our headers > > [NTOSKRNL] > Use sizeof instead of magic numbers > > Let's use strsafe functions now instead of strncpy/wcsncpy, which > doesn't always NULL terminate :) > > Modified: > trunk/reactos/base/applications/notepad/notepad.h > trunk/reactos/include/ddk/ntstrsafe.h > trunk/reactos/include/psdk/strsafe.h > trunk/reactos/ntoskrnl/ex/init.c > > [This mail would be too long, it was shortened to contain the URLs > only.] > > Modified: trunk/reactos/base/applications/notepad/notepad.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/ > applications/notepad/notepad.h?rev=51135&r1=51134&r2=51135&view=diff > > Modified: trunk/reactos/include/ddk/ntstrsafe.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/ddk/ > ntstrsafe.h?rev=51135&r1=51134&r2=51135&view=diff > > Modified: trunk/reactos/include/psdk/strsafe.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/psdk/ > strsafe.h?rev=51135&r1=51134&r2=51135&view=diff > > Modified: trunk/reactos/ntoskrnl/ex/init.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ex/ > init.c?rev=51135&r1=51134&r2=51135&view=diff > >

3 2

Re: [ros-dev] [ros-diffs] [rharabien] 51139: [WIN32K] Make sure strings returned by internal function RegQueryValue are NULL terminated
by Timo Kreuzer 26 Mar '11

26 Mar '11

This breaks REG_MULTI_SZ Am 25.03.2011 23:34, schrieb rharabien(a)svn.reactos.org: > Author: rharabien > Date: Fri Mar 25 22:34:53 2011 > New Revision: 51139 > > URL:http://svn.reactos.org/svn/reactos?rev=51139&view=rev > Log: > [WIN32K] > > Make sure strings returned by internal function RegQueryValue are NULL terminated > > Modified: > trunk/reactos/subsystems/win32/win32k/misc/registry.c > > Modified: trunk/reactos/subsystems/win32/win32k/misc/registry.c > URL:http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/misc/registry.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/misc/registry.c [iso-8859-1] Fri Mar 25 22:34:53 2011 > @@ -58,7 +58,7 @@ > ULONG cbInfoSize, cbDataSize; > > /* Check if the local buffer is sufficient */ > - cbInfoSize = sizeof(KEY_VALUE_PARTIAL_INFORMATION) + *pcbValue; > + cbInfoSize = FIELD_OFFSET(KEY_VALUE_PARTIAL_INFORMATION, Data) + *pcbValue; > if (cbInfoSize<= sizeof(ajBuffer)) > { > pInfo = (PVOID)ajBuffer; > @@ -89,8 +89,11 @@ > /* Did we get the right type */ > if (pInfo->Type == ulType) > { > - /* Copy the contents to the caller */ > - RtlCopyMemory(pvData, pInfo->Data, min(*pcbValue, cbDataSize)); > + /* Copy the contents to the caller. Make sure strings are null terminated */ > + if (ulType == REG_SZ || ulType == REG_MULTI_SZ || ulType == REG_EXPAND_SZ) > + RtlStringCbCopyNW((LPWSTR)pvData, *pcbValue, (LPWSTR)pInfo->Data, cbDataSize); > + else > + RtlCopyMemory(pvData, pInfo->Data, cbDataSize); > } > else > Status = STATUS_OBJECT_TYPE_MISMATCH; > > >

1 0

Re: [ros-dev] [ros-diffs] [rharabien] 51126: [NTOSKRNL] Revert r51108. ProbeForRead doesn't check if memory is readable. Improve comments and replace trick raising exception with call to ExRaiseAccessViolation. [WIN32K] Rem...
by Timo Kreuzer 24 Mar '11

24 Mar '11

Hi, Please also revert the call to ExRaiseAccessViolation. The behaviour is semi-documented here: http://www.uninformed.org/?v=10&a=2 There's a small but potentially important difference, which is the value of the faulting address. Thanks, Timo Am 23.03.2011 16:49, schrieb rharabien(a)svn.reactos.org: > Author: rharabien > Date: Wed Mar 23 15:49:44 2011 > New Revision: 51126 > > URL: http://svn.reactos.org/svn/reactos?rev=51126&view=rev > Log: > [NTOSKRNL] > Revert r51108. ProbeForRead doesn't check if memory is readable. > Improve comments and replace trick raising exception with call to ExRaiseAccessViolation. > > [WIN32K] > Remove ASSERTs in IntSetSysColors: this function is only called in NtUserSetSysColors in SEH block. It shouldn't crash for NULL pointers. > > Modified: > trunk/reactos/ntoskrnl/ex/exintrin.c > trunk/reactos/subsystems/win32/win32k/objects/stockobj.c > > Modified: trunk/reactos/ntoskrnl/ex/exintrin.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ex/exintrin.c?rev… > ============================================================================== > --- trunk/reactos/ntoskrnl/ex/exintrin.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ex/exintrin.c [iso-8859-1] Wed Mar 23 15:49:44 2011 > @@ -104,7 +104,6 @@ > IN ULONG Alignment) > { > ULONG_PTR Last, Current = (ULONG_PTR)Address; > - CHAR Temp; > PAGED_CODE(); > > /* Only probe if we have a valid length */ > @@ -132,16 +131,7 @@ > ExRaiseAccessViolation(); > } > > - /* Round down to the last page */ > - Last = PAGE_ROUND_DOWN(Last) + PAGE_SIZE; > - do > - { > - /* Attempt a read */ > - Temp = *(volatile CHAR*)Current; > - > - /* Go to the next address */ > - Current = PAGE_ROUND_DOWN(Current) + PAGE_SIZE; > - } while (Current != Last); > + /* ProbeForRead doesn't check if memory pages are readable! */ > } > } > > > Modified: trunk/reactos/subsystems/win32/win32k/objects/stockobj.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/ob… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/objects/stockobj.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/objects/stockobj.c [iso-8859-1] Wed Mar 23 15:49:44 2011 > @@ -221,9 +221,6 @@ > { > UINT i; > > - ASSERT(Elements); > - ASSERT(Colors); > - > for (i = 0; i< nColors; i++) > { > if ((UINT)(*Elements)< NUM_SYSCOLORS) > > >

1 0

GSOC Self-Presentation
by perencia 22 Mar '11

22 Mar '11

Hi!, my name is Pedro, and i'm a 5th grade student of computer science in Universitat Autonoma de Barcelona ( Spain ). I'd like to apply in this gsoc, i've always wanted to be part of an open-source project, i think it can be a really profitable and exciting experience to share ideas and discuss them with other motivated coders. Now as i'm finishing my last year i've found myself attracted by low-level questions. I've been aware of ReactOS for some time now - couple of years ago I downloaded the code and submitted a patch for the build system - actually, very silly patch :). About the projects proposed, some of them seem a bit heavy for me. At first the ACPI Hal cought my attention, since i'm doing my final year project en the energy-performance tradeoff in multi-cores, but it seems very daunting, i have no experience in kernel development nor drivers. Although is in Java where i'm really experienced, I'm confident with c and c++, and i'm very interested in COM, I've done some of it in DirectX and i really enjoyed that, so i thought the MMC Console seems more affordable. Anyway, i'd like to get some advice, if that's possible, about where i could direct myself, which project my profile may fit better or which has greater priority, and what can i do to start getting in contact to the project and make a better apply proposal. I hope this would be a beginning of a great and profitable experience for me and the community :)

3 3

Re: [ros-dev] [ros-diffs] [cfinck] 51118: Create a branch for Neeraj Yadav's work on the Audio Mixer
by Ged Murphy 22 Mar '11

22 Mar '11

This seems a little premature. I assume Neeraj is aware that there's no guarantee that the audio mixer will be one of the selected GSoC projects? I'm by no means suggesting that we would do this, but good business sense says that if someone is willing to work on a component outside of GSoC, isn't it counter-productive for the project to use one of their slots up? Anyway, we'll see what we have on the April 8 deadline. I wish Neeraj luck in both his application and his forthcoming work in reactos. Ged. -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of cfinck(a)svn.reactos.org Sent: 22 March 2011 12:46 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [cfinck] 51118: Create a branch for Neeraj Yadav's work on the Audio Mixer Author: cfinck Date: Tue Mar 22 12:45:40 2011 New Revision: 51118 URL: http://svn.reactos.org/svn/reactos?rev=51118&view=rev Log: Create a branch for Neeraj Yadav's work on the Audio Mixer Added: branches/nyadav-audio-branch/ - copied from r51117, trunk/

1 0

Introduction
by Neeraj Yadav 22 Mar '11

22 Mar '11

Hello, My name is Neeraj Yadav. I am an undergraduate student of Indian Institute of Technology, Delhi studying Textile Engineering.Besides my regular studies I have interest in Multimedia, Networking, Network-Programming and Security.I have a decent knowledge of C and C++ programming.I am familiar with git and svn.I am familiar with Linux, windows and Symbian APIs.I have experience of UI design with Qt. ReactOS is coming as my new interest and luckily this year ReactOS has been selected as a mentoring organisation.I find myself appropriate for SSH server implementation and Audio Mixer Project.

2 1

Re: [ros-dev] [ros-diffs] [rharabien] 51108: Fix ProbeForRead. It wasn't ever checking if memory can be accessed. Thanks to big-endian it wasn't breaking MmUserProbeAddress as well. Code is now nearly the same as in ProbeFo...
by Timo Kreuzer 22 Mar '11

22 Mar '11

Windows doesn't do any access checks in ProbeForRead, it only checks the range and alignment. The MmUserProbeAddress access is used to raise an exception with the appropriate parameters. So the old version was correct (except for the misleading comment maybe) Am 21.03.2011 15:43, schrieb rharabien(a)svn.reactos.org: > Author: rharabien > Date: Mon Mar 21 14:43:56 2011 > New Revision: 51108 > > URL: http://svn.reactos.org/svn/reactos?rev=51108&view=rev > Log: > Fix ProbeForRead. It wasn't ever checking if memory can be accessed. Thanks to big-endian it wasn't breaking MmUserProbeAddress as well. Code is now nearly the same as in ProbeForWrite. It shouldn't break anything. If it does, it's not bug in this code. :) > > Modified: > trunk/reactos/ntoskrnl/ex/exintrin.c > > Modified: trunk/reactos/ntoskrnl/ex/exintrin.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ex/exintrin.c?rev… > ============================================================================== > --- trunk/reactos/ntoskrnl/ex/exintrin.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ex/exintrin.c [iso-8859-1] Mon Mar 21 14:43:56 2011 > @@ -103,6 +103,8 @@ > IN SIZE_T Length, > IN ULONG Alignment) > { > + ULONG_PTR Last, Current = (ULONG_PTR)Address; > + CHAR Temp; > PAGED_CODE(); > > /* Only probe if we have a valid length */ > @@ -115,18 +117,31 @@ > (Alignment == 8) || > (Alignment == 16)); > > - /* Check for correct alignment */ > - if (((ULONG_PTR)Address& (Alignment - 1)) != 0) > + /* Check the alignment */ > + if ((Current& (Alignment - 1)) != 0) > { > /* Incorrect alignment */ > ExRaiseDatatypeMisalignment(); > } > - else if (((ULONG_PTR)Address + Length)< (ULONG_PTR)Address || > - ((ULONG_PTR)Address + Length)> (ULONG_PTR)MmUserProbeAddress) > + > + /* Get the end address */ > + Last = Current + Length - 1; > + if ((Last< Current) || (Last>= (ULONG_PTR)MmUserProbeAddress)) > + { > + /* Raise an access violation */ > + ExRaiseAccessViolation(); > + } > + > + /* Round down to the last page */ > + Last = PAGE_ROUND_DOWN(Last) + PAGE_SIZE; > + do > { > /* Attempt a read */ > - *(volatile CHAR* const)MmUserProbeAddress = 0; > - } > + Temp = *(volatile CHAR*)Current; > + > + /* Go to the next address */ > + Current = PAGE_ROUND_DOWN(Current) + PAGE_SIZE; > + } while (Current != Last); > } > } > > > >

2 2

Server down
by Pierre Schweitzer 22 Mar '11

22 Mar '11

Hi, both doxygen.reactos.org & iso.reactos.org are down (which results in daily builds isos not being uploaded). Anyone able to fix them? Regards, P. Schweitzer

1 0

HAL multi-targeted build
by Pierre Schweitzer 22 Mar '11

22 Mar '11

Hi, currently working on HAL and HAL targets (ACPI, MP, UP and so on), I discovered a quite bad issue in our build process. Just look at the function HalInitSystem@8 (halinit.c), depending on the build target we don't add the same code (look at CONFIG_SMP, which is only defined for HAL MP). But, currently, as we are building using HAL library for reducing code redudancy, this halinit.c file is only built ONCE. So, build targets aren't taken into account (MP, ACPI). So, two choices, or we break that model, and forget about lib, and just keep base .rbuild (hal.rbuild, halacpi.rbuild, and so forth) with all files defined in those. Or with find something smarter better such as rebuilding the lib with the new flags for each build? Or finding a way to include .rbuild files in other rbuild files? I'm not really sure about the way to proceed, that's why I "release" that question to the whole ML. Furthermore, could CMAKE be any use here? To facilitate the process? Regards, P. Schweitzer

4 6

'Security Controls' GSoC Idea
by Guillaume Touron 21 Mar '11

21 Mar '11

Hello RoS developers, I introduce myself. I'm Guillaume Touron, I'm a French engineering student at National School of Computer Science and Applied Mathematics with specialization in information systems and security. Apart from my studies I am interested in OS development, Windows internals and application security (vulnerabilities, reverse engineering, rootkits...). I read a lot about how Windows internals work (kernel data structures...) and Windows security. I have also some experience in NT driver development and kernel debugger (WinDBG). For many months now, I study RoS source code, and especially ntoskrnl source. This includes object manager, i/o manager, security layer, traps/exceptions management... I checkouted source code and installed RoS build environment and I'm ready to begin development. I also took a look at Se* kernel exported APIs, and tried to understand how security checks were performed. That's why I'm interested in RoS GSoC Idea 'Security Controls'. Indeed, implementing this feature would be a good start to add multiuser experience in RoS which is currently missing, and to manage efficiently users and groups. I think I know what is needed to complete this project successfully and I'm ready to write a detailed presentation/proposal to explain what I understand and what would be my goals. I also did GSoC 2010 last year for Honeynet Project on network security area, but I'm more interested in kernel development. Finally, few questions : What should I do to propose in a formal way my proposal to RoS community ? Is it an obligation to have already send some patches or can we begin development as a new contributor ? Who can I contact to speak about technical details ? Thank you very much.

4 9

Re: [ros-dev] [ros-diffs] [rharabien] 51103: Don't destroy ImageList used by ListView if control was created without LVS_SHAREIMAGELISTS flag Fixes crashes when closing RegEdit, RApps and hardware tab in mouse settings.
by Gabriel ilardi 21 Mar '11

21 Mar '11

Welcome to the jungle! Nice to see you committing. Good luck and have fun! > Date: Mon, 21 Mar 2011 14:07:30 +0000 > To: ros-diffs(a)reactos.org > From: rharabien(a)svn.reactos.org > Subject: [ros-diffs] [rharabien] 51103: Don't destroy ImageList used by ListView if control was created without LVS_SHAREIMAGELISTS flag Fixes crashes when closing RegEdit, RApps and hardware tab in mouse settings. > > Author: rharabien > Date: Mon Mar 21 14:07:29 2011 > New Revision: 51103 > > URL: http://svn.reactos.org/svn/reactos?rev=51103&view=rev > Log: > Don't destroy ImageList used by ListView if control was created without LVS_SHAREIMAGELISTS flag > Fixes crashes when closing RegEdit, RApps and hardware tab in mouse settings. > > Modified: > trunk/reactos/base/applications/rapps/winmain.c > trunk/reactos/base/applications/regedit/childwnd.c > trunk/reactos/dll/cpl/input/settings.c > > Modified: trunk/reactos/base/applications/rapps/winmain.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/rapps/wi… > ============================================================================== > --- trunk/reactos/base/applications/rapps/winmain.c [iso-8859-1] (original) > +++ trunk/reactos/base/applications/rapps/winmain.c [iso-8859-1] Mon Mar 21 14:07:29 2011 > @@ -10,7 +10,6 @@ > > HWND hMainWnd; > HINSTANCE hInst; > -HIMAGELIST hImageListView = NULL; > HIMAGELIST hImageTreeView = NULL; > INT SelectedEnumType = ENUM_ALL_COMPONENTS; > SETTINGS_INFO SettingsInfo; > @@ -168,8 +167,8 @@ > { > WCHAR szBuffer1[MAX_STR_LEN], szBuffer2[MAX_STR_LEN]; > HICON hIcon; > - > - if (hImageListView) ImageList_Destroy(hImageListView); > + HIMAGELIST hImageListView; > + > (VOID) ListView_DeleteAllItems(hListView); > > /* Create image list */ > @@ -208,7 +207,11 @@ > } > > /* Set image list for ListView */ > - (VOID) ListView_SetImageList(hListView, hImageListView, LVSIL_SMALL); > + hImageListView = ListView_SetImageList(hListView, hImageListView, LVSIL_SMALL); > + > + /* Destroy old image list */ > + if (hImageListView) > + ImageList_Destroy(hImageListView); > > SelectedEnumType = EnumType; > > @@ -725,7 +728,6 @@ > FreeAvailableAppList(); > if (IS_INSTALLED_ENUM(SelectedEnumType)) > FreeInstalledAppList(); > - if (hImageListView) ImageList_Destroy(hImageListView); > if (hImageTreeView) ImageList_Destroy(hImageTreeView); > > PostQuitMessage(0); > > Modified: trunk/reactos/base/applications/regedit/childwnd.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/regedit/… > ============================================================================== > --- trunk/reactos/base/applications/regedit/childwnd.c [iso-8859-1] (original) > +++ trunk/reactos/base/applications/regedit/childwnd.c [iso-8859-1] Mon Mar 21 14:07:29 2011 > @@ -65,7 +65,7 @@ > ReleaseDC(hWnd, hdc); > } > > -static void ResizeWnd(ChildWnd* pChildWnd, int cx, int cy) > +static void ResizeWnd(int cx, int cy) > { > HDWP hdwp = BeginDeferWindowPos(3); > RECT rt, rs, rb; > @@ -77,12 +77,12 @@ > GetWindowRect(hStatusBar, &rs); > cy = rs.bottom - rs.top; > } > - GetWindowRect(pChildWnd->hAddressBtnWnd, &rb); > - cx = pChildWnd->nSplitPos + SPLIT_WIDTH/2; > - DeferWindowPos(hdwp, pChildWnd->hAddressBarWnd, 0, rt.left, rt.top, rt.right-rt.left - tHeight-2, tHeight, SWP_NOZORDER|SWP_NOACTIVATE); > - DeferWindowPos(hdwp, pChildWnd->hAddressBtnWnd, 0, rt.right - tHeight, rt.top, tHeight, tHeight, SWP_NOZORDER|SWP_NOACTIVATE); > - DeferWindowPos(hdwp, pChildWnd->hTreeWnd, 0, rt.left, rt.top + tHeight+2, pChildWnd->nSplitPos-SPLIT_WIDTH/2-rt.left, rt.bottom-rt.top-cy, SWP_NOZORDER|SWP_NOACTIVATE); > - DeferWindowPos(hdwp, pChildWnd->hListWnd, 0, rt.left+cx, rt.top + tHeight+2, rt.right-cx, rt.bottom-rt.top-cy, SWP_NOZORDER|SWP_NOACTIVATE); > + GetWindowRect(g_pChildWnd->hAddressBtnWnd, &rb); > + cx = g_pChildWnd->nSplitPos + SPLIT_WIDTH/2; > + DeferWindowPos(hdwp, g_pChildWnd->hAddressBarWnd, 0, rt.left, rt.top, rt.right-rt.left - tHeight-2, tHeight, SWP_NOZORDER|SWP_NOACTIVATE); > + DeferWindowPos(hdwp, g_pChildWnd->hAddressBtnWnd, 0, rt.right - tHeight, rt.top, tHeight, tHeight, SWP_NOZORDER|SWP_NOACTIVATE); > + DeferWindowPos(hdwp, g_pChildWnd->hTreeWnd, 0, rt.left, rt.top + tHeight+2, g_pChildWnd->nSplitPos-SPLIT_WIDTH/2-rt.left, rt.bottom-rt.top-cy, SWP_NOZORDER|SWP_NOACTIVATE); > + DeferWindowPos(hdwp, g_pChildWnd->hListWnd, 0, rt.left+cx, rt.top + tHeight+2, rt.right-cx, rt.bottom-rt.top-cy, SWP_NOZORDER|SWP_NOACTIVATE); > EndDeferWindowPos(hdwp); > } > > @@ -111,7 +111,7 @@ > last_split = -1; > GetClientRect(hWnd, &rt); > g_pChildWnd->nSplitPos = x; > - ResizeWnd(g_pChildWnd, rt.right, rt.bottom); > + ResizeWnd(rt.right, rt.bottom); > ReleaseCapture(); > } > > @@ -125,7 +125,6 @@ > > static BOOL _CmdWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) > { > - ChildWnd* pChildWnd = g_pChildWnd; > HTREEITEM hSelection; > HKEY hRootKey; > LPCTSTR keyPath, s; > @@ -143,18 +142,18 @@ > /* TODO */ > break; > case ID_TREE_EXPANDBRANCH: > - (void)TreeView_Expand(pChildWnd->hTreeWnd, TreeView_GetSelection(pChildWnd->hTreeWnd), TVE_EXPAND); > + (void)TreeView_Expand(g_pChildWnd->hTreeWnd, TreeView_GetSelection(g_pChildWnd->hTreeWnd), TVE_EXPAND); > break; > case ID_TREE_COLLAPSEBRANCH: > - (void)TreeView_Expand(pChildWnd->hTreeWnd, TreeView_GetSelection(pChildWnd->hTreeWnd), TVE_COLLAPSE); > + (void)TreeView_Expand(g_pChildWnd->hTreeWnd, TreeView_GetSelection(g_pChildWnd->hTreeWnd), TVE_COLLAPSE); > break; > case ID_TREE_RENAME: > - SetFocus(pChildWnd->hTreeWnd); > - (void)TreeView_EditLabel(pChildWnd->hTreeWnd, TreeView_GetSelection(pChildWnd->hTreeWnd)); > + SetFocus(g_pChildWnd->hTreeWnd); > + (void)TreeView_EditLabel(g_pChildWnd->hTreeWnd, TreeView_GetSelection(g_pChildWnd->hTreeWnd)); > break; > case ID_TREE_DELETE: > - hSelection = TreeView_GetSelection(pChildWnd->hTreeWnd); > - keyPath = GetItemPath(pChildWnd->hTreeWnd, hSelection, &hRootKey); > + hSelection = TreeView_GetSelection(g_pChildWnd->hTreeWnd); > + keyPath = GetItemPath(g_pChildWnd->hTreeWnd, hSelection, &hRootKey); > > if (keyPath == 0 || *keyPath == 0) > { > @@ -164,18 +163,18 @@ > DeleteNode(g_pChildWnd->hTreeWnd, 0); > break; > case ID_TREE_EXPORT: > - ExportRegistryFile(pChildWnd->hTreeWnd); > + ExportRegistryFile(g_pChildWnd->hTreeWnd); > break; > case ID_EDIT_FIND: > FindDialog(hWnd); > break; > case ID_EDIT_COPYKEYNAME: > - hSelection = TreeView_GetSelection(pChildWnd->hTreeWnd); > - keyPath = GetItemPath(pChildWnd->hTreeWnd, hSelection, &hRootKey); > + hSelection = TreeView_GetSelection(g_pChildWnd->hTreeWnd); > + keyPath = GetItemPath(g_pChildWnd->hTreeWnd, hSelection, &hRootKey); > CopyKeyName(hWnd, hRootKey, keyPath); > break; > case ID_EDIT_NEW_KEY: > - CreateNewKey(pChildWnd->hTreeWnd, TreeView_GetSelection(pChildWnd->hTreeWnd)); > + CreateNewKey(g_pChildWnd->hTreeWnd, TreeView_GetSelection(g_pChildWnd->hTreeWnd)); > break; > case ID_EDIT_NEW_STRINGVALUE: > case ID_EDIT_NEW_BINARYVALUE: > @@ -183,8 +182,8 @@ > SendMessage(hFrameWnd, WM_COMMAND, wParam, lParam); > break; > case ID_SWITCH_PANELS: > - pChildWnd->nFocusPanel = !pChildWnd->nFocusPanel; > - SetFocus(pChildWnd->nFocusPanel? pChildWnd->hListWnd: pChildWnd->hTreeWnd); > + g_pChildWnd->nFocusPanel = !g_pChildWnd->nFocusPanel; > + SetFocus(g_pChildWnd->nFocusPanel? g_pChildWnd->hListWnd: g_pChildWnd->hTreeWnd); > break; > default: > if ((wID >= ID_TREE_SUGGESTION_MIN) && (wID <= ID_TREE_SUGGESTION_MAX)) > @@ -196,7 +195,7 @@ > s += _tcslen(s) + 1; > wID--; > } > - SelectNode(pChildWnd->hTreeWnd, s); > + SelectNode(g_pChildWnd->hTreeWnd, s); > break; > } > return FALSE; > @@ -317,7 +316,6 @@ > LRESULT CALLBACK ChildWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) > { > BOOL Result; > - ChildWnd* pChildWnd = g_pChildWnd; > > switch (message) > { > @@ -329,45 +327,45 @@ > /* load "My Computer" string */ > LoadString(hInst, IDS_MY_COMPUTER, buffer, sizeof(buffer)/sizeof(TCHAR)); > > - g_pChildWnd = pChildWnd = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(ChildWnd)); > - > - if (!pChildWnd) return 0; > - _tcsncpy(pChildWnd->szPath, buffer, MAX_PATH); > - pChildWnd->nSplitPos = 250; > - pChildWnd->hWnd = hWnd; > - pChildWnd->hAddressBarWnd = CreateWindowEx(WS_EX_CLIENTEDGE, _T("Edit"), NULL, WS_CHILD | WS_VISIBLE | WS_CHILDWINDOW | WS_TABSTOP, > + g_pChildWnd = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(ChildWnd)); > + if (!g_pChildWnd) return 0; > + > + _tcsncpy(g_pChildWnd->szPath, buffer, MAX_PATH); > + g_pChildWnd->nSplitPos = 250; > + g_pChildWnd->hWnd = hWnd; > + g_pChildWnd->hAddressBarWnd = CreateWindowEx(WS_EX_CLIENTEDGE, _T("Edit"), NULL, WS_CHILD | WS_VISIBLE | WS_CHILDWINDOW | WS_TABSTOP, > CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, > hWnd, (HMENU)0, hInst, 0); > - pChildWnd->hAddressBtnWnd = CreateWindowEx(WS_EX_CLIENTEDGE, _T("Button"), _T("Â»"), WS_CHILD | WS_VISIBLE | WS_CHILDWINDOW | WS_TABSTOP | BS_DEFPUSHBUTTON, > + g_pChildWnd->hAddressBtnWnd = CreateWindowEx(WS_EX_CLIENTEDGE, _T("Button"), _T("Â»"), WS_CHILD | WS_VISIBLE | WS_CHILDWINDOW | WS_TABSTOP | BS_DEFPUSHBUTTON, > CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, > hWnd, (HMENU)0, hInst, 0); > - pChildWnd->hTreeWnd = CreateTreeView(hWnd, pChildWnd->szPath, (HMENU) TREE_WINDOW); > - pChildWnd->hListWnd = CreateListView(hWnd, (HMENU) LIST_WINDOW/*, pChildWnd->szPath*/); > - SetFocus(pChildWnd->hTreeWnd); > + g_pChildWnd->hTreeWnd = CreateTreeView(hWnd, g_pChildWnd->szPath, (HMENU) TREE_WINDOW); > + g_pChildWnd->hListWnd = CreateListView(hWnd, (HMENU) LIST_WINDOW/*, g_pChildWnd->szPath*/); > + SetFocus(g_pChildWnd->hTreeWnd); > > /* set the address bar and button font */ > - if ((pChildWnd->hAddressBarWnd) && (pChildWnd->hAddressBtnWnd)) > + if ((g_pChildWnd->hAddressBarWnd) && (g_pChildWnd->hAddressBtnWnd)) > { > hFont = (HFONT)GetStockObject(DEFAULT_GUI_FONT); > - SendMessage(pChildWnd->hAddressBarWnd, > + SendMessage(g_pChildWnd->hAddressBarWnd, > WM_SETFONT, > (WPARAM)hFont, > 0); > - SendMessage(pChildWnd->hAddressBtnWnd, > + SendMessage(g_pChildWnd->hAddressBtnWnd, > WM_SETFONT, > (WPARAM)hFont, > 0); > } > /* Subclass the AddressBar */ > - oldproc = (WNDPROC)(LONG_PTR)GetWindowLongPtr(pChildWnd->hAddressBarWnd, GWL_WNDPROC); > - SetWindowLongPtr(pChildWnd->hAddressBarWnd, GWL_USERDATA, (DWORD_PTR)oldproc); > - SetWindowLongPtr(pChildWnd->hAddressBarWnd, GWL_WNDPROC, (DWORD_PTR)AddressBarProc); > + oldproc = (WNDPROC)(LONG_PTR)GetWindowLongPtr(g_pChildWnd->hAddressBarWnd, GWL_WNDPROC); > + SetWindowLongPtr(g_pChildWnd->hAddressBarWnd, GWL_USERDATA, (DWORD_PTR)oldproc); > + SetWindowLongPtr(g_pChildWnd->hAddressBarWnd, GWL_WNDPROC, (DWORD_PTR)AddressBarProc); > break; > } > case WM_COMMAND: > if(HIWORD(wParam) == BN_CLICKED) > { > - PostMessage(pChildWnd->hAddressBarWnd, WM_KEYUP, VK_RETURN, 0); > + PostMessage(g_pChildWnd->hAddressBarWnd, WM_KEYUP, VK_RETURN, 0); > } > else if (!_CmdWndProc(hWnd, message, wParam, lParam)) > { > @@ -383,7 +381,7 @@ > POINT pt; > GetCursorPos(&pt); > ScreenToClient(hWnd, &pt); > - if (pt.x>=pChildWnd->nSplitPos-SPLIT_WIDTH/2 && pt.x<pChildWnd->nSplitPos+SPLIT_WIDTH/2+1) > + if (pt.x>=g_pChildWnd->nSplitPos-SPLIT_WIDTH/2 && pt.x<g_pChildWnd->nSplitPos+SPLIT_WIDTH/2+1) > { > SetCursor(LoadCursor(0, IDC_SIZEWE)); > return TRUE; > @@ -392,10 +390,10 @@ > goto def; > case WM_DESTROY: > DestroyTreeView(); > - DestroyListView(pChildWnd->hListWnd); > + DestroyListView(g_pChildWnd->hListWnd); > DestroyMainMenu(); > - HeapFree(GetProcessHeap(), 0, pChildWnd); > - pChildWnd = NULL; > + HeapFree(GetProcessHeap(), 0, g_pChildWnd); > + g_pChildWnd = NULL; > PostQuitMessage(0); > break; > case WM_LBUTTONDOWN: > @@ -403,9 +401,9 @@ > RECT rt; > int x = (short)LOWORD(lParam); > GetClientRect(hWnd, &rt); > - if (x>=pChildWnd->nSplitPos-SPLIT_WIDTH/2 && x<pChildWnd->nSplitPos+SPLIT_WIDTH/2+1) > - { > - last_split = pChildWnd->nSplitPos; > + if (x>=g_pChildWnd->nSplitPos-SPLIT_WIDTH/2 && x<g_pChildWnd->nSplitPos+SPLIT_WIDTH/2+1) > + { > + last_split = g_pChildWnd->nSplitPos; > draw_splitbar(hWnd, last_split); > SetCapture(hWnd); > } > @@ -432,7 +430,7 @@ > RECT rt; > draw_splitbar(hWnd, last_split); > GetClientRect(hWnd, &rt); > - ResizeWnd(pChildWnd, rt.right, rt.bottom); > + ResizeWnd(rt.right, rt.bottom); > last_split = -1; > ReleaseCapture(); > SetCursor(LoadCursor(0, IDC_ARROW)); > @@ -476,9 +474,9 @@ > break; > > case WM_SETFOCUS: > - if (pChildWnd != NULL) > - { > - SetFocus(pChildWnd->nFocusPanel? pChildWnd->hListWnd: pChildWnd->hTreeWnd); > + if (g_pChildWnd != NULL) > + { > + SetFocus(g_pChildWnd->nFocusPanel? g_pChildWnd->hListWnd: g_pChildWnd->hTreeWnd); > } > break; > > @@ -486,22 +484,22 @@ > break; > > case WM_NOTIFY: > - if ((int)wParam == TREE_WINDOW) > + if ((int)wParam == TREE_WINDOW && g_pChildWnd != NULL) > { > switch (((LPNMHDR)lParam)->code) > { > case TVN_ITEMEXPANDING: > - return !OnTreeExpanding(pChildWnd->hTreeWnd, (NMTREEVIEW*)lParam); > + return !OnTreeExpanding(g_pChildWnd->hTreeWnd, (NMTREEVIEW*)lParam); > case TVN_SELCHANGED: > { > LPCTSTR keyPath, rootName; > LPTSTR fullPath; > HKEY hRootKey; > > - keyPath = GetItemPath(pChildWnd->hTreeWnd, ((NMTREEVIEW*)lParam)->itemNew.hItem, &hRootKey); > + keyPath = GetItemPath(g_pChildWnd->hTreeWnd, ((NMTREEVIEW*)lParam)->itemNew.hItem, &hRootKey); > if (keyPath) > { > - RefreshListView(pChildWnd->hListWnd, hRootKey, keyPath); > + RefreshListView(g_pChildWnd->hListWnd, hRootKey, keyPath); > rootName = get_root_key_name(hRootKey); > fullPath = HeapAlloc(GetProcessHeap(), 0, (_tcslen(rootName) + 1 + _tcslen(keyPath) + 1) * sizeof(TCHAR)); > if (fullPath) > @@ -512,7 +510,7 @@ > else > fullPath = _tcscpy(fullPath, rootName); > SendMessage(hStatusBar, SB_SETTEXT, 0, (LPARAM)fullPath); > - SendMessage(pChildWnd->hAddressBarWnd, WM_SETTEXT, 0, (LPARAM)fullPath); > + SendMessage(g_pChildWnd->hAddressBarWnd, WM_SETTEXT, 0, (LPARAM)fullPath); > HeapFree(GetProcessHeap(), 0, fullPath); > /* disable hive manipulation items temporarily (enable only if necessary) */ > EnableMenuItem(GetSubMenu(hMenuFrame,0), ID_REGISTRY_LOADHIVE, MF_BYCOMMAND | MF_GRAYED); > @@ -547,15 +545,15 @@ > } > break; > case NM_SETFOCUS: > - pChildWnd->nFocusPanel = 0; > + g_pChildWnd->nFocusPanel = 0; > break; > case TVN_BEGINLABELEDIT: > { > LPNMTVDISPINFO ptvdi; > /* cancel label edit for rootkeys */ > ptvdi = (LPNMTVDISPINFO) lParam; > - if (!TreeView_GetParent(pChildWnd->hTreeWnd, ptvdi->item.hItem) || > - !TreeView_GetParent(pChildWnd->hTreeWnd, TreeView_GetParent(pChildWnd->hTreeWnd, ptvdi->item.hItem))) > + if (!TreeView_GetParent(g_pChildWnd->hTreeWnd, ptvdi->item.hItem) || > + !TreeView_GetParent(g_pChildWnd->hTreeWnd, TreeView_GetParent(g_pChildWnd->hTreeWnd, ptvdi->item.hItem))) > return TRUE; > break; > } > @@ -571,14 +569,14 @@ > ptvdi = (LPNMTVDISPINFO) lParam; > if (ptvdi->item.pszText) > { > - keyPath = GetItemPath(pChildWnd->hTreeWnd, TreeView_GetParent(pChildWnd->hTreeWnd, ptvdi->item.hItem), &hRootKey); > + keyPath = GetItemPath(g_pChildWnd->hTreeWnd, TreeView_GetParent(g_pChildWnd->hTreeWnd, ptvdi->item.hItem), &hRootKey); > _sntprintf(szBuffer, sizeof(szBuffer) / sizeof(szBuffer[0]), _T("%s\\%s"), keyPath, ptvdi->item.pszText); > - keyPath = GetItemPath(pChildWnd->hTreeWnd, ptvdi->item.hItem, &hRootKey); > + keyPath = GetItemPath(g_pChildWnd->hTreeWnd, ptvdi->item.hItem, &hRootKey); > if (RegOpenKeyEx(hRootKey, szBuffer, 0, KEY_READ, &hKey) == ERROR_SUCCESS) > { > lResult = FALSE; > RegCloseKey(hKey); > - (void)TreeView_EditLabel(pChildWnd->hTreeWnd, ptvdi->item.hItem); > + (void)TreeView_EditLabel(g_pChildWnd->hTreeWnd, ptvdi->item.hItem); > } > else > { > @@ -594,15 +592,15 @@ > } > else > { > - if ((int)wParam == LIST_WINDOW) > + if ((int)wParam == LIST_WINDOW && g_pChildWnd != NULL) > { > switch (((LPNMHDR)lParam)->code) > { > case NM_SETFOCUS: > - pChildWnd->nFocusPanel = 1; > + g_pChildWnd->nFocusPanel = 1; > break; > default: > - if(!ListWndNotifyProc(pChildWnd->hListWnd, wParam, lParam, &Result)) > + if(!ListWndNotifyProc(g_pChildWnd->hListWnd, wParam, lParam, &Result)) > { > goto def; > } > @@ -616,27 +614,27 @@ > case WM_CONTEXTMENU: > { > POINT pt; > - if((HWND)wParam == pChildWnd->hListWnd) > + if((HWND)wParam == g_pChildWnd->hListWnd) > { > int i, cnt; > BOOL IsDefault; > pt.x = (short) LOWORD(lParam); > pt.y = (short) HIWORD(lParam); > - cnt = ListView_GetSelectedCount(pChildWnd->hListWnd); > - i = ListView_GetNextItem(pChildWnd->hListWnd, -1, LVNI_FOCUSED | LVNI_SELECTED); > + cnt = ListView_GetSelectedCount(g_pChildWnd->hListWnd); > + i = ListView_GetNextItem(g_pChildWnd->hListWnd, -1, LVNI_FOCUSED | LVNI_SELECTED); > if (pt.x == -1 && pt.y == -1) > { > RECT rc; > if (i != -1) > { > rc.left = LVIR_BOUNDS; > - SendMessage(pChildWnd->hListWnd, LVM_GETITEMRECT, i, (LPARAM) &rc); > + SendMessage(g_pChildWnd->hListWnd, LVM_GETITEMRECT, i, (LPARAM) &rc); > pt.x = rc.left + 8; > pt.y = rc.top + 8; > } > else > pt.x = pt.y = 0; > - ClientToScreen(pChildWnd->hListWnd, &pt); > + ClientToScreen(g_pChildWnd->hListWnd, &pt); > } > if(i == -1) > { > @@ -646,7 +644,7 @@ > { > HMENU mnu = GetSubMenu(hPopupMenus, PM_MODIFYVALUE); > SetMenuDefaultItem(mnu, ID_EDIT_MODIFY, MF_BYCOMMAND); > - IsDefault = IsDefaultValue(pChildWnd->hListWnd, i); > + IsDefault = IsDefaultValue(g_pChildWnd->hListWnd, i); > if(cnt == 1) > EnableMenuItem(mnu, ID_EDIT_RENAME, MF_BYCOMMAND | (IsDefault ? MF_DISABLED | MF_GRAYED : MF_ENABLED)); > else > @@ -657,7 +655,7 @@ > TrackPopupMenu(mnu, TPM_RIGHTBUTTON, pt.x, pt.y, 0, hFrameWnd, NULL); > } > } > - else if ((HWND)wParam == pChildWnd->hTreeWnd) > + else if ((HWND)wParam == g_pChildWnd->hTreeWnd) > { > TVHITTESTINFO hti; > HMENU hContextMenu; > @@ -677,13 +675,13 @@ > if (pt.x == -1 && pt.y == -1) > { > RECT rc; > - hti.hItem = TreeView_GetSelection(pChildWnd->hTreeWnd); > + hti.hItem = TreeView_GetSelection(g_pChildWnd->hTreeWnd); > if (hti.hItem != NULL) > { > - TreeView_GetItemRect(pChildWnd->hTreeWnd, hti.hItem, &rc, TRUE); > + TreeView_GetItemRect(g_pChildWnd->hTreeWnd, hti.hItem, &rc, TRUE); > pt.x = rc.left + 8; > pt.y = rc.top + 8; > - ClientToScreen(pChildWnd->hTreeWnd, &pt); > + ClientToScreen(g_pChildWnd->hTreeWnd, &pt); > hti.flags = TVHT_ONITEM; > } > else > @@ -693,19 +691,19 @@ > { > hti.pt.x = pt.x; > hti.pt.y = pt.y; > - ScreenToClient(pChildWnd->hTreeWnd, &hti.pt); > - (void)TreeView_HitTest(pChildWnd->hTreeWnd, &hti); > + ScreenToClient(g_pChildWnd->hTreeWnd, &hti.pt); > + (void)TreeView_HitTest(g_pChildWnd->hTreeWnd, &hti); > } > > if (hti.flags & TVHT_ONITEM) > { > hContextMenu = GetSubMenu(hPopupMenus, PM_TREECONTEXT); > - (void)TreeView_SelectItem(pChildWnd->hTreeWnd, hti.hItem); > + (void)TreeView_SelectItem(g_pChildWnd->hTreeWnd, hti.hItem); > > memset(&item, 0, sizeof(item)); > item.mask = TVIF_STATE | TVIF_CHILDREN; > item.hItem = hti.hItem; > - (void)TreeView_GetItem(pChildWnd->hTreeWnd, &item); > + (void)TreeView_GetItem(g_pChildWnd->hTreeWnd, &item); > > /* Set the Expand/Collapse menu item appropriately */ > LoadString(hInst, (item.state & TVIS_EXPANDED) ? IDS_COLLAPSE : IDS_EXPAND, buffer, sizeof(buffer) / sizeof(buffer[0])); > @@ -734,7 +732,7 @@ > } > > /* Come up with suggestions */ > - keyPath = GetItemPath(pChildWnd->hTreeWnd, NULL, &hRootKey); > + keyPath = GetItemPath(g_pChildWnd->hTreeWnd, NULL, &hRootKey); > SuggestKeys(hRootKey, keyPath, Suggestions, sizeof(Suggestions) / sizeof(Suggestions[0])); > if (Suggestions[0]) > { > @@ -758,16 +756,16 @@ > s += _tcslen(s) + 1; > } > } > - TrackPopupMenu(hContextMenu, TPM_RIGHTBUTTON, pt.x, pt.y, 0, pChildWnd->hWnd, NULL); > + TrackPopupMenu(hContextMenu, TPM_RIGHTBUTTON, pt.x, pt.y, 0, g_pChildWnd->hWnd, NULL); > } > } > break; > } > > case WM_SIZE: > - if (wParam != SIZE_MINIMIZED && pChildWnd != NULL) > - { > - ResizeWnd(pChildWnd, LOWORD(lParam), HIWORD(lParam)); > + if (wParam != SIZE_MINIMIZED && g_pChildWnd != NULL) > + { > + ResizeWnd(LOWORD(lParam), HIWORD(lParam)); > } > /* fall through */ > default: > > Modified: trunk/reactos/dll/cpl/input/settings.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/cpl/input/settings.c?r… > ============================================================================== > --- trunk/reactos/dll/cpl/input/settings.c [iso-8859-1] (original) > +++ trunk/reactos/dll/cpl/input/settings.c [iso-8859-1] Mon Mar 21 14:07:29 2011 > @@ -14,7 +14,6 @@ > #include "input.h" > > static HWND MainDlgWnd; > -static HIMAGELIST hImgList; > // for SaveInputLang() > static INT OldLayoutNum; > > @@ -299,7 +298,7 @@ > } > > static VOID > -InitLangList(HWND hWnd) > +InitLangList(HWND hWnd, HIMAGELIST hImgList) > { > HKEY hKey, hSubKey; > TCHAR szBuf[MAX_PATH], szPreload[CCH_LAYOUT_ID + 1], szSub[CCH_LAYOUT_ID + 1]; > @@ -370,11 +369,19 @@ > VOID > UpdateLayoutsList(VOID) > { > - (VOID) ImageList_Destroy(hImgList); > + HIMAGELIST hImgList; > + > + /* Clear the list */ > (VOID) ListView_DeleteAllItems(GetDlgItem(MainDlgWnd, IDC_KEYLAYOUT_LIST)); > + > + /* Crate new list */ > hImgList = ImageList_Create(16, 16, ILC_COLOR8 | ILC_MASK, 0, 1); > - InitLangList(MainDlgWnd); > - (VOID) ListView_SetImageList(GetDlgItem(MainDlgWnd, IDC_KEYLAYOUT_LIST), hImgList, LVSIL_SMALL); > + InitLangList(MainDlgWnd, hImgList); > + hImgList = ListView_SetImageList(GetDlgItem(MainDlgWnd, IDC_KEYLAYOUT_LIST), hImgList, LVSIL_SMALL); > + > + /* Destroy old image list */ > + if(hImgList) > + (VOID) ImageList_Destroy(hImgList); > } > > typedef struct _REG_KB_ENTRY_ > @@ -728,12 +735,14 @@ > { > case WM_INITDIALOG: > { > + HIMAGELIST hImgList; > + > MainDlgWnd = hwndDlg; > AddListColumn(hwndDlg); > (VOID) ListView_SetExtendedListViewStyle(GetDlgItem(MainDlgWnd, IDC_KEYLAYOUT_LIST), > LVS_EX_FULLROWSELECT); > hImgList = ImageList_Create(16, 16, ILC_COLOR8 | ILC_MASK, 0, 1); > - InitLangList(hwndDlg); > + InitLangList(hwndDlg, hImgList); > (VOID) ListView_SetImageList(GetDlgItem(MainDlgWnd, IDC_KEYLAYOUT_LIST), hImgList, LVSIL_SMALL); > } > break; > @@ -781,7 +790,6 @@ > } > break; > case WM_DESTROY: > - (VOID) ImageList_Destroy(hImgList); > break; > } > > >

1 0

Theming
by Andrew Green 21 Mar '11

21 Mar '11

I have been doing some investigation on theming. I have been looking into comctl32. One of the issues is that windows version 5 of the control has not theming and uses SxS so that applications that use version 6 will get themed controls. Currently comctl only has one version and applies theming regardless of the version the application requests. I have spoken on the Wine mailing list and the only person that replied did not want to use SxS. I assume to make it easier to maintain(though i don't understand why common parts cant share the same files and build 2 dlls). I was wondering what React OS developers think is the best choice. The second issue is that if comctl32 version 6 is loaded in windows it takes control of components that are usually in user32. Someone said this was called ( window class redirection). I can't really find any information on it. Though isn't this just registering the class except from comctl32? or does this cause a race condition(with the last one one loaded taking control)? is this is how "window class redirection" is different? Also the last thing is. Should sub classing be used? You should be able to load another window proc method even from user32 and call it when it is suitable from new control. I would imagine this could cause issues when the default procedure can't handle something as the new control would. Any advise would be much appreciated.

1 0

Uninitialized static variable in function
by Alexander Potashev 20 Mar '11

20 Mar '11

Hi, In the commit r51083 (http://git.reactos.org/?p=reactos.git;a=commitdiff;h=83ba2eecbf0ff43ec3a178…), please, initialize "i" to 0. Non-initialized variable store garbage, not zeroes. -- Alexander Potashev

5 8

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev