MDX1 or MDX2.. That is the question..

At least, it's been the question people have been asking me quite a bit.  Given we haven't announced the availability of the XNA Framework yet, but we have announced that MDX2 is a "technology preview", but will never ship in a "released" mode, the answer seems relatively straight forward to me.

If you are shipping something that needs to be "released" by a particular date, you'll probably want to be using MDX1, as it is already released and available.  If you have a project that isn't tied to any strong dates and you can wait for us to ship the XNA Framework, you can stick with whatever you're using right now, be it MDX1 or MDX2.

The question is somewhat more complicated if you fall into the former, but the "particular date" is say a year out.  Then it becomes more of a business decision for you.  "Can I risk sticking with MDX2/XNA Framework with no guarantees it would be out within a year."  If you can't, then you should probably be using MDX1..

Comments

• Anonymous
  April 12, 2006
  Is there any chance of an MDX1 hotfix to fix the VS2005 MDA problem?

• Anonymous
  April 12, 2006
  Slightly off topic, What are your thoughts on the performance of XNA compared to MDX?

• Anonymous
  April 12, 2006
  I subscribe 100% to Shadow's legit question. I have the strong feeling that a significant segment of the CLR2.0 based projects with a release date within the next 6 months switched to MDX2.0 for only one reasons: MDX1/Framework2.0 MDA issue. Needless to say that probably in most of the cases the switch was made way before anybody outside Microsoft could possible foreseen that MDX project will merge into XNA and suddenly become uncertain matter.
  
  So, as it is in this very moment, I think we should probably ask ourselves very seriously: MDX1/VS2003 or XNA/VS2005? ...now “That is the” (right) “question”...
  (Magisterial Will, please accept my apologies for daring to play games with your famous words. Thank you!)
  
  But then again, the things change, so personally I would not be surprised at all to see Microsoft releasing MDX2.0 within the next 6 month or so, simply as a gesture of commitment to its customers if not for other economical reasons (let’s not forget, DirectX SDK is a free product).
  

• Anonymous
  April 12, 2006
  yup. that fix would be very helpful indeed.
  
  WM_THX
  thomas woelfer
  
  

• Anonymous
  April 13, 2006
  It might have been fairly obvious, but thanks for the official version :)
  
  As for the VS2005 MDA problem, that's easily disabled by following these instructions: http://www.thezbuffer.com/articles/304.aspx. I've written some 15+ samples (mostly for our MDX website) and I haven't experienced any problems the loaderlock MDA should guard against, so I guess it's safe to turn it off.

• Anonymous
  April 13, 2006
  I understand that MDX2 is still beta, but what is exactly required to deploy an MDX2-based application?
  
  I have a primitive sample that only renders a cylindric mesh in MDX2. It runs fine on my Windows XP system with the DirectX SDK installed.
  
  When I install this MDX2 application on a Windows 2000 system with the DirectX End-User Runtime (and .NET 2.0) installed, it fails miserably with exceptions at startup.
  
  After porting the sample back to MDX1 (still with Visual Studio 2005 / .NET 2.0), it runs on my Windows 2000 system just fine.
  
  What's the magic behind? Is MDX2 runtime support limited to Windows XP or do I need to install the full SDK rather than the DirectX End-User runtime?
  
  Thanks in advance for shedding some light on this.
  Patrick

