Ros-dev

ros-dev@reactos.org

5789 discussions

Re: [ros-dev] [ros-diffs] [sginsberg] 35294: - Temporarily revert my last change. We don't set the SystemThread flag appropriately and it is always zero

by Alex Ionescu

else { /* System Thread */ Thread->StartAddress = StartRoutine; PspSetCrossThreadFlag(Thread, CT_SYSTEM_THREAD_BIT); Looks good to me. And CT_SYSTEM_THREAD_BIT is defined to 0x10 which is correct: union { struct { ULONG Terminated:1; #if (NTDDI_VERSION >= NTDDI_LONGHORN) ULONG ThreadInserted:1; #else ULONG DeadThread:1; #endif ULONG HideFromDebugger:1; ULONG ActiveImpersonationInfo:1; ULONG SystemThread:1; so your patch was correct and should be re-applied. On 12-Aug-08, at 3:22 PM, sginsberg(a)svn.reactos.org wrote: > Author: sginsberg > Date: Tue Aug 12 17:22:51 2008 > New Revision: 35294 > > URL: http://svn.reactos.org/svn/reactos?rev=35294&view=rev > Log: > - Temporarily revert my last change. We don't set the SystemThread > flag appropriately and it is always zero > > Modified: > trunk/reactos/ntoskrnl/ps/kill.c > > Modified: trunk/reactos/ntoskrnl/ps/kill.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ps/kill.c?rev=352… > = > = > = > = > = > = > = > = > ====================================================================== > --- trunk/reactos/ntoskrnl/ps/kill.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ps/kill.c [iso-8859-1] Tue Aug 12 > 17:22:51 2008 > @@ -1086,7 +1086,7 @@ > PETHREAD Thread = PsGetCurrentThread(); > > /* Make sure this is a system thread */ > - if (!Thread->SystemThread) return STATUS_INVALID_PARAMETER; > + if (Thread->SystemThread) return STATUS_INVALID_PARAMETER; > > /* Terminate it for real */ > return PspTerminateThreadByPointer(Thread, ExitStatus, TRUE); > Best regards, Alex Ionescu

16 years, 9 months

Re: [ros-dev] [ros-priv] ROS information policy...

by Thomas Bluemel

Timo Kreuzer wrote: > And when I have already started moaning about this kind of stuff... what > about the arm guys? They are so secret they can't even make their > changelog themselfs? Why that? And why are they so secret that noone > knows? I mean we keep demanding real name and email from everyone > creating a patch, yet a bunch of people have direct commit access and > they keep hiding their names? What reasons are there I thought it was common knowledge already that Alex is the (only) arm "guys". Isn't it more than obvious? Very same coding style, knowledge, comments, rants, ... How stupid does one have to be not to realize the connection? Prove me otherwise... And since you're complaining about not being open, why do you only post this to the private list? Thomas

16 years, 9 months

[ros-diffs] [fireball] 35140: - Add more intrinsic defines. - SVN maintenance.

by Timo Kreuzer

MS defines most of those in the wdk, if NO_INTERLOCKED_INTRINSICS is not defined > +#define InterlockedDecrement _InterlockedDecrement > +#define InterlockedDecrement16 _InterlockedDecrement16 > +#define InterlockedIncrement _InterlockedIncrement > +#define InterlockedIncrement16 _InterlockedIncrement16 > +#define InterlockedCompareExchange _InterlockedCompareExchange > +#define InterlockedCompareExchange16 _InterlockedCompareExchange16 > +#define InterlockedCompareExchange64 _InterlockedCompareExchange64 > +#define InterlockedExchange _InterlockedExchange > +#define InterlockedExchangeAdd _InterlockedExchangeAdd >

16 years, 9 months

Re: [ros-dev] [ros-diffs] [dchapyshev] 35127: - Add cred.c from Wine

by Steven Edwards

On Tue, Aug 5, 2008 at 10:45 AM, <dchapyshev(a)svn.reactos.org> wrote: > +#include "../crypt/crypt.h" Minor nitpicking, Do you mind fixing this? 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

16 years, 9 months

Re: [ros-dev] [ros-diffs] [mkupfer] 35050: revert to 35046, sorry for mistake

by Steven Edwards

On Sat, Aug 2, 2008 at 6:33 PM, <mkupfer(a)svn.reactos.org> wrote: > Author: mkupfer > Date: Sat Aug 2 17:33:58 2008 > New Revision: 35050 > > URL: http://svn.reactos.org/svn/reactos?rev=35050&view=rev > Log: > revert to 35046, sorry for mistake Ignore my message, I did not see where you fixed it. 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

16 years, 9 months

Re: [ros-dev] [ros-diffs] [mkupfer] 35047: Reorganize shdocvw: - Moved and renamed language resource files into created 'lang' directory. - Outdated shdocvw_ros.diff removed.

by Steven Edwards

On Sat, Aug 2, 2008 at 5:57 PM, <mkupfer(a)svn.reactos.org> wrote: > Author: mkupfer > Date: Sat Aug 2 16:57:53 2008 > New Revision: 35047 > > URL: http://svn.reactos.org/svn/reactos?rev=35047&view=rev > Log: > Reorganize shdocvw: > - Moved and renamed language resource files into created 'lang' directory. > - Outdated shdocvw_ros.diff removed. This is wrong, shdocvw will keep being synced as soon as the widl bug is fixed so the resources should stay in the dll root to save whoever is doing the sync the trouble of having to move resources around. -- 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

16 years, 9 months

Re: [ros-dev] [ros-diffs] [sginsberg] 35042: - ExpLookupHandleTableEntry: Apply same changes as was done for ExpFreeHandleTable and ExpAllocateHandleTableEntrySlow in 34467 - ExpAllocateHandleTableEntry: Fail if we don't find a handle table entry

by Alex Ionescu

This is broken. Best regards, Alex Ionescu On Sat, Aug 2, 2008 at 11:25 AM, <sginsberg(a)svn.reactos.org> wrote: > Author: sginsberg > Date: Sat Aug 2 13:25:53 2008 > New Revision: 35042 > > URL: http://svn.reactos.org/svn/reactos?rev=35042&view=rev > Log: > - ExpLookupHandleTableEntry: Apply same changes as was done for ExpFreeHandleTable and ExpAllocateHandleTableEntrySlow in 34467 > - ExpAllocateHandleTableEntry: Fail if we don't find a handle table entry > > Modified: > trunk/reactos/ntoskrnl/ex/handle.c > > Modified: trunk/reactos/ntoskrnl/ex/handle.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ex/handle.c?rev=3… > ============================================================================== > --- trunk/reactos/ntoskrnl/ex/handle.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ex/handle.c [iso-8859-1] Sat Aug 2 13:25:53 2008 > @@ -35,8 +35,10 @@ > ExpLookupHandleTableEntry(IN PHANDLE_TABLE HandleTable, > IN EXHANDLE LookupHandle) > { > - ULONG i, j, k, TableLevel, NextHandle; > - ULONG_PTR TableBase; > + ULONG i, j, k, NextHandle; > + ULONG_PTR TableCode = HandleTable->TableCode; > + ULONG_PTR TableBase = TableCode & ~3; > + ULONG TableLevel = (ULONG)(TableCode & 3); > PHANDLE_TABLE_ENTRY Entry = NULL; > EXHANDLE Handle = LookupHandle; > PUCHAR Level1, Level2, Level3; > @@ -45,13 +47,6 @@ > Handle.TagBits = 0; > NextHandle = *(volatile ULONG*)&HandleTable->NextHandleNeedingPool; > if (Handle.Value >= NextHandle) return NULL; > - > - /* Get the table code */ > - TableBase = *(volatile ULONG_PTR*)&HandleTable->TableCode; > - > - /* Extract the table level and actual table base */ > - TableLevel = (ULONG)(TableBase & 3); > - TableBase = TableBase - TableLevel; > > /* Check what level we're running at */ > switch (TableLevel) > @@ -210,8 +205,8 @@ > PEPROCESS Process = HandleTable->QuotaProcess; > ULONG i, j; > ULONG_PTR TableCode = HandleTable->TableCode; > - ULONG TableLevel = TableCode & 3; > ULONG_PTR TableBase = TableCode & ~3; > + ULONG TableLevel = (ULONG)(TableCode & 3); > PHANDLE_TABLE_ENTRY Level1, *Level2, **Level3; > PAGED_CODE(); > > @@ -733,6 +728,13 @@ > > /* Lookup the entry for this handle */ > Entry = ExpLookupHandleTableEntry(HandleTable, Handle); > + > + /* Make sure that we found an entry */ > + if (!Entry) > + { > + /* We didn't, fail */ > + return NULL; > + } > > /* Get an available lock and acquire it */ > i = ((OldValue & FREE_HANDLE_MASK) >> 2) % 4; > >

16 years, 9 months

Call for participation: ReactOSDbg

by art yerkes

I've written a shell to use with ReactOS' KDBG that gives a more accurate view of what's going on than other methods available to us (it automatically grabs the module list and loads source files as appropriate, shows locals etc) It's not complete yet, and I'm hoping that others will want to participate in working on it. Therefore, I'm asking those with C# experience on windows who want to get involved to lend a hand in adding the remaining features: - abstract pipe implementation for serial ports and windows named pipes - managing breakpoints - type decoding and struct display using the info available from dbghelp - thread and process listing and focus - a 'watch' window and watchpoints - clipboard interaction - annontated disassembly - general features (bugzilla reporting, automatic interaction with rospaste) To work on this, you don't need to be a wizard, just familiar with windows forms development in C# and willing to learn a thing or two along the way, along with a vm to intstall reactos in and beat up on :-) Some day we'll have everything working with windows style kernel debugging, but until then I feel that a superior stopgap is valuable. -- art yerkes <ayerkes(a)speakeasy.net>

16 years, 9 months

Re: [ros-dev] [ros-diffs] [tkreuzer] 34970: - update KPCR and KIPCR - add KeGetPcr() and update KeGetCurrentProcessorNumber

by Alex Ionescu

Kinda curious why you have "unknowns" in a documented structure. On 30-Jul-08, at 7:17 PM, tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Wed Jul 30 21:16:59 2008 > New Revision: 34970 > > URL: http://svn.reactos.org/svn/reactos?rev=34970&view=rev > Log: > - update KPCR and KIPCR > - add KeGetPcr() and update KeGetCurrentProcessorNumber > > Modified: > branches/ros-amd64-bringup/reactos/include/ddk/winddk.h > branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h > > Modified: branches/ros-amd64-bringup/reactos/include/ddk/winddk.h > URL: http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/reactos/inclu… > = > = > = > = > = > = > = > = > ====================================================================== > --- branches/ros-amd64-bringup/reactos/include/ddk/winddk.h > [iso-8859-1] (original) > +++ branches/ros-amd64-bringup/reactos/include/ddk/winddk.h > [iso-8859-1] Wed Jul 30 21:16:59 2008 > @@ -5516,23 +5516,38 @@ > > typedef struct _KPCR > { > - NT_TIB NtTib; > - struct _KPRCB *CurrentPrcb; > - ULONG64 SavedRcx; > - ULONG64 SavedR11; > + union > + { > + NT_TIB NtTib; > + struct > + { > + union _KGDTENTRY64 *GdtBase; > + struct _KTSS64 *TssBase; > + ULONG64 UserRsp; > + struct _KPCR *Self; > + struct _KPRCB *CurrentPrcb; > + PKSPIN_LOCK_QUEUE LockArray; > + PVOID Used_Self; > + }; > + }; > + union _KIDTENTRY64 *IdtBase; > + ULONG64 Unused[2]; > KIRQL Irql; > UCHAR SecondLevelCacheAssociativity; > - UCHAR Number; > + UCHAR ObsoleteNumber; > UCHAR Fill0; > - ULONG Irr; > - ULONG IrrActive; > - ULONG Idr; > + ULONG Unused0[3]; > USHORT MajorVersion; > USHORT MinorVersion; > ULONG StallScaleFactor; > - union _KIDTENTRY64 *IdtBase; > - union _KGDTENTRY64 *GdtBase; > - struct _KTSS64 *TssBase; > + PVOID Unused1[3]; > + ULONG KernelReserved[15]; > + ULONG SecondLevelCacheSize; > + ULONG HalReserved[16]; > + ULONG Unused2; > + PVOID KdVersionBlock; > + PVOID Unused3; > + ULONG PcrAlign1[24]; > } KPCR, *PKPCR; > > typedef struct _KFLOATING_SAVE { > @@ -5552,10 +5567,17 @@ > VOID); > > FORCEINLINE > +PKPCR > +KeGetPcr(VOID) > +{ > + return (PKPCR)__readgsqword(FIELD_OFFSET(KPCR, Self)); > +} > + > +FORCEINLINE > ULONG > KeGetCurrentProcessorNumber(VOID) > { > - return (ULONG)__readgsbyte(FIELD_OFFSET(KPCR, Number)); > + return (ULONG)__readgsword(0x184); > } > > #elif defined(__PowerPC__) > > Modified: branches/ros-amd64-bringup/reactos/include/ndk/amd64/ > ketypes.h > URL: http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/reactos/inclu… > = > = > = > = > = > = > = > = > ====================================================================== > --- branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h > [iso-8859-1] (original) > +++ branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h > [iso-8859-1] Wed Jul 30 21:16:59 2008 > @@ -635,41 +635,42 @@ > NT_TIB NtTib; > struct > { > - struct _EXCEPTION_REGISTRATION_RECORD > *Used_ExceptionList; > - PVOID Used_StackBase; > - PVOID PerfGlobalGroupMask; > - PVOID TssCopy; > - ULONG ContextSwitches; > - KAFFINITY SetMemberCopy; > + union _KGDTENTRY64 *GdtBase; > + struct _KTSS64 *TssBase; > + ULONG64 UserRsp; > + struct _KPCR *Self; > + struct _KPRCB *CurrentPrcb; > + PKSPIN_LOCK_QUEUE LockArray; > PVOID Used_Self; > }; > }; > - struct _KPCR *Self; > - struct _KPRCB *Prcb; > + union _KIDTENTRY64 *IdtBase; > + ULONG64 Unused[2]; > KIRQL Irql; > - ULONG IRR; > - ULONG IrrActive; > - ULONG IDR; > - PVOID KdVersionBlock; > - PKIDTENTRY IDT; > - PKGDTENTRY GDT; > - struct _KTSS *TSS; > + UCHAR SecondLevelCacheAssociativity; > + UCHAR ObsoleteNumber; > + UCHAR Fill0; > + ULONG Unused0[3]; > USHORT MajorVersion; > USHORT MinorVersion; > - KAFFINITY SetMember; > ULONG StallScaleFactor; > - UCHAR SparedUnused; > - UCHAR Number; > - UCHAR Reserved; > - UCHAR L2CacheAssociativity; > - ULONG VdmAlert; > - ULONG KernelReserved[14]; > + PVOID Unused1[3]; > + ULONG KernelReserved[15]; > ULONG SecondLevelCacheSize; > ULONG HalReserved[16]; > - ULONG InterruptMode; > - UCHAR Spare1; > - ULONG KernelReserved2[17]; > - KPRCB PrcbData; > + ULONG Unused2; > + ULONG Fill1; > + PVOID KdVersionBlock; // 0x108 > + PVOID Unused3; > + ULONG PcrAlign1[24]; > + > + ULONG Unknown1; // 0x178 > + ULONG Unknown2; > + ULONG Unknown3; > + USHORT CpuNumber; // 0x184 > + // hack: > + ULONG ContextSwitches; > + > } KIPCR, *PKIPCR; > #pragma pack(pop) > > Best regards, Alex Ionescu

16 years, 9 months

Re: [ros-dev] ARM Guy Broke BOOT on Real Hardware

by tamlin＠algonet.se

Alex wrote: >It looks like a guarded mutex is being acquired at DPC level. That's >pretty bad. Well, at least it's redundant and useless. :-) >Pushlocks shouldn't be acquired at DPC level either Indeed. If "you" are at DPC level, you have but one synchronization to care about - SMP (i.e. CPU<->CPU). >, but there's no >ASSERTs in the pushlock code that check for that. An oversight that should be fixed, I'm sure (even if it happened to slow down the system by a whole order of magnitude, which it won't). >MMProbeAndLockPages should never be called for paged pool addreses >while at DPC level, Should MmProbeAndLock ever be called at IRQL above APC level? I mean, what if the probing fails? Should the paging executive somehow preempt this call and page in the missing pages (or should it simply throw a "page not present" exception - not too great to do at DPC level I'd say)? >which means the driver probably called it for a >non-paged pool address. If my previous suspicion is correct, I build on that and suspect this is an error in itself. The ProbeAndLock call should be done at APC level (though I may be completely wrong, but do read my finishing line). >In that case, the whole loop about checking if the page is present and >then faulting it in is irrelevant, and won't happen. Right. Page fault at DPC level == Bad Move(tm). -- Mike

16 years, 9 months

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