Directx 9.0c (December 2005), what's new?

[Blazkowicz]

thanks for all the infos, I now understand what all this "updated DirectX 9" is about.

What about dealing with D3DX like DirectX itself. Why not provide a .exe installer? (I still have a vbrun60sp5.exe lying around )
Games may tell you to install it, press next to continue, most user will click next or press enter as usual for every step.

Silent install?
That reminds me of Myst, installing Quicktime 2 for Windows 3.1 in C:\WINDOWS\SYSTEM without asking you (and not working anyway after the install). Or I have some sharewares in a folder, with helpful name such as "swtlsetup.exe" or whatever, I don't even know what they are or when I downloaded them (no readme.txt) and if I launch the installer it starts copying stuff in c:\windows and c:\windows\system32 and I still don't know wtf is the app about. (so, ESC/cancel )
I hate that

 

[JHoxley]

thanks for all the infos, I now understand what all this "updated DirectX 9" is about.

Excellent :smile: I'm sadly well practiced in this sort of thing - there were 100's of these threads around this time last year on all the developer forums.

What about dealing with D3DX like DirectX itself. Why not provide a .exe installer?

They do

Silent install?
That reminds me of Myst, installing Quicktime 2 for Windows 3.1 in C:\WINDOWS\SYSTEM without asking you (and not working anyway after the install). Or I have some sharewares in a folder, with helpful name such as "swtlsetup.exe" or whatever, I don't even know what they are or when I downloaded them (no readme.txt) and if I launch the installer it starts copying stuff in c:\windows and c:\windows\system32 and I still don't know wtf is the app about. (so, ESC/cancel )
I hate that

Yeah, I can see the "silent install" part freaking out some people. But I guess it is what it is - if you wanna be that paranoid about knowing everything that ever happens during the execution of your program(s) then so be it!

Regarding the DX silent install, I'd see it more as a "sub install" as part of the greater "game install". You've allowed the game installer to get on with its business - and installing DX (+other dependencies) is just another step on it's route to completion...

Jack

 

[Mendel]

It's not communicated to them and shouldn't be. The end user should not even need to know this is happening.

Of course the end user needs to know and control what software is being installed to his computer. And he also needs to know why a new directx 9.0c must be installed when one already is installed.

I'm still freaked out by all these silent installings. Just try installing monster truck madness, you get directx 2 installation forced down your throat, nothing you can do about it So where do we draw the line?

Agreed. Thats why we already have a number of D3DX DLL's - 24,25,26,27,28 - they are the version numbers for the D3DX component. "9.0c" is the version number for Direct3D (etc..).

Okay, I think I now understand whats going on, thanks for the explanation. I still don't agree or accept it though.


Here's my suggestion on what should happen: They should still call directx 9.0c as such and d3dx components with their own respective version numbers... BUT they should make a better branded package of them both and communicate users about that. I don't know what they should call it but just calling it directx 9.0c (name of month) is still confusing and is not standard way of doing things, that's my opinion.

btw, I have never before even heard of a d3dx dll or about their version numbers, is that their complete history? I'd like a complete timeline with dx versions and their respective d3dx versions and what if any changes there were, if possible. Link would do just nicely.

Again, thanks for the explanation, I don't want to argue about it any more, I'm more than willing to agree to disagree to some degree on this one

 

[JHoxley]

I'm still freaked out by all these silent installings.

Yeah, as I said before - I don't doubt you're the only one. Also in that paper I linked to was a discussion of wrapping the DX EULA in with the main product EULA - thus eliminating any need to agree to the installation of DirectX (check the paper for a more detailed reasoning).

Here's my suggestion on what should happen: They should still call directx 9.0c as such and d3dx components with their own respective version numbers... BUT they should make a better branded package of them both and communicate users about that. I don't know what they should call it but just calling it directx 9.0c (name of month) is still confusing and is not standard way of doing things, that's my opinion.

I can see what you're getting at, but I don't see it happening. D3DX isn't for the end-users, it's for us developers to write software using. I can't think of any examples right now (too early in the morning), but I'd be amazed if it was the only optional software component that the installer had to include.

I have never before even heard of a d3dx dll or about their version numbers, is that their complete history? I'd like a complete timeline with dx versions and their respective d3dx versions and what if any changes there were, if possible. Link would do just nicely.

I don't think there's a link explaining it, but here's the rough idea.

When compiling C/C++ code you can either statically or dynamically link to code. The former method actually takes the (3rd party) code and includes it directly into the executable - this can make for a larger executable, but potential for more optimization by the compiler. Dynamic linkage basically ties your application to a DLL - but the actual functionality is still contained in a seperate binary.

D3DX was always a statically linked library until the December 2004 SDK. With the February '05 SDK onwards it became a dynamically linked library (hence the d3dx_??.dll files). Thus an end user would have no particular reason to know D3DX existed until February of last year.

The reasoning for the change was maintenance/security - statically linked code is effectively "gone" as far as this is concerned. If an issue were found with a static version of D3DX it'd require everyone who compiled against it to update their tools, re-compile, re-test and re-deploy their games. I'm sure you can appreciate why that is just not a valid solution However, if it's a correctly registered dynamic DLL (refer to previous posts in this thread) then it can be patched/maintained via Windows Update or just general one-time runtime upgrades. One change fixes everyone.

As far as changes from version-to-version it's probably not of much interest to you - it'd just be a long list of different functions that are exposed to the application programmer. For example, in the April (or possibly June) revision they introduced the UV Atlas tools which were a big new feature. They make using things like PRT on arbitrary meshes a little bit easier as it can solve the unique texel mapping issues.

There have been a number of bug fixes from version-to-version, but as far as I'm aware there have been no security issues with them yet.

Again, thanks for the explanation, I don't want to argue about it any more, I'm more than willing to agree to disagree to some degree on this one

Hehe, s'ok - been a pleasure discussing this :smile:

Jack

 

[Cowboy X]

Well there is a February 2006 update now .