Short leave of absence

[Alex Ionescu]

Hi,

I am currently entering the last 5 weeks of school of my last year, so 
I'm going to be focusing on that instead of ReactOS. Lately, I've tried 
to work on both, but this has delayed my code as well as hurt my grades. 
I intend to be back around the week of May 10th.

In the meanwhile, I would kindly like to ask developers to e-mail me if 
they have any plans to touch the following:

- Kernel Scheduler, Thread Creation, Context Switching, System 
Initialization. I have re-written everything for a faster and more 
complete system based on NT semantics. Includes everything from realtime 
support, proper dynamic and static priorities, real system thread 
support, much faster scheduling, pre-emption, removal of the PEB/TEB 64K 
block hack and ros-only members, better organized code and Mm routines 
for manipulating kernel stack/teb/peb, etc...

- Pushlocks. I have almost all the necessary support code written and 
I'm only missing one function.

- IRQL management in HAL and Spinlocks. I have highly modified the IRQL 
routines for a large increase in speed, as well as made spinlocks faster 
on UP and non-debug builds. I have also corrected some IRQL routines to 
use the proper KPCR members for the IRR and others.

- Object Manager. I have a complete re-write in progress which uses 
public NT structures instead of our internal ones, adds more security, 
and corrects some missing features and adds some. Majorly changes some 
aspects of the Ob (for example regarding on the status of handle/pointer 
count after creating an object, and the work of ObCreate/ObInsertObject, 
which is totally different in ROS vs NT. See blog article for more 
info). However, any bugs that are easy to fix should still be fixed in 
the current Ob. The new one is months away.

- Queued Spin Locks, KGATES, Guarded Mutex. I already know Filip is 
working on this and I was planning on collaborating with him. Unlike the 
previous things, I haven't actually *coded* anything regarding these, 
but I have the design in my head and would like to work on it, so I 
would love to share what I know if anyone is actively interested in 
working on it.

Once again, to clear up any misconceptions, I'm asking an email to know 
if anyone plans to work on this for the purposes of:
1) Not duplicating work
2) Sharing what information/code I might have written.

In any case, I'll be back in exactly one month, so I don't think it'll 
matter. You guys keep focusing on PnP and other stuff meanwhile, okay? 
*joke*

Best regards,
Alex Ionescu

[Casper Hornstrup]

Will you ever knowledge that rewriting large parts of ReactOS in your working copy
causes all sorts of problems, and start getting the changes into the repository in
smaller chunks or will you ignore these problems and continue to do this in the
future?

Casper
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Alex Ionescu
> Sent: 6. april 2005 00:11
> To: ReactOS Development List
> Subject: [ros-dev] Short leave of absence
>
> Hi,
>
> I am currently entering the last 5 weeks of school of my last year, so
> I'm going to be focusing on that instead of ReactOS. Lately, I've tried
> to work on both, but this has delayed my code as well as hurt my grades.
> I intend to be back around the week of May 10th.
>
> In the meanwhile, I would kindly like to ask developers to e-mail me if
> they have any plans to touch the following:
> Kernel Scheduler, Thread Creation, Context Switching, System
>
> Initialization. I have re-written everything for a faster and more
> complete system based on NT semantics. Includes everything from realtime
> support, proper dynamic and static priorities, real system thread
> support, much faster scheduling, pre-emption, removal of the PEB/TEB 64K
> block hack and ros-only members, better organized code and Mm routines
> for manipulating kernel stack/teb/peb, etc...
> Pushlocks. I have almost all the necessary support code written and
>
> I'm only missing one function.
> IRQL management in HAL and Spinlocks. I have highly modified the IRQL
>
> routines for a large increase in speed, as well as made spinlocks faster
> on UP and non-debug builds. I have also corrected some IRQL routines to
> use the proper KPCR members for the IRR and others.
> Object Manager. I have a complete re-write in progress which uses
>
> public NT structures instead of our internal ones, adds more security,
> and corrects some missing features and adds some. Majorly changes some
> aspects of the Ob (for example regarding on the status of handle/pointer
> count after creating an object, and the work of ObCreate/ObInsertObject,
> which is totally different in ROS vs NT. See blog article for more
> info). However, any bugs that are easy to fix should still be fixed in
> the current Ob. The new one is months away.
> Queued Spin Locks, KGATES, Guarded Mutex. I already know Filip is
>
> working on this and I was planning on collaborating with him. Unlike the
> previous things, I haven't actually *coded* anything regarding these,
> but I have the design in my head and would like to work on it, so I
> would love to share what I know if anyone is actively interested in
> working on it.
>
> Once again, to clear up any misconceptions, I'm asking an email to know
> if anyone plans to work on this for the purposes of:
> Not duplicating work
> Sharing what information/code I might have written.
>
> In any case, I'll be back in exactly one month, so I don't think it'll
> matter. You guys keep focusing on PnP and other stuff meanwhile, okay?
> *joke*
>
> Best regards,
> Alex Ionescu
> _______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://reactos.com:8080/mailman/listinfo/ros-dev

