Re: [AD] preliminary ALLEGRO_USE_C fixup

["Henrik Stokseth" <hstokset@xxxxxxxxxx>]

Haha, neat! just as i suspected... instead of trying to work around linker
problems by defining dummy functions, leaving out declarations etc... we can
simply not export functions or variables that are not a part of the allegro
API. That's good news. Drop my patch for now. Thanks a *lot* btw.

-henrik

----- Original Message -----
From: Javier González <xaviergonz@xxxxxxxxxx>
To: Henrik Stokseth <hstokset@xxxxxxxxxx>; Allegro Conductors
<conductors@xxxxxxxxxx>
Sent: Sunday, April 01, 2001 10:23 PM
Subject: Re: [AD] preliminary ALLEGRO_USE_C fixup


> > i'm wondering if we need > to export *all* functions or if we just have
to
> export those >functions who must be call-able from outside the DLL. if so,
> that would solve these
> > problems.
>
> According to Microsoft Platform SDK:
>
> In Microsoft® Windows®, dynamic-link libraries (DLL) are modules that
> contain functions and data. A DLL is loaded at runtime by its calling
> modules (.EXE or DLL). When a DLL is loaded, it is mapped into the address
> space of the calling process.
>
> (* This is the interesting part *)
> DLLs can define two kinds of functions: exported and internal. The
exported
> functions can be called by other modules. Internal functions can only be
> called from within the DLL where they are defined. Although DLLs can
export
> data, its data is usually only used by its functions.
> DLLs provide a way to modularize applications so that functionality can be
> updated and reused more easilly. They also help reduce memory overhead
when
> several applications use the same functionality at the same time, because
> although each application gets its own copy of the data, they can share
the
> code.
>
> The Microsoft® Win32® application programming interface (API) is
implemented
> as a set of dynamic-link libraries, so any process using the Win32 API
uses
> dynamic linking.
>