Because not everyone wants them, and those who do can get them easily. The PNG format has licensing issues as well IIRC. Not sure if that still applies.

I was pretty sure of that, but it was the excuse for a while. Or maybe it was zlib with the incompatible license; I forget.

Well, I'm just parroting what I've heard in other threads. Feel free to contribute to the thread by informing all what the real reason is.

Because we aren't totally sure how to do it. If we compile zlib/libpng into Allegro, you won't have a way to upgrade those libs without rebuilding Allegro. If we leave them external, there's no easy way to tell if the user already has them or not (Unix could use a configure check, but Windows and DOS has no such way to check).

What's I'd say is to just compile them into their own DLLs durring make, then after running make install, put a note to run 'make install-zlib' and 'make install-libpng' if you don't already have those libs installed. Unix would do those extra installs automatically if configure didn't detect them. Though that still leaves the "problem" that the user would have to link in more than just -lalleg (though here again, Unix could add those as needed, I don't think Windows/DOS would have a way to automatically).

I believe GCC allows you to specify extra libs when creating a lib (via gcc or g++), and those extra libs will be added automatically when the new lib is linked to a program. But AFAIK, MSVC doesn't do that.

I think the main reason is because of what window's programmers term "DLL Hell"... Personally, I wouldn't mind having a few more of the "useful" features incorperated into the main library stream. DLL's are bad, but there is no reason to completely avoid them.

Especially if we could do some cool stuff like specify where the dll's are located...

Speaking of which, is there any way to do something like #define ALLEGRO_DLL_SEARCHPATH "/dlls" and move the dll's out of the program directory (or have the option to place them elsewhere, at least)?:)

Yes; add "../dlls" to your PATH.

Need? Perhaps not. But a) it'd make the Allegro lib bigger, and b) you'd lose out on all the advantages future versions of those libs may have (maybe an updated PNG standard, faster and better decoding/encoding, etc).

You'd only have to recompile and install libpng and zlib.. and everything that uses them automatically uses the updated libs (assuming you're using dynamic libs, which IMO is dumb not to for these).

GCC could probably get away with it, but I don't think other compilers would.

I've tried compiling both Miran's and Steve's GUIs and failed in both cases because I haven't managed to compile some of required libraries. Some of you probably won't agree, but I think that libraries should come in binary form too.

That's not the same thing. There's a difference between many GUI libraries (err, two?) and adding support for PNGs. There aren't 10 different ways to load a PNG. It either works, or doesn't (excluding bugs).

Though, I must ask, does that matter in this day-and-age? It's already bigger than a floppy. How big are SDL, OpenGL, and DirectX?

I still think using dynamic linking is better. Making the lib bigger may not be that big of a deal, but I think the loss of easilly upgrading the libs for your project is. Even if you specify zlib and libpng explicitly on the command line, the ones in Allegro would override it. Not to mention if you do: -lalleg -lsome_other_lib_that_uses_zlib_andor_libpng -lpng -lz.. how would GCC handle that? You could potentially get both versions of the same lib linked in.