- Ros-dev - ReactOS.org

Re: [ros-dev] [ros-diffs] [ros-arm-bringup] 39925: - Implement a new Hyperspace Mapping Interface: - The new interface is portable and much faster than before. For example, unmapping a hyperpage is almost a one-line operation. - The new interface is
by James Tabor 10 Mar '09

10 Mar '09

Hi, Qemu w Head: (subsystems/win32/win32k/ntuser/desktop.c:612) RtlQueryRegistryValues failed for PaintDesktopVersion (c0000034) err:(base/system/winlogon/screensaver.c:86) ImpersonateLoggedOnUser() failed with error 5 (ntoskrnl/se/semgr.c:613) Denying access for caller: granted 0x600e8, desired 0xf01ff (generic mapping 80F290E8) Assertion 'PointerPte->u.Hard.Valid == 0' failed at ntoskrnl/mm/hypermap.c line 100 Entered debugger on embedded INT3 at 0x0008:0x808c1e7e. kdb:> bt Eip: <NTOSKRNL.EXE:c1e7f> Frames: <NTOSKRNL.EXE:7c608> <NTOSKRNL.EXE:7615f> On Tue, Mar 10, 2009 at 4:53 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote: > Boot is broken for me in VMWare, with an assert being hit in > hypermap.c:178. > > > WBR, > Aleksey Bragin. >

1 0

Re: [ros-dev] [ros-diffs] [ros-arm-bringup] 39925: - Implement a new Hyperspace Mapping Interface: - The new interface is portable and much faster than before. For example, unmapping a hyperpage is almost a one-line operation. - The new interface is also thread-safe and uses the EPROCESS hyperspace spinlock. - However, in order to isolate from React Mm internals, the Hyper IRQL and Process are stored as globals, so this will not work on SMP. - For now, mapping vs. zero PTEs are not treated differently, but
by Aleksey Bragin 10 Mar '09

10 Mar '09

Boot is broken for me in VMWare, with an assert being hit in hypermap.c:178. WBR, Aleksey Bragin. On Mar 10, 2009, at 3:31 AM, ros-arm-bringup(a)svn.reactos.org wrote: > Author: ros-arm-bringup > Date: Tue Mar 10 03:31:14 2009 > New Revision: 39925 > > URL: http://svn.reactos.org/svn/reactos?rev=39925&view=rev > Log: > - Implement a new Hyperspace Mapping Interface: > - The new interface is portable and much faster than before. > For example, unmapping a hyperpage is almost a one-line operation. > - The new interface is also thread-safe and uses the EPROCESS > hyperspace spinlock. > - However, in order to isolate from React Mm internals, the > Hyper IRQL and Process are stored as globals, so this will not work > on SMP. > - For now, mapping vs. zero PTEs are not treated differently, > but the two interfaces have been separated pending future work. > - Performance tests with _rdtsc resulted in an improvement of > over 300% compared to the old interface. > - Hyperspace mappings are frequent, so the improvement is > noticeable during startup (3/10ths of a second). > - This also fixes incorrect initializtion of hyperspace -- > pages were zeroed out (which requires hyperspace) before hyperspace > was created.

1 0

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

Re: [ros-dev] [ros-diffs] [dchapyshev] 39709: - Don't direct call IsUserAnAdmin (setupapi in Windows not linked with shell32) - Implement IsUserAdmin in setupapi (based on shell32 implementation) - Implement pSetupIsUserAdmin
by Ged 22 Feb '09

22 Feb '09

Shouldn't advapi32 be using CheckTokenMembership ? -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of dchapyshev(a)svn.reactos.org Sent: 22 February 2009 12:49 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [dchapyshev] 39709: - Don't direct call IsUserAnAdmin (setupapi in Windows not linked with shell32) - Implement IsUserAdmin in setupapi (based on shell32 implementation) - Implement pSetupIsUserAdmin Author: dchapyshev Date: Sun Feb 22 15:49:18 2009 New Revision: 39709 URL: http://svn.reactos.org/svn/reactos?rev=39709&view=rev Log: - Don't direct call IsUserAnAdmin (setupapi in Windows not linked with shell32) - Implement IsUserAdmin in setupapi (based on shell32 implementation) - Implement pSetupIsUserAdmin Modified: trunk/reactos/dll/win32/setupapi/cfgmgr.c trunk/reactos/dll/win32/setupapi/misc.c trunk/reactos/dll/win32/setupapi/setupapi.spec Modified: trunk/reactos/dll/win32/setupapi/cfgmgr.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/setupapi/cfgmgr.… ============================================================================== --- trunk/reactos/dll/win32/setupapi/cfgmgr.c [iso-8859-1] (original) +++ trunk/reactos/dll/win32/setupapi/cfgmgr.c [iso-8859-1] Sun Feb 22 15:49:18 2009 @@ -153,7 +153,7 @@ if (!PnpGetLocalHandles(&BindingHandle, NULL)) return CR_FAILURE; - bAdmin = IsUserAnAdmin(); + bAdmin = IsUserAdmin(); for (i = 0; i < 30; i++) { @@ -209,7 +209,7 @@ FIXME("%p %p %lu %lx %p\n", plcLogConf, dnDevInst, Priority, ulFlags, hMachine); - if (!IsUserAnAdmin()) + if (!IsUserAdmin()) return CR_ACCESS_DENIED; if (plcLogConf == NULL) @@ -336,7 +336,7 @@ TRACE("%p %s %lx %p\n", dnDevInst, debugstr_w(pszID), ulFlags, hMachine); - if (!IsUserAnAdmin()) + if (!IsUserAdmin()) return CR_ACCESS_DENIED; if (dnDevInst == 0) @@ -543,7 +543,7 @@ FIXME("%p %s %p %lx %p\n", pdnDevInst, debugstr_w(pDeviceID), dnParent, ulFlags, hMachine); - if (!IsUserAnAdmin()) + if (!IsUserAdmin()) return CR_ACCESS_DENIED; if (pdnDevInst == NULL) @@ -713,7 +713,7 @@ FIXME("%p %lx %p\n", dnDevInst, ulFlags, hMachine); - if (!IsUserAnAdmin()) + if (!IsUserAdmin()) return CR_ACCESS_DENIED; if (dnDevInst == 0) @@ -812,7 +812,7 @@ FIXME("%p %lx %p\n", dnDevInst, ulFlags, hMachine); - if (!IsUserAnAdmin()) + if (!IsUserAdmin()) return CR_ACCESS_DENIED; if (dnDevInst == 0) @@ -1079,7 +1079,7 @@ TRACE("%lx %lx %lx\n", lcLogConfToBeFreed, ulFlags, hMachine); - if (!IsUserAnAdmin()) + if (!IsUserAdmin()) return CR_ACCESS_DENIED; pLogConfInfo = (PLOG_CONF_INFO)lcLogConfToBeFreed; @@ -3008,7 +3008,7 @@ FIXME("%lx %lx %lx %lx\n", dnFromDevInst, dnToDevInst, ulFlags, hMachine); - if (!IsUserAnAdmin()) + if (!IsUserAdmin()) return CR_ACCESS_DENIED; if (dnFromDevInst == 0 || dnToDevInst == 0) @@ -3385,7 +3385,7 @@ TRACE("%lx %lx\n", ulFlags, hMachine); - if (!IsUserAnAdmin()) + if (!IsUserAdmin()) return CR_ACCESS_DENIED; if (ulFlags & ~CM_DETECT_BITS) @@ -3903,7 +3903,7 @@ FIXME("%lx %lx %lx\n", dnDevInst, ulFlags, hMachine); - if (!IsUserAnAdmin()) + if (!IsUserAdmin()) return CR_ACCESS_DENIED; if (dnDevInst == 0) Modified: trunk/reactos/dll/win32/setupapi/misc.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/setupapi/misc.c?… ============================================================================== --- trunk/reactos/dll/win32/setupapi/misc.c [iso-8859-1] (original) +++ trunk/reactos/dll/win32/setupapi/misc.c [iso-8859-1] Sun Feb 22 15:49:18 2009 @@ -1685,3 +1685,71 @@ { return IsEqualGUID(lpGUID, &GUID_NULL); } + +/* + * implemented + */ +BOOL +WINAPI +IsUserAdmin(VOID) +{ + SID_IDENTIFIER_AUTHORITY Authority = {SECURITY_NT_AUTHORITY}; + HANDLE hToken; + DWORD dwSize; + PTOKEN_GROUPS lpGroups; + PSID lpSid; + DWORD i; + BOOL bResult = FALSE; + + if (!OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY, &hToken)) + { + return FALSE; + } + + if (!GetTokenInformation(hToken, TokenGroups, NULL, 0, &dwSize)) + { + if (GetLastError() != ERROR_INSUFFICIENT_BUFFER) + { + CloseHandle(hToken); + return FALSE; + } + } + + lpGroups = HeapAlloc(GetProcessHeap(), 0, dwSize); + if (lpGroups == NULL) + { + CloseHandle(hToken); + return FALSE; + } + + if (!GetTokenInformation(hToken, TokenGroups, lpGroups, dwSize, &dwSize)) + { + HeapFree(GetProcessHeap(), 0, lpGroups); + CloseHandle(hToken); + return FALSE; + } + + CloseHandle(hToken); + + if (!AllocateAndInitializeSid(&Authority, 2, SECURITY_BUILTIN_DOMAIN_RID, + DOMAIN_ALIAS_RID_ADMINS, 0, 0, 0, 0, 0, 0, + &lpSid)) + { + HeapFree(GetProcessHeap(), 0, lpGroups); + return FALSE; + } + + for (i = 0; i < lpGroups->GroupCount; i++) + { + if (EqualSid(lpSid, lpGroups->Groups[i].Sid)) + { + bResult = TRUE; + break; + } + } + + FreeSid(lpSid); + HeapFree(GetProcessHeap(), 0, lpGroups); + + return bResult; +} Modified: trunk/reactos/dll/win32/setupapi/setupapi.spec URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/setupapi/setupap… ============================================================================== --- trunk/reactos/dll/win32/setupapi/setupapi.spec [iso-8859-1] (original) +++ trunk/reactos/dll/win32/setupapi/setupapi.spec [iso-8859-1] Sun Feb 22 15:49:18 2009 @@ -213,7 +213,7 @@ @ stdcall InstallHinfSection(long long str long) InstallHinfSectionA @ stdcall InstallHinfSectionA(long long str long) @ stdcall InstallHinfSectionW(long long wstr long) -@ stdcall IsUserAdmin() shell32.IsUserAnAdmin +@ stdcall IsUserAdmin() @ stdcall MyFree(ptr) @ stdcall MyMalloc(long) @ stdcall MyRealloc(ptr long) @@ -566,7 +566,7 @@ @ stub pSetupInstallStopEx @ stdcall pSetupIsGuidNull(ptr) @ stub pSetupIsLocalSystem -@ stub pSetupIsUserAdmin +@ stdcall pSetupIsUserAdmin() IsUserAdmin @ stub pSetupMakeSurePathExists @ stub pSetupMalloc @ stub pSetupModifyGlobalFlags

