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

I’ve recently begun development of a small game written in C++ using SDL.
Overall, I’ve been very pleased with the library, but I’ve run into trouble when
it comes to porting the finished product to other machines for testing. It runs
fine on the development machine, but errors out in a multitude of ways when
executed anywhere else. Some research reveals that the problem lies in linking
to external runtime libraries.

I’m using Visual Studio 2008 on a Windows XP machine. Per the SDL installation
instructions, 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. I consider this option unacceptable, as I don’t
want to require an installer for such a simple program. Including the
msvcr90.dll files with the program, per Microsoft’s instruction, isn’t proving a
viable solution (it crashes as well).

In short, my question is: is there a way to use SDL without requiring that my
program be compiled as a multi-threaded DLL? Why is it that other compilers
seem to produce an end-product (a simple executable) that Microsofts’ solution
cannot?

Thank you in advance for any assistance you can provide.

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.

UliOn Sunday 27 January 2008 04:06, Martin wrote:

Ulrich Eckhardt <doomster knuut.de> writes:

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.

Whether it’s normal or not on other platforms, having to bother with an
installer or extra downloads or programs on Windows is more trouble than I’d
like to put my beta testers - much less my users - through. I’ve always been a
fan of self-contained, no-installer-needed programs, and would likemy own code
to be so simple.

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?

Testing shows the difference in size between a statically linked executable
using the libraries I need and a dynamically linked one is about 45k. I think
the ease of use of not having to download or install the extra file is worth the
extra overhead.

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.

Ah, but that’s the problem, and why I’m here: the solution from their end is
simple. Compile it as a statically linked program. But all install
instructions for SDL say it must be compiled as dynamically linked when using
Visual Studio, and I’m curious if anyone knows a way around that issue.

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.

Yep, that’s the idea. How, without abandoning SDL, which seems to require that
linking be dynamic?

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.

I apologize; I was under the impression that they produced just an executable.

I think some of our disagreement here might stem from our preferred
environments. Windows users are, in general, much less forgiving of complicated
download processes and installs than those who come from a *nix background.

And I’m sorry if the question seems amateurish, but the build process has
changed a lot since I last wrote in C nearly a decade ago.> On Sunday 27 January 2008 04:06, Martin wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin wrote:

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.

Yep, that’s the idea. How, without abandoning SDL, which seems to require that
linking be dynamic?

I doubt SDL really requires dynamic linking. You can probably get static
linking going without too much effort. Did you try simply changing that
option in VC++, to see if it just works?

You should carefully note that SDL is licensed LGPL, though. This means
that if you statically link your application to SDL, your application
should also be licensed LGPL or something compatible. (Your
application’s source code should then be available somehow.)

If you’re okay with that, and did get it to work, maybe you can add a
FAQ entry on the wiki for others to find.

Regards,

  • – St?phan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHnHTOcFUq0gzqDwQRAkp5AJ90FXzURoLxV9rBWWxZeBeZJnvSCQCg+u3K
Y6OjpgSiUN3cf9uFMKtWW68=
=0omh
-----END PGP SIGNATURE-----

Whether it’s normal or not on other platforms, having to bother with an
installer or extra downloads or programs on Windows is more trouble than
I’d like to put my beta testers - much less my users - through.

Hehe, I think it’s the other way round: it’s rather that the installation
process is less complicated, i.e. a single commandline statement
automatically installing the required libs in this case. :wink:

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.

Ah, but that’s the problem, and why I’m here: the solution from their end
is simple. Compile it as a statically linked program. But all install
instructions for SDL say it must be compiled as dynamically linked when
using Visual Studio, and I’m curious if anyone knows a way around that
issue.

Ah, now I understand the relation to SDL! FWIW, I’d agree with St?phan in that
you should simply try to link SDL statically (Note: this might require first
building a statically linked SDL, too!). Also consider that SDL is licensed
under the LGPL and it’s implications then, you will have to use a compatible
open source license for your code then, too.

UliOn Sunday 27 January 2008 12:03, Martin wrote:

St?phan Kochen <stephan kochen.nl> writes:

I doubt SDL really requires dynamic linking. You can probably get static
linking going without too much effort. Did you try simply changing that
option in VC++, to see if it just works?

You should carefully note that SDL is licensed LGPL, though. This means
that if you statically link your application to SDL, your application
should also be licensed LGPL or something compatible. (Your
application’s source code should then be available somehow.)

If you’re okay with that, and did get it to work, maybe you can add a
FAQ entry on the wiki for others to find.

Regards,

Ah, I hadn’t considered the licensing requirement. While I support open source
for applications, for certain types of games it has its problems, because it
means there are no surprises in store for a player with C++ knowledge.

So rather than focus on statically linking it, I eventually tracked down the
problem with using it dynamically with the help of the assembly manifest.
Because I downloaded the prebuilt SDL DLL and libraries, it was looking for
mscvr80.dll instead of mscvr90.dll (I’m using VS2008). So when it came time to
port the program elsewhere, my code was trying to use one library (and finding
it) while SDL was trying to use an older one that wasn’t included (and erroring
out).

Rebuilding the SDL libs and dll from the source fixed the error.

Thanks for the help!

Thanks for the help!

Another way to bypass all the microsoft dependencies is to compile the
finish project using MingW32, which is what I do. Produces a pretty small
executable and still uses sdl.dll without having to muck about with anything
else really. Works like a charm.

Cheers,
Peter

It’s quite possible to build an exe which behaves in this way using
VC++ 2005 Express (I’ve not updated to 2008 yet) by using the non-DLL
(static) runtime libraries and including SDL_win32_main.c in your
project instead of SDLmain.lib.

I’d be really surprised if it couldn’t be done in the same way with 2008.

Another PeterOn 28/01/2008, Peter Ketting wrote:

Thanks for the help!

Another way to bypass all the microsoft dependencies is to compile the
finish project using MingW32, which is what I do. Produces a pretty small
executable and still uses sdl.dll without having to muck about with anything
else really. Works like a charm.

Cheers,
Peter


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Please point me to a howto on this if you can. Since Mingw isn’t
supported that well in Vista32, and not at all in Vista64, it would be
nice to duplicate this functionality using Visual Studio.

SteveOn Monday 28 January 2008 18:09, Peter Mackay wrote:

It’s quite possible to build an exe which behaves in this way using
VC++ 2005 Express (I’ve not updated to 2008 yet) by using the non-DLL
(static) runtime libraries and including SDL_win32_main.c in your
project instead of SDLmain.lib.

Hi Steve,

Why are you using Vista ?

XP Pro SP2 with WindowBlinds 6.x is a better choice.

I tried Vista for few days and I hate it very much.
Its a TERRIBLE OS - looks pretty but terrible compatibility issues.

My advice is to go back to XP Pro…

Jesse "JeZ+Lee"
slnthero at aol.com
Silent Hero Productions®
Video Game Design Studio
http://www.SilentHeroProductions.com

Stephen Anthony wrote:> On Monday 28 January 2008 18:09, Peter Mackay wrote:

It’s quite possible to build an exe which behaves in this way using
VC++ 2005 Express (I’ve not updated to 2008 yet) by using the non-DLL
(static) runtime libraries and including SDL_win32_main.c in your
project instead of SDLmain.lib.

Please point me to a howto on this if you can. Since Mingw isn’t
supported that well in Vista32, and not at all in Vista64, it would be
nice to duplicate this functionality using Visual Studio.

Steve


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I don’t have a howto link, but here’s a rough guide:

  1. Create a new Win32 project
  2. Fish SDL_win32_main.c out of the SDL source code and add it to your project.
  3. Set the “Character Set” option to “Use Multi-Byte Character Set”
    (needed for SDL_win32_main.c - possibly a bug?).
  4. Add “SDL.lib” to your list of dependencies.
  5. Add a main() method as per usual.

At this point you should have a functional SDL app. Now to get rid of
the unwanted dependencies:

  1. Go into the project properties, C/C++ subtree, Code Generation
    pane, then change “Runtime Library” from "Multi-threaded Debug DLL"
    and “Multi-threaded DLL” (for Debug and Release configurations
    respectively) to “Multi-threaded Debug” and “Multi-threaded”.

That should do it. I verified it just now, and the only dependencies
of my app are “SDL.DLL” and “KERNEL32.DLL”, as desired.

Hope this helps!

PeterOn 28/01/2008, Stephen Anthony wrote:

On Monday 28 January 2008 18:09, Peter Mackay wrote:

It’s quite possible to build an exe which behaves in this way using
VC++ 2005 Express (I’ve not updated to 2008 yet) by using the non-DLL
(static) runtime libraries and including SDL_win32_main.c in your
project instead of SDLmain.lib.

Please point me to a howto on this if you can. Since Mingw isn’t
supported that well in Vista32, and not at all in Vista64, it would be
nice to duplicate this functionality using Visual Studio.

Steve


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Truth be told, I don’t actually use it full time. However, I work on
projects that are multi-platform, and I need to test them everywhere.
For better or worse, that includes Vista. And I also need to test in
64-bit, for which Vista64 is a better choice than XP64. Basically, I
need to test several Windows configurations and 32/64 issues, and I only
want one install of Windows, so Vista64 it is.

SteveOn Monday 28 January 2008 18:30, Jesse P. wrote:

Hi Steve,

Why are you using Vista ?

XP Pro SP2 with WindowBlinds 6.x is a better choice.

I tried Vista for few days and I hate it very much.
Its a TERRIBLE OS - looks pretty but terrible compatibility issues.

My advice is to go back to XP Pro…

Thanks for the info. I’ll try this out right away.

SteveOn Monday 28 January 2008 18:36, Peter Mackay wrote:

I don’t have a howto link, but here’s a rough guide:

  1. Create a new Win32 project
  2. Fish SDL_win32_main.c out of the SDL source code and add it to your
    project. 3. Set the “Character Set” option to “Use Multi-Byte Character
    Set” (needed for SDL_win32_main.c - possibly a bug?).
  3. Add “SDL.lib” to your list of dependencies.
  4. Add a main() method as per usual.

Actually, mingw32 works just fine for me on this Vista x64 workstation. Who
told you mingw isn’t supported on Vista? Anyway, if you can get the effect
you want on VC++, you might as well go that route. Otherwise, I assure you
that mingw works great.

Chaz> ----- Original Message -----

From: sa666666@gmail.com (Stephen Anthony)
To: "A list for developers using the SDL library. (includes SDL-announce)"

Sent: Monday, January 28, 2008 2:48 PM
Subject: Re: [SDL] Developing a standalone EXE in VC++ with SDL - possible?

On Monday 28 January 2008 18:09, Peter Mackay wrote:

It’s quite possible to build an exe which behaves in this way using
VC++ 2005 Express (I’ve not updated to 2008 yet) by using the non-DLL
(static) runtime libraries and including SDL_win32_main.c in your
project instead of SDLmain.lib.

Please point me to a howto on this if you can. Since Mingw isn’t
supported that well in Vista32, and not at all in Vista64, it would be
nice to duplicate this functionality using Visual Studio.

Steve


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

So, this is not considered static linking of SDL? Hallelujah! You sir, are a
champion!!! I’ve got to try this out on my project now!
-Dave> ----- Original Message -----

From: mackay.pete+sdl@gmail.com (Peter Mackay)
To: "A list for developers using the SDL library. (includes SDL-announce)"

Sent: Monday, January 28, 2008 4:06 PM
Subject: Re: [SDL] Developing a standalone EXE in VC++ with SDL - possible?

I don’t have a howto link, but here’s a rough guide:

  1. Create a new Win32 project
  2. Fish SDL_win32_main.c out of the SDL source code and add it to your
    project.
  3. Set the “Character Set” option to “Use Multi-Byte Character Set”
    (needed for SDL_win32_main.c - possibly a bug?).
  4. Add “SDL.lib” to your list of dependencies.
  5. Add a main() method as per usual.

At this point you should have a functional SDL app. Now to get rid of
the unwanted dependencies:

  1. Go into the project properties, C/C++ subtree, Code Generation
    pane, then change “Runtime Library” from "Multi-threaded Debug DLL"
    and “Multi-threaded DLL” (for Debug and Release configurations
    respectively) to “Multi-threaded Debug” and “Multi-threaded”.

That should do it. I verified it just now, and the only dependencies
of my app are “SDL.DLL” and “KERNEL32.DLL”, as desired.

Hope this helps!

Peter

On 28/01/2008, Stephen Anthony wrote:

On Monday 28 January 2008 18:09, Peter Mackay wrote:

It’s quite possible to build an exe which behaves in this way using
VC++ 2005 Express (I’ve not updated to 2008 yet) by using the non-DLL
(static) runtime libraries and including SDL_win32_main.c in your
project instead of SDLmain.lib.

Please point me to a howto on this if you can. Since Mingw isn’t
supported that well in Vista32, and not at all in Vista64, it would be
nice to duplicate this functionality using Visual Studio.

Steve


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

It’s static linking of the single source file which makes up
SDLmain.lib, which you would have to static link anyway otherwise the
linker wouldn’t find WinMain(). As I understand it, SDLmain.lib is
exempt from the LGPL constraints as there’s no other way to use it.

SDL.DLL is linked dynamically, as usual. So no LGPL violations! :smiley:

PeterOn 29/01/2008, David Olsen wrote:

So, this is not considered static linking of SDL? Hallelujah! You sir, are a
champion!!! I’ve got to try this out on my project now!
-Dave

----- Original Message -----
From: “Peter Mackay” <mackay.pete+sdl at gmail.com>
To: "A list for developers using the SDL library. (includes SDL-announce)"

Sent: Monday, January 28, 2008 4:06 PM
Subject: Re: [SDL] Developing a standalone EXE in VC++ with SDL - possible?

I don’t have a howto link, but here’s a rough guide:

  1. Create a new Win32 project
  2. Fish SDL_win32_main.c out of the SDL source code and add it to your
    project.
  3. Set the “Character Set” option to “Use Multi-Byte Character Set”
    (needed for SDL_win32_main.c - possibly a bug?).
  4. Add “SDL.lib” to your list of dependencies.
  5. Add a main() method as per usual.

At this point you should have a functional SDL app. Now to get rid of
the unwanted dependencies:

  1. Go into the project properties, C/C++ subtree, Code Generation
    pane, then change “Runtime Library” from "Multi-threaded Debug DLL"
    and “Multi-threaded DLL” (for Debug and Release configurations
    respectively) to “Multi-threaded Debug” and “Multi-threaded”.

That should do it. I verified it just now, and the only dependencies
of my app are “SDL.DLL” and “KERNEL32.DLL”, as desired.

Hope this helps!

Peter

On 28/01/2008, Stephen Anthony wrote:

On Monday 28 January 2008 18:09, Peter Mackay wrote:

It’s quite possible to build an exe which behaves in this way using
VC++ 2005 Express (I’ve not updated to 2008 yet) by using the non-DLL
(static) runtime libraries and including SDL_win32_main.c in your
project instead of SDLmain.lib.

Please point me to a howto on this if you can. Since Mingw isn’t
supported that well in Vista32, and not at all in Vista64, it would be
nice to duplicate this functionality using Visual Studio.

Steve


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Me :slight_smile: Seriously though, I’ve been reading that there are problems with
Vista64, and I experienced some of them myself. But if Visual Studio can
suffice, I’d rather use that anyway, since its compiler is better than
the stable one in Mingw (3.4.5). Now, if I could get 4.2.1 working in
Mingw it might be a different story …

SteveOn Monday 28 January 2008 22:29, Charles McGarvey wrote:

Actually, mingw32 works just fine for me on this Vista x64 workstation.
Who told you mingw isn’t supported on Vista?

I’m using Mingw 3.4.5 with the TDM drop-in which provides binaries for gcc
4.2.2:

http://www.tdragon.net/recentgcc/

Basically you just install Mingw normally and then unzip the TDM part on top
of the Mingw install. These gcc builds are said to be “unofficial and
experimental,” but I haven’t had any issues at all with the sort of stuff
I’m doing. I’m using it for Obj-C++, which isn’t a common part of gcc, so
if
this part is so stable, I’ll have to assume that the commonly used parts
will be quite stable. But be sure to check out the “known issues” if you
plan to look into this further.

Chaz> ----- Original Message -----

From: sa666666@gmail.com (Stephen Anthony)
To: "A list for developers using the SDL library. (includes SDL-announce)"

Sent: Tuesday, January 29, 2008 5:53 AM
Subject: Re: [SDL] Developing a standalone EXE in VC++ with SDL - possible?

On Monday 28 January 2008 22:29, Charles McGarvey wrote:

Actually, mingw32 works just fine for me on this Vista x64 workstation.
Who told you mingw isn’t supported on Vista?

Me :slight_smile: Seriously though, I’ve been reading that there are problems with
Vista64, and I experienced some of them myself. But if Visual Studio can
suffice, I’d rather use that anyway, since its compiler is better than
the stable one in Mingw (3.4.5). Now, if I could get 4.2.1 working in
Mingw it might be a different story …

Steve


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org