Ros-dev

ros-dev@reactos.org

5790 discussions

Re: [ros-dev] [ros-diffs] [mkupfer] 39997: - Add a hackfix comment for issue #4243 due to several requests.
by Ged 13 Mar '09

13 Mar '09

It's not UserDrawIconEx which is hacky, it's just the code you added for detecting alpha pixels Ged. -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of mkupfer(a)svn.reactos.org Sent: 13 March 2009 00:21 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [mkupfer] 39997: - Add a hackfix comment for issue #4243 due to several requests. Author: mkupfer Date: Fri Mar 13 03:20:48 2009 New Revision: 39997 URL: http://svn.reactos.org/svn/reactos?rev=39997&view=rev Log: - Add a hackfix comment for issue #4243 due to several requests. Modified: trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c Modified: trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… ============================================================================== --- trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c [iso-8859-1] (original) +++ trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c [iso-8859-1] Fri Mar 13 03:20:48 2009 @@ -1389,6 +1389,7 @@ } +/* FIXME: ReactOS specific hack */ BOOL UserDrawIconEx( HDC hDc,

1 0

Re: [ros-dev] [ros-diffs] [mkupfer] 39989: Evgeniy Boltik <bstsoft AT narod DOT ru> - Fix draw icon with alpha in 32 bit. - See issue #4243 for details.
by Ged 13 Mar '09

13 Mar '09

