curious discovery about geopoly module

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

curious discovery about geopoly module

Graham Hardman
Hi everybody,

regarding the geopoly module in version 3.25.2

a couple of weeks ago I wrote about the fact that the 'pragma
compile_options' command failed to display when I was trying to check
that my special build of the sqlite dll library and the command line
shell was working corrrectly. Richard Hipp's reply was to announce that
he had forgotten to fully broadcast the new module to the rest of the
code.

Fair enough i thought,  since i was still able to test out my ideas
using the shell interface and in my SQLiteExpert program on my windows
10 pc.

Since my previous message I have been doing some tests in 64-bit vba by
adapting code released on github by Govert: SQLiteForExcel [1]

It has been performing well except that, to my great surprise I have
been unable to get it to create a virtual table using geopoly.

Tonight I have documented this in a module that runs some general tests
that all succeed (creating normal tables, inserting records, and
querying the results. A simple Rtree virtual table  was also part of the
testing). The final part of my testing was to try to create a geopoly
vitual table. The prepared statement succeeded, but the step process
failed - returning 1. The extended error code was also 1, and the error
message was "no such module: geopoly"

I guess that makes sense in one way, but it begs the question of why the
shell and my version of SQLiteExpert find a way to understand what is
required. In the meantime it seems I shall have to suspend my vba coding
until the next release where hopefully the above issue will be fixed. I
can provide my code and the library if wished.

The last few lines from my debug printing to the vba intermediate window
is pasted below:

--begin test with a simple geopoly virtual table----
opening an in memory database
SQLite3Open returned 0
open the rtree virtual table
sqlcmd is: 'create virtual table newtab using geopoly(a,b,c)'
SQLite3PrepareV2 returned 0
SQLite3Step failed returning 1
Extended error code is: 1
Extended error message is: no such module: geopoly
SQLite3Finalize returned 1

----forced to abandon testing since geopoly table could not be
created-----

assertion documented

Regards,

Graham Hardman.

 

Links:
------
[1] https://github.com/govert/SQLiteForExcel
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: curious discovery about geopoly module

Clemens Ladisch
Graham Hardman wrote:
> SQLiteForExcel [1] https://github.com/govert/SQLiteForExcel

"sqlite3.dll is a copy of SQLite version 3.11.1"

> "no such module: geopoly"
>
> I guess that makes sense in one way, but it begs the question of why the
> shell and my version of SQLiteExpert find a way to understand what is
> required.

Because they updated their copy of SQLite more recently than three years ago.


Regards,
Clemens
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: curious discovery about geopoly module

Graham Hardman
To clarify: I built my own versions of the library and shell using the
latest amalgamation (3.25.2) specifically to test the geopoly
capability. The build process completed successfully with no error code,
and as I said allow me to create tables and use the geopoly
functionality in the command shell and sqliteexpert.

the vba module for 64 bit windows does not need the stdcall library
offered on the github site.

Thanks,

Graham

On 31-10-2018 12:13 am, Clemens Ladisch wrote:

> Graham Hardman wrote:
>> SQLiteForExcel [1] https://github.com/govert/SQLiteForExcel
>
> "sqlite3.dll is a copy of SQLite version 3.11.1"
>
>> "no such module: geopoly"
>>
>> I guess that makes sense in one way, but it begs the question of why
>> the
>> shell and my version of SQLiteExpert find a way to understand what is
>> required.
>
> Because they updated their copy of SQLite more recently than three
> years ago.
>
>
> Regards,
> Clemens
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: curious discovery about geopoly module

Richard Hipp-3
On 10/30/18, Graham Hardman <[hidden email]> wrote:
> To clarify: I built my own versions of the library and shell using the
> latest amalgamation (3.25.2) specifically to test the geopoly

Are you certain that the third-party tool is picking up your custom
DLL?  Verify by looking at the results of "SELECT sqlite_source_id();"

Are you certain that you enabled GeoPoly when you built your custom
DLL?  Remember that GeoPoly is an extension that defaults off.
--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: curious discovery about geopoly module

Vladimir Vissoultchev
In reply to this post by Graham Hardman
You can try some other sqlite wrapper for VBA, for instance vbRichClient ships with 3.24 -- http://www.vbrichclient.com/#/en/Downloads.htm

Unfortunately as it's primary target is VB6 the stdcall port of sqlite is compiled to x86 binary only.

cheers,
</wqw>

-----Original Message-----
From: sqlite-users [mailto:[hidden email]] On Behalf Of Graham Hardman
Sent: Tuesday, October 30, 2018 11:49 AM
To: SQLite mailing list <[hidden email]>
Subject: [sqlite] curious discovery about geopoly module

Hi everybody,

regarding the geopoly module in version 3.25.2

a couple of weeks ago I wrote about the fact that the 'pragma compile_options' command failed to display when I was trying to check that my special build of the sqlite dll library and the command line shell was working corrrectly. Richard Hipp's reply was to announce that he had forgotten to fully broadcast the new module to the rest of the code.

Fair enough i thought,  since i was still able to test out my ideas using the shell interface and in my SQLiteExpert program on my windows
10 pc.

Since my previous message I have been doing some tests in 64-bit vba by adapting code released on github by Govert: SQLiteForExcel [1]

It has been performing well except that, to my great surprise I have been unable to get it to create a virtual table using geopoly.

Tonight I have documented this in a module that runs some general tests that all succeed (creating normal tables, inserting records, and querying the results. A simple Rtree virtual table  was also part of the testing). The final part of my testing was to try to create a geopoly vitual table. The prepared statement succeeded, but the step process failed - returning 1. The extended error code was also 1, and the error message was "no such module: geopoly"

I guess that makes sense in one way, but it begs the question of why the shell and my version of SQLiteExpert find a way to understand what is required. In the meantime it seems I shall have to suspend my vba coding until the next release where hopefully the above issue will be fixed. I can provide my code and the library if wished.

The last few lines from my debug printing to the vba intermediate window is pasted below:

--begin test with a simple geopoly virtual table---- opening an in memory database SQLite3Open returned 0 open the rtree virtual table sqlcmd is: 'create virtual table newtab using geopoly(a,b,c)'
SQLite3PrepareV2 returned 0
SQLite3Step failed returning 1
Extended error code is: 1
Extended error message is: no such module: geopoly SQLite3Finalize returned 1

----forced to abandon testing since geopoly table could not be
created-----

assertion documented

Regards,

Graham Hardman.

 

Links:
------
[1] https://github.com/govert/SQLiteForExcel
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: curious discovery about geopoly module

Keith Medcalf
In reply to this post by Graham Hardman

select sqlite_source_id();

both where it works and where it doesn't.  Are they the same or different?


---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.

>-----Original Message-----
>From: sqlite-users [mailto:sqlite-users-
>[hidden email]] On Behalf Of Graham Hardman
>Sent: Tuesday, 30 October, 2018 05:25
>To: SQLite mailing list
>Subject: Re: [sqlite] curious discovery about geopoly module
>
>To clarify: I built my own versions of the library and shell using
>the
>latest amalgamation (3.25.2) specifically to test the geopoly
>capability. The build process completed successfully with no error
>code,
>and as I said allow me to create tables and use the geopoly
>functionality in the command shell and sqliteexpert.
>
>the vba module for 64 bit windows does not need the stdcall library
>offered on the github site.
>
>Thanks,
>
>Graham
>
>On 31-10-2018 12:13 am, Clemens Ladisch wrote:
>> Graham Hardman wrote:
>>> SQLiteForExcel [1] https://github.com/govert/SQLiteForExcel
>>
>> "sqlite3.dll is a copy of SQLite version 3.11.1"
>>
>>> "no such module: geopoly"
>>>
>>> I guess that makes sense in one way, but it begs the question of
>why
>>> the
>>> shell and my version of SQLiteExpert find a way to understand what
>is
>>> required.
>>
>> Because they updated their copy of SQLite more recently than three
>> years ago.
>>
>>
>> Regards,
>> Clemens
>> _______________________________________________
>> sqlite-users mailing list
>> [hidden email]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-
>users
>_______________________________________________
>sqlite-users mailing list
>[hidden email]
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: curious discovery about geopoly module

Graham Hardman
In reply to this post by Richard Hipp-3
Hi Richard,
I have discovered that there is a problem in that the vba code (I got
from the github site) is somehow failing to load my custom library from
my specified location and in fact keeps referencing a file with version
3.8.5 from 2014. I am not sure how to overcome this right now apart from
renaming my custom library to something else apart from sqlite3.dll and
updating the references in the sqlite module.

The module uses the declare keyword to hook into externally declared
functions in another dll, and also adds references to some windows
functions - one of which is the LoadLibraryA function from kernel32 and
that is the one that is asked to load my library.
There are, of course, multiple apps on my system that use sqlite3.dll -
including the Bricscad app that I am running my vba code from.