[art yerkes]

On Wed, 6 Apr 2005 09:34:25 +0200
"Casper Hornstrup" [e-mail] wrote:
> Will you ever knowledge that rewriting large parts of ReactOS in your working copy
> causes all sorts of problems, and start getting the changes into the repository in
> smaller chunks or will you ignore these problems and continue to do this in the
> future?
>
> Casper

I still don't see the huge deal here.  What's so wrong with dumping code in a branch
until it gets ripe?
-- 
Here's a simple experiment. Stand on a train track between two locomotives
which are pushing on you with equal force in opposite directions. You will
exhibit no net motion. None the less, you may soon begin to notice that
something important is happening.
-- Robert Stirniman

[Mark Junker]

Casper Hornstrup schrieb:
> Will you ever knowledge that rewriting large parts of ReactOS in your working copy
> causes all sorts of problems, and start getting the changes into the repository in
> smaller chunks or will you ignore these problems and continue to do this in the
> future?

As a developer you should know that it's sometimes impossible to do 
something in small steps. Maybe it's the same here.

Regards,
Mark

[Alex Ionescu]

Casper Hornstrup wrote:
> Will you ever knowledge that rewriting large parts of ReactOS in your working copy
> causes all sorts of problems, and start getting the changes into the repository in
> smaller chunks or will you ignore these problems and continue to do this in the
> future?
>
> Casper
> > Hi,
> >
> > I am currently entering the last 5 weeks of school of my last year, so
> > I'm going to be focusing on that instead of ReactOS. Lately, I've tried
> > to work on both, but this has delayed my code as well as hurt my grades.
> > I intend to be back around the week of May 10th.
> >
> > In the meanwhile, I would kindly like to ask developers to e-mail me if
> > they have any plans to touch the following:
> > Kernel Scheduler, Thread Creation, Context Switching, System
> >
> > Initialization. I have re-written everything for a faster and more
> > complete system based on NT semantics. Includes everything from realtime
> > support, proper dynamic and static priorities, real system thread
> > support, much faster scheduling, pre-emption, removal of the PEB/TEB 64K
> > block hack and ros-only members, better organized code and Mm routines
> > for manipulating kernel stack/teb/peb, etc...

Impossible to split into small parts. They are completely interlinked. 
This is a feature patch and will be in its own branch, like it was 
decided that we're supposed to do. Just like Hartmut's Cc rewrite.
> > Pushlocks. I have almost all the necessary support code written and
> >
> > I'm only missing one function.

Not a rewrite, a one file implementation. Less then 1000 lines.
> > IRQL management in HAL and Spinlocks. I have highly modified the IRQL
> >
> > routines for a large increase in speed, as well as made spinlocks faster
> > on UP and non-debug builds. I have also corrected some IRQL routines to
> > use the proper KPCR members for the IRR and others.

Split as two patches, one for IRQL and one for Spinlocks. Spinlock one 
will probably be < 200 lines, IRQL one will be the size of a file, and 
most certaintly ~500 lines.
> > Object Manager. I have a complete re-write in progress which uses
> >
> > public NT structures instead of our internal ones, adds more security,
> > and corrects some missing features and adds some. Majorly changes some
> > aspects of the Ob (for example regarding on the status of handle/pointer
> > count after creating an object, and the work of ObCreate/ObInsertObject,
> > which is totally different in ROS vs NT. See blog article for more
> > info). However, any bugs that are easy to fix should still be fixed in
> > the current Ob. The new one is months away.

