Windows Graphics

It depends on the version of Windows. On Vista, it most likely uses your graphics card.

The real answer, however, is that it doesnt matter. GDI abstracts what is really going on so that you dont have to care and so that the under the hood part can change without breaking existing programs. In this way, code written for Windows 1.0 can safely be compiled and run on Windows Vista and work as intended.

Quote:

Original post by Colin Jeanne It depends on the version of Windows. On Vista, it most likely uses your graphics card. The real answer, however, is that it doesnt matter. GDI abstracts what is really going on so that you dont have to care and so that the under the hood part can change without breaking existing programs. In this way, code written for Windows 1.0 can safely be compiled and run on Windows Vista and work as intended.

What I'm more interested is the implementation of this graphics system, just in theory, to know how the os works. Yes, Vista does use the gx card for the gui, but i mean XP or prev versions of Windows. How does windows manage to draw such incredibly rich graphics, without a gpu? Is it using the video mem thats installed into the motherboard? Is it the same mem that you would use for 16 bit, A000h or something, but only in 32 bit it has more capailities, cuz I think that in 16bit the max you can go is 800x600x16 with VESA.

In Windows, drivers do all the work. Videocards have, like the mainboard (or any other kind of peripheral for that matter), their own BIOS on which the driver software operates to expose more complex functionality and allow programs to share that code.

In the DOS days, every program was implementing its own video and sound drivers, which resulted in lots of hardware being badly supported, and programmer's hell. VESA in that regard is just an API layer on top of the video-BIOS, and basically was the DOS kind of way to solve the problem.

Generic drivers, such as the ones used during install or safe mode, probably use VESA still for 800x600 or will fall back to VGA (if that fails, Windows will eat your CD).

Memory you allocate on the videocard, is indeed physically on the videocard. Given the fact that a videocard has a processor, a BIOS, and memory, you could say it is a tiny computer in itself.

Hopefully this explains a little (no money back).

Quote:

Memory you allocate on the videocard, is indeed physically on the videocard.

Once again, due to wonders of abstraction, it might not be really the case. While some memory is (I presume) always on the board, some solutions have the ability to provide system memory to graphics card.

Quote:

When I get the dc with a GetDC() and I get a chunk of mem to write my graphics into, where does that mem reside?

Not only you do not know where memory resides, you don't even get the memory, but a handle. This is a very strong hint that you really do not want to know what goes on behind the scenes.

Even more - with some software it's possible that there is no memory, but a network link (see MaxiVista for network screen mirroring), which emulates a graphics driver, but sends data to remote computer.

Under linux/unix there's even harder abstractions with file descriptions, where it's possible to do some really interesting hacks. Not to mention hacking kernel to avoid bad memory blocks or other weird thing.

The sole purpose of OS is to make these tiny details transparent. As such, many real implementations burried so deep, that it's really hard to find out how they are really done.

Quote:

Original post by Prototype In Windows, drivers do all the work. Videocards have, like the mainboard (or any other kind of peripheral for that matter), their own BIOS on which the driver software operates to expose more complex functionality and allow programs to share that code. Hopefully this explains a little (no money back).

So does that mean that I can call the card's BIOS just like I would the motherborads BIOS and ask it to perform a specified service?

Quote:

Original by Antheus Not only you do not know where memory resides, you don't even get the memory, but a handle. This is a very strong hint that you really do not want to know what goes on behind the scenes.

I do know that it returns a handle, I was speaking in hypothetical terms, when you request the device context with GetDC(), what device does it actually mean, because usually (at least in DX) a device is a graphics card.

Quote:

The sole purpose of OS is to make these tiny details transparent. As such, many real implementations burried so deep, that it's really hard to find out how they are really done.

But there are basics for OS design and practically every OS out there uses high-resolution 32 bit for graphics output.

My general question is how does any OS specifically windwos cuz im more familiar with it, draw stuff on to the screen at those resolutions. Ok it uses a driver, but what eaxctly does it do? Does it modify a certain memory location? Is that memory location built into the motherboard? Thanks for fast replies [smile]

Quote:

Original post by Antheus Quote: Memory you allocate on the videocard, is indeed physically on the videocard. Once again, due to wonders of abstraction, it might not be really the case. While some memory is (I presume) always on the board, some solutions have the ability to provide system memory to graphics card.

Fair enough. However on current hardware, shared video memory is a concept worth neglecting.

Quote:

Original post by VanillaSnake21 So does that mean that I can call the card's BIOS just like I would the motherborads BIOS and ask it to perform a specified service?

Sure. Anything other software can do, you can do. So in Windows, you would have to write a driver.

Quote:

Original post by VanillaSnake21 Does it modify a certain memory location?

Basically, that's what it boils down to. The videocontroller scans its memory and converts it to a usable signal for the monitor. Any application has to fill the memory, and Windows is not special in that. You can imagine that the Windows interface is largely just drawn from simple lines and boxes itself, especially the ones pre-XP.

[Edited by - Prototype on June 17, 2007 8:22:18 PM]

So lets say I have a clean system no os, but a simple kernel running in protected mode, which steps do I take to get the output similar to that of Windows? Remember there are no rings, no APIs here, everything must be done in the lowest level possible, I can't even call interrupts anymore, so how could this be done? Thats basically what I was getting at all along, I just wanted to know how windows did so I can use it in a diff os...

It depends upon the graphics card, the interface used to control it is specific to it and probably proprietary. There are some shared standards that you can use to write a generic graphics card driver (e.g. VESA). You could take a look at some open source linux graphics drivers to see how they work. Find either a generic one capable of performing how you want, or find a driver for your graphics card and take a look at the source of that.

The answer is different depending on which graphics technology you're talking about.

For Windows GDI you can find a lot of information in the DDK. You may also be able to scrounge a copy of Windows Graphics Programming by Feng Yuan which covers a lot of internals.

The basics (again, for GDI) go like so:

An HDC is basically a bunch of function pointers to routines supplied by device drivers and/or reference implementations of those routines supplied by GDI. When you make a graphics call GDI first decomposes the call into more primitive operations then calls the corresponding routines in the driver. The driver does whatever magic it does (this could be plotting pixels in system memory, shipping everything up to the GPU, packaging up the call and shipping it across the network, etc, GDI itself neither knows nor cares). It's possible that a given driver doesn't want to handle a call in which case there are a set of routines that GDI can either call directly (bypassing the driver) or the driver can call to get out of the work. In these cases GDI has to have access to a bitmap and be aware of the format of that bitmap (e.g. 1bpp or 32bpp). The bitmap can be created by GDI in system memory at the request of either the app or the driver, or it can be created and managed by the driver which is free to use black magic on it whenever GDI isn't looking.

You can actually think of the whole driver interface being exactly the same as virtual functions in C++. A given driver (derived type) may or may not override various virtual functions supplied by the interface. And GDI has default implementations of those functions (as well as other helper functions) that the driver can use when it wants to.

In addition to fairly obvious things like bitmaps, GDI needs to be aware of stuff like clipping regions, palette tranformations, coordinate transformations, etc. All this information is kept track of somehow (often with the assistance of the window manager) and passed to the driver when needed.