Recently I updated my hardware. Since then, I have encountered a problem using the ID3DXFont interface, particularly the DrawText method.
It took me a while to figure it out.
Stupid Micro$haft have been making crucial changes to DirectX without changing their version number.
Some time between April 2006 and August 2007, the ID3DXFont interface was extended.
Two new methods were injected into the method table, which means that any older executables calling this interface will not work if the user installs the latest directx end-user runtime :O

Attached is an update of the relevant OA32 includefile, correcting this problem for anyone working with 2007 versions of the runtimes.

Undoubtedly, other interfaces will have similar changes, but I'm not going hunting just now.

Posted on 2007-10-14 01:53:25 by Homer
It's been like that for quite a while,  29 times already (if d3dx9_29.dll is the latest). C++ coders needn't notice that, since the header files are there.
Posted on 2007-10-14 10:10:55 by Ultrano
afaik 35 is the latest (august 2007), but that does not mean there are 35 versions, this is just another meaningless number, but at least it grows!
Posted on 2007-10-14 23:50:38 by Homer
Actually it goes from 25 to 35 (10 different versions). Before 25 there was nothing ;p

As for the version numbers: MS started this new naming convention "updates" like "april 2006 update", "summer 2004 update", etc. I think it's because DX10 is for Vista and if they wanted to stick with the old naming, we would have "DX 9.43784823" now :P

minor update: it goes from 25 to 35 - so it's 11 different versions.
Posted on 2007-10-28 17:05:31 by ti_mo_n
and that would be wrong?
Posted on 2007-10-29 11:52:04 by Homer
Confusing, at least ^^' I know that the current state may be confusing for asm programmers, but today no one really cares about asm programmers :( We should start a revolution :P
Posted on 2007-10-29 12:32:53 by ti_mo_n
C++ coders have also some worries. One of those 11 versions changed the whole system of drawing with IDXSprite, then another made the system use buffering, and probably some drawing interfaces have also started using buffering from some point onwards. Such a change generally makes you revisit most of your engine-design decisions, unless you beg for bugs or framedrops.
I'm not up-to-date with the new stuff in the D3DX lib or stuff in the D3D core, since I don't rely on the lib anymore, do buffering myself, and don't push the hardware to the metal. And by requesting a specific core-version, you are assured you get the expected interfaces, performance and interfacing-protocol.
Posted on 2007-10-29 14:53:13 by Ultrano
In C/C++ IDEs you get headers and libs for each version so any change in the parameters (like those mentioned by Homer) is caught during the compilation. D3D9 code creates proper IDirect3D9 interface using the Direct3DCreate9 function (from D3D9.DLL). This function takes the required version as its parameter (the so called 'D3D_SDK_VERSION' which is defined diferrently for each DX9 version). As for the d3dx: every d3dx9 is compatible with every d3d9. Using any of the d3dx function requires proper header and lib and that header/lib pair have the proper .dll name written in them. So it's nearly impossible to mess things up in C/C++. And once compiled, the code is linked with specific dll (hence the change in their names) so that any updates won't mess with existing code.

To summarize things shortly:
- compiling the code requires headers and any lack of synchronization between existing source code and current SDK will be caught by the compiler
- existing code links (at runtime) with its corresponding .dll and with that dll only. Even if it uses only functions like D3DXCreateTextureFromFileInMemoryEx that don't change across different versions.
Posted on 2007-10-29 15:23:49 by ti_mo_n