Ros-dev

ros-dev@reactos.org

5790 discussions

Re: [ros-dev] Ros-dev Digest, Vol 59, Issue 11
by Olaf Siejka 08 Jul '09

08 Jul '09

On the other hand, this PSEH bug has locked up our buildbot for a considerable amount of time. I have no intention to promote hacking or hiding bugs, on the other hand though, the longer we run without debug buildbot, the more regressions and other problems are potentially going unnoticed. This was my major concern over so called MDL probe or as we now know - PSEH2 bug issue.

1 0

Re: [ros-dev] [ros-diffs] [dgorbachev] 41788: "Fix" MDL PROBE FAILED! bug #4663.
by Alex Ionescu 08 Jul '09

08 Jul '09

I'm confused... I've looked through the code, and I don't get what the "Break" does here. Does the ExRaiseStatus somehow end up handled in this path again? That means there's a serious SEH2 bug. On 6-Jul-09, at 11:28 AM, dgorbachev(a)svn.reactos.org wrote: > Author: dgorbachev > Date: Mon Jul 6 22:28:11 2009 > New Revision: 41788 > > URL: http://svn.reactos.org/svn/reactos?rev=41788&view=rev > Log: > "Fix" MDL PROBE FAILED! bug #4663. > > Modified: > trunk/reactos/ntoskrnl/mm/ARM3/mdlsup.c > > Modified: trunk/reactos/ntoskrnl/mm/ARM3/mdlsup.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/mdlsup.c?… > = > = > = > = > = > = > = > = > ====================================================================== > --- trunk/reactos/ntoskrnl/mm/ARM3/mdlsup.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/ARM3/mdlsup.c [iso-8859-1] Mon Jul 6 > 22:28:11 2009 > @@ -679,6 +679,7 @@ > // Oops :( > // > ProbeStatus = _SEH2_GetExceptionCode(); > + _SEH2_YIELD(break); > } > _SEH2_END; > > Best regards, Alex Ionescu

5 9

Code hacking rules, currently applying for NTOSKRNL
by Aleksey Bragin 07 Jul '09

07 Jul '09

I decided to make this as a separate post, though it's a follow up to the previous one. I would like to set, officially, a couple of simple code hacking rules, which are going to apply immediately for the NTOSKRNL module, and to other modules after discussion/acceptance. They apply only to committers (which commit their own or someone else's patches). 1. If you change someone's code, and believe it's a correct change - go ahead and commit. 2. If you need to add a hack to someone's code, and: 2.1. you want to either hack or revert the offending commit which breaks booting: This is allowed only after 24hrs after trying to contact the author / posting to the ros-dev mailing list about the problem. 2.2. you want to either hack or revert the offending commit which contains a certain regression but doesn't cause important consequences like inability to install the OS, or major loss of functionality: This is allowed only from permission of author of the code which you want to hack or, as alternative, from my permission. I think this way we can get some order into the coming commits flow, which is hard to track. Also, please comment on this, so that we can alter those rules and maybe accept them for all modules. Thanks for understanding, Aleksey Bragin.

3 3

ReactOS 3.1.0... what???
by Javier Agustìn Fernàndez Arroyo 07 Jul '09

07 Jul '09

hi guys, if you see latest compatibility database entries you will note that reported ROS version is 3.1.0 why? any clue? some examples: http://www.reactos.org/support/index.php?page=db&view=comp&sec=category&ite… http://www.reactos.org/support/index.php?page=db&view=comp&sec=category&ite…

2 1

Re: [ros-dev] [ros-diffs] [cgutman] 41783: - Fix return value of tdiGetMibForIfEntity so it doesn't return a failure status on success
by Ged 07 Jul '09

07 Jul '09

This looks hackish It also breaks the log as you're potentially returning something different from what the log states -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of cgutman(a)svn.reactos.org Sent: 06 July 2009 08:54 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [cgutman] 41783: - Fix return value of tdiGetMibForIfEntity so it doesn't return a failure status on success Author: cgutman Date: Mon Jul 6 11:54:28 2009 New Revision: 41783 URL: http://svn.reactos.org/svn/reactos?rev=41783&view=rev Log: - Fix return value of tdiGetMibForIfEntity so it doesn't return a failure status on success Modified: trunk/reactos/dll/win32/iphlpapi/ifenum_reactos.c Modified: trunk/reactos/dll/win32/iphlpapi/ifenum_reactos.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/iphlpapi/ifenum_… ============================================================================== --- trunk/reactos/dll/win32/iphlpapi/ifenum_reactos.c [iso-8859-1] (original) +++ trunk/reactos/dll/win32/iphlpapi/ifenum_reactos.c [iso-8859-1] Mon Jul 6 11:54:28 2009 @@ -280,7 +280,7 @@ entry->ent.if_descr); TRACE("} status %08x\n",status); - return status; + return STATUS_SUCCESS; } NTSTATUS tdiGetEntityIDSet( HANDLE tcpFile,

3 4

