Ros-dev April 2012

ros-dev@reactos.org

20 participants
14 discussions

The ReactOS Foundation takes part in the IPv6 Launch Day

by Pierre Schweitzer

Hi, this year, the 6th of June will be once again a special day. This will be the one, the Internet Society has chosen to launch IPv6: http://www.worldipv6launch.org/. It means that starting with this day, all the participant will enable IPv6 and provide it the days, months, years after. The ReactOS Foundation will take part in this event. Currently some services and servers are already available in IPv6, but are not fully maintained. Starting with the 6th of June, major ReactOS services and servers will be available for everybody with IPv6. A roadmap for IPv6 deployment can be found on the ReactOS wiki at: https://www.reactos.org/wiki/IPv6. You will be able to follow all the progress with IPv6. This means that after the 6th of June, any ReactOS developer will be able to work with an IPv6 only on our infrastructure. The transition will be done smoothly. With my best regards, -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

12 years, 8 months

I'd like to hear about your plans for 0.4.0

by Brent Newland

I've posted a topic on the Forums to discuss the roadmap to 0.4.0 (whatever it may be). ReactOS has been on the 0.3.x branch for almost six years, and there's been talk of 0.4, so I'd like to hear from any developers on what plans or goals you might have for 0.4.0, whenever it comes out (within 1-2 years?) If you don't currently have any concrete goals or plans (which I've heard is a possibility), then perhaps it would be a good time to start a dialog between developers and the community so we can start to get an idea of what your (ReactOS) expectations are, and what's in store. http://www.reactos.org/forum/viewtopic.php?f=2&t=11114 It could also give you something to point people to when people ask about 0.4.

12 years, 8 months

Re: [ros-dev] [ros-diffs] [akhaldi] 56311: * Reorganize the whole ReactOS codebase into a new layout. Discussing it will only waste time, so we better have it then talk about it after. * Put ntoskrnl and ntdll in the same f...

by Aleksey Bragin

02.04.2012 0:42, akhaldi(a)svn.reactos.org пишет: > Author: akhaldi > Date: Sun Apr 1 20:42:43 2012 > New Revision: 56311 > > URL: http://svn.reactos.org/svn/reactos?rev=56311&view=rev > Log: > * Discussing it will only waste time, so we better have it then talk about it after. I was thinking it's some of my old commits, until I read the line about april fools day :) > * I'm just kidding, you know, April's fool and all ;) > WBR, Aleksey.

12 years, 8 months

Re: [ros-dev] [ros-diffs] [sginsberg] 56333: - Even while I love having the trap/fpu/context code in C, the bugs this switch introduced continue to amaze me. This time, fix a bug from 45156 when KiFlushNPXState was rewritte...

by Aleksey Bragin

That was a nice catch! 07.04.2012 0:13, sginsberg(a)svn.reactos.org пишет: > Author: sginsberg > Date: Fri Apr 6 20:13:33 2012 > New Revision: 56333 > > URL: http://svn.reactos.org/svn/reactos?rev=56333&view=rev > Log: > - Even while I love having the trap/fpu/context code in C, the bugs this switch introduced continue to amaze me. This time, fix a bug from 45156 when KiFlushNPXState was rewritten in C. The C version could miss to restore the interrupt state, which would lead to interrupts being disabled when it was not expected. This "interrupt leak" was seen in the page fault handler if a page fault occurred after interrupts had been disabled (which had sometimes been observed to occur on the test server during exception handling and thread creation when KiFlushNPXState had been called). This didn't completely hang the system because during thread creation (and other system calls where this may have happened) interrupts would be re-enabled when returning to user mode when restoring eflags, and the exception handling would result in a system call which would enable interrupts again (it appears exception handler would have run with interrupts disabled, though!). This is now fixed, as well as any other issues this might have caused. The hack in the page fault handler remains until another issue has been fixed. > > Modified: > trunk/reactos/ntoskrnl/ke/i386/cpu.c > > Modified: trunk/reactos/ntoskrnl/ke/i386/cpu.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/cpu.c?rev… > ============================================================================== > --- trunk/reactos/ntoskrnl/ke/i386/cpu.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/i386/cpu.c [iso-8859-1] Fri Apr 6 20:13:33 2012 > @@ -1323,7 +1323,12 @@ > if (Thread->NpxState != NPX_STATE_LOADED) > { > /* If there's nothing to load, quit */ > - if (!SaveArea) return; > + if (!SaveArea) > + { > + /* Restore interrupt state and return */ > + __writeeflags(EFlags); > + return; > + } > > /* Need FXSR support for this */ > ASSERT(KeI386FxsrPresent == TRUE); > >

12 years, 8 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev April 2012