Robert Simpson wrote:
>> -----Original Message-----
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, June 07, 2006 10:36 AM
>> To: sqlite-users@sqlite.org
>> Subject: Re: [sqlite] DLLs containing user-defined SQL functions
>>
>>
>> It's official then: The lack of sensible shared library loader
>> is yet another reason to avoid windows at all costs. In fact,
>> I'm thinking this reason will go near the top of the list....
>>
>
>
The Windows way does not seem as powerful as the Unix way. I hate
the M$ operating systems, but I code for them almost every day. So my
next statement isn't so much a defense of Microsoft , but a rebuttal to
your assertion that "the windows shared library loader is not
sensible". The DLL mechanism made sense at the time it was created
(8088, 640K ram, windows 1.0 running in real-mode in 320x200x4 graphics
- not a lot of room for fancy features). You have to consider how and
why the DLL mechanism evolved on windows, and why Microsoft went through
so much effort to NOT break backwards compatibility. Microsoft could
have fixed lots of design flaws in windows, but in doing so they would
have broken the ability for the OS to run older software. They are (or
were before Vista anyway) super paranoid about backwards compatibility.
Raymond Chen blogs about this often in his Microsoft blog.
http://blogs.msdn.com/oldnewthing/archive/category/2282.aspx
DLLs were meant to share code AND resource objects back in the win16
days. Once third parties started writing code that took advantage of
the way those DLLs worked, Microsoft could not change the interface.
> Pardon my ignorance about *nix, but what happens during this whole global
> symbol mapping thing if two libraries both export the same function name?
>
>
The PE (exe,dll,sys) file format on Windows defines an import table.
Each entry in the import table has both a DLL name AND a symbol name (or
ordinal import). It is perfectly valid for one PE file to import two
objects from two different PEs that both have the same symbol name.
Convincing your compiler/linker to produce such a PE import table is
left as an exercise to the reader ;)
> If SQLite only looked to the exe to provide this function, then what would
> happen to folks writing their own libraries that abstracted the database
> layer, but wanted to provide their own userdef functions from within their
> library ... would SQLite find the function in their library instead of the
> exe? What if the exe and/or two other dependent libraries all exported the
> function too and had their own userdefs ... how would SQLite handle all
> these libraries wanting to add their userdefs to SQLite?
>
This is a non-issue.
The problem is that "sqlite.dll"'s import table MUST specify a PE
source object for each symbol name. How would SQLITE.DLL know the name
of your EXE at link time (when the OBJs are turned into the DLL).
There are only two real ways for SQLITE to "reach back" into the EXE.
1) The EXE exports some symbols (for the magic functions that SQLITE
wants to call). The EXE loads SQLITE (via import lib or LoadLibrary).
The EXE calls a function in Sqlite passing it the "HINSTANCE" of the
EXE. Sqlite uses the instance member (really a pointer to the load
address of the PE header of the EXE) as teh first argument to
"GetProcAddress".
2) The EXE simply marshals the pointers into a structure (or passes them
one at a time) into SQLITE by calling a function in SQLITE. But isn't
this what we already have? Why are we trying to change it?
