This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: PATCH: allow PE executables to have an export table
- From: Michael S. Zick <mszick at goquest dot com>
- To: "Ralf Habacker" <Ralf dot Habacker at freenet dot de>,"Fabrizio Gennari" <fabrizio dot ge at tiscalinet dot it>,<binutils at sources dot redhat dot com>
- Date: Wed, 18 Dec 2002 07:10:45 -0600
- Subject: Re: PATCH: allow PE executables to have an export table
- References: <009c01c2a631$0cc80a80$0a1c440a@BRAMSCHE>
Ralf,
The short answer...
It is a "feature" that grew out of "old world" sales and marketing plans.
It can be a technical convience in some cases, but that isn't where it came
from.
On Tuesday 17 December 2002 07:01 pm, Ralf Habacker wrote:
>
> allow me one question: for which cases should this be good ?
>
You write one "main (major)" application that one is priced very low or is
a "give away". It "appears" as a "static linked" application without any
supporting, shared libraries that could be re-used.
You write one or more "add-ons", extra cost, utility programs or an "enhanced"
version of the program.
Again, no shared library comes with this version.
In addition, this version is not complete... It will not load and run by its
self - you must have the "free-bee" also.
It is the exports of the "free-bee" that are taking the place of a shared
library.
> The advantage is that an application(1)
could be linked to another
> application(2) or dll(3), but makes this sense ?
>
Depends on your marketing plan.
> I assume the windows runtime linker could not load the application (1),
> because it does not contain the structure and the startup code, dll's
> usually have.
>
Yup - that is why systems that build these things have "import libraries".
It is the "import library" that supplies the glue to make the exports of the
first program usable as an external, shared library.
> Regards
> Ralf