Ros-dev November 2013

ros-dev@reactos.org

20 participants
18 discussions

[ros-diffs] [akhaldi] 60074: [WINE/TEST] * Introduce a way to properly mark the todos instead of counting them as failures. Brought to you by Thomas Faber.
by James Tabor 14 Nov '13

14 Nov '13

Hi. This should be removed, we are not wine and I personally work "hard on" getting wine todos fixed in ReactOS! This also breaks the DCE test. Background, GvG and then the old guard back in the day thought the same way as I do about this issue. We should count the todo's as failures and not bypass these failues. Why? It may point to a critical bug that could break functionality somewhere else. That was the reasoning then and I agree with it. Cheating the tests is just plain cheating...... James

4 5

Re: [ros-dev] [ros-diffs] [jimtabor] 60974: - Wine had some fixups added since this was last synced. CORE-???? & CORE-7574.
by Hermès BÉLUSCA - MAÏTO 13 Nov '13

13 Nov '13

Hi James, What do you have in mind when you write CORE-???? ? Is it something related to http://jira.reactos.org/browse/CORE-7469 ? Cheers, Hermès ---------------------------------------------------------------------------- -------------------------- Author: jimtabor Date: Wed Nov 13 17:21:41 2013 New Revision: 60974 URL: http://svn.reactos.org/svn/reactos?rev=60974&view=rev Log: - Wine had some fixups added since this was last synced. CORE-???? & CORE-7574. Modified: trunk/rostests/winetests/user32/sysparams.c

1 0

My presentation at Google Montreal
by Alex Ionescu 13 Nov '13

13 Nov '13

http://youtu.be/pVXt_dELZNo?t=1m15s -- Best regards, Alex Ionescu

6 6

[ros-diffs] [jimtabor] 60883: [Win32k] - Add support for receiving message thread death
by James Tabor 08 Nov '13

08 Nov '13

Hi all! I noticed the crash of the two tests bots, I'll have a fix in about 10 hours or so. Sorry for the delays, James

1 1

Re: [ros-dev] [ros-diffs] [gadamopoulos] 60880: [shell32] - Initialize comctl32 properly
by Timo Kreuzer 07 Nov '13

07 Nov '13

This looks like MSVC won't like it. Am 07.11.2013 15:14, schrieb gadamopoulos(a)svn.reactos.org: > GetModuleFileNameW(hInstance, swShell32Name, MAX_PATH); > swShell32Name[MAX_PATH - 1] = '\0'; > > - InitCommonControlsEx(NULL); > + /* Initialize comctl32 */ > + INITCOMMONCONTROLSEX InitCtrls; > + InitCtrls.dwSize = sizeof(INITCOMMONCONTROLSEX); >

2 1

Re: [ros-dev] [ros-diffs] [pschweitzer] 60871: [NTOSKRNL] - Implement MiUnlockProcessWorkingSetShared() and make use of it in MiUnlockProcessWorkingSetForFault(). - Complete implementation of MiLockProcessWorkingSetForFault()
by Alex Ionescu 06 Nov '13

06 Nov '13

What JIRA task is this associated with? -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of pschweitzer(a)svn.reactos.org Sent: Tuesday, November 5, 2013 2:04 PM To: ros-diffs(a)reactos.org Subject: [ros-diffs] [pschweitzer] 60871: [NTOSKRNL] - Implement MiUnlockProcessWorkingSetShared() and make use of it in MiUnlockProcessWorkingSetForFault(). - Complete implementation of MiLockProcessWorkingSetForFault() Author: pschweitzer Date: Tue Nov 5 22:03:42 2013 New Revision: 60871 URL: http://svn.reactos.org/svn/reactos?rev=60871&view=rev Log: [NTOSKRNL] - Implement MiUnlockProcessWorkingSetShared() and make use of it in MiUnlockProcessWorkingSetForFault(). - Complete implementation of MiLockProcessWorkingSetForFault() Modified: trunk/reactos/ntoskrnl/mm/ARM3/miarm.h Modified: trunk/reactos/ntoskrnl/mm/ARM3/miarm.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/miarm.h?r… ============================================================================== --- trunk/reactos/ntoskrnl/mm/ARM3/miarm.h [iso-8859-1] (original) +++ trunk/reactos/ntoskrnl/mm/ARM3/miarm.h [iso-8859-1] Tue Nov 5 22:03:42 2013 @@ -1197,6 +1197,30 @@ // FORCEINLINE VOID +MiUnlockProcessWorkingSetShared(IN PEPROCESS Process, + IN PETHREAD Thread) { + /* Make sure we are the owner of a safe acquisition (because shared) */ + ASSERT(MI_WS_OWNER(Process)); + ASSERT(!MI_IS_WS_UNSAFE(Process)); + + /* Ensure we are in a shared acquisition */ + ASSERT(Thread->OwnsProcessWorkingSetShared == TRUE); + ASSERT(Thread->OwnsProcessWorkingSetExclusive == FALSE); + + /* Don't claim the lock anylonger */ + Thread->OwnsProcessWorkingSetShared = FALSE; + + /* Release the lock and re-enable APCs */ + ExReleasePushLockShared(&Process->Vm.WorkingSetMutex); + KeLeaveGuardedRegion(); +} + +// +// Unlocks the working set for the given process // FORCEINLINE VOID MiUnlockProcessWorkingSetUnsafe(IN PEPROCESS Process, IN PETHREAD Thread) { @@ -1330,7 +1354,7 @@ else { /* Owner is shared (implies safe), release normally */ - ASSERT(FALSE); + MiUnlockProcessWorkingSetShared(Process, Thread); *Safe = TRUE; *Shared = TRUE; } @@ -1343,16 +1367,24 @@ IN BOOLEAN Safe, IN BOOLEAN Shared) { - ASSERT(Shared == FALSE); - /* Check if this was a safe lock or not */ if (Safe) { - /* Reacquire safely */ - MiLockProcessWorkingSet(Process, Thread); + if (Shared) + { + /* Reacquire safely & shared */ + MiLockProcessWorkingSetShared(Process, Thread); + } + else + { + /* Reacquire safely */ + MiLockProcessWorkingSet(Process, Thread); + } } else { + /* Unsafe lock cannot be shared */ + ASSERT(Shared == FALSE); /* Reacquire unsafely */ MiLockProcessWorkingSetUnsafe(Process, Thread); }

2 1

Re: [ros-dev] [ros-diffs] [dgorbachev] 60832: [CMAKE] Reduce the disk space needed to build ReactOS (disabled for LTCG builds - linker bug #15143).
by Aleksey Bragin 02 Nov '13

02 Nov '13

Nice to see you committing, hto! Regards, Aleksey Bragin On 02.11.2013 17:56, dgorbachev(a)svn.reactos.org wrote: > Author: dgorbachev > Date: Sat Nov 2 13:56:47 2013 > New Revision: 60832 > > URL: http://svn.reactos.org/svn/reactos?rev=60832&view=rev > Log: > [CMAKE] > Reduce the disk space needed to build ReactOS (disabled for LTCG builds - linker bug #15143). > > Modified: > trunk/reactos/toolchain-gcc.cmake >

1 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 60802: [NTOSKRNL] Implement MiSetControlAreaSymbolsLoaded and MiLoadUserSymbols. These are responsible for marking the control area that we've loaded the symbols and for effectively l...
by Timo Kreuzer 02 Nov '13

02 Nov '13

Am 31.10.2013 00:17, schrieb pschweitzer(a)svn.reactos.org: > +VOID > +NTAPI > +MiSetControlAreaSymbolsLoaded(IN PCONTROL_AREA ControlArea) > +{ > + KIRQL OldIrql; > + > + ASSERT(KeGetCurrentIrql() <= APC_LEVEL); > + > + OldIrql = KeAcquireQueuedSpinLock(LockQueuePfnLock); > + ControlArea->u.Flags.DebugSymbolsLoaded |= 1; > + > + ASSERT(OldIrql <= APC_LEVEL); > + KeReleaseQueuedSpinLock(LockQueuePfnLock, OldIrql); > + ASSERT(KeGetCurrentIrql() <= APC_LEVEL); > +} No offence, but seriously? The PFN lock to set a flag?

2 2

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 November 2013