Ros-dev March 2011

ros-dev@reactos.org

34 participants
47 discussions

by Ged Murphy

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.

13 years, 8 months

unanswered gsoc mails

by Gerard Murphy

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.

13 years, 9 months

Merging liveCD and Install CD

by Andrew Green

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.

13 years, 9 months

Re: [ros-dev] MP/UP HAL issues

by Love Nystrom

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

13 years, 9 months

Re: [ros-dev] MP/UP HAL issues

by Love Nystrom

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

13 years, 9 months

Re: [ros-dev] MP/UP HAL issues

by Love Nystrom

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

13 years, 9 months

[GSOC]GUI first stage installer

by Andrew Green

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.

13 years, 9 months

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

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

13 years, 9 months

Re: [ros-dev] [ros-diffs] [rharabien] 51139: [WIN32K] Make sure strings returned by internal function RegQueryValue are NULL terminated

by Timo Kreuzer

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

13 years, 9 months

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

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

13 years, 9 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev March 2011