Quote:Original post by paulble
Quote:Original post by MichaelT
Not at all, it is a common problem. It was a bad call to begin with and now we have to live with it. Hopefully they admit their wrongdoings and remove the versionname idea entirely. Better to have the developers patch their software instead. It have only been a few months so the damage is still controllable.
The solution we ended up with for d3dx is the result of some very real issues. For example, Microsoft would like to continually improve the HLSL compiler and other technologies in d3dx (and, in general, most want us to do that too). Some developers who use d3dx must ship on Windows 9x platforms. Most developers who use d3dx are not willing to accept the regression risk that updating shared dlls ex-post-testo causes. Relying on developers to "patch their software" is not always an option -- some developers (or publishers) no longer even exist -- so Microsoft has to try and have solutions whereby we can service our code that applications depend on.
Walking backwards through the above factors, we need a DLL in order to be able to service d3dx effectively. Allowing applications to ship that DLL in their application directory means extremely costly servicing (gdiplus has taught us that). Regression risk means that each release of the shared DLL must be side-by-side in some manner. Windows 9x (and 2k) do not support the Fusion Side-by-Side DLL infrastructure (SxS DLLs) so we have to do some sort of versioning-in-the-filename system.
This isn't a large conspiracy or some wierd power play. It costs us to service things. The monetary aspect is one part but also, our team loses time if we ever have to patch difficult-to-service components. That is time that is better spent on helping developers for our platform in other ways. So poor servicability costs Microsoft and our developers (in different ways). We elected to try and be prepared to service our components if the need arises.
D3DX is in relatively wide use by applications running on a number of Microsoft's platforms and its servicing story required a unique solution. D3DX has also grown from humble beginnings into a pretty large set of APIs and technology in one DLL. We've taken what we've learned through this episode and applied it in numerous ways to future APIs and components. The ability to drop 9x and 2k support (at some point in the future) frees us up tremendously. Ideally, our ability to service components developers depend on would not affect their ability to develop. We're working toward that.
As always though, everyone's comments are welcome, we are listening and trying to improve the situation.
Thanks,
Paul Bleisch
WGGT Solutions
Thanks a lot for the updated comments (and background) surrounding the D3DX DLL Paul.
I think from a developer perspective, more communication like this needs to be in the SDK documentation IMHO. It really beats just being told "Here's how it is, deal with it."
I understand the support side of this though. By day, I do a lot of support for 3rd party apps on the servers and we're constantly running into the same issues you've outlined above. ;)
D3DX has quickly grown from a tacky addon (back in DX7) to the incredibly usefull set of utility methods it provides today.
Although this is an annoying change (for us right now) at the end of the day, it's probably just gonna be a "blip" in the history of DX (ie. similar to the "blip" when DX8.1 came out with no DirectDraw support and the mountains of fury posts here about that).
As for feedback, I think the only problems we're experiencing is the versioning process of the DLL and its redistribution. There should be a simple way that the proper D3DX DLL can be downloaded (or bundled?) for any game using it without violating the DX license agreement and which the customer does not need to redownload the entire runtime installation.
OR perhaps a way to include this "updating" process via the DirectX Control Panel. Then I can simply tell my customers to go to the Control Panel guy and hit the "update D3DX" button which will automagically try to grab the latest version from the MS website and dump it on the local machine (in a quiet mode).
