Hi,
I'd like to give you a little report on the status of the cache manager
rewrite branch. Since Filip and Hartmut are gone no one worked on it,
though the actual functionality is already completed since the first
commit in February 2005 and the code just needs to debugged.
So decided to give it a try and merged the changes from trunk in there.
I had to recreated the branch, from the last unlocked revision because
of all the directory movements and tortoise merge having problems with
them.
I also did some debugging work on it. I have stored my results in the
bugzilla bugs 942, 1360 and 1362. These are the only bugs I know of
which hinder the branch from being merged to trunk. I am going on
holiday tomorrow, so it would be nice if anyone else could continue
working on fixing them.
You can also help testing because we should do a lot of testing before
merging. Especially file IO intensive applications, like installers need
testing. Also the ext2fs branch, Microsoft's ntfs.sys and Vmware tools
could work. But I haven't tested any of them.
I will provide a patch to trunk so you do not have to check out or
switch to the branch which is quite annoying, because all the locked
entries are checked out again.
Hopefully the new cache manager will be in place when I am back.
Best Regards
Maarten Bosma
Hi!
URL: http://svn.reactos.ru/svn/reactos?rev=21550&view=rev
Log:
revert comctl32 Wine sync. There are some issues with it and I don't have time to fix it at the moment.
Tonight, I will have time to check and see what we need to make this work.
Thanks,
James
ReactOS.Bugzilla(a)reactos.org wrote:
> http://www.reactos.org/bugzilla/show_bug.cgi?id=1358
>
>
> tomasgroth(a)yahoo.dk changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> BugsThisDependsOn|1342 |
>
>
>
>
Hi!
What is the status of these bugs? Have all of them been added to the tree yet?
Thanks,
James
Aleksey Bragin wrote:
> 'I read this code and it looked clean to me' line means that
> the commiter
> read the code, and assures all or some parts of the following:
> 1. The code doesn't match any reverse-engineered rules (as on
> wiki page regarding Audit)
> 2. The code is publically documented
> 3. The code has nothing to do with reverse engineering (has either
> completely different implementation from the windows one -
> example freeldr
> vs. ntldr/osloader, or doesn't have any counterpart in
> windows at all).
Then why not describe it using one of the above reasons?
A note such as 'This code uses MSDN documented functions only' is clear and
useful.
A note saying 'I read this code and it looked clean to me' isn't and could
mean anything.
> > It gives a good base point for us to start our defence from.
> We are not under attack. We are just doing some preventive measures.
I know. I said 'if the cleanliness of the code is ever questioned again'.
If that does happen, it could be in the form of an attack from an outside
company.
Having a better analysis as to why something was unlocked would be
advantageous if this situation ever arose.
> > This was all decided when we originally locked the code,
> > but no one has been following it.
> arty, w3seek, me have been following this rules on the
> possibly dirty code, so please don't speak for everyone.
I don't mean the auditing methods, I mean the lack of useful message.
I'm not accusing or judging anyone, I'm just trying to get a better
unlocking system in place.
As the code we audit gets closer to the border line of clean and dirty,
we're gonna need to ensure we don't leave messages like 'yep, looks ok to
me'
I hope mail this isn't coming across to anyone as argumentative. It's
difficult to have a conversation over email without it sounding hostile. It
isn't meant that way :)
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: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
If the author has been contacted, it should be noted in the commit log. That
alone is enough reason to squash any doubts anyone had. The authors word is
always trusted.
If the author couldn't be contacted, then the code should go through the
audit procedure Art put forward. Whichever part of that procedure was passed
should be noted in the commit log.
Even if it's just something as simple as 'this code uses is fully documented
on XYZ: http://..'
Doing things this way ensures we can look back at the code if the
cleanliness of the reversing methods is ever questioned again. It gives a
good base point for us to start our defence from.
This was all decided when we originally locked the code, but no one has been
following it. Thus we have terms like 'I read this code and it looked clean
to me'.
IMO, that isn't worth anything. I could read parts of the kernel and it
appear to be clean to me. Contacting Alex or correctly auditing the code
would prove otherwise.
In light of this, I think some of the audit measures we went to were a bit
of an over reaction. Perhaps we should have only decided to audit kernel
mode code, or subsections of it.
However we choose to do everything and I'm a firm believer in the phrase 'If
you going to do something, do it right'
Ged.
-----Original Message-----
From: Saveliy Tretiakov [mailto:saveliyt@mail.ru]
Sent: 07 April 2006 13:52
To: ReactOS Development List
Subject: Re: [ros-dev] ncpa
I always contact authors when it is possible. Some authors have left
project years ago and are unreachable.
Murphy, Ged (Bolton) wrote:
>The authors of the code should always be contacted before unlocking unless
>the app it produces isn't a part of Windows.
>
>Not doing so undermines the audit process and commit lines like 'I looked
at
>this code and it appears clean' is doing just that.
>
>Ged.
>
>-----Original Message-----
>From: Saveliy Tretiakov [mailto:saveliyt@mail.ru]
>Sent: 07 April 2006 13:11
>To: ReactOS Development List
>Subject: Re: [ros-dev] ncpa
>
>
>Do we need to audit ncpa?
>
>_______________________________________________
>Ros-dev mailing list
>Ros-dev(a)reactos.org
>http://www.reactos.org/mailman/listinfo/ros-dev
>************************************************************************
>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: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
>
>
>_______________________________________________
>Ros-dev mailing list
>Ros-dev(a)reactos.org
>http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>
>
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
************************************************************************
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: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
The authors of the code should always be contacted before unlocking unless
the app it produces isn't a part of Windows.
Not doing so undermines the audit process and commit lines like 'I looked at
this code and it appears clean' is doing just that.
Ged.
-----Original Message-----
From: Saveliy Tretiakov [mailto:saveliyt@mail.ru]
Sent: 07 April 2006 13:11
To: ReactOS Development List
Subject: Re: [ros-dev] ncpa
Do we need to audit ncpa?
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
************************************************************************
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: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
This is all that stands in the way of getting 0.3.0 out the door.
As soon as we can config the network adapters via the dialog, we can branch
and start bug hunting.
This would also be a good time to enlist some more testers under the Munger
wing ;)
I'm going to have a look at this tonight, but I've had a look before and
IIRC, I had trouble hunting the bug down.
It would be good if someone with a bit more experience in this area could
have a look.
I think Gé was working on this before Christmas, so I'm hopefully gonna
catch up with him tonight via IM, as I'm not sure if he's subscribed to
ros-dev anymore.
We've been promising this for about 18 months now. I know a hell of a lot of
work has been done in other areas (in fact, the jump from 0.3 to 0.4 should
be relatively small as much of the 0.4 work is done), but we need to
deliver.
After all the recent goings on, getting 0.3.0 would be a nice boost for the
project, in terms of both morale and PR.
Is anyone willing to help?
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: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
Hello!
In an effort to put ReactOS development into higher scales, I would
like to announce that I am creating a global list of all possible
development tasks, broken down into modules/sections/etc. By the time
all tasks in this list are fully completed, ReactOS would result in
transition to a beta-stage and bumping version number to >= 0.5 (so
you understand how big this todolist will be).
This list would be a base to the global ReactOS Roadmap which is
going to show a current status of reactos, expected times before
future releases, and what future releases will contain exactly.
And the most important: It makes every programmer willing to
participate in the project to find a task he feels familiar with,
actually do it, and see how it advances the project. All the way
before, the only really managed part of development was fixing bugs,
because Bugzilla is storing all bugs descriptions/patches/
assignations/etc. Now, similar thing will come in help to the general
development.
Creating such a list is quite a hard task, and it can't be done by an
individual, so:
Attention all ReactOS Developers, please! Your word is very valuable
here! Please, compile a list of tasks you think ReactOS needs and
send it here as a reply to this message (I will put a preliminary
draft of what I already compiled so far too somewhere in the wiki).
Each task should be a clearly outlined work if possible, however all
information is important so you can add something like "//TODO: Add
more details about this task later" too.
Example of a task considered as "good" to me:
- Boot manager
-- Make Loader Parameter Block compatible with Windows XP one
Example of a less exact task, but which is still "good"
- Boot manager
-- Make boot process conforming to NTLDR boot process, so that
FreeLdr can boot Windows without NTLDR.
Example of a "bad" task
- NTOSKRNL
-- Improve kernel
Thank you for the collaboration, I know this maybe a quite hard to
do, but it's the first steps of an effort to get development to the
speed and quality we never had before. Other things to mention are
continuos integration system, regression testing frameworks, etc, etc.
With the best regards,
Aleksey Bragin.
On 4/6/06, Thomas Weidenmueller <w3seek(a)reactos.com> wrote:
> There are several issues with this patch:
>
> > + /* What a strage dance */
> > + struct client_config *config = ifi->client->config;
>
> 1) dhcp crashes for me on the line above.
Strange, it works for me here.
>
> > + char ComputerName [MAX_COMPUTERNAME_LENGTH + 1];
>
> 2) use Unicode, please. Obsolete as described in 4)
I really tire of hearing this. None of the code in dhcp.exe is
unicode right now. I've tried to hack on several pieces of ros only
to be told "USE UNICODE" by another dev. Trying to convert entire
modules has always gone terribly for me.
>
> > + DWORD ComputerNameSize = sizeof ComputerName / sizeof ComputerName[0];
> > +
> > + GetComputerName(ComputerName, & ComputerNameSize);
>
> 3) missing error check, leading to buffer overflow if accessed the
> string in ComputerName
>
> > + /* This never gets freed since it's only called once */
> > + LPSTR lpCompName =
> > + HeapAlloc(GetProcessHeap(), 0, strlen(ComputerName) + 1);
>
> 4) makes the ComputerName buffer on the stack obsolete. Only use the
> dynamic buffer. strlen will likely cause a buffer overflow if the
> computer name was longer than the length of the (obsolete) static buffer
> on the stack, since the static buffer will never be initialized in this
> case.
I'll try to fix this.
>
> > + if (lpCompName !=NULL) {
> > + GetComputerName(lpCompName, & ComputerNameSize);
>
> 5) once again missing error check which may cause buffer overflows in
> the following code
>
> > + /* Send our hostname, some dhcpds use this to update DNS */
> > + config->send_options[DHO_HOST_NAME].data = strlwr(lpCompName);
>
> 6) strlwr is POSIX ;)
Not helpful, suggest something better.
>
> > + config->send_options[DHO_HOST_NAME].len = strlen(ComputerName);
>
> 7) operating on the wrong buffer, may cause buffer overflow due to 5)
>
> > + warn("util.c read_client_conf poorly implemented!");
>
> Indeed :(
>
> Apart from the bugs mentioned in this code, GetComputerNameExA has a few
> bugs: 1) incorrectly returning ERROR_OUTOFMEMORY instead of FALSE and 2)
> not checking the return value of RtlUnicodeStringToAnsiString.
>
> - Thomas
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
WD
--
<Bizzeh> it even has a panda that pops out of your case and mauls
people who ask stupid questions