1 0

SVN server maintenance and upgrade
by Aleksey Bragin 21 Feb '09

21 Feb '09

Hi, we have put our efforts today to upgrade the SVN server machine, which now runs Subversion 1.5.1, and do some routine maintenance like recompressing the reactos repository, reconfiguring everything, etc. As a result, some total (not even readonly access) downtime happened, however it was only slightly more than a couple of hours, so hopefully noone's suffered too much. Now it runs stable, and better than before. Enjoy. Thanks to Franz, Colin and Christoph for helping with setting up and transferring the server. Their help is greatly appreciated. WBR, Aleksey Bragin.

2 1

Re: [ros-dev] Hello Everyone...
by Richard Campbell 19 Feb '09

19 Feb '09

Hi there everyone, Thanks for the comments. Yes, i will be on IRC soon. My AIM username is eek2121. Thanks, Richard Campbell > > > > On Wed, Feb 18, 2009 at 4:04 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote: >> Hi Richard, >> very nice to see you back! >> >> Do you use IRC? If not, any other IM messenger? I could be reached as >> fireballrus(a)gmail.com for gtalk, fireballrus in Skype, 3890063 in ICQ. >> >> If all the above fails, we'll just exchange emails, this is fine too. >> >> >> I'll add your login to the svn, and let you know the password. Your work is >> appreciated! >> >> >> >> WBR, >> Aleksey Bragin. >> >> >> On Feb 18, 2009, at 8:01 AM, Richard Campbell wrote: >> >>> Hi Guys, >>> >>> So After a LONG hiatus I've finally decided to get back into writing >>> code for ReactOS. Some (most?) of you may not remember me. I've been >>> lurking on the lists since 2000-2001, and was an active developer with >>> CVS access for a while back in 2002-2003 (check the commit messages >>> for rcampbell, also submitted quite a few patches). have never stopped >>> reading (although i was/am using a different email address), but >>> haven't touched the code before now. I have a couple of questions: >>> 1) Is my SVN username active? The username is rcampbell. If not, >>> I'll just use bugzilla. 2) Any documentation on coding guidelines >>> such as styles, etc. or rules? I'm sure this has changed since my >>> heyday. >>> >>> Thanks, >>> >>> Richard Campbell >>> _______________________________________________ >>> Ros-dev mailing list >>> Ros-dev(a)reactos.org >>> http://www.reactos.org/mailman/listinfo/ros-dev >> >> >