Regarding the other questions: My custom shell and library (referenced
in sqliteexpert) return the correct string for sqlite_source_id(), and
they do know that geopoly is active because I can create the virtual
table and use all of the geopoly special functions.

I welcome any help you can provide.

Graham

On 31-10-2018 12:34 am, Richard Hipp wrote:
> On 10/30/18, Graham Hardman <[hidden email]> wrote:
>> To clarify: I built my own versions of the library and shell using the
>> latest amalgamation (3.25.2) specifically to test the geopoly
>
> Are you certain that the third-party tool is picking up your custom
> DLL?  Verify by looking at the results of "SELECT sqlite_source_id();"
>
> Are you certain that you enabled GeoPoly when you built your custom
> DLL?  Remember that GeoPoly is an extension that defaults off.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: curious discovery about geopoly module

Graham Hardman
In reply to this post by Vladimir Vissoultchev
Hi,
and thanks for the suggestion. I am familiar with the vbRichClient
solution. There are also odbc drivers that are free to use but in the
end I am looking for system that has to work as 64 bit inside  64-bit
Autocad where vba runs in-process. The system that I am using seems
ideal in that I can build my custom library to include the geopoly
module and that of course doesnt get enabled in the standard releases
from the sqlite.org site.
See my reply to Richard Hipp's message. Once I overcome the problem and
get my custom library loaded I expect to make good progress.

regards,
Graham


On 31-10-2018 12:35 am, Vladimir Vissoultchev wrote:

> You can try some other sqlite wrapper for VBA, for instance
> vbRichClient ships with 3.24 --
> http://www.vbrichclient.com/#/en/Downloads.htm
>
> Unfortunately as it's primary target is VB6 the stdcall port of sqlite
> is compiled to x86 binary only.
>
> cheers,
> </wqw>
>
> -----Original Message-----
> From: sqlite-users
> [mailto:[hidden email]] On Behalf Of
> Graham Hardman
> Sent: Tuesday, October 30, 2018 11:49 AM
> To: SQLite mailing list <[hidden email]>
> Subject: [sqlite] curious discovery about geopoly module
>
> Hi everybody,
>
> regarding the geopoly module in version 3.25.2
>
> a couple of weeks ago I wrote about the fact that the 'pragma
> compile_options' command failed to display when I was trying to check
> that my special build of the sqlite dll library and the command line
> shell was working corrrectly. Richard Hipp's reply was to announce
> that he had forgotten to fully broadcast the new module to the rest of
> the code.
>
> Fair enough i thought,  since i was still able to test out my ideas
> using the shell interface and in my SQLiteExpert program on my windows
> 10 pc.
>
> Since my previous message I have been doing some tests in 64-bit vba
> by adapting code released on github by Govert: SQLiteForExcel [1]
>
> It has been performing well except that, to my great surprise I have
> been unable to get it to create a virtual table using geopoly.
>
> Tonight I have documented this in a module that runs some general
> tests that all succeed (creating normal tables, inserting records, and
> querying the results. A simple Rtree virtual table  was also part of
> the testing). The final part of my testing was to try to create a
> geopoly vitual table. The prepared statement succeeded, but the step
> process failed - returning 1. The extended error code was also 1, and
> the error message was "no such module: geopoly"
>
> I guess that makes sense in one way, but it begs the question of why
> the shell and my version of SQLiteExpert find a way to understand what
> is required. In the meantime it seems I shall have to suspend my vba
> coding until the next release where hopefully the above issue will be
> fixed. I can provide my code and the library if wished.
>
> The last few lines from my debug printing to the vba intermediate
> window is pasted below:
>
> --begin test with a simple geopoly virtual table---- opening an in
> memory database SQLite3Open returned 0 open the rtree virtual table
> sqlcmd is: 'create virtual table newtab using geopoly(a,b,c)'
> SQLite3PrepareV2 returned 0
> SQLite3Step failed returning 1
> Extended error code is: 1
> Extended error message is: no such module: geopoly SQLite3Finalize
> returned 1
>
> ----forced to abandon testing since geopoly table could not be
> created-----
>
> assertion documented
>
> Regards,
>
> Graham Hardman.
>
>
>
> Links:
> ------
> [1] https://github.com/govert/SQLiteForExcel
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: curious discovery about geopoly module

Graham Holden
In reply to this post by Graham Hardman

