Windows GDi -> Graphics Engine and Some Linux Stuff

[Tyler]

I have been looking through the ReactOS code and i am unable to see how the user mode GDI (gdi32.dll) communicates with its kernel mode counterpart, which in turn talks to the driver. Does anyone know of the method used, as i cannot find any Graphics related system calls.

On a related note in the X Windows System is all graphics related code in user mode meaning no system calls relating graphics?

Finally if X11 communicates with the graphics driver how do the virtual consoles (the text consoles you can switch to) go back into text mode? Defininitive, not speculation please this could seriously hinder my current programming position.

Thankyou.

[Alboin]

For Linux graphics, I do believe X uses ioctl to access /dev/mem. Here. Also, one can access the Linux framebuffer, like directfb does.

Good Luck!

[Tyler]

Thankyou, yet another step towards completiong... a few million more and i will be well on my way.

[Tyler]

Any ideas?

[JoeKayzA]

I have been looking through the ReactOS code and i am unable to see how the user mode GDI (gdi32.dll) communicates with its kernel mode counterpart, which in turn talks to the driver. Does anyone know of the method used, as i cannot find any Graphics related system calls.

Are you sure about that? gdi32.dll communicates with the win32k.sys module in the kernel, and the only way that could be done is through system calls. AFAIK there is a device object for graphics that handles control operations (like setting video mode and stuff) and the win32k.sys that handles all drawing related issues.

I know you didn't want speculation, and I'm sorry I can't give you references right now, so please take this with a grain of salt for now. When I'm at home I'll take a look at the reactos source code to give you more definitive answers and references in code. (I'm interested in these things as well, as you might see)

[Tyler]

Are you sure about that? gdi32.dll communicates with the win32k.sys module in the kernel, and the only way that could be done is through system calls.

That is exactly what i assumed, but unlike NTDLL i could find no dispatch routines for calling win32k, i pobably jsut missed something really obvious so i will go over it again, thanks for the help.

[JoeKayzA]

Ok, I had a closer look at the ReactOS code now, this has made some things clearer.

(ReactOS 0.30 source tarball)/subsystems/win32/win32K/main/dllmain.c, line 356: defines a function DriverEntry which is called when win32k.sys is loaded. Within this function (line 369), a call to KeAddSystemServiceTable() is performed. Through this function, the win32k.sys module registers its exported system calls.

About the dispatcher, I couldn't find one either, however the rbuild file (dll/win32/gdi32/gdi32.rbuild: line 45) specifies a file misc/win32k.S, that really smells like system call code. Unfortunately, my knowledge ends here...

I hope this could give you some hints or thoughts... maybe building the whole source tree could show more, it seems that a bunch of files is generated dynamically.

[Tyler]

Thanks i will look into that, i've never really tried to understand ReactOS because i have no interest in NT Architecture... but i guess it's time for a better look.

[Brynet-Inc]

Thanks i will look into that, i've never really tried to understand ReactOS because i have no interest in NT Architecture... but i guess it's time for a better look.

I have no interest in NT Architecture either.. Finally someone else!

[Tyler]

Thanks i will look into that, i've never really tried to understand ReactOS because i have no interest in NT Architecture... but i guess it's time for a better look.

I have no interest in NT Architecture either.. Finally someone else!

erm... erm... damn im stuck agreeing with you.

Well then there is only one thing for it, in the wise words of the Todd.. virtual high five!

I just wish the NT architecture would burn in hell, preferably sooner than later.

[JoeKayzA]

I just wish the NT architecture would burn in hell, preferably sooner than later.

Agreed, in general. There are some interesting aspects in the NT architecture, but in practice it has grown into a pile of hacks (win32k.sys being the first and most significant). Well ok....

[Tyler]

You wouldn't happen to know if they use a specialised compiler? I find that user32.dll calls functions that it references nowhere... which all appear in the win32k. If the win32k in the kernel then it should be impossible for it to directly call this functions.

So does it use a specialised compiler/linker that replaces these calls with system calls?

[Andrew275]

I actually like NT's kernel architecture quite a bit for the most part. Now the stuff on top of it is another story. But I think Cutler made a lot of good fundamental design choices.

[Colonel Kernel]

So does it use a specialised compiler/linker that replaces these calls with system calls?

I believe that each address space has an area reserved for CPU-specific system call stubs (to abstract away the implementation differences between syscall/sysret and sysenter/sysexit). I think these stubs are put there by the kernel directly rather than loaded in any DLL... that probably accounts for what you're seeing.

[Tyler]

So does it use a specialised compiler/linker that replaces these calls with system calls?

I believe that each address space has an area reserved for CPU-specific system call stubs (to abstract away the implementation differences between syscall/sysret and sysenter/sysexit). I think these stubs are put there by the kernel directly rather than loaded in any DLL... that probably accounts for what you're seeing.

yeah i have seen those, i use a similar self modfying code system to replace many redundent checks in my system including SYSCALL vs INT. Unfortunately it does not explain who resolves the name of the functions. Now that i come to think of it, i can't remember why i wanted to know now, but it is always nice to find out.