ReactOS Community > ReactOS Blogs

I have been writing allot testcase and blackbox testcase see how windows xp works
as you all maybe not known GetStockObject only have 0-19 offical param values
But I did write a for loop from 0 to 255 to see for fun what happen I did see
value GetStockObject(9) did return 0; and I belive it is not insuse any longer
I do not known, but then I did found GetStockObject(20) and GetStockObject(21)
did return values, thanks to ReactOS Gdi handle macros it is easy to found out
if it is really a handle or not so I use the marco for that and then I use the macro
that return the object type of the handle. The GetStockObject(20) did return a
handle to a GDI_OBJECT_TYPE_COLORSPACE and the other GetStockObject(21)
return a handle to GDI_OBJECT_TYPE_BITMAP. This is not documented in MSDN
and I do not have more informations of it at moment

summer :
GetStockObject(20)
return handle to a GDI_OBJECT_TYPE_COLORSPACE

GetStockObject(21)
return handle to a GDI_OBJECT_TYPE_BITMAP

more info will come

Update :
GetStockObject(21) alwasy return a HBITMAP and the bitmap is always 1x1 1bpp
I call that value DC_BITMAP

Comments (0) | Trackbacks (0)

Frist time I found msdn did not match the doc in msdn for DdCreateDirectDrawObject
it was year 2003 when I started play with it and some company concacted me asked
how to use MS directx hal direcly so I did help few company solv it and share my notes
basic for free. in return they did help with some code to reactos and support how
to use some api I did not figout yet. Thuse company rember this I am great full the
cobpration we did at icq and email.

here is next chock
DdCreateDirectDrawObject is the gdi32.dll name it store the handle in pDirectDrawGlobal->hDD
and some other info ms did leave out. Rember the DdCreateDirectDrawObject is call on
NtGdiDdCreateDirectDrawObject seen it depns if it windows 2000 or XP/2003 or Vista who
NtGdiDdCreateDirectDrawObject will acts. any way it is not imported here.
now the found begins for all kernel mode programers. the hDD that returns is not real
handle it is a kernel mode pointer to a undocment struct call EDD_DIRECTDRAW_LOCAL
see yuan directx and gdi32 book for this struct.

Comments (2) | Trackbacks (0)

Hi I am working on ReactOS own dxg.sys I started using the struct _VMEMHEAP if we look at msdn it look like
typedef struct _VMEMHEAP
{
DWORD dwFlags;
DWORD stride;
LPVOID freeList;
LPVOID allocList;
DWORD dwTotalSize;
FLATPTR fpGARTLin;
FLATPTR fpGARTDev;
DWORD dwCommitedSize;
DWORD dwCoalesceCount;
HEAPALIGNMENT Alignment;
DDSCAPSEX ddsCapsEx;
DDSCAPSEX ddsCapsExAlt;
LARGE_INTEGER liPhysAGPBase;
HANDLE hdevAGP;
LPVOID pvPhysRsrv;
} VMEMHEAP, FAR LPVMEMHEAP;

But it missing two member and hdevAGP is not a handle it is a pointer to the struct EDD_DIRECTDRAW_GLOBAL
how does the real struct look like, here is the correct one

typedef struct _VMEMHEAP
{
DWORD dwFlags;
DWORD stride;
LPVOID freeList;
LPVOID allocList;
DWORD dwTotalSize;
FLATPTR fpGARTLin;
FLATPTR fpGARTDev;
DWORD dwCommitedSize;
DWORD dwCoalesceCount;
HEAPALIGNMENT Alignment;
DDSCAPSEX ddsCapsEx;
DDSCAPSEX ddsCapsExAlt;
LARGE_INTEGER liPhysAGPBase;
PEDD_DIRECTDRAW_GLOBAL hdevAGP;
LPVOID pvPhysRsrv;
BYTE pAgpCommitMask;
DWORD dwAgpCommitMaskSize;
} VMEMHEAP, FAR *LPVMEMHEAP;

The EDD_DIRECTDRAW_GLOBAL can be found in the book we recomdated or in ReactOS include file

Comments (0) | Trackbacks (0)

At satday I did start playing with ms d3d9.dll as I already known the
true struct that a COM object are using are hidden for public.

Example 1
install DDK/SDK/DXSDK
then use ddraw.h from sdk or ddk, only header we need from ddk is ddrawi.h
it contain ddraw.dll allmost all struct. But for example it is egunt

DirectDrawCreateEx(&MyDraw....);
now we type cast MyDraw to
DDIRECTDRAW_INT that exists in ddrawi.h
like
LPDDIRECTDRAW_INT NewDraw = (LPDDIRECTDRAW_INT)MyDraw;
we got now known every internal struct for ddraw and how ms ddraw fill it

Now to d3d9 I figout directx 9.0c COM object size is 0x47b8 Bytes big
so the struct we should type cast to is 0x47b8 bytes big.

My home made struct look like this at moment
struct tagDIRECTD3D9_INT
{
LPVOID lpVtbl; / LPDIRECTD3D9 functoions table /
CRITICAL_SECTION d3d9_cs;
DWORD unkonwn1;
DWORD dwProcessId; / ProcessID which process have create this /
struct tagDIRECTD3D9_INT lpInT; / pointer to it self /
DWORD dwIntRefCnt; / incress and deciress by Addref and Release /
DWORD unkonwn2;
GUID DisplayGuid; / {67685559-3106-11D0-B971-00AA00342F9F} */
....
}

all data was found by mointor events in d3d9 with diffent code
example code
IDirect3D9 g_D3D=NULL;
g_D3D = Direct3DCreate9(D3D_SDK_VERSION);
myDX = ( struct tagDIRECTD3D9_INT ) g_D3D;
myDX = ( struct tagDIRECTD3D9_INT *) g_D3D;

then put break point on frist and second mydx and code betwin them

Comments (0) | Trackbacks (0)

I have not blog on long time.
what have I done, I have been working on varius thing like give support to kimtablor and timo in win32k when it was need. same time done a huge change in win32k. It was make our win32k directx support working more like windwos xp/2003, our old desgin was base on windows 2000. now it is gone and we are using new desgin, it mean we got all dx api redirected to dxg.sys and we also got a new thing dxeng it is the that part dxg.sys will call to in win32k when it need todo something.

what more I been playing with allot stuff and working.

Most thing is getting better OpenGL support to reactos by updating mesa and make mesa icd interface working better
thanks to that we are now runing allot diffent games in our own local tree, but thuse change will be in 0.3.4
we also import wine dx support. so u will see wine dx support in reactos as frist step. Screen shot extsts on our website
I will say big thanks to Thomas (reactos devloper), fireball (reactos devloper) and one other guy Kamil Hornicek tykef at atlas dot cz (
irc nick : Pigglesworth), with out theres help, and my we should never had opengl 2.1 support in reactos and working icd interface in mesa32 it mean mesa32 works in windows with the icd interface.

Comments (0) | Trackbacks (0)

I am currently working on getting our general gdi object code more windows compatible and more performant. I have been gathering some info on how the stuff works on windows.
These are my findings:

After modifying gdihv (gdi handle viewer, can be found in our rosapps) it showed me all deleted objects. That are objects where bits 16 - 23 of the type field are zero.
Most of the entries in the table are completely empty with all fields zero. But there are several entries, wich are not completely zero.
Example:
Index: 0x1922, ProcessID: 0, KernelData: 0x00001926, Type: 0x00002805 (bitmap)

It looks like the lower 16 bits of the type field are still containing the object type and the reuse counter. Bits 16-23 are 0 and bits 24-31 can still contain some flags.
Now to the KernelData member. It isn't a kernel mode pointer! Most entries have a value of 0x1xxx, so it is also unlikely that it is the lower 16 bits of the former kernel mode pointer. Let's have a look at the example. The KernelData value is 0x1926, wich is pretty near to it's index wich is 0x1922. When we look at index 0x1926, we find this:
Index: 0x1926, ProcessID: 0, KernelData: 0x00001927, Type: 0x00001908 (palette)
And going on with index 0x1927:
Index: 0x1927, ProcessID: 0, KernelData: 0x00001928, Type: 0x00001905 (bitmap)
Index: 0x1928, processID: 0, KernelData: 0x00000000, Type: 0x04001901 (dc)
Looks like KernelData is a link to the next free entry and we have reached the end here.
Every KernelData value of one of these deleted entries points to another deleted entry by index.

Some more interesting facts:
- the first 10 entries in the handle table are completely zero. Probably reserved for something.
- the number of linked, deleted entries is relatively small (was about 100 on my system)
- the free entry with the hightest index has a KernelData of 0 and all following entries are completely zero.

In ReactOS we currently have an additional singly linked list of free entries. But nothing speaks against using the entries themselves as the free list. Disadvantages are that we have no assembly optimized function like InterlockedPopEntrySList, that works with indices into the handle table and there is a small overhead, because both linked deleted entries and complete zero entries must be taken care of.
I already wrote an implemenation for finding a free entry that should be only a little slower. If written in asm it might even be even faster.
But it still bugs me. I need to think a little more about it and I hope I find either a way that would allow a C implemenation that is not slower or I find some other advantage.

Comments (0) | Trackbacks (0)

I, Timo and Jim Tablor are working on gdi32.dll and win32k.sys in reactos
And make it more windows compatible and when it is done, we can
take our gdi32.dll from reactos and use it in windows xp Build 2600 sp2
it will not be posible to do this for other version of windows. But I am
willing writing a warper betwin our gdi32.dll and windows syscall table
so it mean we need 2 dll todo so. I been talking with our project leaders
about the lates idea, Alesky seam not like it it, for it will create a a smaller
overhead and he dislike that.

Now to good news
we have complete syscall list over windows syscall table for win32k.sys for
Windows 2000 sp4 (32Bits), Windows XP sp2 (32 Bits), Windows Vista (32
Bits). That mean we can write a simple dll files that works on all thuse OS
and on ReactOS. It meaing we can provide a public interface to thuse api if
we wanted. And let each devloper using them, we already have such dll in ReactOS it need be update for Vista syscall table, Later we will add 2003
32bits syscall table, and then the 64bits version of the syscall table, for each
of thuse windows nt that exists

I have also started on puting some note toghter, the Windwos NT gdi32.dll export list and win32k.sys export list, and doing smaller redirect and correct
implement in the doc. so it is very easy for anyone to start make their own
gdi32.dll, if I some time going to a company that I been helping time and time and sittdown on their nt4 server I will gather the syscall list for
win32k.sys as well. What does this mean with simple word ?
It mean we can self create our own gdi32.dll from scrach and implement all
new api for any of thuse os if we which.

The document will problare be avail
when all informations are in. But people at irc getting a preivew of
that document time to time. The lates version are always internal
betwin me and timo, and few other devs that request the lates
doc, for syscall and redirect and smaller code for gdi32.dll.
All info in the doc will go into ReactOS gdi32 and win32k
It mean we will getting very well working gdi32 and win32k
when all changes are in, we for not forget Jim Tablor big redesign
that everyone waiting on Share Memory for gdi32 and win32k.
He is working hard getting this inplace.

Comments (0) | Trackbacks (0)

Timo told me it exists a blog about a program call
syscall lister at openrce, but I did not manger d/l
it, after a while I found the program in another
forum with exe file and full source code, that is
cool. Before I continue I need expain some basic.
Windows NT have syscall tables, it is thuse tables
that user mode api call on to switch to kmode
and doing the context switch. Context switch is to
save the fpu status and allot other thing before
we going into kmode, and context switch is doing
the kmode mode switch as well, In Windows NT
we have learn it always exists four syscall table,
one for NTOSKRNL and one for win32k and it exists
two syscall table that is always empty. I never have
belive Micrsoft leave this table empty. So I run syscall
lister on my windows and found 3 diffent syscall table
In use, The ntoskrnl.sys at table 0, win32k.sys at
table 1, and unexpected spud.sys at table 2. It mean we
got tree diffent syscall table

here is the name I found and the syscall number on win2k 2195sp4
id name param
0x2000: SPUDInitialize 2
0x2001: ? ?
0x2002: SPUDTransmitFileAndRecv 4
0x2003: SPUDSendAndRecv 4
0x2004: SPUDCancel 1
0x2005: SPUDGetCounts 1
0x2006: SPUDCreateFile 15

I hope I figout what thuse doing and how they works.
soon

Comments (4) | Trackbacks (0)

Hi

It have happen allot In reatcos this week
here is what happen

This not my week this week my boss think I work slow but I am great code behine coder but he
whant a faster coder, This is not good and my futuer are unsure at the work place at moment.
not good at all, Now I just have a smaller fight with Colin_Finck he manger getting me on my bad
side. it was not meaing yelling at him at all, he is new with commit access, but he learn how
everthings works, everyone doing smaller mistake they are new, he did commit a patch
that was not approv by our PnP devloper, most of us devloper do not write direcly into the
bugzila or tells we are working on a bugs, it is basic more knowing what each one is working
on, Next thing was it did not exists a real name and a email to the commit he did. it also
trun me up a bit. also a mistake some new can do. Basic before you can commit a patch
you need found the devloper that wroking in the area the patch applays to. and ask him
about it, But the wrost thing I did go bit over the limit what was accpapte to say,
Colin_Finck did get alomst everthing I was irrations over, and it blow out over him, it was not
suppos to happen at all, it is my second time I been in fight with some got commit access
the frist time I will not speak about, only that I am best friend with that personm he still teasing
me time to time what I did say to him. But I hope Colin_Finck did not take it so hard. I am really
sorry what happen.

Comments (0) | Trackbacks (0)

Hi
I been nag bit and ireate over our windows handling in win32k it does not working correct, most of you notice allot of drawing issue with the windows I been begin some that known ReactOS windows handling code look at it, so Timo Kreuzer did start looking at and fixing smaller bugs, some times back now, it have taken week to fixing one drawing bug after another with windows handling Timo did contact me yestday he notice clipping on the windows in UserGetDCEx does not being set for the hdc, That is serius problem and he did think it must be wrong with our bitblt it is not our bitblt can handler case with cliping and obje the cliping rules then, and it also exists hdc without clipping, and our bitblt obje that rules as well. Only thing I can image something are forgeting setting the clipping for the windows handling or it being delete, I guessing it being deletet in our case, for some werid reason, he ask me looking into this, I do not known the windows handling code. so I will try figout it it with him, toghter will try figout how to solv this problem.

Comments (0) | Trackbacks (0)