> There are, of course, multiple apps on my system that use sqlite3.dll - including the Bricscad app that I am running my vba code from.Speculating somewhat: Have you tried updating the copy Briscad is using? If one version is already in memory, you _may_ have problems persuading Windows to load a different version, and -- even if you can -- I've a feeling that SQLite might not like that.Graham.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: curious discovery about geopoly module

Dominique Devienne
On Wed, Oct 31, 2018 at 12:51 PM Graham Holden <[hidden email]>
wrote:

> > There are, of course, multiple apps on my system that use sqlite3.dll -
> including the Bricscad app that I am running my vba code from.Speculating
> somewhat: Have you tried updating the copy Briscad is using? If one version
> is already in memory, you _may_ have problems persuading Windows to load a
> different version, and -- even if you can -- I've a feeling that SQLite
> might not like that.Graham.
>

From past discussions on this list, I remember that loading SQLite several
times in the same process,
even with renamed symbols, would be problematic on Posix system, because
SQLite uses a "singleton"
of some kind (as a workaround for broken POSIX semantic around file IO if I
recall correctly). But on Windows,
there was no such restriction that I can recall. Dan or Richard can
probably shed more light on this.

Seems like Graham already has a custom build, so renaming the symbols
sounds possible at least. FWIW. --DD
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: curious discovery about geopoly module

Graham Hardman
Hi,
I have managed to get passed the first hurdle by renaming my custom
library and then editing all the statements declaring functions to be
imported from my custom library. My code now reports correct version and
source_id values, and can create the intended geopoly tables.

I am pleased about this, although still puzzled by the fact that the
windows LoadLibrary call returned a non null pointer and windows help
file implies that it is ok for multiple copies of same name libraries to
be loaded together.

Also, by checking, I found that my Bricscad application (latest version)
contains the exact same older version 3.8.5 that my vba code ended up
hooking into. I will discuss this with them, but perhaps the problem
arose because vba runs in the same 64-bit process as their application.

Thanks to all who responded to my posts.

regards,
Graham


On 01-11-2018 1:03 am, Dominique Devienne wrote:

> On Wed, Oct 31, 2018 at 12:51 PM Graham Holden <[hidden email]>
> wrote:
>
>> > There are, of course, multiple apps on my system that use sqlite3.dll -
>> including the Bricscad app that I am running my vba code
>> from.Speculating
>> somewhat: Have you tried updating the copy Briscad is using? If one
>> version
>> is already in memory, you _may_ have problems persuading Windows to
>> load a
>> different version, and -- even if you can -- I've a feeling that
>> SQLite
>> might not like that.Graham.
>>
>
> From past discussions on this list, I remember that loading SQLite
> several
> times in the same process,
> even with renamed symbols, would be problematic on Posix system,
> because
> SQLite uses a "singleton"
> of some kind (as a workaround for broken POSIX semantic around file IO
> if I
> recall correctly). But on Windows,
> there was no such restriction that I can recall. Dan or Richard can
> probably shed more light on this.
>
> Seems like Graham already has a custom build, so renaming the symbols
> sounds possible at least. FWIW. --DD
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: curious discovery about geopoly module

Peter da Silva-2
On 2018-11-01, at 02:51, Graham Hardman <[hidden email]> wrote:
> I am pleased about this, although still puzzled by the fact that the windows LoadLibrary call returned a non null pointer and windows help file implies that it is ok for multiple copies of same name libraries to be loaded together.

