Ros-dev

ros-dev@reactos.org

1 participants
5793 discussions

Start a nNew thread

Symbols...
by Timo Kreuzer 10 Mar '09

10 Mar '09

Hi, Can someone please enable symbols for sysreg. Thanks, Timo

1 0

Undocumented field in PEB?
by Jun Koi 06 Mar '09

06 Mar '09

Hi, I notice that in Windows Vista - and also Windows XP - there seems to be an undocumented field in PEB. >From Windbg, I found some below fields in PEB structure' ... +0x064 NumberOfProcessors : Uint4B +0x068 NtGlobalFlag : Uint4B +0x070 CriticalSectionTimeout : _LARGE_INTEGER ... We can see that NtGlobalFlag is at offset 0x68, and is 4 bytes field. So the next field should be at 0x6C. However, CriticalSectionTimeout is at 0x70. - So the question is why that happens? I suspect that there is an undocumented field after NtGlobalFlag, which is removed from the debugging data. Any idea? - Another thing: ReactOS now faithfully declares the PEB structure like above, without that secret 4 bytes hole. As a result, the ReactOS's PEB size is 4 bytes short than PEB structure in Windows. Do we need to care about that? Or not? Thanks, J

4 6

KPROCESS update?
by Jun Koi 04 Mar '09

04 Mar '09

Hi, I examined Windows XP 3, latest update, and found some differences in its KPROCESS and our KPROCESS definition. Specifically, in our KPROCESS we have the union of ProcessFlags, between 2 fields Affinity, and BasePriority. This ProcessFlags field is 4 bytes in size. But XP3's KPROCESS has no such a ProcessFlags at that place. Instead, they have a field named StackCount, with only 2 bytes in size. So I wonder why there is the difference. The answer might be that we have not updated ketypes.h for a long time, and latest update of Windows changed some structures, therefore we have not catched up with yet. 1) Is that the correct understanding? 2) If so, will we update our structures to reflect the changes? Below is the output from my Windows XP. Thanks, J Windows XP Kernel Version 2600 (Service Pack 3) UP Free x86 compatible Product: WinNt, suite: TerminalServer SingleUserTS Personal Built by: 2600.xpsp_sp3_gdr.080814-1236 kd> dt -a -b -v _KPROCESS ntdll!_KPROCESS struct _KPROCESS, 29 elements, 0x6c bytes +0x000 Header : struct _DISPATCHER_HEADER, 6 elements, 0x10 bytes +0x000 Type : UChar +0x001 Absolute : UChar +0x002 Size : UChar +0x003 Inserted : UChar +0x004 SignalState : Int4B +0x008 WaitListHead : struct _LIST_ENTRY, 2 elements, 0x8 bytes +0x000 Flink : Ptr32 to +0x004 Blink : Ptr32 to +0x010 ProfileListHead : struct _LIST_ENTRY, 2 elements, 0x8 bytes +0x000 Flink : Ptr32 to +0x004 Blink : Ptr32 to +0x018 DirectoryTableBase : (2 elements) Uint4B +0x020 LdtDescriptor : struct _KGDTENTRY, 3 elements, 0x8 bytes +0x000 LimitLow : Uint2B +0x002 BaseLow : Uint2B +0x004 HighWord : union __unnamed, 2 elements, 0x4 bytes +0x000 Bytes : struct __unnamed, 4 elements, 0x4 bytes +0x000 BaseMid : UChar +0x001 Flags1 : UChar +0x002 Flags2 : UChar +0x003 BaseHi : UChar +0x000 Bits : struct __unnamed, 10 elements, 0x4 bytes +0x000 BaseMid : Bitfield Pos 0, 8 Bits +0x000 Type : Bitfield Pos 8, 5 Bits +0x000 Dpl : Bitfield Pos 13, 2 Bits +0x000 Pres : Bitfield Pos 15, 1 Bit +0x000 LimitHi : Bitfield Pos 16, 4 Bits +0x000 Sys : Bitfield Pos 20, 1 Bit +0x000 Reserved_0 : Bitfield Pos 21, 1 Bit +0x000 Default_Big : Bitfield Pos 22, 1 Bit +0x000 Granularity : Bitfield Pos 23, 1 Bit +0x000 BaseHi : Bitfield Pos 24, 8 Bits +0x028 Int21Descriptor : struct _KIDTENTRY, 4 elements, 0x8 bytes +0x000 Offset : Uint2B +0x002 Selector : Uint2B +0x004 Access : Uint2B +0x006 ExtendedOffset : Uint2B +0x030 IopmOffset : Uint2B +0x032 Iopl : UChar +0x033 Unused : UChar +0x034 ActiveProcessors : Uint4B +0x038 KernelTime : Uint4B +0x03c UserTime : Uint4B +0x040 ReadyListHead : struct _LIST_ENTRY, 2 elements, 0x8 bytes +0x000 Flink : Ptr32 to +0x004 Blink : Ptr32 to +0x048 SwapListEntry : struct _SINGLE_LIST_ENTRY, 1 elements, 0x4 bytes +0x000 Next : Ptr32 to +0x04c VdmTrapcHandler : Ptr32 to +0x050 ThreadListHead : struct _LIST_ENTRY, 2 elements, 0x8 bytes +0x000 Flink : Ptr32 to +0x004 Blink : Ptr32 to +0x058 ProcessLock : Uint4B +0x05c Affinity : Uint4B +0x060 StackCount : Uint2B +0x062 BasePriority : Char +0x063 ThreadQuantum : Char +0x064 AutoAlignment : UChar +0x065 State : UChar +0x066 ThreadSeed : UChar +0x067 DisableBoost : UChar +0x068 PowerState : UChar +0x069 DisableQuantum : UChar +0x06a IdealNode : UChar +0x06b Flags : struct _KEXECUTE_OPTIONS, 7 elements, 0x1 bytes +0x000 ExecuteDisable : Bitfield Pos 0, 1 Bit +0x000 ExecuteEnable : Bitfield Pos 1, 1 Bit +0x000 DisableThunkEmulation : Bitfield Pos 2, 1 Bit +0x000 Permanent : Bitfield Pos 3, 1 Bit +0x000 ExecuteDispatchEnable : Bitfield Pos 4, 1 Bit +0x000 ImageDispatchEnable : Bitfield Pos 5, 1 Bit +0x000 Spare : Bitfield Pos 6, 2 Bits +0x06b ExecuteOptions : UChar

