Board index » cppbuilder » Stand-alone EXE won't run

Stand-alone EXE won't run

Okay, here's an interesting one for you.

I have a very peculiar behavior with an app I've created.  I have a set of
packages that all of my applications use.  The contents of the packages vary
from components to library functions, etc.  With my most recent application
I wanted to send the EXE to a colleague to demonstrate the progress.
Instead of shipping all of the packages, code guard DLL, Borland packages,
and memory manager DLL I decided to turn off "Build with Runtime Packages".
I rebuilt the application and ran it.  Access violation in startup code
(prior to any of the App's code).

Okay, not such a big deal.  I've heard of this sort of problem before.  But
here's the kicker.  I turned debugging on for each package and rebuilt them.
I was going to attempt to step through the initialization code, just in case
the reason for the AV was code in a package that always assumed it would be
running in a package, etc.  I then rebuilt the app, and it ran just fine.

Okay, I thought maybe there was a mismatch in code so I turned off debugging
for all of the packages again, rebuilt them, rebuilt the app, and AV on
startup again.  Weird.  After a few more toggles of the debugging flag I
finally narrowed the problem down to one package.  If the package is built
with debugging enabled then the app will run just fine.  If the package is
built without debugging the app will AV on startup.  Now again, this only
happens if the app is built without "Runtime Packages" enabled (one big
EXE).  Settings for Dynamic RTL and CodeGuard have no effect on the outcome.
Also, debugging settings and CodeGuard in the APP have no effect on the
outcome either.

Now here's the question, what might cause this situation?  Or what should I
be looking for?  Global initializers, improper use of PACKAGE keyword, etc.
I will be looking at the package very soon but figured I would submit this
question just in case someone else has any ideas.

- Clayton

PS - Please, I don't want any "this is the wrong newsgroup" posts.  This is
the closest newsgroup and my question doesn't belong in .language or
.vcl.components.xxx.  If there were a .compiler or .package newsgroup then I
would post there.

 

Re:Stand-alone EXE won't run


Packages are DLLs, not static libraries.  You cannot link them into the EXE.
You must have any packages used on the machine for the program to work.

The error you received was probably from the startup code trying to load the
packages but could also have been from your changing project options but not
doing a Project|Build_all to force all the object files to be rebuilt with
the new options settings.

.  Ed

Re:Stand-alone EXE won't run


First, thanks for the response.

"Ed Mulroy (TeamB)" <e...@mulroy.org> wrote in message
news:3b4cbb3a$2_1@dnews...

Quote
> Packages are DLLs, not static libraries.  You cannot link them into the
EXE.
> You must have any packages used on the machine for the program to work.

I'm not following what you're trying to get across.  I'm turning off "Build
with run-time packages" (Project | Options | Packages) and then performing a
complete build of my app.  This is how stand-alone EXE's are created.  The
closest I can understand from your post is you think I'm adding the LIB file
manually to the application, which I'm not.

Quote
> The error you received was probably from the startup code trying to load
the
> packages but could also have been from your changing project options but
not
> doing a Project|Build_all to force all the object files to be rebuilt with
> the new options settings.

Like I said above I did a complete build.  I didn't do a make.

- Clayton

Re:Stand-alone EXE won't run


Clayton,

You just said:

Quote
> I'm not following what you're trying to get
> across.  I'm turning off "Build with run-time
> packages" (Project | Options | Packages)
> and then performing a complete build of my
> app.  This is how stand-alone EXE's are created.

You said that you were using packages.  When you turned off build with
run-time packages did you also remove the code which used those DLL's?  The
error you describe leads me to think that the code is still in there.

.  Ed

Re:Stand-alone EXE won't run


"Ed Mulroy (TeamB)" <do_not_send_em...@mulroy.org> wrote in message
news:3b4cdb71_1@dnews...

Quote
> You said that you were using packages.  When you turned off build with
> run-time packages did you also remove the code which used those DLL's?
The
> error you describe leads me to think that the code is still in there.

Forgive me, but, I still don't see what you are trying to tell me.  I'm
wondering if you and I are talking about two different concepts.  The point
of turning off "Build with run-time packages" is to actually link the code
used from a package into the EXE.

This is exactly the same thing as placing a TEdit or a TLabel on a form.  If
I (the application developer) want to make a stand-alone EXE I turn off
"Build with run-time packages."  My EXE will no longer be dependent upon
VCL50.BPL and will contain the components TEdit and TLabel.  If how I'm
interpreting what you've said above is correct I shouldn't then be expected
to remove the TLabel, the TEdit, and any code that uses those components
from my form to successfully run my application.  If this isn't what you
mean then perhaps you should describe what you mean in more detail.

Until next time,

- Clayton

Re:Stand-alone EXE won't run


Don't forget to turn the "Use Dynamic RTL" option off as well, the program
won't be stand-alone unless BOTH options are disabled

Gambit

"Clayton M. Arends" <nospam.claytonare...@hotmail.com> wrote in message
news:3b4cbd6f_2@dnews...

Quote
> I'm not following what you're trying to get across.  I'm turning off
"Build
> with run-time packages" (Project | Options | Packages) and then performing
a
> complete build of my app.  This is how stand-alone EXE's are created.

Re:Stand-alone EXE won't run


I do not know how to make it more clear.  Use a DLL and you must have the
DLL on the machine when it runs.

This is different subject from and is unrelated to use of the TEdit or
TLabel classes.

.  Ed

Re:Stand-alone EXE won't run


"Ed Mulroy (TeamB)" <do_not_send_em...@mulroy.org> wrote in message
news:3b4d1a57$1_1@dnews...

Quote
> I do not know how to make it more clear.  Use a DLL and you must have the
> DLL on the machine when it runs.

Why are you stuck on discussing DLL's?  I realize that an EXE will not work
if a DLL that it is dependent on is not present (Windows will display an
error dialog box; however, it won't AV).  But I'm not talking about DLL's
nor did I ever infer that I am using DLLs.  I am simply talking about the
package system of BCB --- BPL's.  Yes, a BPL is a DLL but BPLs are special
in that used code can be stripped out and placed into the EXE (by the
linker).

Quote
> This is different subject from and is unrelated to use of the TEdit or
> TLabel classes.

This response supports my notion that you and I are not discussing the same
things or are on different tangents.  For what I'm discussing, which is the
package system (i.e. BPL files), TEdit and TLabel are quite relevant.  They
are perfect examples of code that is included into an EXE when run-time
packages have been turned off.  But the only reason I mentioned them is
because your post claimed that I should remove code from my app that makes
use of classes or functions in my package (BPL).

Let me sum-up to try to hit on the major principals again:

- My app executes just fine on my machine, building the app with and
  without runtime packages, as long as the package in question was
  built with debug turned on.
- If the package was built with debug turned off, and then the app
  was built without run-time packages, the app will AV on startup.
- The AV has only happened on my machine ... I have never attempted
  to send it to my colleague when it wasn't working.
- After building the package with debugging turned on, and after
  rebuilding the app with run-time packages turned off (and of course
  Dynamic RTL and Code Guard turned off) I can distribute it to my
  colleague as a stand-alone EXE.

The reason for my post was a simple one: Why does it only work if that
package was built with debug turned on?  If you can't answer the question,
that's fine.  I don't really expect anyone to have *the* answer.  I was just
hoping for some general pointers.

- Clayton

Re:Stand-alone EXE won't run


Quote
> For what I'm discussing, which is the
> package system (i.e. BPL files), TEdit
> and TLabel are quite relevant.

What I was saying is that TEdit and TLabel are part of the VCL.  That is
runtime library code supplied with both DLL/import library and static
library versions.  Packages in general are DLL's and not all have an
associated static library.  A static library is optional for a package.

The startup code contains code which goes through a table, calling
initialization routines for items in the project.  If the startup code calls
the initialization code for a package whose DLL is not present or at least
was not found on the machine the behavior you describe is consistent with
what might be expected to occur.

Quote
> - After building the package with debugging
> turned on, and after rebuilding the app with
> run-time packages turned off (and of course
> Dynamic RTL and Code Guard turned off) I
> can distribute it to my colleague as a
> stand-alone EXE.

That is the part I misread in your message.

There is some additional code which is placed in the application when
debugging is turned on, code which apparently is there to assist the IDE
de{*word*81}.  I do not know the internals of that code but some of what it
appears to do is help with locating and initializing at or most likely
before the time the program starts.  I do not know specifics of how that
would cause the app to run when it crashes otherwise.

.  Ed

Re:Stand-alone EXE won't run


Quote
> package system of BCB --- BPL's.  Yes, a BPL is a DLL but BPLs are special
> in that used code can be stripped out and placed into the EXE (by the
> linker).

Hmmm... I don't think this is so... .bpl's are nomal .dlls in this regard...
thry can not
be statically linked to the application not can their code be extracted and
inserted
into the application code automatically by the linker.

Instead when you build the .bpl you also check the option to create a static
library
aswell, and when you choose to build a stand-alone application that .lib
file gets
used. If it hasn't been built then you must dynamically link that .dll...

Hmmm... or am I getting something wrong here?

Jurko :-)

P.S. Wow ... learning how to play a guitar for a week now, and my typing has
sped up by a factor of 3 :-))) I like this .... :-)))

