While working on the model loading code, the compiler complained about fopen() being deprecated. These warnings aren't new, but I've been wondering for a while what exactly caused the functions to become deprecated. So after a Google search I found myself at the MSDN reading "Security Enhancements in the CRT", which led me to partially read "Repel Attacks on Your Code with the Visual Studio 2005 Safe C and C++ Libraries". Basically the functions are deprecated because new ones were written which check for buffer overruns and various misc. checks such as making sure that pointers are not NULL. The part which I'm the most interested in however are the changes they made to error handling. More functions return error codes now, which makes my job a little easier since I don't have to guess at why the function returned a NULL pointer.

I also did a little research into the relation between Direct3D/OpenGL and the graphics driver. I've wondered for a while how you could make your own graphics API, and I think I have an answer: You can't unless you write your own drivers or can convince driver developers to adopt your API. This might be a bit vague, so I'll try to explain my understanding of how things work.

A graphics API is just an interface to the graphics driver. You are effectively communicating "directly" with the graphics driver when you use Direct3D/OpenGL (I'll get to why that is in quotes shortly). If you aren't familiar with the term in relation to programming, an "interface" is a set of functions which act as the only way of communicating with a "black box". A "black box" in this case is a chunk of code which you do not have access to, and you do not know how it works exactly. Direct3D/OpenGL is pretty much just a design which the driver developers use. Because all of the driver developers will be working with the same design, you end up with a common "face" to the driver, allowing your program to easily communicate without trying to figure out which driver it is talking to.

This brings us to why I used quotes earlier. There is actually another layer in between your application and the graphics driver when you use Direct3D. Rather than plugging your application directly into the driver, you are attached to the Direct3D layer (I am assuming this is d3d*.dll). The Direct3D layer performs some additional work (again, I am assuming here) and handles communication with the actual graphics driver.

In the case of OpenGL, I think you are plugged directly into the graphics driver... I don't know very much about OpenGL though.

Reposted from http://invisiblegdev.blogspot.com/