Embed SDL.dll in the .exe

SDL Development
21

Hey,

I guess that could be done simply enough, by modifying 7-zip’s .exe
self-extractor, so that it runs $destdir/bin/myprog.exe after it’s
done extracting the .zip (or the .zip is already extracted) :wink:

And put savegames in the personal folder rather than in the game
install directory, because the install directory is likely to be
erased with such an easy setup.–
Sylvain

On Fri, Sep 28, 2007 at 12:27:30PM -0400, Jonathan Dearborn wrote:

Hey,

If anyone wants to tackle this in Windows, here is what I suggest (thoroughly crazy):

Write a program that extracts all of the necessary files (.exe, .dll, .png, .etc) from itself, then runs the main executable that was extracted. There you go! So you’ll probably have to write a program that creates such a program.

Jonny D

Date: Fri, 28 Sep 2007 17:22:53 +0200> From: @Sylvain_Beucler> To: sdl at lists.libsdl.org> Subject: Re: [SDL] Embed SDL.dll in the .exe> > On Fri, Sep 28, 2007 at 08:41:03AM -0600, Charles McGarvey wrote:> > FYI: Drag 'n drop installation works on Mac OS X without complete > > static linking because applications are really “bundles” or > > directories made to look like files. So you can dynamic link to > > libraries you put inside the bundle which provides the benefits of > > brain-dead installation and the benefits of dynamic linking > > (including satisfying the LGPL license).> > > I believe you still need an installer if you distribute the> application via Internet.> > > If I understand correctly:> > - the app (something.app) is displayed as a single executable to the> user, from the file browser (“Finder”)> > - but it’s actually a directory that contains both the executable and> the resources. Under Windows it is possible to embed resources> directly in the .exe – or for all platforms, you can simply cat it> at the end of the .exe with an easy-to-recognize delimiter, as .zip> auto-extrators do. The OSX way makes things easier for the> programmer (just fopen()).> > - when you drag 'n drop the .app, you actually move a directory, so> it’s a single operation with a file browser (but you already can do> that with most games by moving the installation directory)> > - if you got it from a HTTP or FTP website, you’d need to download> each and every files from the something.app/ directory. So instead> you have to bundle it in a single archive. Apparently OSX apps often> come as a .dmg (can it do more than a .zip btw?)> > – > Sylvain> _______________________________________________> SDL mailing list> SDL at lists.libsdl.org> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Discover the new Windows Vista
windows vista - Search

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

22

Sylvain Beucler wrote:

Hey,

I guess that could be done simply enough, by modifying 7-zip’s .exe
self-extractor, so that it runs $destdir/bin/myprog.exe after it’s
done extracting the .zip (or the .zip is already extracted) :wink:

And put savegames in the personal folder rather than in the game
install directory, because the install directory is likely to be
erased with such an easy setup.

no need for modifying anything, there is already this FREE, wonderful
tool zip2exe:

i think its the same tool used by the “single-exe” (in reality a single
zipexe) games on www.experimentalgameplay.com.

but if you want to have a commercial solution, you can even embed dlls
into the exe and load them directly from the exe to memory and execute
from memory. http://www.molebox.com/ (there are of course many others,
thats just the one that usually pops up in google)

or you can do it for free, but with some effort:
http://www.joachim-bauch.de/tutorials/load_dll_memory.html/en
but i personally gave up on this, way to complex and complicated. i
rather did the effort to tweak some openAL source code such that i was
able to make a static lib of openAL (openAL was the only lib i could not
statically compile, and even the openAL list refused to help me. but now
i know how to compile it statically. if anyone is interested, i will
email you the howto.txt)

23

FYI: Drag 'n drop installation works on Mac OS X without complete
static linking because applications are really “bundles” or
directories made to look like files. So you can dynamic link to
libraries you put inside the bundle which provides the benefits of
brain-dead installation and the benefits of dynamic linking
(including satisfying the LGPL license).

I believe you still need an installer if you distribute the
application via Internet.

You do not. You just archive the .app bundle any way you want (dmg
is popular). To install, you just unarchive and move the .app bundle
wherever you want (usually the Applications folder).

If I understand correctly:

  • the app (something.app) is displayed as a single executable to the
    user, from the file browser (“Finder”)

Correct.

  • but it’s actually a directory that contains both the executable and
    the resources. Under Windows it is possible to embed resources
    directly in the .exe – or for all platforms, you can simply cat it
    at the end of the .exe with an easy-to-recognize delimiter, as .zip
    auto-extrators do. The OSX way makes things easier for the
    programmer (just fopen()).

