RE: [ros-svn] [gdalsnes] 16793: my 1st

[Murphy, Ged (Bolton)]

gdalsnes(a)svn.reactos.com wrote:

>   my 1st
>  
>  
>  Added files:
>  branches/hardons1stbranch/
>  
>  Updated files:
>  branches/hardons1stbranch/kapi.h branches/hardons1stbranch/ntuser.h
>  
>  Deleted files:
>  branches/hardons1stbranch/debug.h branches/hardons1stbranch/debug1.h 

Hi Hardon.
Out of interest, what's the purpose of this branch? 
(probably been discussed in IRC, but I missed it)

Thanks,
Ged.





************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk 
<mailto:[e-mail]> and then delete this message. 

Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com

[Gunnar Dalsnes]

Its yet another win32k rewrite attempt:-)

Gunnar

Murphy, Ged (Bolton) wrote:
>   Hi Hardon.
>  Out of interest, what's the purpose of this branch? 
>  (probably been discussed in IRC, but I missed it)
>  
>  Thanks,
>  Ged.

[Richard]

What's the point?  No offense, but it will never get finished.  What 
purpose does this serve?  What bugs are you attempting to fix?  Why not 
fix them directly and not even attempt a rewrite?

Richard

Gunnar Dalsnes wrote:

>   Its yet another win32k rewrite attempt:-)
>
>  Gunnar
>
>  Murphy, Ged (Bolton) wrote:
>
> >   Hi Hardon.
> >  Out of interest, what's the purpose of this branch? (probably been 
> >  discussed in IRC, but I missed it)
> >
> >  Thanks,
> >  Ged. 
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev
>

[Alex Ionescu]

Richard wrote:

>   What's the point? 
Fix it.

>   No offense, but it will never get finished.   
Most probably not. One man cannot do this alone.

>   What purpose does this serve?   
Fix a myriad of win32k bugs.

>   What bugs are you attempting to fix? 
Too many to list, but perhaps related to timers, queues, user mode heap, 
etc.

>   Why not fix them directly and not even attempt a
> rewrite? 
I think he is trying to fix them directly. The thing with win32k is that 
if you fix A, BCD will break. You will fix B, only to see E and F break, 
and attempting to fix E and C in the same time will make a conflict, 
causing G not to function. G will have to be reimplemented from scratch, 
and finally E and F will work again. However, to get C going, H, I, J 
need to be rewritten. After doing so, your A fix does not work anymore, 
because it depended on the old broken code. Fixing A fixes the trick, 
but B has broken as well now, since it depended on A. You finally manage 
to fix A and D, but your H, I, J rewrite causes K, L and Z to be 
incompatible with the kernel. After yet another round of rewriting their 
implementations, you notice that you've rewritten half the thing and the 
two halves look like shit. You proceed in rewriting M-X.

>  
>  Richard
>  
Best regards,
Alex Ionescu

[Gedi]

Alex Ionescu wrote: 

>  
>  I think he is trying to fix them directly. The thing with win32k is 
>  that if you fix A, BCD will break. You will fix B, only to see E and F 
>  break, and attempting to fix E and C in the same time will make a 
>  conflict, causing G not to function. G will have to be reimplemented 
>  from scratch, and finally E and F will work again. However, to get C 
>  going, H, I, J need to be rewritten. After doing so, your A fix does 
>  not work anymore, because it depended on the old broken code. Fixing A 
>  fixes the trick, but B has broken as well now, since it depended on A. 
>  You finally manage to fix A and D, but your H, I, J rewrite causes K, 
>  L and Z to be incompatible with the kernel. After yet another round of 
>  rewriting their implementations, you notice that you've rewritten half 
>  the thing and the two halves look like shit. You proceed in rewriting 
>  M-X. 

LMAO.
If you can read that without ending up with your head up your arse, you 
need help  ;)


Ged.

[yash]

>   if you fix A, BCD will break. You will fix B, only to
> see E and F break, 
if it really goes like that, you should keep rewriting the unit from  
scratch, each time making a better design in respect to more and more and  
more isolation and adding more and more and more abstraction levels. you  
must use all your previous experience each time redesigning the internals.  
also you must find ways to constantly fuel yourself with more patience and  
motivation.

yash

[Alex Ionescu]

yash wrote:

>  
> >   if you fix A, BCD will break. You will fix B,
> > only to see E and F break, 
>
>  if it really goes like that, you should keep rewriting the unit from  
>  scratch, each time making a better design in respect to more and more 
>  and  more isolation and adding more and more and more abstraction 
>  levels. you  must use all your previous experience each time 
>  redesigning the internals.  also you must find ways to constantly fuel 
>  yourself with more patience and  motivation.
>
>  yash  
Hi Yash,

You've nailed it. This is what win32k needs. A collaborative, 
well-planned, well-designed rewrite.

Best regards,
Alex Ionescu

[James Tabor]

Alex Ionescu wrote:
>   yash wrote:
>  
> >  
> > >   if you fix A, BCD will break. You will fix B,
> > > only to see E and F break, 
> >
> >
> >  if it really goes like that, you should keep rewriting the unit from  
> >  scratch, each time making a better design in respect to more and more 
> >  and  more isolation and adding more and more and more abstraction 
> >  levels. you  must use all your previous experience each time 
> >  redesigning the internals.  also you must find ways to constantly fuel 
> >  yourself with more patience and  motivation.
> >
> >  yash  
>  
>  
>  Hi Yash,
>  
>  You've nailed it. This is what win32k needs. A collaborative, 
>  well-planned, well-designed rewrite.
>  
>  Best regards,
>  Alex Ionescu 
Yes!
James

[Richard]

Then where is this effort?  Why is one developer wandering off on his 
own?  How about setting a 'win32k rewrite' as a goal for 0.4?  That is, 
if 0.3 ever makes it out the door...

Honestly, i think that devs should work towards the feature set we 
planned for 0.3, however that is just me.  Granted, there is no money 
involved in this project, but not setting goals and randomly doing 
rewrites is the fast way to code burnout, boredom, and lost interest.  
Drowning yourself in an impossibly large project is nuts.

Richard

Alex Ionescu wrote:

>   yash wrote:
>
> >  
> > >   if you fix A, BCD will break. You will fix B,
> > > only to see E and F 
> > >  break, 
> >
> >
> >  if it really goes like that, you should keep rewriting the unit from  
> >  scratch, each time making a better design in respect to more and more 
> >  and  more isolation and adding more and more and more abstraction 
> >  levels. you  must use all your previous experience each time 
> >  redesigning the internals.  also you must find ways to constantly 
> >  fuel yourself with more patience and  motivation.
> >
> >  yash  
>
>  Hi Yash,
>
>  You've nailed it. This is what win32k needs. A collaborative, 
>  well-planned, well-designed rewrite.
>
>  Best regards,
>  Alex Ionescu
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev
>

[James Tabor]

Richard wrote:
>   Then where is this effort?  Why is one developer
> wandering off on his 
>  own?  How about setting a 'win32k rewrite' as a goal for 0.4?  That is, 
>  if 0.3 ever makes it out the door...
>  
>  Honestly, i think that devs should work towards the feature set we 
>  planned for 0.3, however that is just me.  Granted, there is no money 
>  involved in this project, but not setting goals and randomly doing 
>  rewrites is the fast way to code burnout, boredom, and lost interest.  
>  Drowning yourself in an impossibly large project is nuts.
>  
>  Richard
>   
Hello! I'm here too! Hello, hay! Hello!
James

[Richard]

This wasn't directed at any one person :P

This is directed at everyone in general.  A problem i've noticed that 
alotta devs are having is a problem i tend to have as well.  In order 
for ReactOS to actually become a useable, viable desktop alternative 
someday, goals need to be SET and MET.  You set a goal, and you work 
towards the goal.  When all the goals are met, you release a new 
version.  Remember 0.3?  It was due out last year wasn't it?  It's now 
almost NEXT year and there is still a lot of work to do for 0.3.

p.s. anyone remember my svn username? :P

Richard

James Tabor wrote:

>   Richard wrote:
>
> >   Then where is this effort?  Why is one developer
> > wandering off on his 
> >  own?  How about setting a 'win32k rewrite' as a goal for 0.4?  That 
> >  is, if 0.3 ever makes it out the door...
> >
> >  Honestly, i think that devs should work towards the feature set we 
> >  planned for 0.3, however that is just me.  Granted, there is no money 
> >  involved in this project, but not setting goals and randomly doing 
> >  rewrites is the fast way to code burnout, boredom, and lost 
> >  interest.  Drowning yourself in an impossibly large project is nuts.
> >
> >  Richard
> >  
>  Hello! I'm here too! Hello, hay! Hello!
>  James
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev
>

[Alex Ionescu]

Richard wrote:

>   This wasn't directed at any one person :P
>
>  This is directed at everyone in general.  A problem i've noticed that 
>  alotta devs are having is a problem i tend to have as well.  In order 
>  for ReactOS to actually become a useable, viable desktop alternative 
>  someday, goals need to be SET and MET.  You set a goal, and you work 
>  towards the goal.  When all the goals are met, you release a new 
>  version.  Remember 0.3?  It was due out last year wasn't it?  It's now 
>  almost NEXT year and there is still a lot of work to do for 0.3.
>
>  
Setting goals is one thing, but meeting them is another. ReactOS is not 
a company. Although we try really hard to set certain goals, there is no 
rule saying "Thomas, you can't implement NTMARTA! We are supposed to 
work on networking" or "Hartmut, stop fixing the Cache Manager, fix 
networking instead!" or "Filip, stop working on NT compatibility, we 
need networking!!". If we do that, then all the devs would simply not do 
any more work. ReactOS is a free environment where everyone does what he 
wants. Mathematically, 8 developers working on one feature, then all 
working on another feature, then all working on another feature versus 8 
developers working each on their own features equals to the same. In the 
short term, one gives you your goal much faster (yay, we have 
networking), but leaves everythign else in the dust (video? multi-user? 
pnp? dust in the wind...). The other method, in the short term, gives 
you an impression of nothing working (which is true, since everything is 
only, say 10% implemented), but in the long run will give you a complete 
system. ReactOS has chosen to follow that second method.

Best regards,
Alex Ionescu

[Richard]

I agree with your points, and i'm not saying that devs shouldn't be 
allowed to work on a given featureset, i just believe that we should be 
focused more on the goals for the next release.

Richard

Alex Ionescu wrote:

>   Richard wrote:
>
> >   This wasn't directed at any one person :P
> >
> >  This is directed at everyone in general.  A problem i've noticed that 
> >  alotta devs are having is a problem i tend to have as well.  In order 
> >  for ReactOS to actually become a useable, viable desktop alternative 
> >  someday, goals need to be SET and MET.  You set a goal, and you work 
> >  towards the goal.  When all the goals are met, you release a new 
> >  version.  Remember 0.3?  It was due out last year wasn't it?  It's 
> >  now almost NEXT year and there is still a lot of work to do for 0.3.
> >
> >  
>  Setting goals is one thing, but meeting them is another. ReactOS is 
>  not a company. Although we try really hard to set certain goals, there 
>  is no rule saying "Thomas, you can't implement NTMARTA! We are 
>  supposed to work on networking" or "Hartmut, stop fixing the Cache 
>  Manager, fix networking instead!" or "Filip, stop working on NT 
>  compatibility, we need networking!!". If we do that, then all the devs 
>  would simply not do any more work. ReactOS is a free environment where 
>  everyone does what he wants. Mathematically, 8 developers working on 
>  one feature, then all working on another feature, then all working on 
>  another feature versus 8 developers working each on their own features 
>  equals to the same. In the short term, one gives you your goal much 
>  faster (yay, we have networking), but leaves everythign else in the 
>  dust (video? multi-user? pnp? dust in the wind...). The other method, 
>  in the short term, gives you an impression of nothing working (which 
>  is true, since everything is only, say 10% implemented), but in the 
>  long run will give you a complete system. ReactOS has chosen to follow 
>  that second method.
>
>  Best regards,
>  Alex Ionescu
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev
>

[Alex Ionescu]

Richard wrote:

>   I agree with your points, and i'm not saying that
> devs shouldn't be 
>  allowed to work on a given featureset, i just believe that we should 
>  be focused more on the goals for the next release.
>
>  Richard
>
>  
If the devs suddently feel a motivation to fix something completely 
unrelated, or to implement it, you have two choices:

1) Let them use that sudden rush (I'm sure you know the rush when you 
REALLY feel like coding something) to do something useful, even if it 
won't be used until ReactOS 0.99
2) Tell them to stop. In which case not only do you piss them off, but 
you also lose that great code they were about to write.

The main reason why so many of the win32k rewrites ended was because 
people kept telling the developers doing it to give up, continue later, 
or focus on other tasks. I think we should be encouraging Gunnar, not 
crticising him.

And sorry if this sounds harsh Richard, it's not directed only to you, 
and in many ways I agree with your points... I've often thought like 
you, until I imaginzed myself in the other situation, where I'd be the 
one told to do something else... as frusrating as it is when behaving as 
a "Project Manager", it's a godsend when thinking in a Developer's
mindset.

We do however have some measures in place to ensure that total chaos 
does not happen. One of them are blockers before releases, which most 
devs seem to be interested and actively participating in. And then there 
is also a more extreme measure that a lot of the devs agree on, but 
hasn't really been put in place, which is to be able to lock the tree 
temporarily if 3 or more developers designate a certain bug as 
hyper-critical. I believe Casper will now jump in and start ripping this 
idea to shreds, but I've talked to many other developers who agree to 
it... Even if implemented however, it will probably never be used unless 
something massive is going on, in which case the devs would probably 
focus on it out of their own good will.

Best regards,
Alex Ionescu

[Casper Hornstrup]

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.com [mailto:[e-mail]] On Behalf Of Alex
> Ionescu
>  Sent: 29. juli 2005 04:44
>  To: ReactOS Development List
>  Subject: Re: [ros-dev] RE: [ros-svn] [gdalsnes] 16793: my 1st
>  
>  The main reason why so many of the win32k rewrites ended was because
>  people kept telling the developers doing it to give up, continue later,
>  or focus on other tasks. 
Yes, blame other people. It is so much easier. It certainly couldn't be
that the developers who felt the need to rewrite several years of
development effort in a few months took on too much work and lost
motivation/interest before the work was completed. Working in smaller
steps and keeping the code in the repository working at all times
means you can loose interest/motivation at any time and zero work is
lost. Yes, it requires some thinking/research/planning to do it in
smaller steps, but you will have reduced the risk from being very
high to be almost non-existent.

Casper

[Alex Ionescu]

Casper Hornstrup wrote:

>  Yes, blame other people.
>  
^^^ Good sarcastic message pointing out that blaming others isn't good.

>   It is so much easier. It certainly couldn't be
> that the developers...
>  
^^^ Contradictory sarcastic remark to above point, stating that 
developers should be blamed instead.

Are developers not "other people"? You, yourself, are blaming "other 
people". I was never part of any win32k rewrite, nor where you, I 
suppose, so whether we blame someone that disses the developers, or the 
developers themselves, we are both blaming "other people".

Best regards,
Alex Ionescu

[erick]

On Thu, 28 Jul 2005, Alex Ionescu wrote:
>   > This wasn't directed at any one person :P
>  >
>  > This is directed at everyone in general.  A problem i've noticed that 
>  > alotta devs are having is a problem i tend to have as well.  In order 
>  > for ReactOS to actually become a useable, viable desktop alternative 
>  > someday, goals need to be SET and MET.  You set a goal, and you work 
>  > towards the goal.  When all the goals are met, you release a new 
>  > version.  Remember 0.3?  It was due out last year wasn't it?  It's now 
>  > almost NEXT year and there is still a lot of work to do for 0.3. 
Hi,

I'm interested in helping (lots of network coding experience from DOS
WATTCP and embedded systems right through to Win2003), but the reactos web
server outage isn't making it any easier to get started.

Anyways, I just wanted to wade in on the completion comments...

Projects tend to mature quicker when there is momentum, and momentum
usually comes from achieving less ambitious/reachable goals first.  In
particular, goals which make money and pay people to help.

We could learn a lot from the Linux and FreeBSD groups which 
capitalized on corporate money ages ago to fund this sort of work.

Yes, it will be great to have reactos as a viable desktop alternative, but
an earlier achievement will be a decent Win32-compatible black box running
relatively little GUI code.

If you want some examples: control systems, DHCP servers, Win32 web
pages without needing buggy IIS, etc.

You may think that niche is being filled by Linux/FreeBSD, but I think the
ability to use Windows development tools and device drivers will make
ReactOS a better choice for many people.  

I think NTFS is important, but I know millions of computers would be happy
to use captivefs and their windows license.  A perfect example would be to
use ReactOS + captive FS to install Windows XP on workstations.  Right now
people are paying for Powerquest/etc. $$$ per station to do this.  

The installation idea is neat because it would be free advertising to the
windows administration community that ReactOS is out there, and that
it may become relevant to their needs.

The networking section is critical.  High performance would be nice, but
not essential to get our foot in the door.

Erick

[Jakob Eriksson]

erick wrote:

[snip]

>  Projects tend to mature quicker when there is momentum,
> and momentum
> usually comes from achieving less ambitious/reachable goals first.  In
> particular, goals which make money and pay people to help.
>   
>  
Amen.

>  Yes, it will be great to have reactos as a viable
> desktop alternative, but
> an earlier achievement will be a decent Win32-compatible black box running
> relatively little GUI code.
>   
>  
Exactly!  We and ReactOS could wipe the floor with both
Windows CE and Windows XP embedded with one mop.


// Jakob