Didn't know where to post this so I through it up in here. What is the best strategy for accessing hardware addresses on your computer, or is it indeed OS specific? For instance, if I wanted to access some registers on my video card, or get access to a GPIO port how could I go about doing it in a protected mode setting? Or is it impossible/reliant on the OS to supply system calls for this? If this is the case what API would I utilize to access hardware under XP/Vista?
Protected mode in x86 allows the OS (kernel mode, ring0) code to prevent any and all access to memory and IO ports. In fact Windows does exactly this (as does Windows).
There are some drivers available that can poke holes in the security system - particularly allowing code in user-mode to access IO ports.
For example this:
http://www.beyondlogic.org/porttalk/porttalk.htm
However, for most intents and purposes beyond simple applications to modify the status of the parallel port pins, you probably need a kernel driver to access the real hardware. Writing drivers is a fairly sophisticated way of dealing with hardware, but unfortunately, it's the way that the OS wants us to work with things.
To write Windows drivers, you need a Windows Device Driver Kit for the OS you are targetting (although the latest kit also has support for older OS's, so the Vista WDK will be fine for XP or Win2K - Win9X has a completely different driver architecture, so I'd ignore that alltogether). You probably also need a second PC, so that you can use WinDbg to debug the driver - also, you probably don't want to mess up your current PC by for example using a block of memory after freeing it [and the filesystem decided that's where it's going to put some important file-data that when it's written over by your code prevents the file-system from ever working again!]...
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Been, there, done that, have we?Originally Posted by matsp
... also, you probably don't want to mess up your current PC by for example using a block of memory after freeing it [and the filesystem decided that's where it's going to put some important file-data that when it's written over by your code prevents the file-system from ever working again!]...
--
Mats
Mainframe assembler programmer by trade. C coder when I can.
Not quite I never thrashed the hard-disk, but I managed to mess up some internal data structures in the OS so it crashed - weird blue-screens that you don't expect, in modules that you didn't even know existed.Been, there, done that, have we?
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
So why do you need to directly access hardware?
Why not aspire to learn something? You don't have to stay in application land all the time.
Depending on what kind of access you need, you can do a lot from user mode on Windows. You could use NtOpenSection() on "\device\physicalmemory" followed by NtMapViewOfSection() to bring portions of physical addresses into your address space.
And I'm sure there is a way to read and write ports, if you have proper privileges. All of it probably requires administrator privileges.
Have fun locking up your computer
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Sure.
But sometimes it's also a bad idea to directly access hardware.
Depends on the why.
So if it's for learning, I say go right ahead, but if it's some hackish solution to a problem, then I would say step back a bit and think it over.
100% for fun. I have been playing around with various flavors of microcontrollers, and wanted to play around with my pc at a lower level as well. Mostly to learn how things are happening at a lower level.
Good luck then, and have fun!
Try http://forum.osdev.org/ its a fairly decent site for learning low level stuff.
You can find that and other sites deedicated to OS development at - http://www.google.com/Top/Computers/...ating_Systems/
