Redistribution with Visual Studio 2010

[1337]

In the last few days I've tried to create an actual Orxonox binary archive of the kicklib branch, compiled with Visual Studio 2010.

But it turns out that (as if I didn't know..) we really cannot ship an archive without some installation for various reasons:

1. Even though it once worked to just ship the right DLL for the DirectX SDK used by Ogre (d3dx9_42.dll), this didn't work (strange crashes) on at least one computer (almost new Windows 7 installation).
2. Microsoft doesn't allow shipping of the DirectX as DLLs because the user must agree to their EULA (silent installation is also not allowed)
3. OpenAL doesn't load properly if it wasn't installed (shipping OpenAL32.dll is not enough)
4. Shipping the VS 2010 runtime (msvcp100.dll and msvcrt100.dll) will not make them subject to possible security updates (like the one from last Wednesday for ATL)

Conclusions:

• When deploying Orxonox binaries as an archive (possibly self extracting), we need the user to install the DirectX SDK runtime, OpenAL and the VS 2010 runtime manually.
• Developers need to install the DirectX SDK runtime (unless they have at least the DirectX SDK August 2009 installed) and OpenAL.

I've only had a look at VS 2010 so far. For MinGW, it will not be necessary to install any runtime (we can just ship the DLLs), but DirectX and OpenAL will still be necessary.

An idea to improve on this would be to create an installer with CPack that takes care of the three runtimes and then installs Orxonox in an arbitrary location that has write access or normally (with files being written to AppData). Do you think we need that latter distinction? Because currently we have to tell CMake whether the installation is copyable (everything in one folder inlcuding config) or actually installed.

So much about this topic. I guess I'm currently the only one worried about this kind of stuff, but I would nevertheless like to share what I've found out.

[x3n]

Thanks for sharing your experience.

For MinGW, it will not be necessary to install any runtime (we can just ship the DLLs), but DirectX and OpenGL will still be necessary.

I assume you mean OpenAL? As for DirectX: You're talking about "DirectX SDK runtime", is that the same as the normal DirectX runtime (I'm wondering about the "SDK" in the name)? Because I would be very surprised if the end-user has to install anything SDK related. Apart from that, installing DirectX is common for games.

But instead of installing DirectX we could simply use OpenGL unless the user has already installed a sufficient recent version of DirectX. A notice in the graphics menu could inform the user that he has to install DirectX if he wants to use the DirectX renderer.

For OpenAL we could use another workaround, because it's such a tiny executable and also a very short installation: Every time the user starts the game, we check if OpenAL is installed. If it isn't, we start the installer from within the game (so we ship Orxonox together with the OpenAL installer). Since OpenAL installs itself in the system directory, the Orxonox installation remains copyable.

Concerning the VS 2010 runtime: I don't know much about the runtime installer, so I can not give much advice, but I know (and I already did it for another project) that you can link the libraries statically. This way the dlls (and we have a lot of them) become bigger, but we don't have to install the runtime libraries. So if the installation pleasure matters more than the size of the package this would be a good solution (remember, the data will be several hundered mbs in the end, so the dlls are not that important in comparison).

[1337]

For MinGW, it will not be necessary to install any runtime (we can just ship the DLLs), but DirectX and OpenGL will still be necessary.

I assume you mean OpenAL?

Corrected, thx.

As for DirectX: You're talking about "DirectX SDK runtime", is that the same as the normal DirectX runtime (I'm wondering about the "SDK" in the name)? Because I would be very surprised if the end-user has to install anything SDK related. Apart from that, installing DirectX is common for games.

The DirectX 9.0c runtime is installed on every system >= Win XP SP 2. So we fortunately don't have to install that. However if you develop with the DirectX SDK, you will also need that runtime (d3dx9_42.dll) too, which may only be installed on systems with recent games that use it and don't ship it as DLLs only. We can prettty much assume that it isn't installed an a target system.

But instead of installing DirectX we could simply use OpenGL unless the user has already installed a sufficient recent version of DirectX. A notice in the graphics menu could inform the user that he has to install DirectX if he wants to use the DirectX renderer.

That is indeed a solution. However the user is strongly encouraged to use DirectX on Windows because of performance reasons (I've got more than twice the framerate).

For OpenAL we could use another workaround, because it's such a tiny executable and also a very short installation: Every time the user starts the game, we check if OpenAL is installed. If it isn't, we start the installer from within the game (so we ship Orxonox together with the OpenAL installer). Since OpenAL installs itself in the system directory, the Orxonox installation remains copyable.

I like the idea, but I'm hoping this doesn't provoke any user access problems.

Concerning the VS 2010 runtime: I don't know much about the runtime installer, so I can not give much advice, but I know (and I already did it for another project) that you can link the libraries statically. This way the dlls (and we have a lot of them) become bigger, but we don't have to install the runtime libraries. So if the installation pleasure matters more than the size of the package this would be a good solution (remember, the data will be several hundered mbs in the end, so the dlls are not that important in comparison).

I guess a little rephrasal of my previous statement will make your comment obsolete:
Simply shipping the two necessary DLLs is very well possible and extremely simple.

But the point is that if we do so, then these libraries will not be subject to any security updates received through Windows Update. Since Orxonox is just a game, this shouldn't matter. Nevertheless I would be happier to have the user install the runtime on to the system.

[1337]

In the meantime, I've been gathering even more information on DirectX and OpenAL.

For the DirectX SDK end user runtime it is technically possible to just ship the DLLs. The reason why it was not working was because I didn't ship D3DCompiler_42.dll because it being loaded dynamically and therefore not a direct dependency. Somehow it then just loaded an old version or so which resulted in a really strange crash.
Anyway, now it works. And I've seen direct DLL shipment in other games too, but not the big ones like UT or so. Strictly speaking, that is illegal. However Orxonox is small fish to fry, so I think we should go unnoticed if we just ship the DLL. And if there is ever any problem, we can always changes the strategy.

As for OpenAL, I have not found a direct violation of their license if we ship the DLLs. Still, they always recommend to use their installer.
But there still is the technical issue. However if I look at my binary directories of Mass Effec 1/2 or UT 3, then I see OpenAL32.dll and wrap_oal.dll (the wrapper library). Now, in my newly set up Win XP SP3 VM (VirtualBox), shipping wrap_oal.dll too seems to do the trick.
I still have to test this with Windows Vista though.

All in all, we can do without any installations at all, even for MSVC and DirectX. However there are two drawbacks: no updates and it's illegal strictly speaking.