5 6

Re: [ros-dev] [ros-diffs] [tkreuzer] 39849: Initial version of a gdi font driver for bitmap fonts (.fon / .fnt). It starts to work, but not yet correctly. Glyphs are truncated. Developed on Windows XP.
by Steven Edwards 03 Mar '09

03 Mar '09

On Mon, Mar 2, 2009 at 9:42 PM, <tkreuzer(a)svn.reactos.org> wrote: > URL: http://svn.reactos.org/svn/reactos?rev=39849&view=rev > Log: > Initial version of a gdi font driver for bitmap fonts (.fon / .fnt). It starts to work, but not yet correctly. Glyphs are truncated. Developed on Windows XP. Are you planning on using FreeType in 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

2 1

Re: [ros-dev] [ros-diffs] [dchapyshev] 39841: - Get system color depth for application list
by Ged 02 Mar '09

02 Mar '09

If EnumDisplaySettings fails GetSystemColorDepth could be anything. -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of dchapyshev(a)svn.reactos.org Sent: 02 March 2009 12:47 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [dchapyshev] 39841: - Get system color depth for application list Author: dchapyshev Date: Mon Mar 2 15:46:53 2009 New Revision: 39841 URL: http://svn.reactos.org/svn/reactos?rev=39841&view=rev Log: - Get system color depth for application list Modified: trunk/reactos/base/applications/taskmgr/applpage.c Modified: trunk/reactos/base/applications/taskmgr/applpage.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/taskmgr/… ============================================================================== --- trunk/reactos/base/applications/taskmgr/applpage.c [iso-8859-1] (original) +++ trunk/reactos/base/applications/taskmgr/applpage.c [iso-8859-1] Mon Mar 2 15:46:53 2009 @@ -58,6 +58,29 @@ ); #endif +static INT +GetSystemColorDepth(VOID) +{ + DEVMODE pDevMode; + INT ColorDepth; + + pDevMode.dmSize = sizeof(DEVMODE); + pDevMode.dmDriverExtra = 0; + EnumDisplaySettings(NULL, ENUM_CURRENT_SETTINGS, &pDevMode); + + switch (pDevMode.dmBitsPerPel) + { + case 32: ColorDepth = ILC_COLOR32; break; + case 24: ColorDepth = ILC_COLOR24; break; + case 16: ColorDepth = ILC_COLOR16; break; + case 8: ColorDepth = ILC_COLOR8; break; + case 4: ColorDepth = ILC_COLOR4; break; + default: ColorDepth = ILC_COLOR; break; + } + + return ColorDepth; +} + INT_PTR CALLBACK ApplicationPageWndProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam) { @@ -101,8 +124,8 @@ column.cx = 95; (void)ListView_InsertColumn(hApplicationPageListCtrl, 1, &column); /* Add the "Status" column */ - (void)ListView_SetImageList(hApplicationPageListCtrl, ImageList_Create(16, 16, ILC_COLOR8|ILC_MASK, 0, 1), LVSIL_SMALL); - (void)ListView_SetImageList(hApplicationPageListCtrl, ImageList_Create(32, 32, ILC_COLOR8|ILC_MASK, 0, 1), LVSIL_NORMAL); + (void)ListView_SetImageList(hApplicationPageListCtrl, ImageList_Create(16, 16, GetSystemColorDepth()|ILC_MASK, 0, 1), LVSIL_SMALL); + (void)ListView_SetImageList(hApplicationPageListCtrl, ImageList_Create(32, 32, GetSystemColorDepth()|ILC_MASK, 0, 1), LVSIL_NORMAL); UpdateApplicationListControlViewSetting();