Re: [ros-dev] [ros-diffs] [dgorbachev] 41788: "Fix" MDL PROBE FAILED! bug #4663.
by Aleksey Bragin 06 Jul '09

06 Jul '09

Uhm, why hack the kernel again? Testing on the buildbot was fixed to accept this, so there is no urge. I was just trying to help RPG to find the issue, along with vmware/vbox video drivers regression, due to a MmMapIoSpace(128Mb) call. Please read the next email. WBR, Aleksey. On Jul 6, 2009, at 10:28 PM, dgorbachev(a)svn.reactos.org wrote: > Author: dgorbachev > Date: Mon Jul 6 22:28:11 2009 > New Revision: 41788 > > URL: http://svn.reactos.org/svn/reactos?rev=41788&view=rev > Log: > "Fix" MDL PROBE FAILED! bug #4663.

2 1

Re: [ros-dev] [ros-diffs] [dgorbachev] 41788: "Fix" MDL PROBE FAILED! bug #4663.
by KJK::Hyperion 06 Jul '09

06 Jul '09

dgorbachev(a)svn.reactos.org wrote: > --- trunk/reactos/ntoskrnl/mm/ARM3/mdlsup.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/ARM3/mdlsup.c [iso-8859-1] Mon Jul 6 22:28:11 2009 > @@ -679,6 +679,7 @@ > // Oops :( > // > ProbeStatus = _SEH2_GetExceptionCode(); > + _SEH2_YIELD(break); > } > _SEH2_END; What's that supposed to do?

1 0

Re: [ros-dev] [ros-diffs] [jimtabor] 41776: - Implement the client shutdown procedure. Tested with wine user32 msg undocumented 0x3B tests. Wine tests: msg: 6175 tests executed (0 marked as todo, 937 failures), 5 skipped. - Add missing end session types. - Reference: winproc.c WM_CLIENTSHUTDOWN http://wiki.winprog.org/wiki/Windows_messages
by Timo Kreuzer 05 Jul '09

05 Jul '09

jimtabor(a)svn.reactos.org schrieb: > Author: jimtabor > Date: Sun Jul 5 06:21:35 2009 > New Revision: 41776 > > URL: http://svn.reactos.org/svn/reactos?rev=41776&view=rev > Log: > - Implement the client shutdown procedure. Tested with wine user32 msg undocumented 0x3B tests. Wine tests: msg: 6175 tests executed (0 marked as todo, 937 failures), 5 skipped. > - Add missing end session types. > - Reference: winproc.c WM_CLIENTSHUTDOWN http://wiki.winprog.org/wiki/Windows_messages > > [...] > > + List = IntWinListChildren(pWindow); > Oh, how I loathe this function. It walks through the chain of windows to count them, allocates a buffer from paged pool. Walks through the chain again, fills the buffer with the windows' handles and returns the buffer so that the calling function can walk through the buffer and use the handles to query the pointers to the windows again. And this all happens while holding the global user lock. Hint: you can remove 11 lines of code and change 2 lines and get the same result, only faster. Regards, Timo

1 0

Re: [ros-dev] [ros-diffs] [dchapyshev] 41755: - Fixes return values for PeekMessageA/W
by Steven Edwards 05 Jul '09

05 Jul '09

On Fri, Jul 3, 2009 at 5:53 AM, <dchapyshev(a)svn.reactos.org> wrote: > - if (-1 == (int) Res || ! Res) > - { > - return Res; > + if (-1 == (int) Res || !Res) > + { > + return FALSE; I know you didn't write the check and were just changing the return values but as a matter of style could we do something like if (((int) Res || !Res) == -1) or would the extra parens mess up the order of operations? Not a big deal, its just easier on my eyes. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

2 2

Commit log
by Ged 05 Jul '09

05 Jul '09

I think we all agree that the process of filling out a changelog is a task we would rather avoid. Collibri has made some efforts to alleviate this and despite getting some good results we're also seeing a lot of information which isn't changelog oriented. This now leaves us with a new problem of having to manually go through data output from Collibri's tool and reformat it. This is arguably more time consuming than the original method and isn't working for us in its current form. The current problem with this method is that a commit log is not a changelog and getting something which can be classed as a changelog from this without human intervention is an impossible task. There are also some people who would rather write their own changelog instead of allowing a tool to generate it for you. The problem as I see it is two fold : - Commit messages generally contain cryptic message, humour, idioms and frustration - Patches can spread over a wide range of modules making it difficult to insert them into the correct position in the changelog. A possible solution to this is to wrap up a changelog in XML elements. Such a commit log would be as follows : ............................................................................ .......................... - Stop mixing unicode and ANSI strings - Don't dereference NULL pointers <changelog> <notepad>Converted the application to Unicode</notepad> <user32>Fixed a crash highlighted via adobe acrobat</user32> </changelog> ............................................................................ .......................... This will allow anyone who wants to have a changelog autogenerated at release time to take advantage and anyone who wants to do their own to ignore it. The problem with this method lies in getting the XML tags correct. Anyone have any other ideas? Ged.

11 15

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev