Publishing Single Exe without including Multiple DLLs

Hello,

I have developed an application with Visual Studio 2010 and successfully integrating FORTRAN Code. There are multiple projects within a single solution file. Therefore, this results in multiple DLLs including the exe to run the application.

The executable works fine when all the accompanying DLLs are within the same folder as the exe. However, I want to deliver a single executable without any other DLLs.

Does anyone know how to make a single executable without DLLs hanging within the same folder or on the machine? I want to send someone the final executable and have them be able to run the application without anything else install on their machine. Is this even possible?

Regards, Bill Johnson

Bill,

What is wrong with multiple DLLs in the program directory? Answer: it is usually tedious copying everything to the right folders.

Part of the answer to the underlying inconvenience of this is to use an installer program. Like a number of other users in this forum I use Jordan Russell's free InnoSetup program. This takes your application, all its DLL files, sample data, fonts etc, and bundles them up in a single (compressed) EXE for distribution. When you run this standalone Setup program, it unpacks everything into the right folders, installs fonts (etc) and can, if you want, create file associations and other registry entries, and put shortcuts on the desktop, in the Start menu etc. The current method of providing online help is to use a compiled hypertext help file, so a fully-fledged application always runs to more than one file (when installed) anyway!

You can download InnoSetup from Jordan Russell Software's web site and it is completely free to use. When you get the hang of it you can customize the appearance of the install / setup program when it runs, and allow user choice where everything goes.

Using a bunch of DLLs is how just about every Windows program ever distributed operates. Using an installer at least gives you only one file* to distribute ...

Eddie

*actually two, as if you distribute on a CD or DVD you will probably also want an AUTORUN.INF file as well as the Setup.EXE - AUTORUN.INF is more complicated if you put it on a USB drive.

Hello LitusSaxonicum,

Thank you for your reply. I guess there is nothing really wrong with Multiple DLLs and an exe. However, I am a little concern of reverse compiling the DLL and getting at the source code. I have had that there are apps out there that one can use to uncompile the DLL and get at the source code.

Have you heard of this or have any experience with it?

Bill

If you can reverse engineer a DLL then I guess you can do the same for an exe. You could only get some sort of machine or assembler code out of this process which would be of no use to anyone.

The direct way to create a single executable is simply to move all of the DLL subroutines into the compilation of the executable. As a Plato (or Visual Studio) project you would simply add the dll files to the exe project.

Alternatively (for Win32) you could change from a DLL to a LIB (a static library) and then use the LIB in the compilation of your exe.

Years ago (late 90's), (my impression was that) Lahey was concerned that people that did not licence the Lahey .dll could link it into their program and get access to Lahey's library procedures. They must have identified some procedures, apart from the basic OS interfaces, which were of value. As a consequence, they did not allow the equivalent of salflibc.dll to be released with software generated, requiring a static library interface. Not sure how long this restriction applied, or if anyone actually contemplated this reverse engineering approach.

John

Bill,

For a computer scientist, it may well be a concern. But for an engineer or scientist not in that field, the effort required to reverse engineer a DLL is a significant cost, and I suspect that once one knows what a program looks like, and how its 'look and feel' operates, it is about as easy to write it again from scratch as it is to decompile it. The 'look and feel' is of course presented up-front. So is the design of all one's icons in readily copyable form.

Decompiling doesn't reinstate your source code in Fortran, and even if by some miracle it did, it would be devoid of comments, and probably with all the variable names 'aliased'.

Cracking your copy protection scheme, and distributing working copies of your application is probably easier. In various foreign countries they do this all the time.

The benefit of separate DLLs is that one can often do program updates by a small modified DLL, rather than with the whole EXE.

A question for Paul: is it possible to use Clearwin+ from a compiler other than FTN95, just because one has Salflibc.dll?

Eddie

I doubt it but you could try from C/C++. FTN95 has extensions for ClearWin+ that other Fortran compilers will not have.

Paul,

In one way that's a relief, as FTN95 is my compiler of choice, and a big element of that is Clearwin - I'd be devastated if it turned out that you could get Clearwin from the PE and use it with some other compiler ... I expect it wouldn't go down well at Silverfrost, either!

Eddie