• Anonymous
  April 13, 2006
  Dear Rim,
  
  I hate to be rude, but you are missing the point. It's not that you can not turn the MDA off. In fact you might turn the MDA on/off as much as you like, well... pretty much in the same manner you can use try/catch to hide a variety of errors in your code.
  
  The point is you are deploying commercial applications to a variety of customers and in order to run without errors you need to apply system wide changes or deploy together with your application mda.config files. In the first case you need to inform your customers about these changes before installing your application; in the second case it is very possible that your customers will notice the mda file that just came with your application. In both cases, you will end-up providing endless explanations to your customers why you had to do that. These explanations could sound like this: “I decided to use a very cool Microsoft product in my application but you know what, it happens that I’m getting a LoaderLock MDA error when I run it so I had to hide it.” You simply do not afford to do that.
  
  Not yet convinced? Let me put the problem this way: you have a beautiful application that works wonderful BUT... is based on MDX2.0 BETA. What stops you deploying that application? You know it runs perfectly, your DV group just put the OK stamp on it and yet you have to put your application’s RTM on hold. That’s right. Somewhere in the chain there is a tiny BETA, and although you know this is not a problem from your application perspective, 99.9% of your customers might not be that sure about. That BETA might be the difference between success and total failure. The irony makes that if Microsoft would declare tomorrow the very same MDX2.0 anything but BETA, the above problem would miraculously disappear. Why Microsoft does not afford to do that, at least not right now, we could probably extrapolate the above or similar scenarios, just making sure to use the appropriate 6 digits magnitude order when considering the number of potentially impacted users.
  

• Anonymous
  April 18, 2006
  Sandrino,
  
  I don't think you understand what these MDA's are.  It's stands for Manged Debugging Assistant.  They only exist as part of Visual Studio 2005 and only run when you are debugging (i.e. running your app from inside VS).
  
  When using the MDX1.1 libraries the MDA gives a false alert about a possible loader lock problem.  To get round it you just turn them off.
  
  When you turn them off you are only saying to Visual Studio that you don't want them to run for THIS project.  All other projects are unaffected.  
  
  But the main point is that you do not need to "apply system wide changes or deploy together with your application mda.config files." on the users' (customers') machines.  Nothing needs to be done on users' machines.  MDA's are only a part of Visual Studio.  So when you run a compiled assembly outside of the VS development environment there are no MDA's active anyway.  So there's nothing to give false warnings about a loader lock problem.
  
  I use VS2005 with the MDX1.1 libraries and regularly deploy to other machines.  All I ship is the .exe and dlls.  No mda.config files.  I don't even know what they are.  I don't make any changes to the destination machine's configuration at all.  The program works fine.
  
  Paul

• Anonymous
  April 19, 2006
  Sandrino: Paul is correct. The MDA only fires when the application is run under the debugger. When the application is running from the EXE its doing exactly the same thing as it used to under .Net 1.1 and MDX 1. There are no configuration changes to make on on any of your end users machines. If you have a link to what an MDA.config file is I would love to know.
  
  Patrick: Since MDX2 is in beta there is currently no other way to get the assemblies onto a machine other than installing the SDK. The Runtimes do not contain it. Nobody wants to encourage people to go live with beta software. Give Tom's announcement its likely there never will be.
  

• Anonymous
  April 22, 2006
  
  Please, please release MDX 2.0. MDX 1.1 is not a good option for development targetting .NET 2.0.
  
  XNA is a totally seperate platform and should be kept as such. Why destroy MDX 2.0 in the process?

• Anonymous
  May 15, 2006
  How much different will be XNA and MDX2?
  
  If XNA will be totally incompatible or very difficult to port from MDX2 is not very clear to me.
  
  I've read that the people of Microsoft are putting great effort in make XNA nearly equal to MDX2, at least in the managed Direct3D part, but these are compromises only. I've liked to see MDX2 in a non-beta form rather than wait for the full XNA framework and the delays associated with a "revolutionary" technology from Microsoft (Vista anyone?)
  
  I hope converting MDX2 code to the XNA framework will not need "Carmack-like" programming skills or monetary fees.
  
  (Sorry but my english is not very good)

• Anonymous
  January 21, 2009
  PingBack from http://www.keyongtech.com/2528456-directx-audiovideoplayback-namespace-in-directx

• Anonymous
  May 29, 2009
  PingBack from http://paidsurveyshub.info/story.php?title=tom-miller-s-blog-mdx1-or-mdx2-that-is-the-question