February 2006 SDK Available..

I'm always the last person to announce these things, but.. Hey.. Did you hear?  The February SDK is out!

While the MDX2 assembly is still in beta form for this release, it's still pretty exciting for me currently.  The time in which it will be in release mode is rapidly approaching, and I'd be lying if I didn't say I'm quite excited about the future.

For this release, there was more of the same as the last release.  Missing functionality implemented (you can actually save your textures/surfaces again!)  Bug fixes, performance improvements, the majority of the D3D samples were ported to MDX2 as well.

Obviously I can't promise anything right now, but we're hard at work trying to get this up to the quality required to be called "released", and I'm confident of our ability to get it done. Everyone's on board, the documentation is coming along nicely, and things are moving at a nice pace.  I'm excited because it seems to me that soon, we'll be starting the revolution of managed code in gaming.

As always, please provide any feedback in the API you feel needs more polish.  I believe David has been deleting/locking posts in the public forums on the beta, so make sure you post them in the beta newsgroups. I try to monitor that relatively often (and when I forget, David's there to remind me).  I'd recommend getting any suggestions/comments/feedback/bugs/anything else in quickly though. Time's a-tickin!

Comments (17)

  1. tanks,, tanks

    We have allso realease a game engine running

    MDX2 assembly and February version

    your software just work this time

    tanks again.



  2. LinWinOverlord says:

    Why did you move DirectShow header files from the DXSDK to the Platform SDK… Now I have to waste 200MB+ because of features that I don’t want but installer installs just because I need DirectShow! I already have Visual Studio 2005! Fix this for the next DXSDK and Platform SDK

  3. Micah says:


    I hate to burden this with you, but I am still getting the "The specified module could not be found. (Exception from HRESULT: 0x8007007E) error", even with the Feb SDK.  I get it on both my win2003 boxes ( however, I had beta build on my desktop and don’t trust it as much ).  I have a brand new laptop that has Windows 2003 Sp1, MSDN version of VS2005 and Net 1.1 and 2.0.   Thats it!  Of course the Feb SDK is on the box.

    My only thought is this error is due to Win2K3.  It seems everyone else is having no trouble using the beta build.  However, a lot of developers are using VS Express and XP.

    I get the error as soon as I make a call to the DirectX assembly, like initializing a device.  Even just one line like init the PresentParameters thows the exception.

    As of yesterday, I am fully giving up.  So I thought I would at least ask you if you could shed some light on what .dll is missing from my system.

    I do have an XP box, but it is not a development environment, it is mine and my wifes personal desktop.  I just did not what to install an IDE and SDK just to validate a test case.

    Thanx for listening.



  4. Tom Miller says:


    Do you have XInput9_1_0.dll on your system?

  5. Micah says:


    The search came up negative for XInput9_1_0.dll.  

    I then searched for XInput* and got about 14 lines of results all residing in various DX SDK Feb directories.  So things like XInput.h, .lib, etc.



  6. Tom Miller says:

    I find it strange you don’t have that dll on your system.. :/  That is most certainly the cause of your problems..  Did you install everything in the SDK?

  7. Micah says:

    I only downloaded and installed the big 337 MB one.  Are there any satellite packages that you recommend.  Also, I checked a box that only has the December SdK and that file is not on that box either ( this is here at work ).

    I can try to install the End User Runtimes packages and see what happens.



  8. Micah says:

    Ok, I did not realize that the SDK installer had the redistributable unchecked by default.  So, now I see the files XInput9_1_0.dll in Feb 06 SDK redist directoryOct2005_xinput_x86.cab and _x64.cab respectively.  If they are in .cab files, then are those files not deployed?

    My one line of code MDX solution still throws the exception as seen above.  To the best of my knowledge, every item in the SDK installer was set to install and no red x’s.

    So, now I am stuck again.  I hope you don’t think I am a moron 8-P


  9. Cyrus says:

    I can’t get DirectInput running, whats wrong with the following code?

    It worked with the MDX 1.1 Assemblies:

    Device mouse = new Device(SystemGuid.Mouse);



       CooperativeLevelFlags.Background |


    mouse.Acquire(); // ARGUMENTEXCEPTION here 🙁

  10. Andreas Jung says:

    Check return codes (HRESULTs) from the unmanaged method equivalents in the unmanaged DX docs.

    It basically says that you get this exception when the data format has not been set for this device. A look at your code seems to confirm this.

    I guess MDX derived the device format from the device GUID in earlier releases and this behavior did now change or something similar.

    Good luck…

  11. Thomas Kadlec says:

    Does PIX work using managed directx in FEB2006 release?  

    I’m almost positive I’ve been able to use PIX to profile a managed dx app in the past.  Although now when I attempt to profile a mdx app with PIX, pressing start experiment doesn’t seem to really do anything (the mdx app never displays).

    For this test i used DirectX SDK (February 2006)SamplesManagedDirect3DBinx86csBasicHLSL.exe as my expiriment program path.

    Using c++ basichlsl.exe works as expected though.

  12. Marcus says:

    Hi Tom,

    Using DirectX 8’s DirectSound with VB6, i’m sure there was an event that fired when the SecondaryBuffer object had finished playing a WAV file. I notice from your current managed DX9 examples that the way you determine if a file has finished playing is by using a timer that just keeps firing until the WAV has finally finished. Would it be worth/possible to add the event? Just seems to me that the timer method is a bit "clunky"?


  13. swt says:

    Just want to let you know I posted some feedback in the Beta newsgroup:

       – "February MDX 2.0 Feedback" (2/15)

       – "Additional MDX 2.0 Feedback" (2/17)

    Hope you saw this feedback.  I can enter these suggestions into the beta feedback system if necessary.

  14. Alexander Gayevoy says:

    Greetings, Tom

      We are porting our DirectX C# software from April 2005 SDK to Feb 2006 SDK, and it’s difficult!

      I personaly like and dislike some new design elements of the new DirectX. One of them, that I really dont like is to pass byte[] to the methods of GraphicsBuffer and others (in particular GraphicsBuffer.Write() and Direct3D.Geometry.ComputeBoundingSphere()). Is it possible to pass just GraphicsBuffer as an alternative?

      By the way, we enchanced previous version of the DirectX framework, e.g. made it thread safe. The only thing we couldnt achive is to have more then one DirectX controls inside same Form (on different tabpages of a TabControl), but it would be possible if we had DirectX sources 😉 It just doesnt like to share hardware device between two controls. However, we made similar control with OpenGL (C#).

      If you would like to talk about DirectX design and our work (for framework), please, feel free to drop me a line at tau_alex (@) yahoo (dot) com.

       Thank you!

    Kind regards,

      Alexander Gayevoy

      Microsoft Certified Application Developer

      Indie Consulting Services


  15. LudVichzme says:

    Hi !

    I don’t know if this comment will help you, but I hope.

    So with the following apps :

    Managed DirectX 2.0

    Visual C# Express (Final)

    Windows 2003 Server

    if you try to Create a D3DDevice in your app width MDX2.0 , you’ll receive a FileNotFound exception

    (The specified module could not be found. (Exception from HRESULT: 0x8007007E) )

    So with FileMon, I’ve seen that the problem is that the dll XINPUT9_1_0.dll is missing.

    Re-installing the DXSDK or the Redist don’t resolve the problem !

    So to solve the problem you must

      – Open the file "C:Program FilesMicrosoft DirectX SDK (February 2006)RedistOct2005_xinput_x86.cab"

      – Extract the file xinput9_1_0.dll to your Program Executable Path.

    And then, the program will run without any problem 🙂

    Sorry If my English is bad, but I’m from France :s But I hope that this message will help persons whichs are trying to dev under w2003.

    Ludovic C. From France

  16. Andris11 says:

    Hello, hopefully someone watching this,

    I started a thread on microsoft’s forums to get help with ManagedDX buffered mouse input.


    The whole problem might well be with typecasting an ‘int BufferedData.Offset’ value to DirectInput.Mouse type. (code snippet provided)

    I didn’t found any official documentation regarding the correct use of MDX.DirectInput, especially of the buffered mouse am also suspicious about being there a bug or incomplete implementation with DirectInput and buffered mouse…

    Can anybody help? Best on the forum thread mentioned.

    Thanks a lot

Skip to main content