[sqlite] function pointers? - Re: [sqlite] DLLs containing user-defined SQL functions
Hello, Regardless of program loading design, wouldn't this feature be better coded using function pointers? Ie. Have a "register/load" function that maps functions in the exe? PS. It would be helpful to have sqlite3OSMalloc() and sqlite3OSFree() as function pointers as well, so an application can do it's own memory management without recompiling SQLite library. Best regards, Kervin --- [EMAIL PROTECTED] wrote: > "Igor Tandetnik" <[EMAIL PROTECTED]> wrote: > > > > Note an inherent chicken and egg problem: you > can't build two DLLs (or > > an EXE and a DLL) using this approach where a > circular dependency > > exists, that is, where DLL A needs a function > exported from DLL B, and > > at the same time DLL B needs a function exported > from DLL A. To > > successfully link DLL A, you need an import > library from DLL B, but an > > import library is produced as a side effect of > link process, and to link > > DLL B you need an import library from DLL A, which > you can't build until > > you've built B, ... There is a way to break this > circle with the use > > of so called export files (.exp ), but the > technique is rather > > cumbersome. You don't want to go that way unless > there's a gun to your > > head. > > > > 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 > > Thanks, everybody, for your help. > > -- > D. Richard Hipp <[EMAIL PROTECTED]> > >
Re: [sqlite] DLLs containing user-defined SQL functions
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... Despite disliking many of the Win32 "features", I see no problem with the way DLLs work. As for dynamic linking, you can do everything what *nix systems do, the only problem is that it is not the *nix way. If MS would introduce something better than DLL mechanism, new applications using it would not work on older systems like WinXP or Win2000. This sounds like breaking the backward compatibility to me. I think this thread wins the 1st prize for posts per second. Looks like every mailing list or newsgroup has to have a win vs nix discussion at some point. -- cundo
Re: [sqlite] DLLs containing user-defined SQL functions
What you're trying to do is possible without .def files or import files or whatever. Just put something like this in sqlite3.h before everything: #ifdef _WIN32 #define S3EXPORT __declspec(dllexport) #define S3IMPORT __declspec(dllimport) #define S3CALL __stdcall #ifdef _S3_USER_DLL_IMPLEMENTATION_ #define S3IMPEXP S3EXPORT #else #define S3IMPEXP S3IMPORT #endif #else #define S3EXPORT #define S3IMPORT #define S3CALL #define S3IMPEXP #endif And annotate your exportable function declarations and implementations accordingly. When you compile sqlite3.dll or sqlite3.exe you compile with -U_S3_USER_DLL_IMPLEMENTATION_ or simply do not define it. When a user compiles their own code/DLL they must compile with this flag: -D_S3_USER_DLL_IMPLEMENTATION_ For every single function that you want accessible to 3rd party DLLs you must prepend with the S3CALL macro just before the function name - this also includes function pointers. Before the return code you need to prepend the S3IMPEXP macro. S3IMPEXP int S3CALL sqlite3_open( const char *filename, /* Database filename (UTF-8) */ sqlite3 **ppDb /* OUT: SQLite db handle */ ); Each User DLL must have well known function(s) for sqlite to call the user's code. They must be declared as follows: S3EXPORT int S3CALL MyExampleDllEntryPoint(int whatever); This is a good source of information of how to make Java JNI DLLs with MinGW - basically the same thing you're trying to do: http://www.mingw.org/mingwfaq.shtml#faq-jni-dll Notice that a .def file is nowhere to be seen. All this symbol import/export nonsense does have advantages - it speeds up the loading/linking of symbols in shared libraries, and it reduces symbol pollution when you have to dynamically load/link several shared libraries into the same program, reducing the chance of symbol collision. GCC has recognized this fact and has added a similar feature to its compiler: http://gcc.gnu.org/wiki/Visibility __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [sqlite] DLLs containing user-defined SQL functions
Robert Simpson wrote: Pardon my ignorance about *nix, but what happens during this whole global symbol mapping thing if two libraries both export the same function name? generally the first one is picked, though there's variations between OS. the search order for first is fairly flexible depending on environment settings and other options. there are also strong and weak symbols, where the weak symbol is only picked if no library provides a strong one. some systems also support specifying that all calls to "foo" in a library refer to the "foo" in that library, and not any other, but any other library calling "foo" may land in a different symbol. depending on what you pass to dlopen/dlsym, you can usually find the symbol you want. -- Ted Unangst www.coverity.com Coverity, Inc.
Re: [sqlite] DLLs containing user-defined SQL functions
Dennis Jenkins wrote: You can do something very similar on windows. Just dump a hacked "kernel32.dll" into the same directory as the EXE. This might not work with SP2 of XP for system DLLs. However, if the EXE uses a non-system DLL (like libJpeg.dll), then just replace that one. Put some code into the DllMain function that installs whatever hook procedure you need, and viola! You have just compromised the EXE and can do anything on that system that you want that the user running the EXE has the rights to do. Dennis, This issue with the DLL search order has been changed in Win XP SP1 and later, as the following link explains. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure06122003.asp The pertinent section is copied below. DLL Search Order Has Changed No longer is the current directory searched first when loading DLLs! This change was also made in Windows XP SP1. The default behavior now is to look in all the system locations first, then the current directory, and finally any user-defined paths. This will have an impact on your code if you install a DLL in the application's directory because Windows Server 2003 no longer loads the 'local' DLL if a DLL of the same name is in the system directory. A common example is if an application won't run with a specific version of a DLL, an older version is installed that does work in the application directory. This scenario will fail in Windows Server 2003. The reason this change was made was to mitigate some kinds of trojaning attacks. An attacker may be able to sneak a bad DLL into your application directory or a directory that has files associated with your application. The DLL search order change removes this attack vector. The SetDllDirectory function, also available in Windows XP SP1, modifies the search path used to locate DLLs for the application and affects all subsequent calls to the LoadLibrary and LoadLibraryEx functions by the application. Dennis Cote
Re: [sqlite] DLLs containing user-defined SQL functions
[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.
Re: [sqlite] DLLs containing user-defined SQL functions
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]>
Re: [sqlite] DLLs containing user-defined SQL functions
Robert Simpson wrote: >> -Original Message- >> From: Dennis Jenkins [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, June 07, 2006 11:46 AM >> To: sqlite-users@sqlite.org >> Subject: Re: [sqlite] DLLs containing user-defined SQL functions >> >> 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 >>>> >>>> >>>> >>> 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 ;) >> > > I know how Windows works -- being a Windows programmer :) I was asking > about how *nix works. On the surface the *nix way resolving these global > symbols seemed like a keen way for some kind of injection attack or > something. > > You are 100% correct. I misread your email. Reading way too fast I'm not sure how Unix works (elf or a.out file formats). It is probably well documented. It is easy to do injection attacks on either platform. Just put a hacked copy of "libc.so" on the system (in /tmp even) and modify the user's share library path environment variable before invoking the application. You can do something very similar on windows. Just dump a hacked "kernel32.dll" into the same directory as the EXE. This might not work with SP2 of XP for system DLLs. However, if the EXE uses a non-system DLL (like libJpeg.dll), then just replace that one. Put some code into the DllMain function that installs whatever hook procedure you need, and viola! You have just compromised the EXE and can do anything on that system that you want that the user running the EXE has the rights to do. On windows you can also simply "inject" a foreign DLL into a running process. I've written some code to do it. My injected DLL enumerates all of the GDI objects in the ruuning app, allowing my to capture all of the HBITMAPs that back the HDCs. ;)
RE: [sqlite] DLLs containing user-defined SQL functions
> -Original Message- > From: Dennis Jenkins [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 07, 2006 11:46 AM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] DLLs containing user-defined SQL functions > > 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 > >> > >> > > > 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 ;) I know how Windows works -- being a Windows programmer :) I was asking about how *nix works. On the surface the *nix way resolving these global symbols seemed like a keen way for some kind of injection attack or something.
Re: [sqlite] DLLs containing user-defined SQL functions
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?
Re: [sqlite] DLLs containing user-defined SQL functions
"Igor Tandetnik" <[EMAIL PROTECTED]> wrote: > > Note an inherent chicken and egg problem: you can't build two DLLs (or > an EXE and a DLL) using this approach where a circular dependency > exists, that is, where DLL A needs a function exported from DLL B, and > at the same time DLL B needs a function exported from DLL A. To > successfully link DLL A, you need an import library from DLL B, but an > import library is produced as a side effect of link process, and to link > DLL B you need an import library from DLL A, which you can't build until > you've built B, ... There is a way to break this circle with the use > of so called export files (.exp ), but the technique is rather > cumbersome. You don't want to go that way unless there's a gun to your > head. > 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 Thanks, everybody, for your help. -- D. Richard Hipp <[EMAIL PROTECTED]>
Re: [sqlite] DLLs containing user-defined SQL functions
Hello,
It could be done using something like that :
===
sharedenv.h// used in calling program and DLL.
===
typedef struct{
pointer to functions funA,funB ... etc
} mysharedfuns;
=
Main Program
=
mysharedfuns sharedfuns;
main()
{
sharedfuns.funA=
.. etc
LoadLibray (DLL);
InitDLL();
}
=
DLL:
=
#include
mysharedfuns mainfuns;
int InitDLL(mysharefuns *src)
{
mainfuns.funA=src->funA;
etc ..
}
The InitDLL function has to be called from the main program just after the
LoadLibrary.
The shared environment is then initialized; functions funA,funB ... are
callable from the DLL..
Best regards,
Laurent Blanquet.
==
- Original Message -
From: <[EMAIL PROTECTED]>
To: "Sqlite-users"
Sent: Wednesday, June 07, 2006 4:30 PM
Subject: [sqlite] DLLs containing user-defined SQL functions
I'm trying to add the ability to dynamically load DLLs
containing SQL functions and collating sequences to
SQLite. Things are working great on Unix, but I'm having
issues with Windows. Windows experts, please help me.
Suppose the main program (the .exe file) contains a
function procA() and the DLL contains a function procB().
I want procB() to be able to call procA(). The idea
is that the main program uses LoadLibrary() to pull
in the DLL, then GetProcAddress() to find the address
of procB(). Then the main program calls procB() in
the DLL which in turn calls procA() in the main program.
This all works great on Unix. When I use dlopen() to
attach the shared library, the procA() reference in
the shared library is automatically resolved to the
address of procA() in the main program.
But on Windows, I cannot get the DLL to compile because
it is complaining about the missing procA().
Another way to ask the question is this: How do I build
a DLL in windows that can call routines contained in the
main program that attached the DLL using LoadLibrary()?
--
D. Richard Hipp <[EMAIL PROTECTED]>
- Original Message -
From: <[EMAIL PROTECTED]>
To: "Sqlite-users"
Sent: Wednesday, June 07, 2006 4:30 PM
Subject: [sqlite] DLLs containing user-defined SQL functions
I'm trying to add the ability to dynamically load DLLs
containing SQL functions and collating sequences to
SQLite. Things are working great on Unix, but I'm having
issues with Windows. Windows experts, please help me.
Suppose the main program (the .exe file) contains a
function procA() and the DLL contains a function procB().
I want procB() to be able to call procA(). The idea
is that the main program uses LoadLibrary() to pull
in the DLL, then GetProcAddress() to find the address
of procB(). Then the main program calls procB() in
the DLL which in turn calls procA() in the main program.
This all works great on Unix. When I use dlopen() to
attach the shared library, the procA() reference in
the shared library is automatically resolved to the
address of procA() in the main program.
But on Windows, I cannot get the DLL to compile because
it is complaining about the missing procA().
Another way to ask the question is this: How do I build
a DLL in windows that can call routines contained in the
main program that attached the DLL using LoadLibrary()?
--
D. Richard Hipp <[EMAIL PROTECTED]>
- Original Message -
From: <[EMAIL PROTECTED]>
To: "Sqlite-users"
Sent: Wednesday, June 07, 2006 4:30 PM
Subject: [sqlite] DLLs containing user-defined SQL functions
I'm trying to add the ability to dynamically load DLLs
containing SQL functions and collating sequences to
SQLite. Things are working great on Unix, but I'm having
issues with Windows. Windows experts, please help me.
Suppose the main program (the .exe file) contains a
function procA() and the DLL contains a function procB().
I want procB() to be able to call procA(). The idea
is that the main program uses LoadLibrary() to pull
in the DLL, then GetProcAddress() to find the address
of procB(). Then the main program calls procB() in
the DLL which in turn calls procA() in the main program.
This all works great on Unix. When I use dlopen() to
attach the shared library, the procA() reference in
the shared library is automatically resolved to the
address of procA() in the main program.
But on Windows, I cannot get the DLL to compile because
it is complaining about the missing procA().
Another way to ask the question is this: How do I build
a DLL in windows that can call routines contained in the
main program that attached the DLL using LoadLibrary()?
--
D. Richard Hipp <[EMAIL PROTECTED]>
Re: [sqlite] DLLs containing user-defined SQL functions
On 6/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: The disadvantages to the windows approach are obvious. Before I add this characteristic to the ever-growing list of reasons why I hate windows and especially hate programming for windows, I should be fair and ask if there are any advantages to the windows way of doing things that I have overlooked. The result, if sold, will make more money ;)
Re: [sqlite] DLLs containing user-defined SQL functions
[EMAIL PROTECTED] wrote: > "Igor Tandetnik" <[EMAIL PROTECTED]> wrote: > >>> This all works great on Unix. When I use dlopen() to >>> attach the shared library, the procA() reference in >>> the shared library is automatically resolved to the >>> address of procA() in the main program. >>> >> On Windows, the loader works in a very different way. Basically, >> export/import connections are established at link time, not at load >> time. The loader does not perform a symbol search over all the DLLs, the >> import tables in the executable image (emitted by the linker) tell it >> exactly where to look. >> >> > > That explanation does not seem entirely accurate (especially the second sentence). If that were true, it owuld not be possible to release an updated DLL with re-arranged entry points and expect the caller EXE or DLL to link to it properly; yet that works. Refer to the blog of the guy at Microsoft who wrote (or rewrote) the DLL loader: http://blogs.msdn.com/mgrier/rss.aspx > The disadvantages to the windows approach are obvious. > Before I add this characteristic to the ever-growing > list of reasons why I hate windows and especially hate > programming for windows, I should be fair and ask if > there are any advantages to the windows way of doing > things that I have overlooked. > > -- > D. Richard Hipp <[EMAIL PROTECTED]> > >
Re: [sqlite] DLLs containing user-defined SQL functions
"Igor Tandetnik" <[EMAIL PROTECTED]> wrote: > > > This all works great on Unix. When I use dlopen() to > > attach the shared library, the procA() reference in > > the shared library is automatically resolved to the > > address of procA() in the main program. > > On Windows, the loader works in a very different way. Basically, > export/import connections are established at link time, not at load > time. The loader does not perform a symbol search over all the DLLs, the > import tables in the executable image (emitted by the linker) tell it > exactly where to look. > The disadvantages to the windows approach are obvious. Before I add this characteristic to the ever-growing list of reasons why I hate windows and especially hate programming for windows, I should be fair and ask if there are any advantages to the windows way of doing things that I have overlooked. -- D. Richard Hipp <[EMAIL PROTECTED]>
RE: [sqlite] DLLs containing user-defined SQL functions
> -Original Message- > From: Robert Simpson [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 07, 2006 7:55 AM > To: 'sqlite-users@sqlite.org' > Subject: RE: [sqlite] DLLs containing user-defined SQL functions > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, June 07, 2006 7:30 AM > > To: Sqlite-users > > Subject: [sqlite] DLLs containing user-defined SQL functions > > > [snip] > > Another way to ask the question is this: How do I build > > a DLL in windows that can call routines contained in the > > main program that attached the DLL using LoadLibrary()? > > The main executable would have to export the function through > a .DEF file, and your DLL would have to get the pointer to > the function through GetProcAddress() as follows: > > proc = GetProcAddress(GetModuleHandle(NULL), > "exe_exported_func_name"); A caveat: It's uncommon for executables to export functions, but not unheard of. Regular C/C++ programs will have no problem adapting to this mechanism, but other languages that either don't use an exe, or use a proxy exe, could not support it without additional SQLite API's to change the load behavior. You'd need options to either allow you to set a compile-time directive to hardcode the function, or to specify what HMODULE to call GetProcAddress() on.
RE: [sqlite] DLLs containing user-defined SQL functions
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 07, 2006 7:30 AM > To: Sqlite-users > Subject: [sqlite] DLLs containing user-defined SQL functions > [snip] > Another way to ask the question is this: How do I build > a DLL in windows that can call routines contained in the > main program that attached the DLL using LoadLibrary()? The main executable would have to export the function through a .DEF file, and your DLL would have to get the pointer to the function through GetProcAddress() as follows: proc = GetProcAddress(GetModuleHandle(NULL), "exe_exported_func_name");
Re: [sqlite] DLLs containing user-defined SQL functions
Hi Richard, I'm no windows expert, but why don't you use something like the tcl stubs mechanism? Build a static sqlite_stubs.a library and link all loadable dynamic libs against it. Kind regards Ulrich On Wednesday 07 June 2006 16:30, [EMAIL PROTECTED] wrote: > I'm trying to add the ability to dynamically load DLLs > containing SQL functions and collating sequences to > SQLite. Things are working great on Unix, but I'm having > issues with Windows. Windows experts, please help me. > > Suppose the main program (the .exe file) contains a > function procA() and the DLL contains a function procB(). > I want procB() to be able to call procA(). The idea > is that the main program uses LoadLibrary() to pull > in the DLL, then GetProcAddress() to find the address > of procB(). Then the main program calls procB() in > the DLL which in turn calls procA() in the main program. > > This all works great on Unix. When I use dlopen() to > attach the shared library, the procA() reference in > the shared library is automatically resolved to the > address of procA() in the main program. > > But on Windows, I cannot get the DLL to compile because > it is complaining about the missing procA(). > > Another way to ask the question is this: How do I build > a DLL in windows that can call routines contained in the > main program that attached the DLL using LoadLibrary()? > > -- > D. Richard Hipp <[EMAIL PROTECTED]>
