Dynamic library loading facility has been introduced today into the Allegro 4.9 trunk.

It is disturbing for developers to track dependencies of static libraries. In fact I have no intention to know that Allegro is using this, this, this and that library and I should put proper ones on import list.

I would like to know your opinion about switching to dynamic loading for specified libraries:

• d3d9.dll - Direct3DCreate9() and Direct3DCreate9Ex()

• dsound.dll - DirectSoundCreate8()

• dinput8.dll - DirectInput8Create()

• opengl32.dll/gdi32.dll - WGL functions only and rest as extensions

• psapi.dll - GetModuleFileNameEx()

This operation will reduce dependencies to:
- dxguid.lib
- winmm.lib

First can be eliminated by using static copies of used GUID's. They should not change in future.

That mean linking of static version of Allegro library to final application will reduce to two libs: winmm.lib and Allegro itself.

What's Your Opinion?

EDIT:
Now list above is displayed correctly.

Sounds good to me... but I'm not a dev.

In the attachments you can find patch for Direct3D9 driver. After applying D3D9 and D3D9Ex will be dynamically loaded from d3d9.dll.

I had tried to use _al_open_library() to handle dynamic libraries but those routines are not available while D3D is initialized, so I went back to WinAPI functions.

If approved I can provide patches for rest of mentioned libraries.

I think it complicates things too much. There should be a way (if there isn't already) to compile out any driver you don't need, but this is going too far.

I'm confused what this is for. Why would you want any dynamic linking for a static build... isn't the point of a static build that you don't do dynamic linking? Do the current A4.9 static binaries require those .dll's to be present?

Yes, there is no static linking to D3D (and probably some others).

Static version of Allegro depends on all mentioned libraries. All of those have to be linked by user application explicitly.

Some of those dependencies can be eliminated at compile time, but this is just stripping the functionality.

Users of Allegro provided as DLL don't have to worry about those things. Things are different when you want to create a monolith executable.

You don't agree because Allegro should depend on d3d9.lib or there is other reason?

As far as I know static linking allow to reduce amount of dll's on which your application depends. In my case I use Allegro as static library so my final application is a single executable. Which is very suitable for casual games.

But still. Even static version of Allegro require d3d9.dll to be present on user system.

Most DirectX *.lib files are just import libraries for dll's and there is no way to link them statically.

The difference between statically linked D3D9 and dynamically linked D3D9 is that Allegro will not crash if d3d9.dll is not present on user system and then fallback to OpenGL is possible.

If it overcomplicates things then maybe it's not that good after all. Most users will probably use the dynamic lib anyway, and those going with the static one can take the extra hassle. But don't mind me, this is up to you the devs.

Well considering D3D9 comes with Vista and Windows 7, it's not much of any issue except on XP. On XP, probably 90% of people already have D3D installed (a lot of computer manufacturers will install it before the machine ships). If they don't have D3D9 libs installed, what makes you think they'll have OpenGL libs installed? The drivers usually come together. Sure, we could fall back on OpenGL 1.1 that comes with windows, but Allegro doesn't support that anyway. So I don't see any point in complicating the code for this.

You got the point. It looks like I have to deal with those extra libraries as usual.

In fact I forgot about fact that Allegro require higher version of OpenGL than 1.1.