[EMAIL PROTECTED] wrote:
> Dennis Jenkins <[EMAIL PROTECTED]> wrote:
>
>> 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.
>>
>
> How does introducing a new shared library format that supports
> automatic bidirectional linking (as in Unix) break backwards
> compatibility? Nobody says they have to stop supporting DLLs.
> Just provide something better in addition to DLLs...
>
> --
> D. Richard Hipp <[EMAIL PROTECTED]>
>
>
The windows DLLs _DO_ support bi-directional linking. "A" can
depend on "B" and "B" can depend on "A". The windows kernels actually
have code to handle this. It is documented in the blog postings last
summer that I mentioned earlier. It has done this since win95. Not
sure about win 3.11. The problem is that under normal circumstances,
you can't create the DLLs like this. You have to create a fake DLL "B",
generate the real "A" using fake "B"s import library, then use the real
A to generate a real B. But for us, "A" is a user's EXE and "B" is
sqlite3.dll. Not very convenient. The user will be forced to compile
their own SQLITE3.DLL file.
As proof, consider the following exports from USER32.dll and
GDI32.dll. They are circularly linked:
tdump \WINDOWS\system32\gdi32.dll | grep "\.dll"
Turbo Dump Version 4.2.16.1 Copyright (c) 1988, 1996 Borland International
Imports from KERNEL32.dll
Imports from ntdll.dll
Imports from USER32.dll
Exports from GDI32.dll
tdump \WINDOWS\system32\user32.dll | grep "\.dll"
Turbo Dump Version 4.2.16.1 Copyright (c) 1988, 1996 Borland International
Imports from GDI32.dll
Imports from KERNEL32.dll
Imports from ntdll.dll
Exports from USER32.dll
Can you give a concrete example of what you are trying to do? This
is my assumption:
1) You are STATICALLY linking sqlite3 into some program. There is no
SQLITE3.DLL.
2) From the point of view of the OS, SQLITE does not exists. There is
only the EXE and some system DLLs that you have no control over.
3) The EXE (from the OS point of view) wants to dynamically load a DLL
that an sqlite programmer has created. This DLL will export certain
symbols, like "foo" and "bar". So the sqlite3 engine will use
"LoadLibrary" and "GetProcAddress" to obtain function pointers to "foo"
and "bar".
4) "foo" and "bar" need to call normal (or hidden?) sqlite functions
that reside in the EXE. For example, "sqlite3_changes" or
"sqlite3_errcode" (actual names don't matter).
5) Step #4 fails because the EXE does not export those symbols. You can
make the EXE export those symbols by creating a DEF file for the EXE.
6) You could also make this work if the user of SQLITE created a DLL
instead of statically linking it in. In this case. both the "addon.dll"
and "prog.exe" would have imports from "sqlite3.dll". This would work
beautifully, so long as "prog.exe" and "addon.dll" match the
"sqlite3.dll". Since we should all treat "sqlite3*" as an opaque
structure, this should not be a big problem.
7) Idea from #6 is a no-go if the user is using the Sqlite3 crypto
extension, as your license agreement requires that we use the crypto
extension in such a way that a third party can't make use of it. IE, we
can't put it into the sqlite3.dll file, as someone who did not pay for
it could just take the DLL and have the functionality callable from
their own app. Therefore, those of us that use the crypto extension in
any "insecure" environment must statically link against sqlite.