Once again, a self-contained feature branch will be done for this.
> > Queued Spin Locks, KGATES, Guarded Mutex. I already know Filip is
> >
> > working on this and I was planning on collaborating with him. Unlike the
> > previous things, I haven't actually *coded* anything regarding these,
> > but I have the design in my head and would like to work on it, so I
> > would love to share what I know if anyone is actively interested in
> > working on it.

Not a rewrite, a three file implementation. Will be split in three 
patches, all which will be < 1000 lines.
Then QSL will be implementted step by step in parts of the kernel.

I don't see the problem with... 6 small patches, one for each new 
implemented feature, and 2 branches for specific large rewrites. I'm 
starting to think you just had to say somethign mean before I left.

Oh well.

Best regards,
Alex Ionescu

[Casper Hornstrup]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Alex Ionescu
> Sent: 6. april 2005 16:34
> To: ReactOS Development List
> Subject: Re: [ros-dev] Short leave of absence
> Not a rewrite, a three file implementation. Will be split in three
> patches, all which will be < 1000 lines.
> Then QSL will be implementted step by step in parts of the kernel.
>
> I don't see the problem with... 6 small patches, one for each new
> implemented feature, and 2 branches for specific large rewrites. I'm
> starting to think you just had to say somethign mean before I left.
>
> Oh well.
>
> Best regards,
> Alex Ionescu

Oh great, sorry then. It just sounded to me like you had a 10 mile patch
in your working copy and developers should discuss their intentions with you
before contributing to any of these areas. I mean, just describing the change
took ~1500 characters.

Casper

[Phillip Susi]

So... is any of this massive rewrite in a branch in the repository or is 
it all still in his working copy?

I'm quite interested in the changes so even if it's not ripe yet I'd 
like to svn switch to the branch and take a look at the changes so far.

Casper Hornstrup wrote:
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of Alex Ionescu
> > Sent: 6. april 2005 16:34
> > To: ReactOS Development List
> > Subject: Re: [ros-dev] Short leave of absence
> > Not a rewrite, a three file implementation. Will be split in three
> > patches, all which will be < 1000 lines.
> > Then QSL will be implementted step by step in parts of the kernel.
> >
> > I don't see the problem with... 6 small patches, one for each new
> > implemented feature, and 2 branches for specific large rewrites. I'm
> > starting to think you just had to say somethign mean before I left.
> >
> > Oh well.
> >
> > Best regards,
> > Alex Ionescu
>
> Oh great, sorry then. It just sounded to me like you had a 10 mile patch
> in your working copy and developers should discuss their intentions with you
> before contributing to any of these areas. I mean, just describing the change
> took ~1500 characters.
>
> Casper

[Jason Filby]

Good idea, would be nice to see some of the proposed changes upfront.
That way you (Alex) could even get some early feedback.

Best of luck for your exams!

Cheers
Jason

On Apr 6, 2005 6:19 PM, Phillip Susi [e-mail] wrote:
> So... is any of this massive rewrite in a branch in the repository or is
> it all still in his working copy?
>
> I'm quite interested in the changes so even if it's not ripe yet I'd
> like to svn switch to the branch and take a look at the changes so far.

[Alex Ionescu]

Phillip Susi wrote:
> So... is any of this massive rewrite in a branch in the repository or 
> is it all still in his working copy?

Thomas will have a diff of my Pushlock patch and collaborate on 
finishing the missing function.

The Kernel re-write will be in a branch in May as soon as it's bootable. 
I am against branching unbootable versions of ROS. Buggy, yes, but not 
unbootable. As soon as it's bootable (even if it crashes every 5 seconds 
and doesn't run anything anymore), it will be branched. Also, my design 
isn't finished yet, so it's another reason why it's not ready for 
primetime (for example, I haven't even added NPX saving for user-mode 
context switch), and I've added no SMP support yet.

