Ros-dev

ros-dev@reactos.org

2 participants
5791 discussions

ncpa
by Murphy, Ged (Bolton) 07 Apr '06

07 Apr '06

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

6 6

Roadmap / List of tasks / Attn. all developers
by Aleksey Bragin 07 Apr '06

07 Apr '06

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.

13 15

Re: [ros-dev] Re: [ros-diffs] [amunger] 21474: DHCP Client fixes and enhancements Set the correct hardware type flag. Fixes bug 651. Send option 12 on discovery, allows some DHCP servers to dynamically update DNS. Send option 61 for good measure. We
by WaxDragon 06 Apr '06

06 Apr '06

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

3 2

RE: [ros-dev] Re: [ros-diffs] [amunger] 21474: DHCP Client fixes and enhancements
by Murphy, Ged (Bolton) 06 Apr '06

06 Apr '06

Thomas Weidenmueller wrote: > I don't mean to offend anybody with my criticism, I just want to point > out what could and should be fixed or done differently. Your criticism is hugely appreciated. That's the whole point of ros-diffs :) WaxDragon wrote: > I'll try to fix this. I'll give you a hand with it tonight if you need one. 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

1 0

Re: [ros-diffs] [amunger] 21474: DHCP Client fixes and enhancements Set the correct hardware type flag. Fixes bug 651. Send option 12 on discovery, allows some DHCP servers to dynamically update DNS. Send option 61 for good measure. We use the MAC address as some other OSes do.
by Thomas Weidenmueller 06 Apr '06

06 Apr '06

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. > + char ComputerName [MAX_COMPUTERNAME_LENGTH + 1]; 2) use Unicode, please. Obsolete as described in 4) > + 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. > + 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 ;) > + 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

1 0

RE: ncpa
by Ge van Geldorp 04 Apr '06

04 Apr '06

> From: "Murphy, Ged (Bolton)" <MurphyG(a)cmpbatteries.co.uk> > > 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 Ge was working on this before Christmas, I was > 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. I am, although I don't read every message anymore. The status of the applet when I worked on it was that the UI was complete and I was starting to work on transfering the data from the dialog to the TCP/IP driver (via the DHCP client). That part simply isn't implemented yet. I don't have any uncommitted code floating around. Ge

1 0

RE: [ros-diffs] [greatlrd] 21453: Start Implement HEL 1. Start im plement HEL Inisate 2. Start implement HEL GetAvailMem
by Murphy, Ged (Bolton) 04 Apr '06

04 Apr '06

> + DWORD HELMemoryAvilable; > + This->HELMemoryAvilable = HEL_GRAPHIC_MEMORY_MAX; > + *free = This->HELMemoryAvilable; There is a small typo throughout this code "Available" :) ************************************************************************ 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

1 0

Re: [ros-diffs] [tretiakov] 21429: [AUDIT] msgina is clean.
by Ged Murphy 01 Apr '06

01 Apr '06

aleksey(a)studiocerebral.com wrote: > Author: tretiakov > Date: Fri Mar 31 21:47:52 2006 > New Revision: 21429 > > URL: http://svn.reactos.ru/svn/reactos?rev=21429&view=rev > Log: > [AUDIT] msgina is clean. > > What is the reason for these being clean signed off as clean? Did you speak to the authors? Did you follow the conditions in the wiki?

5 6

Re: [ros-diffs] [gedmurphy] 21413: update Wine sync doc
by Thomas Weidenmueller 31 Mar '06

31 Mar '06

aleksey(a)studiocerebral.com wrote: > -reactos/dll/win32/comctl32 # Synced to Wine-0_9_5 > +reactos/dll/win32/comctl32 # Synced to Wine-20060328 The "synchronization" lacks a bunch of changes. Only a few files were actually synchronized. - Thomas

2 1

Re: [ros-diffs] [tretiakov] 21409: Implement NdrCContextMarshall()
by Ged Murphy 30 Mar '06

30 Mar '06

These changes break second stage. CSR initialasation error. Ged. aleksey(a)studiocerebral.com wrote: > Author: tretiakov > Date: Wed Mar 29 23:09:43 2006 > New Revision: 21409 > > URL: http://svn.reactos.ru/svn/reactos?rev=21409&view=rev > Log: > Implement NdrCContextMarshall() > > Modified: > trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c > > Modified: trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c > URL: http://svn.reactos.ru/svn/reactos/trunk/reactos/dll/win32/rpcrt4/ndr_marsha… > ============================================================================== > --- trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c (original) > +++ trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c Wed Mar 29 23:09:43 2006 > @@ -3231,6 +3231,15 @@ > } > > /*********************************************************************** > + * NDRCContextMarshall > + */ > +void WINAPI NDRCContextMarshall(IN NDR_CCONTEXT CContext, OUT void *pBuff ) > +{ > + CContextHandle *ctx = (CContextHandle*)CContext; > + memcpy(pBuff, ctx->Ndr, sizeof(ctx->Ndr)); > +} > + > +/*********************************************************************** > * NdrClientContextMarshall > */ > void WINAPI NdrClientContextMarshall(PMIDL_STUB_MESSAGE pStubMsg, > > > >

1 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev