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 c
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
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_IMPLEMEN
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 depe
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
[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
>>
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
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 functi
> -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
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
>>
>>
&g
> -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 sensib
"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 fu
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 use
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
[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.
>>>
"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
> -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-
> >
Hi,
You will have to declare the function identically in the both the main
app and dll. Then pass a pointer containing the address of the function
in the main app when calling procB. Alternatively declare an extra
export in the dll allowing to register this main app function.
(delphi syntax
> -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
&g
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
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 D
21 matches
Mail list logo