This has been a problem in Windows for years. Microsoft themselves used to include version numbers in library base names (eg, MSVCRT40.DLL) and other vendors use similar tricks to keep "DLL hell" at bay. I suspect that your solution of using a different library name is actually best practice. :(
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: curious discovery about geopoly module

R Smith-2
In reply to this post by Graham Hardman
On 2018/11/01 9:51 AM, Graham Hardman wrote:
>
> I am pleased about this, although still puzzled by the fact that the
> windows LoadLibrary call returned a non null pointer and windows help
> file implies that it is ok for multiple copies of same name libraries
> to be loaded together.

This is an old Windows problem, one which I think they (M$) have
self-regretted so many times. What I deduced long ago after resolving a
similar problem (and I could be wrong, I don't have insider info on it)
is that Windows' idea of DLLs was to have it so the DLLs live in a
common area in the Windows system path (typically
c:\program files\common files\system) from where it can be shared to all
the lovely apps everywhere needing to use it. AND, how wonderful would
it be if, when a DLL is updated, everyone benefits from the new version.
Right?

So what they did is the DLL loader seems to have a rule of loading the
DLL FIRST from the windows common DLL area, and only if not available
there (because that's where the updatedest DLL would be, right?) then
see if local DLL exists next to the app and loads it.

Most applications play nice and do not install their greasy little DLLs
to the Widows DLL common area, but just hug them locally (in the app
folder). But some, thinking probably they were doing the right thing, do
install DLLs to the common area, and sometimes this includes a DLL like
sqlite3.dll which starts causing problems for everyone else using it,
because they don't actually distribute/install newest versions, so
everything else loading the same library gets the last installed version
of the last app to successfully install to the common area.

Even this wouldn't be such a catastrophe if the common area DLLs weren't
usually "in use" by the services it supports, so it can't be updated by
anyone else, unless you KNOW which service(s) is/are using it and stop
all of them.

This leaves a new application install with very few options, if you
can't get Windows to use your local DLL, nor can you update the "in-use"
one in the common area... How then do you cause the system to use your
newest DLL?  There are a few hacky ways:

1 - The easiest is to just use a different name (and to do your part by
not installing it for all).

2 - Use a side-by-side isolation assembly.
     See:
https://docs.microsoft.com/en-us/windows/desktop/SbsCs/isolated-applications-and-side-by-side-assemblies-portal
     This option is fine if you develop new software to be isolated from
any DLL conflicts from the start, but it's a LOT of effort to just fix
one conflict.

3 - This is my favourite - Use DLL redirection, which involves simply
adding a .local file to your app path (so myapp.exe must be accompanied
by myapp.local).
     This does require and extra file to maintain, but it's relatively
easy and means you don't need to be concerned with sorting out DLL
naming or isolation.
     I believe the file's presence matters, but its content is
irrelevant (I usually add a line like "** Force local DLLs **" as the
content), which makes Widows look locally first when loading DLLs.
     See:
https://docs.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-redirection
NB! - The .local file will force local redirection for ALL DLLs you use,
some of which may not be intended, like if you supply xxx.dll as a
back-up, but would prefer Windows to use it's internal (and possibly
newer) xxx.dll if present.
NB2! - As is the standard for M$, every fix must have a fallback... so
known common DLLs cannot be redirected like this (there is a list
maintained in the Windows registry in
HKLM/SYSTEM/CurrentControlSet/Control/Session Manager/KnownDLLs/ of what
Windows regards as "common" DLLs. Make sure your DLL is not in there,
for if it is, options 1 & 2 above are your only remaining venues).


HTH - Cheers!
Ryan

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: curious discovery about geopoly module

Simon Slavin-3
On 1 Nov 2018, at 10:40am, R Smith <[hidden email]> wrote:

> Most applications play nice and do not install their greasy little DLLs to the Widows DLL common area, but just hug them locally (in the app folder). But some, thinking probably they were doing the right thing, do install DLLs to the common area, and sometimes this includes a DLL like sqlite3.dll which starts causing problems for everyone else using it, because they don't actually distribute/install newest versions, so everything else loading the same library gets the last installed version of the last app to successfully install to the common area.

That's the problem.  The standard Windows installer has a way of saying "install this common-area DLL if and only if there isn't one in there, or it's a later version than the one already in there". When only professionals wrote Windows programs that needed installing, it was fine, but now days few people use it because

(A) Some DLLs have bugs, the programmer figured this out and wrote around the bug, but their work-around does't involve a version-check.  Updating the DLL fixes a bug their app depends on.
(B) My installer installs my app which works perfectly.  If you have trouble with another app, take it up with their support team, not mine.

Now days most houses use Installshield which has its own problems.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: curious discovery about geopoly module

Graham Hardman
In reply to this post by R Smith-2
Thanks for the very detailed info. I am certainly a lot wiser now!

Graham

On 01-11-2018 11:40 pm, R Smith wrote:

> On 2018/11/01 9:51 AM, Graham Hardman wrote:
>>
>> I am pleased about this, although still puzzled by the fact that the
>> windows LoadLibrary call returned a non null pointer and windows help
>> file implies that it is ok for multiple copies of same name libraries
>> to be loaded together.
>
> This is an old Windows problem, one which I think they (M$) have
> self-regretted so many times. What I deduced long ago after resolving
> a similar problem (and I could be wrong, I don't have insider info on
> it) is that Windows' idea of DLLs was to have it so the DLLs live in a
> common area in the Windows system path (typically
> c:\program files\common files\system) from where it can be shared to
> all the lovely apps everywhere needing to use it. AND, how wonderful
> would it be if, when a DLL is updated, everyone benefits from the new
> version. Right?
>
> So what they did is the DLL loader seems to have a rule of loading the
> DLL FIRST from the windows common DLL area, and only if not available
> there (because that's where the updatedest DLL would be, right?) then
> see if local DLL exists next to the app and loads it.
>
> Most applications play nice and do not install their greasy little
> DLLs to the Widows DLL common area, but just hug them locally (in the
> app folder). But some, thinking probably they were doing the right
> thing, do install DLLs to the common area, and sometimes this includes
> a DLL like sqlite3.dll which starts causing problems for everyone else
> using it, because they don't actually distribute/install newest
> versions, so everything else loading the same library gets the last
> installed version of the last app to successfully install to the
> common area.
>
> Even this wouldn't be such a catastrophe if the common area DLLs
> weren't usually "in use" by the services it supports, so it can't be
> updated by anyone else, unless you KNOW which service(s) is/are using
> it and stop all of them.
>
> This leaves a new application install with very few options, if you
> can't get Windows to use your local DLL, nor can you update the
> "in-use" one in the common area... How then do you cause the system to
> use your newest DLL?  There are a few hacky ways:
>
> 1 - The easiest is to just use a different name (and to do your part
> by not installing it for all).
>
> 2 - Use a side-by-side isolation assembly.
>     See:
> https://docs.microsoft.com/en-us/windows/desktop/SbsCs/isolated-applications-and-side-by-side-assemblies-portal
>     This option is fine if you develop new software to be isolated
> from any DLL conflicts from the start, but it's a LOT of effort to
> just fix one conflict.
>
> 3 - This is my favourite - Use DLL redirection, which involves simply
> adding a .local file to your app path (so myapp.exe must be
> accompanied by myapp.local).
>     This does require and extra file to maintain, but it's relatively
> easy and means you don't need to be concerned with sorting out DLL
> naming or isolation.
>     I believe the file's presence matters, but its content is
> irrelevant (I usually add a line like "** Force local DLLs **" as the
> content), which makes Widows look locally first when loading DLLs.
>     See:
> https://docs.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-redirection
> NB! - The .local file will force local redirection for ALL DLLs you
> use, some of which may not be intended, like if you supply xxx.dll as
> a back-up, but would prefer Windows to use it's internal (and possibly
> newer) xxx.dll if present.
> NB2! - As is the standard for M$, every fix must have a fallback... so
> known common DLLs cannot be redirected like this (there is a list
> maintained in the Windows registry in
> HKLM/SYSTEM/CurrentControlSet/Control/Session Manager/KnownDLLs/ of
> what Windows regards as "common" DLLs. Make sure your DLL is not in
> there, for if it is, options 1 & 2 above are your only remaining
> venues).
>
>
> HTH - Cheers!
> Ryan
>
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: curious discovery about geopoly module

Graham Hardman
In reply to this post by Simon Slavin-3
Thanks. In my case there is no installer as such. My vba code runs
inside the same process as the host cad system. In this case Bricscad
has already loaded their copy of dqlite3.dll and my like-named file
could not demand precedence.

Graham

On 02-11-2018 3:16 am, Simon Slavin wrote:

> On 1 Nov 2018, at 10:40am, R Smith <[hidden email]> wrote:
>
>> Most applications play nice and do not install their greasy little
>> DLLs to the Widows DLL common area, but just hug them locally (in the
>> app folder). But some, thinking probably they were doing the right
>> thing, do install DLLs to the common area, and sometimes this includes
>> a DLL like sqlite3.dll which starts causing problems for everyone else
>> using it, because they don't actually distribute/install newest
>> versions, so everything else loading the same library gets the last
>> installed version of the last app to successfully install to the
>> common area.
>
> That's the problem.  The standard Windows installer has a way of
> saying "install this common-area DLL if and only if there isn't one in
> there, or it's a later version than the one already in there". When
> only professionals wrote Windows programs that needed installing, it
> was fine, but now days few people use it because
>
> (A) Some DLLs have bugs, the programmer figured this out and wrote
> around the bug, but their work-around does't involve a version-check.
> Updating the DLL fixes a bug their app depends on.
> (B) My installer installs my app which works perfectly.  If you have
> trouble with another app, take it up with their support team, not
> mine.
>
> Now days most houses use Installshield which has its own problems.
>
> Simon.
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users