The same applies for the ob re-write. It is incomplete, doesn't even 
compile (I would write it on the bus in notepad without even checking if 
it compiles..it's probably full of typos). As soon as it's bootable, 
I'll branch it for comments.

As for Spinlocks/IRQL, it's also incomplete... I've written only 1/4th 
of the necessry HAL routines, and this too is not yet ready for review 
(useless, imo, to review something that isn't even complete).
> I'm quite interested in the changes so even if it's not ripe yet I'd 
> like to svn switch to the branch and take a look at the changes so far.

If you really really want to see some of the new functions in the 
scheduler I can send them to you on a case-by-case basis. This is not 
yet possible for the OB stuff because it's much less ripe. It's still a 
flower, not a fruit :)

I can also send you the basic IRQL stuff I've written (only 4 functions 
so far) if you really want to see it as well.

Best regards,
Alex Ionescu

[nick_journals]

Hi guys,

When I run the qemu version. I get an error: 'Couldn't open codepage 
registry key' and the system won't start... :-/
Any idea what is wrong here?

Tnx,
Nick

[Robert Köpferl]

This is a file system damage that happened inside the image file while 
packaging.  (so clicking away qemu)
You can either boot some kind of dos and run chkdsk.exe
or download a new file revision, which will be upped in 10 min

nick_journals wrote:
> Hi guys,
>
> When I run the qemu version. I get an error: 'Couldn't open codepage 
> registry key' and the system won't start... :-/
> Any idea what is wrong here?
>
> Tnx,
> Nick _______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://reactos.com:8080/mailman/listinfo/ros-dev

[nick_journals]

Thanx Robert. Works now :-))

I just wanted to congratulate you all for the fantastic work and progress 
you guys made, 0.2.6 really kicks ass.
It much much faster then earlier and it already feels like the 'real thing'.

Sadly I couldn't contribute anymore but I still follow the list each and 
every day. And the progress is fantastic!

Keep up the good work & have a nice weekend all,
Nick
----- Original Message ----- 
From: "Robert Köpferl" [e-mail]
To: "ReactOS Development List" [e-mail]
Sent: Saturday, April 09, 2005 12:17 PM
Subject: Re: [ros-dev] 0.2.6
> This is a file system damage that happened inside the image file while 
> packaging.  (so clicking away qemu)
> You can either boot some kind of dos and run chkdsk.exe
> or download a new file revision, which will be upped in 10 min
>
> nick_journals wrote:
> > Hi guys,
> >
> > When I run the qemu version. I get an error: 'Couldn't open codepage 
> > registry key' and the system won't start... :-/
> > Any idea what is wrong here?
> >
> > Tnx,
> > Nick _______________________________________________
> > Ros-dev mailing list
> > [e-mail]
> > http://reactos.com:8080/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://reactos.com:8080/mailman/listinfo/ros-dev

[Saravanan Jayakumar]

Hello,
 Can anyone let me know which is the latest homepage for reactOS.Which
has all the latest info.
thanks
 Jay

On Apr 9, 2005 6:15 PM, nick_journals [e-mail] wrote:
> Thanx Robert. Works now :-))
>
> I just wanted to congratulate you all for the fantastic work and progress
> you guys made, 0.2.6 really kicks ass.
> It much much faster then earlier and it already feels like the 'real thing'.
>
> Sadly I couldn't contribute anymore but I still follow the list each and
> every day. And the progress is fantastic!
>
> Keep up the good work & have a nice weekend all,
> Nick
> ----- Original Message -----
> From: "Robert Köpferl" [e-mail]
> To: "ReactOS Development List" [e-mail]
> Sent: Saturday, April 09, 2005 12:17 PM
> Subject: Re: [ros-dev] 0.2.6
> > This is a file system damage that happened inside the image file while
> > packaging.  (so clicking away qemu)
> > You can either boot some kind of dos and run chkdsk.exe
> > or download a new file revision, which will be upped in 10 min
> >
> > nick_journals wrote:
> > > Hi guys,
> > >
> > > When I run the qemu version. I get an error: 'Couldn't open codepage
> > > registry key' and the system won't start... :-/
> > > Any idea what is wrong here?
> > >
> > > Tnx,
> > > Nick _______________________________________________
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://reactos.com:8080/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://reactos.com:8080/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://reactos.com:8080/mailman/listinfo/ros-dev