- Ros-dev - ReactOS.org

Re: [ros-dev] [ros-diffs] [mpiulachs] 31563: - Show localized error messages
by Ged Murphy 02 Jan '08

02 Jan '08

Can you fill the headers out correctly please? See any other the other reactos sources as to how this is done. There's also a wiki page detailing this. Thanks, Ged. +/* + * ReactOS kernel + * Copyright (C) 2003 ReactOS Team + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ +/* $Id: registry.h 21704 2006-04-22 13:55:01Z tretiakov $ + * COPYRIGHT: See COPYING in the top level directory + * PROJECT: ReactOS text-mode setup + * FILE: subsys/system/usetup/errcode.h + * PURPOSE: + * PROGRAMMER: + */

1 0

Re: [ros-dev] cursoricon.c
by tamlin＠algonet.se 02 Jan '08

02 Jan '08

oripipa wrote: >IS this correct? interpreting a shared cursos should never be destroyed? No. But then shared resources are not yet implemented (at least wasn't last I checked) why this code wasn't too incorrect. Your change most certainly is not right, as it'd make the code never remove anything from the list. Current code removes the process-owned icons (from the list) when the process terminates. Is this case really properly locked? I don't know. More research is needed for shared resources. -- Mike

2 1

Re: [ros-dev] [ros-diffs] [zguo] 31552: Finish editing all the documentation in ntddraw.
by Aleksey Bragin 02 Jan '08

02 Jan '08

On Jan 2, 2008, at 8:26 AM, zguo(a)svn.reactos.org wrote: > Author: zguo > Date: Wed Jan 2 08:26:00 2008 > New Revision: 31552 > > +* Before calling this function please set the > puCanCreateSurfaceData->ddRVal to an error value such as > DDERR_NOTUSPORTED, > +* The Function NtGdiD3dContextDestroy destorys the context data we > got from NtGdiD3dContextCreate Editing Magnus' text leads to a temporary syndrome of an obtained greatlordia (light form, fortunately) ;) WBR, Aleksey Bragin.

1 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 31536: [FORMATTING] Fix indentation
by Aleksey Bragin 01 Jan '08

01 Jan '08

It looks like the first part of the patch contains some new stuff along with reformatting. WBR, Aleksey Bragin. On Jan 1, 2008, at 9:55 PM, pschweitzer(a)svn.reactos.org wrote: > Author: pschweitzer > Date: Tue Jan 1 21:55:52 2008 > New Revision: 31536 > > URL: http://svn.reactos.org/svn/reactos?rev=31536&view=rev > Log: > [FORMATTING] Fix indentation > > Modified: > trunk/reactos/drivers/filesystems/ntfs/fsctl.c > > Modified: trunk/reactos/drivers/filesystems/ntfs/fsctl.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/ > filesystems/ntfs/fsctl.c?rev=31536&r1=31535&r2=31536&view=diff > ====================================================================== > ======== > --- trunk/reactos/drivers/filesystems/ntfs/fsctl.c (original) > +++ trunk/reactos/drivers/filesystems/ntfs/fsctl.c Tue Jan 1 > 21:55:52 2008 > @@ -54,64 +54,64 @@ > > like this: > - if (DiskGeometry.MediaType == FixedMedia) > + if (PartitionInfo.PartitionType != PARTITION_IFS)

1 0

Invitation to exhibit at SoCal Linux Expo 6x
by Gareth J. Greenaway 01 Jan '08

01 Jan '08

Greetings, I would like to formerly invite the ReactOS project to participate in the 6th Annual Southern California Linux Expo. The show will be taking place February 8th - 10th, 2008 in Los Angeles, CA conveniently located near the LAX airport. ReactOS had a presence at SCALE 5x, Alex Ionescu and a few community members showed off ReactOS and answered questions from attendees. It would be great having ReactOS at the show again for 2008. Because ReactOS is a dotORG organization, we would provide a complementary booth including all amenities such as electricity, Internet access, etc. We would also provide 3 complementary passes to the show for those people interested in representing ReactOS. If this sounds like something that someone from the ReactOS project might be interested in, I encourage you to fill out our dotORG Exhibitor Application which can be found here, http://www.socallinuxexpo.org/scale6x/conference-info/calls-for-papers/call… Any questions, please do not hesitate to ask. Thank you and Happy Holidays! Gareth -- Gareth J. Greenaway <g(a)socallinuxexpo.org> Voice - 877-831-2569 x130 Southern California Linux Expo http://www.socallinuxexpo.org

1 0

Happy New Year, ReactOS!
by Aleksey Bragin 31 Dec '07

31 Dec '07

Hi, it's 2 hours before the new year comes here, and I take this chance to wish our developers, testers, supporters, helpers, and everyone else a good, happy and lucky new year! It's been (and it still is!) a pleasure to work with you all (during all years, even if there were troubles), a lot of progress has been done. Everyone worked as hard as he was able to, and results are truly fantastic. I appreciate that a lot, and the new, coming year is going to be even more interesting! Happy New Year! With the best regards, Aleksey Bragin.

1 0

About GDIOBJHDR header changes
by Magnus Olsen 31 Dec '07

31 Dec '07

Hi I been working on dxg.sys some time now and documented some behovir, I started blackbox how DxLock work. it is base on gdi how thing it work, using same GDIOBJHDR struct. I do not go into detail here we all known who dx is handle in win32k in xp and higher. here is the public header of GDIOBJHDR typedef struct _GDIOBJHDR { HGDIOBJ hHmgr; PVOID unknownCount; ULONG cExcLock; ULONG Tid; }GDIOBJHDR, PGDIOBJHDR; I want change it to typedef struct _GDIOBJHDR { HGDIOBJ hHmgr; WORD Count; WORD Type; ULONG cExcLock; ULONG Tid; }GDIOBJHDR, PGDIOBJHDR; hHmgr Handle for this object. Count A counter of a kind Type which GDI Object type it is cExcLock if the object is lock or not Tid The Thread it belong to I hope we can do this change and I want comment and verify from Timo and Jim about this change

4 16

cursoricon.c
by Oriol 31 Dec '07

31 Dec '07

IS this correct? interpreting a shared cursos should never be destroyed? IntDestroyCurIconObject(PWINSTATION_OBJECT WinSta, PCURICON_OBJECT CurIcon, BOOL ProcessCleanup) { PSYSTEM_CURSORINFO CurInfo; HBITMAP bmpMask, bmpColor; BOOLEAN Ret; PCURICON_PROCESS Current = NULL; PW32PROCESS W32Process = PsGetCurrentProcessWin32Process(); /* Private objects can only be destroyed by their own process */ if (NULL == CurIcon->hModule) { ASSERT(CurIcon->ProcessList.Flink->Flink == &CurIcon->ProcessList); Current = CONTAINING_RECORD(CurIcon->ProcessList.Flink, CURICON_PROCESS, ListEntry); if (Current->Process != W32Process) { DPRINT1("Trying to destroy private icon/cursor of another process\n"); return FALSE; } } *--> else if (TRUE/*! ProcessCleanup*/) { DPRINT("Trying to destroy shared icon/cursor\n"); return FALSE; } ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com

1 0

Re: [ros-dev] [ros-diffs] [greatlrd] 31509: Implement DxDdUnlockDirectDrawSurface Fixed smaller typo in DxDdLockDirectDrawSurface sorry
by Alex Ionescu 31 Dec '07

31 Dec '07

On 30-Dec-07, at 6:12 PM, greatlrd(a)svn.reactos.org wrote: > > + pSurfacelcl = (PDD_SURFACE_LOCAL)(((PBYTE)&pSurfacelcl) + > sizeof(DD_BASEOBJECT)); > This code makes absolutely no sense. You do realize you're returning a stack address, right? Best regards, Alex Ionescu

2 1

0.3.4 release
by Aleksey Bragin 27 Dec '07

27 Dec '07

Hi, the only critical blocker left on the release is the keyboard/mouse detection problem in qemu. There are a couple of other major issues related to the installation in qemu, but if they aren't solved by january, I'm ok to release with them. LiveCD is going to be partly broken too, because hardly any application starts in it, but I don't have time to fix this issue (if anyone volunteers - feel free to). The CursorIcon problem would be fun to have solved too (hint: janderwald & shell32). With the best regards, Aleksey Bragin.

4 3

Re: [ros-dev] compiling multiple .mcs
by Aleksey Bragin 24 Dec '07

24 Dec '07

Maybe let's postpone mc translations to further releases (like 0.4)? WBR, Aleksey Bragin. On Dec 24, 2007, at 5:21 AM, Timo Kreuzer wrote: > I have just compiled kernel32 with 2 different .mcs in the rbuild file > and it compiles without problems. > The resources shown by PE explorer were as expected the German ones > (2nd > mc file) > It also created 2 headers. > A slight change to the rbuild syntax could fix that problem: > > <file locale="en-US">lang/errcodes-en-US.mc</file> > <file locale="de-DE">lang/errcodes-de-DE.mc</file> > <mcheader target="include/psdk/errcodes.h>msg-en-US.mc</file> > > I had to manually add the #include to the rc file. This job should > also > be done by rbuild. > rbuild should create the rsrc.rc in the intermediate dir and > include all > locaized rcs and precompiled mcs for the languages > that are to be compiled. IIRC this feature is already in the rbuild > branch. > > Greeting, > Timo

1 0

compiling multiple .mcs
by Timo Kreuzer 24 Dec '07

24 Dec '07

I have just compiled kernel32 with 2 different .mcs in the rbuild file and it compiles without problems. The resources shown by PE explorer were as expected the German ones (2nd mc file) It also created 2 headers. A slight change to the rbuild syntax could fix that problem: <file locale="en-US">lang/errcodes-en-US.mc</file> <file locale="de-DE">lang/errcodes-de-DE.mc</file> <mcheader target="include/psdk/errcodes.h>msg-en-US.mc</file> I had to manually add the #include to the rc file. This job should also be done by rbuild. rbuild should create the rsrc.rc in the intermediate dir and include all locaized rcs and precompiled mcs for the languages that are to be compiled. IIRC this feature is already in the rbuild branch. Greeting, Timo

1 0

BETA Version of RosBE-Unix 1.1
by Colin Finck 22 Dec '07

22 Dec '07

Hello everybody, For your information, I finished a new version of RosBE-Unix. To be on the safe side, I marked it as a BETA version, so you still have time to try it out :-) You can get the BETA version of RosBE-Unix 1.1 from http://reactos.colinfinck.de. The major changes are updated compilers (they are exactly the same as in RosBE-Windows 1.1 now) and several bug fixes. A complete list of changes is available here: http://www.reactos.org/forum/viewtopic.php?p=39179#39179. Please try it out and report bugs if you find some. Best regards, Colin Finck

1 0

Re: [ros-dev] [ros-diffs] [hpoussin] 31369: No need to compile libxml2, as it is not used
by Steven Edwards 21 Dec '07

21 Dec '07

On Dec 21, 2007 5:26 AM, <hpoussin(a)svn.reactos.org> wrote: > Author: hpoussin > Date: Fri Dec 21 13:26:41 2007 > New Revision: 31369 > > URL: http://svn.reactos.org/svn/reactos?rev=31369&view=rev > Log: > No need to compile libxml2, as it is not used It should be. If you change the config.h for the wine modules and add an include path so that msi and msxml can find the libxml2 public headers and compile I bet Office 2003 and friends will install on ReactOS. -- 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

1 0

Re: [ros-dev] [ros-diffs] [fireball] 31324: - Changed .spec back to .def again (this time .def is a modified output of that .spec, so that stdcall exported symbols are not decorated with @X). - Added winebuild-generated "real" stubs, to be converted to real implementation in the future.
by Aleksey Bragin 19 Dec '07

19 Dec '07

Generic behavior is to 1) use .spec for DLLs (because usually DLLs are shared with Wine, which uses the same format), but for msvcrt it was not possible. 2) implement a stub as soon as possible whenever it is hit WBR, Aleksey Bragin. On Dec 19, 2007, at 4:20 PM, Sylvain Petreolle wrote: > Could these stubs be added to other dlls too ? > > For example, audiosrv crashes is being killed by EXCEPTION_WINE_STUB, > because setupapi misses the CMP_RegisterNotification function. > > Kind regards, > Sylvain Petreolle (aka Usurp)

1 0

[ros-diffs] [fireball] 31324: - Changed .spec back to .def again (this time .def is a modified output of that .spec, so that stdcall exported symbols are not decorated with @X). - Added winebuild-generated "real" stubs, to be converted to real implementation in the future.
by Sylvain Petreolle 19 Dec '07

19 Dec '07

Could these stubs be added to other dlls too ? For example, audiosrv crashes is being killed by EXCEPTION_WINE_STUB, because setupapi misses the CMP_RegisterNotification function. Kind regards, Sylvain Petreolle (aka Usurp) Je ne suis pas d'accord avec ce que vous dites, mais je me battrai jusqu'à la mort pour que vous ayez le droit de le dire.I may disagree with what you have to say, but I shall defend, to the death, your right to say it. - VoltaireRun your favorite Windows apps with free ReactOS : http://www.reactos.orgListen to non-DRMised Music: http://www.jamendo.com

1 0

Re: [ros-dev] [ros-diffs] [cfinck] 31298: Revert 31292, 31294 and 31297. Every change I try for fixing the build in one component breaks the build for another component. winebuild wasn't synchronized completely to the Wine version anyway, and the cur
by Steven Edwards 19 Dec '07

19 Dec '07

On Dec 18, 2007 6:03 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote: > I merged it, taking in account winebuild's changes (using output() > function for example), so in 31300 it seems to work correctly. > > I didn't really understood that AJ's message - Wine does not need > stubs as stubbed functions at all, but rather want all of them to be > manually implemented in a standalone .c file as stubs? or? As we discused on IRC he wants to do away with pseudo-stubs or at least does not think they should be used in a PE build. I tend to agree a function should either be implemented, fully stubbed or not there at all unless an application is proven to need it. Needless stubbing results in breakage when an application calls GetProcAddress/LoadLibrary and would normally fail with grace if the function is not there. Instead it can hit one of these fake stubs, assume its safe to keep working and blow up on you. As for your other question about decoration in mangled symbols for stdcall functions I am not quite sure I understand it. The only decorated functions I saw in the spec file were all cdecl. There were others that are exported variables and some stdcall functions but they did not have decoration unless I just missed it. -- 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

1 0

Re: [ros-dev] [ros-diffs] [cfinck] 31298: Revert 31292, 31294 and 31297. Every change I try for fixing the build in one component breaks the build for another component. winebuild wasn't synchronized completely to the Wine version anyway, and the current Wine
by Aleksey Bragin 18 Dec '07

18 Dec '07

I merged it, taking in account winebuild's changes (using output() function for example), so in 31300 it seems to work correctly. I didn't really understood that AJ's message - Wine does not need stubs as stubbed functions at all, but rather want all of them to be manually implemented in a standalone .c file as stubs? or? WBR, Aleksey Bragin. On Dec 18, 2007, at 5:11 AM, Steven Edwards wrote: > On Dec 17, 2007 6:36 PM, <cfinck(a)svn.reactos.org> wrote: >> Every change I try for fixing the build in one component breaks >> the build for another component. >> winebuild wasn't synchronized completely to the Wine version >> anyway, and the current Wine version removed support for the -- >> pedll option we use, so a full clean sync isn't possible. > > Can you merge the --pedll patch up to the trunk rather than reverting? > You might want to comment out the stubs anyway or add real stubs and > submit them to wine as per Alexandre's rejection of the patch by GvG > > http://www.winehq.org/pipermail/wine-devel/2004-December/031978.html > > 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