1 0

Answers to the questions about r39721 and r39723
by Dmitry Gorbachev 25 Feb '09

25 Feb '09

Hi, Alex Ionescu wrote: > This new hack directly slows down every context switch instead of every > page fault -- the latter is a less important perf hit. This slowdown is very small, especially when comparing with other "Hack of Doom". I just want to see, is it the only raison d'être of that old hack or not. Aleksey Bragin wrote: > Why so, Dmitry? Looks like a hack? IopEnumerateDevice() loads drivers, but link in ArcName directory for a boot device should exist for it.

1 0

Re: [ros-dev] [ros-diffs] [dgorbachev] 39721: Call IopEnumerateDevice() later, after IopCreateArcNames().
by Aleksey Bragin 24 Feb '09

24 Feb '09

Why so, Dmitry? Looks like a hack? WBR, Aleksey Bragin. On Feb 23, 2009, at 4:17 PM, dgorbachev(a)svn.reactos.org wrote: > Author: dgorbachev > Date: Mon Feb 23 16:17:07 2009 > New Revision: 39721 > > URL: http://svn.reactos.org/svn/reactos?rev=39721&view=rev > Log: > Call IopEnumerateDevice() later, after IopCreateArcNames(). > > Modified: > trunk/reactos/ntoskrnl/io/iomgr/iomgr.c > > Modified: trunk/reactos/ntoskrnl/io/iomgr/iomgr.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/ > iomgr/iomgr.c?rev=39721&r1=39720&r2=39721&view=diff > ====================================================================== > ======== > --- trunk/reactos/ntoskrnl/io/iomgr/iomgr.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/io/iomgr/iomgr.c [iso-8859-1] Mon Feb 23 > 16:17:07 2009 > @@ -496,9 +496,6 @@ > /* Call back drivers that asked for */ > IopReinitializeBootDrivers(); > > - /* Initialize PnP root relations */ > - IopEnumerateDevice(IopRootDeviceNode->PhysicalDeviceObject); > - > /* Check if this was a ramdisk boot */ > if (!_strnicmp(LoaderBlock->ArcBootDeviceName, "ramdisk(0)", 10)) > { > @@ -512,6 +509,9 @@ > /* Mark the system boot partition */ > if (!IopMarkBootPartition(LoaderBlock)) return FALSE; > > + /* Initialize PnP root relations */ > + IopEnumerateDevice(IopRootDeviceNode->PhysicalDeviceObject); > + > #ifndef _WINKD_ > /* Read KDB Data */ > KdbInit(); >

1 0

Sound code cleanup and structuring
by Andrew Greenwood 24 Feb '09

24 Feb '09

Hi, As you're all probably aware, myself and janderwald are in the process of working on sound. I thought I'd give a brief update on this, but I also need some feedback on the location of the various sound components in our tree as I think it needs a little reorganisation. At present, I am focusing on the user-mode portion of sound support, with the goal of getting NT4 audio drivers working (legacy Sound Blaster cards etc.) while janderwald is getting newer style WDM audio drivers up and running. I don't want to duplicate code, hence I have been intentionally developing some helper libraries that can be easily reused. Think of them as dedicated abstractions of the various Windows APIs with a dedicated purpose (sound support.) The components involved or which are planned are: - Common library for user-mode side of sound support - Helper library specifically for NT4 device sound support (device "discovery" etc.) - sndblst.dll, mmdrv.dll and wdmaud.drv user-mode DLLs (making use of the above two components, slight variation in functionality for each - Windows 3.1 used to use the equivalent of these as the actual drivers, hence why there are multiple.) - Kernel-mode common library for NT4 style sound drivers - Sound Blaster library (to be shared between sndblst.sys and PortCls implementation) - UART401 library (to be shared between mpu401.sys and PortCls implementation) - Kernel Streaming API - Kernel Streaming components - Port Class driver At the moment I have a few things dotted around a "sound" directory within "include/reactos" I also have some stuff in our "lib" directory (the helpers I wrote) Kernel streaming related components seem to be spread around various places in drivers/wdm and drivers/ksfilter My attempts so far at NT4 drivers are still sat in drivers/multimedia Basically, I want to try and structure this better. I don't think sndblst.dll/mmdrv.dll/wdmaud.drv belong in dll/win32, and I'm wondering if my helper libraries for sound should sit next to the relevant components directory-wise. Or are they fine being in "lib"? They're only used for sound components. Finally, does anyone object to me removing the entire of the drivers/multimedia tree as nothing in there works at all? I wrote most of the code there, there is some redundant code from the very early ReactOS days in "sound", I can leave that if it's really needed. I want to start implementing sndblst.sys properly so I want to clean up a bit first, but thought I'd ask first before I do anything further. Andrew

1 0

Re: [ros-dev] [ros-diffs] [dgorbachev] 39723: Remove a hack from KiTrap14. Put a hack in other place.
by Alex Ionescu 23 Feb '09

23 Feb '09

This new hack directly slows down every context switch instead of every page fault -- the latter is a less important perf hit. Best regards, Alex Ionescu On Mon, Feb 23, 2009 at 1:18 PM, <dgorbachev(a)svn.reactos.org> wrote: > Author: dgorbachev > Date: Mon Feb 23 16:18:28 2009 > New Revision: 39723 > > URL: http://svn.reactos.org/svn/reactos?rev=39723&view=rev > Log: > Remove a hack from KiTrap14. Put a hack in other place. > > Modified: > trunk/reactos/ntoskrnl/ke/i386/ctxswitch.S > trunk/reactos/ntoskrnl/ke/i386/trap.s > > Modified: trunk/reactos/ntoskrnl/ke/i386/ctxswitch.S > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/ctxswitch… > > ============================================================================== > --- trunk/reactos/ntoskrnl/ke/i386/ctxswitch.S [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/i386/ctxswitch.S [iso-8859-1] Mon Feb 23 > 16:18:28 2009 > @@ -389,6 +389,9 @@ > > /* Checking NPX, disable interrupts now */ > mov eax, [esi+KTHREAD_INITIAL_STACK] > + > + /* HACK */ > + mov ecx, [eax - 4] > cli > > /* Get the NPX State */ > > Modified: trunk/reactos/ntoskrnl/ke/i386/trap.s > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/trap.s?re… > > ============================================================================== > --- trunk/reactos/ntoskrnl/ke/i386/trap.s [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/i386/trap.s [iso-8859-1] Mon Feb 23 16:18:28 > 2009 > @@ -1924,10 +1924,6 @@ > NoFixUp: > mov edi, cr2 > > - /* ROS HACK: Sometimes we get called with INTS DISABLED! WTF? */ > - test dword ptr [ebp+KTRAP_FRAME_EFLAGS], EFLAGS_INTERRUPT_MASK > - je HandlePf > - > /* Enable interrupts and check if we got here with interrupts disabled > */ > sti > test dword ptr [ebp+KTRAP_FRAME_EFLAGS], EFLAGS_INTERRUPT_MASK > >

1 0

Hacking Application and Testing ReactOS
by James Tabor 23 Feb '09

23 Feb '09

Hi All! When did this start? Why are we hacking application to work with ReactOS? I see in change 39703 has gone from one kernel call to three. Performance? We need to fix the real problem and it is a very old one too.... SetWindowPos is very broken. Placing bandaids over a bullet wound is not going to fix the problem. Patching around it too! Remember adding hax on top of other hax rant I've posted over the years. Creates more problems and these are still the problems we are having now. Applications must work on other target systems first prior to working with ReactOS. TaskMgr must work on the target system first! Evgeniy Boltik changes are based on good research but testing the changes after is lacking. Evgeniy! Collect and create your test suite of application and test them! AbiWord, FF, ReactOS apps and others that are known to work before your changes. Once you get into a rhythm of testing it becomes easier... Thanks, James

2 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