This looks hacky -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of mkupfer(a)svn.reactos.org Sent: 12 March 2009 21:26 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [mkupfer] 39989: Evgeniy Boltik <bstsoft AT narod DOT ru> - Fix draw icon with alpha in 32 bit. - See issue #4243 for details. Author: mkupfer Date: Fri Mar 13 00:25:49 2009 New Revision: 39989 URL: http://svn.reactos.org/svn/reactos?rev=39989&view=rev Log: Evgeniy Boltik <bstsoft AT narod DOT ru> - Fix draw icon with alpha in 32 bit. - See issue #4243 for details. Modified: trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c Modified: trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… ============================================================================== --- trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c [iso-8859-1] (original) +++ trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c [iso-8859-1] Fri Mar 13 00:25:49 2009 @@ -1389,82 +1389,6 @@ } -#define STRETCH_CAN_SRCCOPY_ONLY - -#ifdef STRETCH_CAN_SRCCOPY_ONLY -void -FASTCALL -DoStretchBlt(HDC DcDest, int XDest, int YDest, int WidthDest, int HeightDest, - HDC DcSrc, int XSrc, int YSrc, int WidthSrc, int HeightSrc, - DWORD Rop3, BOOL Color) -{ - HDC DcStretched; - HBITMAP BitmapStretched; - HBITMAP OldBitmap; - - if (WidthDest == WidthSrc && HeightDest == HeightSrc) - { - NtGdiBitBlt(DcDest, XDest, YDest, WidthDest, HeightDest, - DcSrc, XSrc, YSrc, Rop3, 0, 0); - } - else if (SRCCOPY == Rop3) - { - NtGdiStretchBlt(DcDest, XDest, YDest, WidthDest, HeightDest, - DcSrc, XSrc, YSrc, WidthSrc, HeightSrc, - Rop3, 0); - } - else - { - DcStretched = NtGdiCreateCompatibleDC(DcSrc); - if (NULL == DcStretched) - { - DPRINT1("Failed to create compatible DC\n"); - return; - } - if (Color) - { - BitmapStretched = NtGdiCreateCompatibleBitmap(DcDest, WidthDest, - HeightDest); - } - else - { - BitmapStretched = IntGdiCreateBitmap(WidthDest, HeightDest, 1, 1, NULL); - } - if (NULL == BitmapStretched) - { - NtGdiDeleteObjectApp(DcStretched); - DPRINT1("Failed to create temporary bitmap\n"); - return; - } - OldBitmap = NtGdiSelectBitmap(DcStretched, BitmapStretched); - if (NULL == OldBitmap) - { - NtGdiDeleteObject(BitmapStretched); - NtGdiDeleteObjectApp(DcStretched); - DPRINT1("Failed to create temporary bitmap\n"); - return; - } - if (! NtGdiStretchBlt(DcStretched, 0, 0, WidthDest, HeightDest, - DcSrc, XSrc, YSrc, WidthSrc, HeightSrc, - SRCCOPY, 0) || - ! NtGdiBitBlt(DcDest, XDest, YDest, WidthDest, HeightDest, - DcStretched, 0, 0, Rop3, 0, 0)) - { - DPRINT1("Failed to blt\n"); - } - NtGdiSelectBitmap(DcStretched, OldBitmap); - NtGdiDeleteObject(BitmapStretched); - NtGdiDeleteObjectApp(DcStretched); - } -} -#else -#define DoStretchBlt(DcDest, XDest, YDest, WidthDest, HeightDest, \ - DcSrc, XSrc, YSrc, WidthSrc, HeightSrc, Rop3, Color) \ - NtGdiStretchBlt((DcDest), (XDest), (YDest), (WidthDest), (HeightDest), \ - (DcSrc), (XSrc), (YSrc), (WidthSrc), (HeightSrc), \ - (Rop3), 0) -#endif /* STRETCH_CAN_SRCCOPY_ONLY */ - BOOL UserDrawIconEx( HDC hDc, @@ -1482,7 +1406,6 @@ BITMAP bmpMask, bmpColor; COLORREF oldFg, oldBg; BOOL DoFlickerFree; - INT nStretchMode; SIZE IconSize; HDC hdcOff; @@ -1524,7 +1447,31 @@ when cxWidth or cyHeight is 0 */ if ((bmpColor.bmBitsPixel == 32) && (cxWidth != 0) && (cyHeight != 0)) { - bAlpha = TRUE; + SURFACE *psurfOff = NULL; + PFN_DIB_GetPixel fnSource_GetPixel = NULL; + INT x, y; + + //Find alpha into icon + psurfOff = SURFACE_LockSurface(hbmColor ? hbmColor : hbmMask); + if (psurfOff) + { + fnSource_GetPixel = DibFunctionsForBitmapFormat[psurfOff->SurfObj.iBitmapFormat].DIB_GetPixel; + if (fnSource_GetPixel) + { + for (x = 0; x < psurfOff->SurfObj.sizlBitmap.cx; x++) + { + for (y = 0; y < psurfOff->SurfObj.sizlBitmap.cy; y++) + { + bAlpha = ((BYTE)(fnSource_GetPixel(&psurfOff->SurfObj, x, y) >> 24) & 0xff); + if (bAlpha) + break; + } + if (bAlpha) + break; + } + } + SURFACE_UnlockSurface(psurfOff); + } } if (!diFlags) @@ -1608,8 +1555,6 @@ goto cleanup; } - nStretchMode = IntGdiSetStretchBltMode(hdcOff, STRETCH_DELETESCANS); - oldFg = IntGdiSetTextColor(hdcOff, RGB(0, 0, 0)); oldBg = IntGdiSetBkColor(hdcOff, RGB(255, 255, 255)); @@ -1622,7 +1567,7 @@ goto cleanup; } - DoStretchBlt(hdcOff, + NtGdiStretchBlt(hdcOff, (DoFlickerFree || bAlpha ? 0 : xLeft), (DoFlickerFree || bAlpha ? 0 : yTop), cxWidth, @@ -1633,7 +1578,7 @@ IconSize.cx, IconSize.cy, ((diFlags & DI_IMAGE) ? SRCAND : SRCCOPY), - FALSE); + 0); NtGdiSelectBitmap(hdcMem, hOldMem); } @@ -1642,7 +1587,7 @@ { hOldMem = NtGdiSelectBitmap(hdcMem, (hbmColor ? hbmColor : hbmMask)); - DoStretchBlt(hdcOff, + NtGdiStretchBlt(hdcOff, (DoFlickerFree || bAlpha ? 0 : xLeft), (DoFlickerFree || bAlpha ? 0 : yTop), cxWidth, @@ -1653,7 +1598,7 @@ IconSize.cx, IconSize.cy, ((diFlags & DI_MASK) ? SRCINVERT : SRCCOPY), - NULL != hbmColor); + 0); NtGdiSelectBitmap(hdcMem, hOldMem); } @@ -1729,7 +1674,6 @@ IntGdiSetTextColor(hdcOff, oldFg); IntGdiSetBkColor(hdcOff, oldBg); - IntGdiSetStretchBltMode(hdcOff, nStretchMode); Ret = TRUE;

2 1

Re: [ros-dev] rosapps
by WaxDragon 12 Mar '09

12 Mar '09

The only things I have habitually used in rosapps are ctm, ncftp, and download. I'd hate to see these go away. OTOH, there are quite a few things that l would consider "tests" in rosapps that could be moved. I think the argument that rosapps to long to build is crap. If you want to reduce the build time, ditch explorer. On Mar 12, 2009 11:02 AM, "Ged" <gedmurphy(a)gmail.com> wrote: I prefer this idea. I'd like to see rosapps removed completely and have all non essential stuff in trunk built via an rbuild variable (turned off by default) Ged. -----Original Message----- From: ros-dev-bounces(a)reactos.org [mailto: ros-dev-bounces(a)reactos.org] ... Behalf Of Thomas Bluemel Sent: 12 March 2009 14:17 To: ReactOS Development List Subject: Re: [ros-de...

2 1

Restructuring ReactOS
by Richard Campbell 10 Mar '09

10 Mar '09

Hi Guys, One of the big issues I'm seeing with regards to ReactOS is the lack of overall structure. Currently ReactOS is loosely compatible with NT, 2000, XP, and even Vista. However, I believe that in order to achieve true stability and compatibility some changes should be implemented. I'm offering my opinion as a suggestion of how to structure things. While I believe that everyone should be allowed to have fun developing a great project, I believe that we can still do this, while maintaining a little more structure. Please feel free to comment on this email. First Issue: Moving Target Every since I first started watching ReactOS in 2001, I've noticed that ROS is suffering from moving target syndrome. Microsoft continually releases new versions of Windows each year, and ROS struggles to keep up. driver compatibility, app compatibility, etc. are all affected by this. Development is all over the place. If someone knows how to implement a vista API call, they do it. XP? Same, etc. The problem is this can cause compatibility issues with drivers and apps that do DLL hooking, as well as other oddball scenarios. In order to have truely 100% compatibility, we need to find a way to deal with this type of development. I propose picking a single target, Either Windows XP or Windows 2003, to serve as the trunk (I currently recommend Windows XP since it is compatible with nearly everything out there.) All core development will be based around this. Our releases will be based around this. Branches will be created for Windows 7, Windows Server 2008, and Windows Vista specific code. Any platform specific code will go into this branch. Any code that is no longer valid will be removed from this branch. This allows multiple versions of Windows to be targetted at the same time. The trunk will continue on it's path until a) It is 90-100% compatible with most apps/drivers or b) XP/2003 become so old and out of date they aren't used by anyone anymore, similar to the way 98/NT4/2000 are now. If either of those scenarios happen, we vote to switch to a different branch. We should avoid switching to the most cutting edge version of windows, however, and instead focus on the most widely used version at the time. Second Issue: ROS Hacks I've noticed that a lot of times, people implement app specific hacks in ROS, or worse, they implement ROS specific hacks in different apps. Both of these are very bad practices. Instead of doing either of these, I'd recommend discussing the problems you find with the other developers over the mailing list. For instance, if app XYZ is working, rather than submitting a hackish patch to get it to work, find the root cause of the issue, and solve it there or ask for help to solve it. Third Issue: Unit Tests While there are winetests as well as other small tests, ReactOS (That i know of, unless it's in a seperate repo) does not have an official testing framework. Each developer here should take some time out and write a test for every api currently supported by windows, make it pass on Windows, and then commit it to SVN. If we all write tests, This will help identify bugs in ROS vs Windows. Low level tests are ESPECIALLY needed. Our driver compatibility currently sucks, and it's getting worse every day. Unit testing for driver specific APIs and the HAL would help improve ROS dramatically. Final Issue: Stop mixing user and kernel mode code. On occasion i see developers use ReactOS specific kernel mode code in userland. This process should be avoided. All ROS apps should work on both Windows and ROS, and should not contain any ROS specific checks,etc. This goes back to the second issue. I look forward to hearing your responses to my opinion, and I hope that we can work on getting at least some of these opinions implemented so that we may build a truly great Microsoft Windows Compatible Alternative! Thanks, Richard Campbell

