EXE+salflibc.dll together

Hello. It is possible that during compilation I can attach salflibc.dll to EXE program. Now when I distribute *.exe program I have to attache the library separately. Thak you for any suggestion.

No, you have to distribute salflibc with your executable. There is no way to link them into one file.

Actually, there is. FTN95 alone has no way to do it, what you need is an 'installer'. The one I use is 'inno setup' (see www.jrsoftware.org). Basically, you write a set of instructions as to what files are to be placed where when your program is installed, what icons are to go on desktop or start menu etc, and inno setup 'compiles' a setup.exe program that does it all!

At the very least, your program is at least one EXE, SALFLIBC.DLL, and posibly also a CHM help file. You may also have example data. You might wish to put entries into the Registry etc. inno setup does all of that.

What's more, it is free!

Eddie

Thank you for all replies.

On the subject of installers - the best tool I have found over the years (and I have used quite a few), particularly for creating MSI installers, is WiX - The Windows Installer XML toolkit available from http://wix.sourceforge.net. It enables full manipulation of the MSI database structure via an defined XML API and has non of the drawbacks of UI tools which (especially for MSI installers) often have limitations.

I also use the installer that Eddie suggested, it is very easy to use and very effective, giving a professional looking appearance to the installation. Many software vendors use this installer for both commercial products as well as freeware.

Still I would support the first poster. It would be better if Salford find the way to add its libraries to the exe. Salford is the only company with such, let me highlight this, disadvantage. In the DOS era when EXEs were 10KB and the libraries 1MB it had some sense to save on executable space. Now 1MB libraries do not add any excess weight to harddrives or not to uncommon 10MB EXE files. At least users must have the choise. With the installer you will mess with different versions libraries if you will install more than one application

With the installer you will mess with different versions libraries if you will install more than one application

Sorry, but I can't follow your logic here. With an installer, generally a new sub-directory will be created under C:\Program Files . This sub-directory will then contain all the necessary files for your application which may include multiple exe's, example files, tutorials, documentation and so on and of course a copy of Salflibc.dll Then, if at some later date the user installs another of your applications with a newer salflibc.dll, this will all go into a different installation area. There is no reason for the earlier application to be influenced by the later one.

In practice, aren't self contained exe's a bit of a rarity anyway, the vast majority of windows applications use multiple DLL's

Following on from Johns reply - there are very few examples of self-contained executables and even where there are, they often rely on say Visual C runtime libraries. Out of interest - which compiler(s) do you know of that produce binaries that do not have dependencies on runtime DLLs?

Even if you could attach the DLL to your EXE, you still need your help file to be separate (i.e. to fit in with normal - i.e. current - Windows practice, your help hypertext is in a .chm file, which is processed through the hypertext help (hh.exe) program.

Once you have two files to install, there is no reason not to have more.

Using the installer I mentioned, there is only a single EXE on the distribution disk - in my case, SETUP.EXE . This contains the target program(s), salflibc.dll, the .chm file, examples, etc etc, all effectively 'zipped' into the installer ...

Eddie

Quoted from JohnHorspool

With the installer you will mess with different versions libraries if you will install more than one application

Sorry, but I can't follow your logic here

Easy to illustrate that is this: I was just recently hit by interference asking for help here when eventually what happen is that two salford's fortran installations communicated via path.

This is also answer to Andrew's question about which compiler 😃

Sorry - to clarify - I was asking which compiler generates binaries that do NOT have runtime dependencies.

I do not know any. Lets take compilers themself as an example, they are also executables. Compilers are exactly such executables which is not worth implementing in one single exe file. They are permanently in development and bug fixes and it would be a hell to install it each time the comma somewhere was missed 😃. And nobody usually installs several copies of them.

The tasks which benefit from being a single executable are numerous relatively small codes - gadgets, toys etc. which people sometimes tend to use for decades. During such timescales any doubts salflibc will change so much, that most probably will be completely incompativle with older executables ? 😃 Lot of freeware and shareware are single-file executables which do not need installs and this sometimes is very convenient.

By the way, how many people still use fortran 77 ?

Dan,

I generally use FORTRAN 77 style: fixed format in a .FOR file. I have been seduced slightly with:

(a) ! for inline comments (b) array = constant when I want to intialise the whole array (but I always add a ! comment so I'll know what it is doing later) (c) I have used & as the continuation marker in new code as I don't think I'll ever drop a deck of cards again (the last time I did so was in 1972 anyway!)

I ONLY use implicitly-typed variables, and only use lower-case for debugging code. In 39 years of programming Fortran I only ever used 2 explicitly-typed variables, and they have given me so much aggravation ever since that last year I finally renamed them!

So count me as pretty much using fortran-77

If you always put salflibc in the same sub-directory as the program, and don't add a new path setting, you never get a conflict. FTN95 needs a PATH because it is a command-line program, so it doesn't get its PATH from the registry, but from AUTOEXEC. I think that it is a mistake to put salflibc.dll in WINDOWS\SYSTEM

Eddie

Quoted from Andrew Sorry - to clarify - I was asking which compiler generates binaries that do NOT have runtime dependencies.

Was that a challenge? How about Prospero PC Fortran?

Regards

Ian

Well! that gave my age away didn't it, before long I'll be reminiscing over ICL Jean!

Ian

MS Fortran also generated a single EXE, as did Supersoft, Digital Research, Ryan-Macfarland and several others. Salford with DBOS, Lahey and some others with 'DOS extenders' started the multi-file paradigm.

I used to take my Lotus Elan +2S to the same garage as the MD of Prospero took his. Are they still in business? I have the GEM version of their compiler gathering dust on a shelf!

Eddie

Eddie,

Well, you certainly won that one! I don't know if Prospero still exist, I couldn't find them on Google.

Regards

Ian

PS my current car is also lots of trouble....! Elise 111s S2

I'm pretty sure that Lahey F95 ver 5.5 (a few years old) can generate a single .exe which can be distributed without a .dll However, the use of .dll's is a good thing. Dan's problem with an old dll was fixed by using an updated dll. There are few instances where new dll's and not backwardly compatible. With the explosion in the size of win32 graphics programs, dll's are a definate improvement. Lets leave this idea back in the 90's, where it was done to death.

John C

I of course 'fixed' library differences. By editing for 30 minutes 500 instances of one function changed during last 5-7 years to subroutine and commenting in another library the whole block related to opengl.

If someone else will upgrade by himself, then my codes he uses will not work at all. I think Salford responded not less than 1000 times on the problems with the two libraies in the path. Or may be 10000.

And the request of single executable always was demanded by the users even since first appearance of Salford in 80th. I did not supported them at that time. Now I find it is actually useful.

Is it hard to do like a brain surgery?

Removing the dependance on a separate 'Fortran' DLL (salflibc.dll) is on the wish list but is not a priority at the moment. Sorry.