Ros-dev

ros-dev@reactos.org

5788 discussions

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

GSOC Self-Presentation

by perencia

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

13 years, 10 months

Re: [ros-dev] [ros-diffs] [cfinck] 51118: Create a branch for Neeraj Yadav's work on the Audio Mixer

by Ged Murphy

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/

13 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev