I don't think so. The WoW layer allows 32 bit code to talk to the 64 bit
OS, but there is no support included to connect 32 bit and 64 bit user
application pieces (executable and dll).
On 5/15/16 5:22 PM, Bart Smissaert wrote:
> So, is there any way that a 32 bit VB6 ActiveX dll or a32 bit VB6
So, is there any way that a 32 bit VB6 ActiveX dll or a32 bit VB6 ActiveX
exe could access a 64 bit SQLite dll?
All this only comes into play for me when using 64 bit VBA in Excel.
I have no problem to access the 64 bit SQLite dll from 64 bit VBA.
RBS
On Sun, May 15, 2016 at 7:12 PM, Richard
> > But I think if you compile code for the x64 processor chip and call it
> > from x86 or vice versa then either it doesn't work or you pay a high
> > price for thunking from one to the other. I think that's unavoidable
> > regardless of OS.
>
> Right: doesn't work. There's no performance
> > Actually, it's everyone using a language other than C/C++, plus a
> > proportion of those too. I use C#, but if you want to call Sqlite from
> > Java, Python, etc or even some generic C/C++ app that supports
> > plug-ins, then at some point there is a DLL
>
> How does that follow? Any
On 5/15/16 1:00 AM, dandl wrote:
>>> But I think if you compile code for the x64 processor chip and call it
>>> from x86 or vice versa then either it doesn't work or you pay a high
>>> price for thunking from one to the other. I think that's unavoidable
>>> regardless of OS.
>> Right: doesn't
On Thu, 12 May 2016 00:36:31 +1000
"dandl" wrote:
> But I think if you compile code for the x64 processor chip and call
> it from x86 or vice versa then either it doesn't work or you pay a
> high price for thunking from one to the other. I think that's
> unavoidable regardless of OS.
Right:
On Wed, 11 May 2016 11:30:34 +1000
"dandl" wrote:
> > more about DLLs than it is about SQLite.
>
> Actually, it's everyone using a language other than C/C++, plus a
> proportion of those too. I use C#, but if you want to call Sqlite
> from Java, Python, etc or even some generic C/C++ app that
> bounces at mailinglists.sqlite.org] On Behalf Of Simon Slavin
> There must be a Windows element in there, though. On the Mac I can create
a
> create a project in Xcode which has C, C++, Objective-C, Java and Python
code
> in (probably other languages too) and they can all call functions in
> bounces at mailinglists.sqlite.org] On Behalf Of Simon Slavin
> It's only a certain kind of Windows user who wants DLLs for everything.
If
> that's what you need you are going to have to make sure you get the right
> DLL. But the fact that most SQLite programmers don't use a DLL is why
you're
On Tue, 10 May 2016, at 17:17, Simon Slavin wrote:
>
> On 10 May 2016, at 4:56pm, Jeremy Nicoll
> wrote:
>
> > That suggests to me that sqldiff & sqlite3 only use a small fraction of
> > the code present in
> > a DLL, and the link only includes those functions in the resulting .exe.
>
>
> bounces at mailinglists.sqlite.org] On Behalf Of Simon Slavin
>
>> It's only a certain kind of Windows user who wants DLLs for everything. If
>> that's what you need you are going to have to make sure you get the right
>> DLL. But the fact that most SQLite programmers don't use a DLL is why
sorry that is LISTDLLS no ' or space ... and not singular.
On Tue, May 10, 2016 at 7:02 PM, J Decker wrote:
> In general...
>
> while sqlite tool in question is running one could run listdll's in an
> admin console window and see... listdll takes a executable name to
> filter its list...
>
>
In general...
while sqlite tool in question is running one could run listdll's in an
admin console window and see... listdll takes a executable name to
filter its list...
maybe you have another compatible one in the path it's finding?
Because it's not Any CPU.
On 10 May 2016, at 4:56pm, Jeremy Nicoll
wrote:
> That suggests to me that sqldiff & sqlite3 only use a small fraction of
> the code present in
> a DLL, and the link only includes those functions in the resulting .exe.
Correct.
The SQLite tools do not use a DLL. They have the SQLite
On Tue, 10 May 2016, at 16:26, Scott Robison wrote:
> I believe the tools provided by the site statically like SQLite so no DLL
> is required. The DLL is provided as a courtesy to those who do not want
> to link their own apps statically.
>
> Not near a computer to confirm this, but I know for a
On Tue, 10 May 2016, at 14:45, J Decker wrote:
> On Tue, May 10, 2016 at 2:23 AM, Jeremy Nicoll
> > I was under the impression that I'm using the 64-bit DLL on a W8.1
> > 64-bit system, with the 32-bit tools. Does that mean that there's
> > some clever trick in the tools to make that work?
>
On Mon, 9 May 2016, at 15:48, jicman at barrioinvi.net wrote:
> Well, I can not use the SQLite 64bit DLL in a 64bit environment with a
> 32bit application.
I was under the impression that I'm using the 64-bit DLL on a W8.1
64-bit system,
with the 32-bit tools. Does that mean that there's soe
On Tue, May 10, 2016 at 9:56 AM, Jeremy Nicoll <
jn.ml.sqlu.725 at letterboxes.org> wrote:
> On Tue, 10 May 2016, at 16:26, Scott Robison wrote:
>
> > I believe the tools provided by the site statically like SQLite so no DLL
> > is required. The DLL is provided as a courtesy to those who do not
On May 10, 2016 8:48 AM, "Jeremy Nicoll"
wrote:
>
> On Tue, 10 May 2016, at 14:45, J Decker wrote:
> > On Tue, May 10, 2016 at 2:23 AM, Jeremy Nicoll
>
> > > I was under the impression that I'm using the 64-bit DLL on a W8.1
> > > 64-bit system, with the 32-bit tools. Does that mean that there's
On Tue, May 10, 2016 at 2:23 AM, Jeremy Nicoll
wrote:
> On Mon, 9 May 2016, at 15:48, jicman at barrioinvi.net wrote:
>
>> Well, I can not use the SQLite 64bit DLL in a 64bit environment with a
>> 32bit application.
>
> I was under the impression that I'm using the 64-bit DLL on a W8.1
> 64-bit
On 2016-05-07 01:29, Simon Slavin wrote:
> On 7 May 2016, at 3:28am, Keith Medcalf wrote:
>
>> I presume you mean that running 32-bit application on a 64-bit OS is
>> slower than the same application run on a 32-bit OS.
>
> Hold on. The original poster was talking about using a 32-bit DLL,
There are reasons for 64bit to be faster - more registers to work with.
(from https://en.wikipedia.org/wiki/X86-64 )
In addition to increasing the size of the general-purpose registers,
the number of named general-purpose registers is increased from eight
(i.e. eax, ebx, ecx, edx, ebp, esp, esi,
> On 7 May 2016, at 3:28am, Keith Medcalf wrote:
> > I presume you mean that running 32-bit application on a 64-bit OS is
> slower than the same application run on a 32-bit OS.
> Hold on. The original poster was talking about using a 32-bit DLL, not a
> 32-bit application. I don't know what
On 7 May 2016, at 3:28am, Keith Medcalf wrote:
> I presume you mean that running 32-bit application on a 64-bit OS is slower
> than the same application run on a 32-bit OS.
Hold on. The original poster was talking about using a 32-bit DLL, not a
32-bit application. I don't know what
> I have found that the Windows 32bit DLL works slower on a 64bit machine
> than on a 32bit. I would have thought that the calls from the
> applications would have the same response for both machines since the
> application is a 32 bit application. Anyone thinks otherwise? Thanks.
I presume
On 6 May 2016, at 5:36pm, Jose I. Cabrera wrote:
> I have found that the Windows 32bit DLL works slower on a 64bit machine than
> on a 32bit. I would have thought that the calls from the applications would
> have the same response for both machines since the application is a 32 bit
>
Greetings!
I have found that the Windows 32bit DLL works slower on a 64bit machine than on
a 32bit. I would have thought that the calls from the applications would have
the same response for both machines since the application is a 32 bit
application. Anyone thinks otherwise? Thanks.
jos?
27 matches
Mail list logo