1 0

Re: [ros-dev] [ros-diffs] [cfinck] 31298: Revert 31292, 31294 and 31297. Every change I try for fixing the build in one component breaks the build for another component. winebuild wasn't synchronized completely to the Wine version anyway, and the current Wine
by Steven Edwards 18 Dec '07

18 Dec '07

On Dec 17, 2007 6:36 PM, <cfinck(a)svn.reactos.org> wrote: > Every change I try for fixing the build in one component breaks the build for another component. > winebuild wasn't synchronized completely to the Wine version anyway, and the current Wine version removed support for the --pedll option we use, so a full clean sync isn't possible. Can you merge the --pedll patch up to the trunk rather than reverting? You might want to comment out the stubs anyway or add real stubs and submit them to wine as per Alexandre's rejection of the patch by GvG http://www.winehq.org/pipermail/wine-devel/2004-December/031978.html 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

1 0

Re: [ros-dev] DLL Base Addresses (For Marc)
by Aleksey Bragin 17 Dec '07

17 Dec '07

On Dec 16, 2007, at 4:10 PM, Marc Piulachs wrote: > Hi Alex, > > Let me see if I understood this correctly. The problem is not > really on > manually choosing the base address, the problem is that module's > "baseaddress" attribute is optional, even when the module is of type > "win32dll", if this attribute is empty rbuild sets a common default > base > address (0x10000000 for win32 dll's). No, the problem is exactly choosing the address: modules overlap with each other, and manually calculating baseaddresses often doesn't work. Alex proposed to automate this process and do a baseaddress.rbuild file generator. There are not many dlls with baseaddress missing, and if it's missing, it should be added to those (in trunk). > AFAIK we are using the same base address that the equivalent > component has > on windows so auto generating it using any sort of tool is not > really an > option. Not really, in most cases (might be with a few exceptions), it's not possible to use exactly Windows' base address (because size of our modules and windows modules often differs). The problem is to distribute the dlls in the memory address space so that they don't overlap. As for baseaddress in xml form - baseaddress is a module's property, it's not a standalone object which is part of the module. I don't see why it should be given a standalone tag (maybe I'm missing something). WBR, Aleksey Bragin.

6 7

Re: [ros-dev] [ros-diffs] [cfinck] 31296: Rename DSOUND_DllRegisterServer to DllRegisterServer and DSOUND_DllUnregisterServer to DllUnregisterServer. (the same is already done in the other DirectX DLL's with SPEC files) I wonder how dsound.dll could be compile
by Steven Edwards 17 Dec '07

17 Dec '07

Hello, On Dec 17, 2007 5:01 PM, <cfinck(a)svn.reactos.org> wrote: > URL: http://svn.reactos.org/svn/reactos?rev=31296&view=rev > Log: > Rename DSOUND_DllRegisterServer to DllRegisterServer and DSOUND_DllUnregisterServer to DllUnregisterServer. (the same is already done in the other DirectX DLL's with SPEC files) > I wonder how dsound.dll could be compiled in the past cause the SPEC file never referenced to these functions. Maybe there was a bug in older versions of binutils. Perhaps it was ignoring unresolved exports marked PRIVATE. -- 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

1 1

MESSAGETABLE localisation
by Timo Kreuzer 16 Dec '07

16 Dec '07

I have thought about localizing our messagetables, like kernel32's errorcodes.mc Now the question is: how do we do this? We could simply add all localisations inside the current file without changing anything else in the build process. I didn't test if it works, but it should. But it would lead to huge files full of different languages and would also remove the possibility for custom selection of the languages that are compiled. I would prefer to go the way we do with other localisation: put different .mc files in the lang subfolder. But afaik mc files don't allow inclusion of external files, so we need some build process that compiles the different mc files into rc files and include those into a main rc file. Currently our mcs are defined in makefile. This should move to the rbuild files and rbuild should compile the mc files and create the needed rc: <module...> ... <file>foo.c</file> <file>foo.rc</file> ... <autoresource>auto.rc</autoresource> <localization isoname="de-DE">lang/de-DE.rc</localization> <msgtable isoname="de-DE">lang/msgtable-de-DE.mc</msgtable> </module> rbuild would generate <intermediate dir>\lang\msgtable-de-DE.mc.rc and auto.rc containing includes to the generated files. IMO auto.rc should be the file that is compiled, including all localizations and the unlocalized resource file. #include "lang/de-DE.rc" #include "lang/msgtable-de-DE.mc.rc" If I understood Fireball correctly, this is also msvc compatible. And if not, rbuild just would have to generate the files differently. Some ideas for simplifying the rbuild definitions: Instead of <file>, <localization> and <msgtable> we could simply use <file> for unconditional compilation, <file locale="en-US"> for localized conditional compilation. And then let rbuild decide from the file extension what to do with it. resources/messagetables could automatically be included in an autogenerated rc file, without explicitly defining it in the rbuild file. Regards, Timo

3 3

Re: [ros-dev] [ros-diffs] [greatlrd] 31268: fix a typo
by Simon Blomqvist 16 Dec '07

16 Dec '07

Is this code for human ? "@@ -81,7 +81,7 @@ * if they forget set it, the ddraw will autoamtic * set it for system memory. */ - if ((pDDSD->dwFlags & DDSCAPS_SYSTEMMEMORY) != DDSCAPS_SYSTEMMEMORY) + if ((pDDSD->ddsCaps.dwCaps & DDSCAPS_SYSTEMMEMORY) == DDSCAPS_SYSTEMMEMORY) { pDDSD->dwFlags = pDDSD->dwFlags | DDSD_LPSURFACE; }" On Dec 16, 2007 1:46 AM, <greatlrd(a)svn.reactos.org> wrote: > Author: greatlrd > Date: Sun Dec 16 03:46:43 2007 > New Revision: 31268 > > URL: http://svn.reactos.org/svn/reactos?rev=31268&view=rev > Log: > fix a typo > > Modified: > trunk/reactos/dll/directx/ddraw/Surface/createsurface.c > > Modified: trunk/reactos/dll/directx/ddraw/Surface/createsurface.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/directx/ddraw/Surface/… > > ============================================================================== > --- trunk/reactos/dll/directx/ddraw/Surface/createsurface.c (original) > +++ trunk/reactos/dll/directx/ddraw/Surface/createsurface.c Sun Dec 16 > 03:46:43 2007 > @@ -81,7 +81,7 @@ > * if they forget set it, the ddraw will autoamtic > * set it for system memory. > */ > - if ((pDDSD->dwFlags & DDSCAPS_SYSTEMMEMORY) != DDSCAPS_SYSTEMMEMORY) > + if ((pDDSD->ddsCaps.dwCaps & DDSCAPS_SYSTEMMEMORY) == > DDSCAPS_SYSTEMMEMORY) > { > pDDSD->dwFlags = pDDSD->dwFlags | DDSD_LPSURFACE; > } > > > -- MVH Simon Blomqvist Tel - 0735307474 IT www.AgentEyes.com Internet Café www.cafe.agenteyes.com Konst www.konstgrossisten.com/ Jag ringer gratis med www.skype.se mitt id är: simonblomqvist

1 0

gdi object code optimization
by James Tabor 14 Dec '07

14 Dec '07

Hi! Let us start on this now.... It is time to restructure the GDI OBJ Lock Unlock mess! Don't wait for me. I'm working on the DCE issue which is a mess due to gdiobj.c over think object locking system. The new ideas I have will not be compatible with the current system. Thanks, James

3 2

GDI_TABLE_ENTRY structure
by James Tabor 14 Dec '07

14 Dec '07

Hi! Sorry for the delay here,,, This is what we know to be correct sofar. The "Book" section 3.4 GdiTableCell structure is not necessarily correct. typedef struct _GDI_TABLE_ENTRY { PVOID KernelData; SHORT Count:15; Count number of refs. SHORT Lock:1; Does set if locked by process. It also explains why the count shows 1 -> 3 most of the time. SHORT ProcessId; Process Id is here. SHORT nUpper; should match the upper half of the handle. CHAR ObjectType; example-> 0x0401, // not all memdc, dc =1, etc,,, CHAR Flags; --> 0x04 is here, set if memdc, sometimes~. PVOID UserData; } GDI_TABLE_ENTRY, *PGDI_TABLE_ENTRY; Thanks, James

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