[SDL] Developing a standalone EXE in VC++ with SDL - possible?

[Ulrich Eckhardt]

On Sunday 27 January 2008 04:06, Martin wrote:
> I set my compiler to generate code as a
> "multi-threaded DLL." However, it turns out this means VC++ won't compile
> the EXE as a standalone (well, standalone as in the EXE and SDL.dll) but
> instead wants to install its own DLLS on the target machine.

Of course, this is actually normal an expected. For things like the C API 
(printf, fopen, exit...) you need library code, dito for the C++ API 
(namespace std) and any other addon library like SDL, too. So, either you 
include all of it in the executable (static linking) or you ship parts of it 
as a DLL or require the user to install the DLL. Note: installing libraries 
on their own and not only as part of a program is actually pretty normal on 
non MS Windows platforms. Further, nothing of this has anything to do with 
SDL.

> I consider this option unacceptable, as I don't want to require an
> installer for such a simple program.

I don't want to download libraries that I already have. I also don't want 
copies of the libraries clogging up my RAM even though they could be shared 
as DLLs. How about providing a URL where users can download additional 
required libs instead of bundling them with your program?

> Including the msvcr90.dll files with the program, per 
> Microsoft's instruction, isn't proving a viable solution (it crashes as
> well).

If the vendor say "do this" and it doesn't work, I'd take it to the vendor's. 
All your problems are rather off-topic here.

> In short, my question is: is there a way to use SDL without requiring that
> my program be compiled as a multi-threaded DLL?

Yes, using static linking.

> Why is it that other compilers seem to produce an end-product (a simple
> executable) that Microsofts' solution cannot?

Other compilers don't work differently, they also need runtime libraries that 
are usually linked dynamically.

Uli