6 7

Restructuring ReactOS...
by Richard Campbell 10 Mar '09

10 Mar '09

Restructuring ReactOS Hi Guys, One of the big issues I'm seeing with regards to ReactOS is the lack of overall structure. Currently ReactOS is loosely compatible with NT, 2000, XP, and even Vista. However, I believe that in order to achieve true stability and compatibility some changes should be implemented. I'm offering my opinion as a suggestion of how to structure things. While I believe that everyone should be allowed to have fun developing a great project, I believe that we can still do this, while maintaining a little more structure. Please feel free to comment on this email. First Issue: Moving Target Every since I first started watching ReactOS in 2001, I've noticed that ROS is suffering from moving target syndrome. Microsoft continually releases new versions of Windows each year, and ROS struggles to keep up. driver compatibility, app compatibility, etc. are all affected by this. Development is all over the place. If someone knows how to implement a vista API call, they do it. XP? Same, etc. The problem is this can cause compatibility issues with drivers and apps that do DLL hooking, as well as other oddball scenarios. In order to have truely 100% compatibility, we need to find a way to deal with this type of development. I propose picking a single target, Either Windows XP or Windows 2003, to serve as the trunk (I currently recommend Windows XP since it is compatible with nearly everything out there.) All core development will be based around this. Our releases will be based around this. Branches will be created for Windows 7, Windows Server 2008, and Windows Vista specific code. Any platform specific code will go into this branch. Any code that is no longer valid will be removed from this branch. This allows multiple versions of Windows to be targetted at the same time. The trunk will continue on it's path until a) It is 90-100% compatible with most apps/drivers or b) XP/2003 become so old and out of date they aren't used by anyone anymore, similar to the way 98/NT4/2000 are now. If either of those scenarios happen, we vote to switch to a different branch. We should avoid switching to the most cutting edge version of windows, however, and instead focus on the most widely used version at the time. Second Issue: ROS Hacks I've noticed that a lot of times, people implement app specific hacks in ROS, or worse, they implement ROS specific hacks in different apps. Both of these are very bad practices. Instead of doing either of these, I'd recommend discussing the problems you find with the other developers over the mailing list. For instance, if app XYZ is working, rather than submitting a hackish patch to get it to work, find the root cause of the issue, and solve it there or ask for help to solve it. Third Issue: Unit Tests While there are winetests as well as other small tests, ReactOS (That i know of, unless it's in a seperate repo) does not have an official testing framework. Each developer here should take some time out and write a test for every api currently supported by windows, make it pass on Windows, and then commit it to SVN. If we all write tests, This will help identify bugs in ROS vs Windows. Low level tests are ESPECIALLY needed. Our driver compatibility currently sucks, and it's getting worse every day. Unit testing for driver specific APIs and the HAL would help improve ROS dramatically. Final Issue: Stop mixing user and kernel mode code. On occasion i see developers use ReactOS specific kernel mode code in userland. This process should be avoided. All ROS apps should work on both Windows and ROS, and should not contain any ROS specific checks,etc. This goes back to the second issue. I look forward to hearing your responses to my opinion, and I hope that we can work on getting at least some of these opinions implemented so that we may build a truly great Microsoft Windows Compatible Alternative! Thanks, Richard Campbell

1 0

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

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