Talking to hardware with c++
by Matthew Shapiro · in Technical Issues · 06/04/2002 (8:40 am) · 6 replies
I know it's possible to interface with hardware in some way in c++. Windows interfaces with the display to produce the gui, linux for the display (which is totlaly written in c++). OS's use ti for sound, memory access, hard drive access. But I cna't seem to find any information on how this is accomplished. Can anyone point me to some resources? My main thing is talking to the graphics card.
--KallDrexx
--KallDrexx
#2
--KallDrexx
06/04/2002 (9:09 am)
Thanks Il'l look at those links, but what I want to do prolly has more to do with how, say OpenGL uses Graphics Acceleration (hardware). --KallDrexx
#3
The OpenGL dll is nothing more than a driver of sorts.
06/04/2002 (10:22 am)
that would still be a driver, Windows versions derived from NT ( 2000 / XP ) don't allow direct hardware access.The OpenGL dll is nothing more than a driver of sorts.
#4
Any information available about doing it in linux as I would like my project to work on both.
thanks
--Kalldrexx
06/04/2002 (12:52 pm)
so the opengl "driver" basically is what tells windows how to interact with hardware? hmm.Any information available about doing it in linux as I would like my project to work on both.
thanks
--Kalldrexx
#5
So, Your code talks to opengl, opengl talks to the drivers, the drivers talk to the metal. Thats kinda what happens. I don't know the details of how it happens, as I've never written any device drivers or coded to metal. With programmible shaders in the modern graphics cards you are, in a sense, directly manipulating the hardware.
If you want to do what opengl does, then you probably want to look at the opengl implementation code. I don't know if it is available, but since it is open, it might. Failing that, you could have a look at mesa code, that is an unofficial implementation of opengl I think.
06/04/2002 (2:30 pm)
No, OpenGL talks to the driver. The Card Manufacturers have to expose an interface to opengl. The Opengl gives you the extra level of abstraction, making it platform independant.So, Your code talks to opengl, opengl talks to the drivers, the drivers talk to the metal. Thats kinda what happens. I don't know the details of how it happens, as I've never written any device drivers or coded to metal. With programmible shaders in the modern graphics cards you are, in a sense, directly manipulating the hardware.
If you want to do what opengl does, then you probably want to look at the opengl implementation code. I don't know if it is available, but since it is open, it might. Failing that, you could have a look at mesa code, that is an unofficial implementation of opengl I think.
#6
Any modern OS is not going to like you trying to talk directly to hardware. It
violates security and just generally mucks with things that shouldn't be mucked with
by user processes.
Most modern hardware doesn't have full specifications released anyway, so you're
going to be spending massive amounts (months, years) reverse engineering useful
information out of the hardware to be able to communicate with it directly anyway.
And by the time you figure it out, the hardware will be obsolete, replaced with
hardware that has different internals, and thus all your hardware specific code will
be useless.
writing hardware specific code for games is just plain silly. Use hardware abstraction
APIs like DirectX or OpenGL so your software will run on more than just one type of
hardware. There's really not any speed benefit to be had by direct hardware access
anyway if the drivers to the hardware are good to begin with (NVidia's drivers,
for example, are ridiculously well optimized and trying to outdo them with limited
amounts of knowledge as to what the hardware is doing is just foolish).
If you are REALLY interested in talking to hardware just for the sake of learning, grab
Windows DDK (search for it on msdn.microsoft.com..I believe its openly available to
anyone though I personally get it via my MSDN subscription). For Linux, grab the kernel
source code from any one of thousands of places. You might also want to check out
some of the Linux-specific device driver books. O'Reilly has one that is highly
recommended from other people though I haven't read it personally.
If you gave us more information on the whys of your request we might be able to suggest
better alternatives..What is it that you are trying to accomplish? (if anything?)
06/11/2002 (2:34 pm)
Why do you want to talk to the hardware directly?Any modern OS is not going to like you trying to talk directly to hardware. It
violates security and just generally mucks with things that shouldn't be mucked with
by user processes.
Most modern hardware doesn't have full specifications released anyway, so you're
going to be spending massive amounts (months, years) reverse engineering useful
information out of the hardware to be able to communicate with it directly anyway.
And by the time you figure it out, the hardware will be obsolete, replaced with
hardware that has different internals, and thus all your hardware specific code will
be useless.
writing hardware specific code for games is just plain silly. Use hardware abstraction
APIs like DirectX or OpenGL so your software will run on more than just one type of
hardware. There's really not any speed benefit to be had by direct hardware access
anyway if the drivers to the hardware are good to begin with (NVidia's drivers,
for example, are ridiculously well optimized and trying to outdo them with limited
amounts of knowledge as to what the hardware is doing is just foolish).
If you are REALLY interested in talking to hardware just for the sake of learning, grab
Windows DDK (search for it on msdn.microsoft.com..I believe its openly available to
anyone though I personally get it via my MSDN subscription). For Linux, grab the kernel
source code from any one of thousands of places. You might also want to check out
some of the Linux-specific device driver books. O'Reilly has one that is highly
recommended from other people though I haven't read it personally.
If you gave us more information on the whys of your request we might be able to suggest
better alternatives..What is it that you are trying to accomplish? (if anything?)
Associate Matt Fairfax
PopCap
Overview of Windows Driver Development
Micorosft Windows Driver Development Kits