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