I’m not sure about what you can and can’t do with exe files, but I
think one of the unique things about bundles in Mac OS X is that you
can also put dynamic libraries directly inside the bundle which the
main executable can link against. I’m not sure if you can put
dynamic libraries in exe files–I think that would only happen with
static linking, but I don’t know the details of Windows binaries.

  • when you drag 'n drop the .app, you actually move a directory, so
    it’s a single operation with a file browser (but you already can do
    that with most games by moving the installation directory)

Except users like drag 'n drop installation better than they like
installers, which put files who knows where. They also know that it
will be just as easy to uninstall if they so choose: just drag the
app to the Trash. I (as a developer) like it because I don’t need to
have an installer or uninstaller.

  • if you got it from a HTTP or FTP website, you’d need to download
    each and every files from the something.app/ directory. So instead
    you have to bundle it in a single archive. Apparently OSX apps often
    come as a .dmg (can it do more than a .zip btw?)

A dmg file is basically an archive format (like tar). It also
supports bz2 or gzip compression. The only thing I can say that’s
interesting about it is that when you open a dmg file, it is mounted
as a separate file system so your don’t have to unarchive everything,
just drag out whatever you want–but you can do that with zip files
on Windows, too.

Anyway, my point in brining all this up is that perhaps a similar
method could be implemented in Windows such that we can have pure
drag and drop installation, including dynamic libraries, etc. Sorry
if this is mostly off-topic for SDL, but I’d love to be able to
create this kind of installation experience on Windows for my SDL apps.

Cheers,
chazOn Sep 28, 2007, at 9:22 AM, Sylvain Beucler wrote:

On Fri, Sep 28, 2007 at 08:41:03AM -0600, Charles McGarvey wrote:

24

Hey,

If anyone wants to tackle this in Windows, here is what I suggest (thoroughly crazy):

Write a program that extracts all of the necessary files (.exe, .dll, .png, .etc) from itself, then runs the main executable that was extracted. There you go! So you’ll probably have to write a program that creates such a program.

Jonny D

I did something similar but didn’t like the result… I packed everything into one executable. When run, the executable would decompress all DLLs and load them with LoadLibrary. The problems were:

  1. I had to declare all the functions from the DLLs that I was using to be able to call them (since I wasn’t linking the app to the import libraries of the DLLs I had to get their addresses with GetProcAddress).
  2. Since I was not unpacking another executable, I was having trouble loading the DLLs in the right order. Since the path where they were decompressing was not on the path where Windows looks for DLLs, when I loaded SDL_image.dll, for example, the application stopped complaining it couldn’t find SDL.dll. So I had to LoadLibrary them in the right order.

Unpacking another executable along with the DLLs may solve those problems. Since it will be decompressed in the same path as the DLLs, it will automatically find them when run. No need to use LoadLibrary and get their addresses with GetProcAddress, and Windows will be able to find and load them in the right order.

This is easy to do, just write a small executable that reads a ZIP attached to the end of the executable, decompress all its contents somewhere, execute the application (an EXE that was decompressed) and, when the app terminates, cleanup everything.

As I’m in need of such solution, I’ll try to code something and release to the list.

Cheers,

Andre

25

Andre de Leiradella wrote:

Hey,

If anyone wants to tackle this in Windows, here is what I suggest (thoroughly crazy):

Write a program that extracts all of the necessary files (.exe, .dll, .png, .etc) from itself, then runs the main executable that was extracted. There you go! So you’ll probably have to write a program that creates such a program.

Jonny D

I did something similar but didn’t like the result… I packed everything into one executable. When run, the executable would decompress all DLLs and load them with LoadLibrary. The problems were:

  1. I had to declare all the functions from the DLLs that I was using to be able to call them (since I wasn’t linking the app to the import libraries of the DLLs I had to get their addresses with GetProcAddress).
  2. Since I was not unpacking another executable, I was having trouble loading the DLLs in the right order. Since the path where they were decompressing was not on the path where Windows looks for DLLs, when I loaded SDL_image.dll, for example, the application stopped complaining it couldn’t find SDL.dll. So I had to LoadLibrary them in the right order.

Unpacking another executable along with the DLLs may solve those problems. Since it will be decompressed in the same path as the DLLs, it will automatically find them when run. No need to use LoadLibrary and get their addresses with GetProcAddress, and Windows will be able to find and load them in the right order.

This is easy to do, just write a small executable that reads a ZIP attached to the end of the executable, decompress all its contents somewhere, execute the application (an EXE that was decompressed) and, when the app terminates, cleanup everything.

As I’m in need of such solution, I’ll try to code something and release to the list.

Cheers,

Andre

this sounds exactly as what this zip2exe software does:

why do you want to write your own tool ?
but if you do - let us know. and have a look at

www.experimentalgameplay.com - some of those use the very same technique
of extracting all stuff and then executing the extracted exe.> _______________________________________________

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

26

If you are going to go down the self-extracting/compressed exe route,
you may find the following article of interest:
http://web.archive.org/web/20060527143009/f0dder.schwump.net/packandstuff.htm
(web.archive.org link since the original seems to be down at the moment)

Granted, most people will not run more than one instance of an SDL
application at the same time, nor are likely to run more than one SDL
app at the same time, either.On Fri, Sep 28, 2007 at 09:22:23PM +0200, Andre Krause wrote:

no need for modifying anything, there is already this FREE, wonderful
tool zip2exe:

(Free) ZIP 2 Secure EXE - Create Self-Extracting Executable with AES Encryption from a Zip Compression File and Automatically Run Setup

–
Jon Dowland

27

this sounds exactly as what this zip2exe software does:

(Free) ZIP 2 Secure EXE - Create Self-Extracting Executable with AES Encryption from a Zip Compression File and Automatically Run Setup

why do you want to write your own tool ?
but if you do - let us know. and have a look at

First because I didn’t know about this tool :slight_smile: I thought it was
standard zip2exe stuff with ugly screens asking the user if he/she wants
to decompress the file or run Winzip :-p

But now that I visited the link, I still need to unroll my own tool. I
need the -ea option, and am not willing to pay for something I can write
:slight_smile: But it looks like a very good tool.

www.experimentalgameplay.com - some of those use the very same technique
of extracting all stuff and then executing the extracted exe.

Thanks for the link, I’ll take a closer look into it when I have more
time. Seems to have some great stuff!

Cheers,

Andre

28

Quoting Jon Dowland :> On Fri, Sep 28, 2007 at 09:22:23PM +0200, Andre Krause wrote:

no need for modifying anything, there is already this FREE, wonderful
tool zip2exe:

(Free) ZIP 2 Secure EXE - Create Self-Extracting Executable with AES Encryption from a Zip Compression File and Automatically Run Setup

If you are going to go down the self-extracting/compressed exe route,
you may find the following article of interest:
http://web.archive.org/web/20060527143009/f0dder.schwump.net/packandstuff.htm
(web.archive.org link since the original seems to be down at the moment)

Granted, most people will not run more than one instance of an SDL
application at the same time, nor are likely to run more than one SDL
app at the same time, either.

this is all beginning to sound like an installer and defeating the point :wink:

29

Andre de Leiradella wrote:

this sounds exactly as what this zip2exe software does:

(Free) ZIP 2 Secure EXE - Create Self-Extracting Executable with AES Encryption from a Zip Compression File and Automatically Run Setup

why do you want to write your own tool ?
but if you do - let us know. and have a look at

First because I didn’t know about this tool :slight_smile: I thought it was
standard zip2exe stuff with ugly screens asking the user if he/she wants
to decompress the file or run Winzip :-p

But now that I visited the link, I still need to unroll my own tool. I
need the -ea option, and am not willing to pay for something I can write
:slight_smile: But it looks like a very good tool.

oops - i didnt noticed that it is not totally free. i didnt know about
that -ea “premium” option.

so well - i hope you manage to do your own tool, and i hope you make it
opensource and free so we all can use it in case we need such a scenario.

but i ask myself how reliable is it to detect a (temporary) writable
directory on the different windows platforms? what will vista say to
such a behaviour?>

www.experimentalgameplay.com - some of those use the very same technique
of extracting all stuff and then executing the extracted exe.

Thanks for the link, I’ll take a closer look into it when I have more
time. Seems to have some great stuff!

Cheers,

Andre

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

30

oops - i didnt noticed that it is not totally free. i didnt know about
that -ea “premium” option.

so well - i hope you manage to do your own tool, and i hope you make it
opensource and free so we all can use it in case we need such a scenario.

It’s not that difficult at a first glance. And since I’ll write it
because I need it, I’ll have the chance to test it with a real application.

Yes, I will release the tool for free, but I’m not sure about open
source. And keep in mind that it’ll be very simple, no extended features
as ZIP 2 Secure EXE, and that it will take a while before I have
something to release. After I have it working then I can add features
based on requests though…

but i ask myself how reliable is it to detect a (temporary) writable
directory on the different windows platforms? what will vista say to
such a behaviour?

Now that’s a good question. I’ll be using fnkdat to get a temporary
directory to where I can decompress the application, and Vista is not
yet listed as a supported platform. My guess is that it will work, since
applications must have some place where they can write config files and
stuff even on Vista. But I may be wrong.

I’ll test the tool on Vista before releasing it.

Cheers,

Andre