-2

I was making a Delphi application, and wanted to test it on another PC to see if everything was working properly. I compiled and built the executable file, of course and I transfered all of the files from the Project folder to the other PC. When I launched the .exe file on the PC, nothing would happen. I then ticked the "Build with runtime packages" option in Project Options:

enter image description here

This made the .exe go from around 300 KBs to around 30 KBs, but now, instead of being able to launch the application on another (non-Delphi) PC, that PC got an error saying it was missing various files required to open the .exe .

I sent the same thing to various friends and all reported the same problem. My application is a rather simple lottery prototype application, so I don't understand why I'm having trouble opening it on other PCs. Are there other special options I need to enable for this to work?

mkrieger1
  • 19,194
  • 5
  • 54
  • 65
Miles Rayne
  • 49
  • 2
  • 6
  • 1
    You need to send various missing files together with the executable. – Sertac Akyuz May 10 '16 at 20:37
  • Is there an easy way to find out which files I'd need to include with my executable? Because if there wasn't, I'd have to go from PC to PC and find which PC is missing which file to run my executable. – Miles Rayne May 10 '16 at 20:39
  • 1
    Press the "help" button shown on the picture, select "see also", select "runtime packages", then select "deciding which runtime packages to use". Reading the topic should help. – Sertac Akyuz May 10 '16 at 20:44
  • In any case, don't use runtime packages for a simple, one executable, application. It's handy rather for modularized apps. – Sertac Akyuz May 10 '16 at 20:51
  • Simply remove the checkbox and rebuilt. Now your code should work. (unless there are other dll's we don't know about). – Johan May 10 '16 at 20:56
  • When I do this, the other (non-delphi) PC that I try to open my application with just simply refuses to open it. No explanation provided. No error message, no missing file message. It just shows down in the taskbar, but the window of the program just doesn't appear. – Miles Rayne May 10 '16 at 21:05
  • If it won't start on another PC when compiled to a stand-alone .Exe, does your project use any TDataSet-descendant components, e.g. TClientDataSet ones? – MartynA May 10 '16 at 21:14
  • Monitor which dlls your application uses when running stand-alone on the development PC (outside the delphi IDE). http://stackoverflow.com/questions/311268/monitoring-application-calls-to-dll Then double check that those dlls are present on the other PC. Database components are notorios for requiring external dlls. And obviously the database needs to be available :-). – Johan May 10 '16 at 21:15
  • If you turn on *build with runtime packages*, you're telling the IDE you want to use the RTL/VCL packages without linking the code into your executable, which means you need to distribute those packages. If you turn *off* build with runtime packages, you don't need anything other than any third-party dependencies you've added to your project. To demonstrate, File->New->VCL forms application, make no changes, compile, copy Project1.exe to a different computer, and run it. – Ken White May 11 '16 at 01:52
  • Why not leave those particular settings alone and let Delphi's default settings do their magic? – Jerry Dodge May 11 '16 at 04:45
  • You say that your application is visible on taskbar but there is no window of it. Are you sure that your application window position at start might be just outside of visible area on other computers? This may especially occur if you are developing on multi-monitor setup and deploy your program to single-monitor computer. You could set up main form `Position` property to `poScreenCenter` in order to force the form to always be started at center of the screen. – SilverWarior May 11 '16 at 19:52

3 Answers3

8

When you use runtime packages, you need to distribute those packages. These are the .bpl files that your program links to. It will be a subset of the packages listed in the runtime packages edit box in your screenshot. You should just list the packages that you use.

The net result of doing this is that the total amount that you will have to distribute is much greater than a single monolithic executable. Because in a monolithic executable the unused code can be stripped. If you want to minimize the size of your program, and make life simple, do not use runtime packages.

It would be worthwhile reading Embarcadero's documentation:

Working with Packages and Components

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • Excellent explanation of runtime packages but enabling runtime packages has caused a different problem for op. He needs to deselect build with runtime packages and fix the original issue as Deltics answers – Remko May 11 '16 at 13:17
  • @Remko I had not appreciated that. We'd obviously need more info to say anything much about that. – David Heffernan May 11 '16 at 13:22
4

Solve the first problem.

Using Runtime Packages will not solve the problem of your EXE not running on certain PC's. All it does is increase the complexity of deploying your application (as you have found).

Unless you need Runtime Packages for other, specific reasons, then you are far, far better off NOT using them, especially if you do not understand them (which based on the way you describe having discovered them does appear to be the case, if we're being honest).

Concentrate on finding out why your application does not run as a single, stand-alone EXE.

With all of the problems involving runtime packages your EXE is currently not even reaching the point of running your application code, and this may be where your original problem lies. Which means that once you have solved all the issues created by Runtime Packages, you will stil be left with an EXE which does not run. i.e. your original problem.

What does your application do when it starts ? Does it attempt to load files from any specific locations ? What are those locations ? What are the files ? Are you using any third party libraries which may expect DLL's to be present or other external files ? Are you trying to read or write settings to the registry or any external files (INI files etc).

What is the OS you are trying to run on ? This can be a very significant question for applications compiled with older Delphi versions. Have you tried configuring the EXE to run in Compatibility Mode for older versions of Windows ? (something that you do in Windows itself, not when compiling the EXE).

These are the questions you should be focussing on. Not runtime packages.

Deltics
  • 22,162
  • 2
  • 42
  • 70
2

Gday,

A small tool that's been around for a while to help you with this is Dependency Walker. You can find it at http://www.dependencywalker.com. It's helped me out on more than one occasion. This will tell you what files (usually BPLs as stated in the other responses) need to be sent with your EXE.

Also look at NSIS to create a simple installer, and put your EXE and supporting BPLs and any other files in the same directory.

Pat Heuvel
  • 96
  • 4
  • 1
    The IDE itself will identify which runtime packages are needed, which provides a list of the *supporting BPLs* without resorting to a third-party tool. – Ken White May 11 '16 at 01:48
  • 2
    @KenWhite Where can I find such a list? As far as I know there isn't any easy way to determine what bpl dependencies an application has. – J.Pelttari May 11 '16 at 05:15
  • 3
    @J.Pelttari: Turn on runtime packages. Build (not compile) your application. Project->Information lists the required runtime package files - right side, section labeled *Packages used*. – Ken White May 11 '16 at 12:53