Re:Stand-alone EXE won't run


Quote
"Jurko" <Ju...@ve-mil.hr> wrote in message news:3b4eed6f$1_1@dnews...
> Hmmm... I don't think this is so... .bpl's are nomal .dlls in this
regard...
> thry can not be statically linked to the application not can their code be
> extracted and inserted into the application code automatically by the

linker.

Well I guess all of my stand-alone applications are running by divine
intervention.

Quote
> Instead when you build the .bpl you also check the option to create a
static
> library aswell, and when you choose to build a stand-alone application
> that .lib file gets used. If it hasn't been built then you must
dynamically
> link that .dll...

Perhaps this is the 'Project Options | Linker | Generate Import Library'
option which is checked on by default.  Since I never change this setting
all of my packages can automatically work either way.  e.g. as a static link
library or as a DLL.

- Clayton

Re:Stand-alone EXE won't run


"Generate import library" generates a library containing no code.  Instead
it contains the name of the DLL and references to the items the DLL exports
and is an alternative way for describing the DLL to the linker to using a
module definition file.  It is not used when linking with a static library.

.  Ed

Re:Stand-alone EXE won't run


Nope... you checked

    'generate .lib file'

Jurko

"Clayton M. Arends" <nospam.claytonare...@hotmail.com> wrote in message
news:3b4f0ef1$1_2@dnews...

Quote
> "Jurko" <Ju...@ve-mil.hr> wrote in message news:3b4eed6f$1_1@dnews...

> > Hmmm... I don't think this is so... .bpl's are nomal .dlls in this
> regard...
> > thry can not be statically linked to the application not can their code
be
> > extracted and inserted into the application code automatically by the
> linker.

> Well I guess all of my stand-alone applications are running by divine
> intervention.

> > Instead when you build the .bpl you also check the option to create a
> static
> > library aswell, and when you choose to build a stand-alone application
> > that .lib file gets used. If it hasn't been built then you must
> dynamically
> > link that .dll...

> Perhaps this is the 'Project Options | Linker | Generate Import Library'
> option which is checked on by default.  Since I never change this setting
> all of my packages can automatically work either way.  e.g. as a static
link
> library or as a DLL.

> - Clayton

Re:Stand-alone EXE won't run


Quote
"Jurko" <Ju...@ve-mil.hr> wrote in message news:3b4f1a6e_2@dnews...
> Nope... you checked

>     'generate .lib file'

Well fine, *that's* the one that's the setting that controls it and is
already checked by default.

- Clayton

Other Threads