3 2

truck build problems
by Steven Edwards 19 Feb '09

19 Feb '09

Hi, Does buildbot have its own custom config.rbuild that it uses? I've been having a lot of trouble as I've been trying to boot a build in either vmware or qemu with a virgin ReactOS source tree and RosBE-unix and I always get hung up at the same place. buildbot builds don't show the problem I am having so I am trying to nail down what in the environment could cause the problem. -- 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

3 3

Mapping Network Drives??
by Nick Couchman 19 Feb '09

19 Feb '09

I've search around the ReactOS site, the mailing lists, and the Wiki, and haven't seen this subject out there much. We have an older application that runs on Windows over a network connection. The software must be run over the network and must have a mapped network drive to function correctly. I know that Samba-TNG is available for ReactOS, but this seems to only smbclient and no way to mount or map a network share. Are there any plans or current efforts to support mapped network drive functionality? Thanks - Nick This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

2 1

Test mail
by Andrew Greenwood 18 Feb '09

18 Feb '09

Can we e-mail? Yes we can! (I hope...)

3 2

Hello Everyone...
by Richard Campbell 18 Feb '09

18 Feb '09

Hi Guys, So After a LONG hiatus I've finally decided to get back into writing code for ReactOS. Some (most?) of you may not remember me. I've been lurking on the lists since 2000-2001, and was an active developer with CVS access for a while back in 2002-2003 (check the commit messages for rcampbell, also submitted quite a few patches). have never stopped reading (although i was/am using a different email address), but haven't touched the code before now. I have a couple of questions: 1) Is my SVN username active? The username is rcampbell. If not, I'll just use bugzilla. 2) Any documentation on coding guidelines such as styles, etc. or rules? I'm sure this has changed since my heyday. Thanks, Richard Campbell

6 5

ping pong
by Richard Campbell 18 Feb '09

18 Feb '09

ping?

1 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 39637: fix formatting
by Hervé Poussineau 17 Feb '09

17 Feb '09

tkreuzer(a)svn.reactos.org a écrit : > Author: tkreuzer > Date: Mon Feb 16 21:57:45 2009 > New Revision: 39637 > > URL: http://svn.reactos.org/svn/reactos?rev=39637&view=rev > Log: > fix formatting ... > @@ -118,7 +122,7 @@ > KeAcquireSpinLock(Lock, &OldIrql); > Result = *Destination; > if(*Destination == Result) > - *Destination = *Exchange; > + *Destination = *Exchange; > KeReleaseSpinLock(Lock, OldIrql); > return Result; > } > Is formatting really better now?

1 0

[ros-diffs] [dgorbachev] 39422: Fix bug #4129 in CmpGetNameControlBlock().
by Dmitry Gorbachev 17 Feb '09

17 Feb '09

> No, it's just a matter of coding style used in the kernel. What is a logical basis for adopting this particular rule? Sometimes it is not just a matter of preference. These parentheses are unnecessary for humans, and if they are not needed for compilers or some other tools, they are bad! Without them, the bug could be noticed earlier. Cheers, Dmitry

7 13

[ros-diffs] [dgorbachev] 39422: Fix bug #4129 in CmpGetNameControlBlock().
by Dmitry Gorbachev 17 Feb '09

17 Feb '09

Well, there should be some limit of the number of parentheses, you will probably not want to use them in the a + b * c expression.

2 1

[ros-diffs] [dgorbachev] 39422: Fix bug #4129 in CmpGetNameControlBlock().
by Dmitry Gorbachev 17 Feb '09

17 Feb '09

> I personally feel consistent application of the style is also important, > and that there does not exist a reason to deviate from the established > coding style in this situation. I agree that it is good to follow the consistent coding style. The question is this style itself is good. I meant the abstract case of ((a = b) && (c = d)), not the concrete case of ((ConvKey == HashEntry->ConvKey) && (Length == Ncb->NameLength)).

2 1

[ros-diffs] [dgorbachev] 39422: Fix bug #4129 in CmpGetNameControlBlock().
by Dmitry Gorbachev 17 Feb '09

17 Feb '09

Actually, no reasons were given to use extra parentheses *in this case*. Past mistakes do not justify future mistakes.

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev