[SDL] Question re SDLmain Design Concept

[Doug]

Thanks for the detailed replies, everyone...


>There is nothing to stop you statically linking the runtime libs, and
>dynamically linking SDL. All you have to do is rebuild SDLmain so that
>it also uses the runtime libs statically. The main SDL library will
>continue to work just fine without rebuilding.

This is what I did.  I just rebuild SDLmain to statically link to the C 
runtime library.  As mentioned, I did NOT rebuild SDL.DLL at all - it 
remains unchanged and unmodified.

Before I started investigating this, I had not realized the linking 
structure of SDL, in that I didn't see how SDLmain is code that is part of 
MY application, and SDL.DLL is "external" code that is outside of my main 
application's "sandbox".  Since I did NOT want to rebuild all of SDL, I 
ignored this for a while.  Since I discovered that I can just rebuild only 
SDLmain to static link to solve my problem, this was a VERY easy solution.

Just in case anyone else made the same mistake I did, there is no 
SDLmain.DLL - there's only an SDLmain.LIB that drops "init" code directly 
into my application's code space.


>VS2005 doesn't let you create an app that just uses MSVCR71.dll or
>whatever ? That's really bad if it doesn't.

VS2005 uses manifests embedded in the application.  These manifests 
indicate what runtime libraries the application requires.  Only a release 
build statically-linked application has no EXTERNAL dependencies on a 
runtime library.  And since VS2005 is new, a typical WinXP system does not 
have the required runtime libraries present.

Microsoft provides a distro package that installs the runtime libraries 
required - and this is the "best practice".  But if you know which runtime 
libraries are needed, you CAN copy them to the application's folder and if 
they are present the application will run.  The latter case is not 
recommended my Microsoft as it does an endrun around the SxS assemblies 
management.