gdalsnes@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@exideuk.co.uk mailto:postmaster@exideuk.co.uk 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
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@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
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
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.
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
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
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
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@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
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
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@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
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
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@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
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
-----Original Message----- From: ros-dev-bounces@reactos.com [mailto:ros-dev-bounces@reactos.com] 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
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
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
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