[sqlite] 64bit DLL vs 32bit
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 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 Damon > wrote: > >> 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 work. There's no performance penalty because there's no 32-64 bit thunking layer. https://blogs.msdn.microsoft.com/oldnewthing/20081020-00/?p=20523 >>> An interesting post, but not I think from someone with a deep >>> understanding >>> of the matter. >>> >>> IMHO it would be perfectly possible to chunk either way, within the >>> limitations of a 4GB address space. The WOW64 layer already provides the >>> means for x86 apps to call the x64 Windows API. A thunk can do anything, >>> unless it's physically impossible or blocked by policy. >>> >>> Regards >>> David M Bennett FACS >>> >>> Andl - A New Database Language - andl.org >>> >>> You can thunk an arbitrary 32 bit module to 64 bit code because the >> memory accessibly by the 32 bit code is all accessible by the 64 bit code. >> The converse doesn't work. Either the 64 bit code needs to make sure it >> puts the data in the lower 4GB, or the thunk layer needs to know enough >> about the data to copy it. >> >> This works for WOW64, as the 64 bit side is code designed to make it work >> with the thunking layer. >> >> For arbitrary 64 bit code, the thunking layer won't know enough about what >> needs to be copied into accessible memory. >> >> -- >> Richard Damon >> >> >> ___ >> sqlite-users mailing list >> sqlite-users at mailinglists.sqlite.org >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >> > ___ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > -- Richard Damon
[sqlite] 64bit DLL vs 32bit
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 Damon wrote: > 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 work. There's no performance penalty because there's no >>> 32-64 bit thunking layer. >>> >>> >>> https://blogs.msdn.microsoft.com/oldnewthing/20081020-00/?p=20523 >>> >> An interesting post, but not I think from someone with a deep >> understanding >> of the matter. >> >> IMHO it would be perfectly possible to chunk either way, within the >> limitations of a 4GB address space. The WOW64 layer already provides the >> means for x86 apps to call the x64 Windows API. A thunk can do anything, >> unless it's physically impossible or blocked by policy. >> >> Regards >> David M Bennett FACS >> >> Andl - A New Database Language - andl.org >> >> You can thunk an arbitrary 32 bit module to 64 bit code because the > memory accessibly by the 32 bit code is all accessible by the 64 bit code. > The converse doesn't work. Either the 64 bit code needs to make sure it > puts the data in the lower 4GB, or the thunk layer needs to know enough > about the data to copy it. > > This works for WOW64, as the 64 bit side is code designed to make it work > with the thunking layer. > > For arbitrary 64 bit code, the thunking layer won't know enough about what > needs to be copied into accessible memory. > > -- > Richard Damon > > > ___ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
[sqlite] 64bit DLL vs 32bit
> > 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 penalty because there's no > 32-64 bit thunking layer. > > https://blogs.msdn.microsoft.com/oldnewthing/20081020-00/?p=20523 An interesting post, but not I think from someone with a deep understanding of the matter. IMHO it would be perfectly possible to chunk either way, within the limitations of a 4GB address space. The WOW64 layer already provides the means for x86 apps to call the x64 Windows API. A thunk can do anything, unless it's physically impossible or blocked by policy. Regards David M Bennett FACS Andl - A New Database Language - andl.org
[sqlite] 64bit DLL vs 32bit
> > 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 higher-than-C language has its own binding system, > and SQLite is a module of some kind, where the C library is wrapped in the > module that exposes its own API. If the module statically links in > libsqlite3.a -- as, arguably, it should -- then there's no version ambiguity, > no DLL, and no chance of conflict. Then I think you misunderstood. You dropped in a 'module' without mentioning that this would have to be written in C/C++. There is absolutely no way to call Sqlite statically from any language other than C (or one of the rare languages that implement a C-compatible ABI). So: [Here HLL means Java/C#/Python/Perl/etc] HLL -> Sqlite, DLL HLL -> C-module dynamically linked -> Sqlite, DLL HLL -> C-module statically linked -> Sqlite, no DLL The reason this matters is that every 'module' injects its own world view. If you want to call Sqlite from a HLL and make it look like other databases then you use a 'module'. But if you want to call Sqlite from a HLL and see exactly the same API that libpq exposes then you call the libpq DLL. This is what I do in Andl. I need to control the communications channel in ways that your 'modules' do not allow, so I use the libpq DLL. Regards David M Bennett FACS Andl - A New Database Language - andl.org
[sqlite] 64bit DLL vs 32bit
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 work. There's no performance penalty because there's no >> 32-64 bit thunking layer. >> >> https://blogs.msdn.microsoft.com/oldnewthing/20081020-00/?p=20523 > An interesting post, but not I think from someone with a deep understanding > of the matter. > > IMHO it would be perfectly possible to chunk either way, within the > limitations of a 4GB address space. The WOW64 layer already provides the > means for x86 apps to call the x64 Windows API. A thunk can do anything, > unless it's physically impossible or blocked by policy. > > Regards > David M Bennett FACS > > Andl - A New Database Language - andl.org > You can thunk an arbitrary 32 bit module to 64 bit code because the memory accessibly by the 32 bit code is all accessible by the 64 bit code. The converse doesn't work. Either the 64 bit code needs to make sure it puts the data in the lower 4GB, or the thunk layer needs to know enough about the data to copy it. This works for WOW64, as the 64 bit side is code designed to make it work with the thunking layer. For arbitrary 64 bit code, the thunking layer won't know enough about what needs to be copied into accessible memory. -- Richard Damon
[sqlite] 64bit DLL vs 32bit
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: doesn't work. There's no performance penalty because there's no 32-64 bit thunking layer. https://blogs.msdn.microsoft.com/oldnewthing/20081020-00/?p=20523 --jkl
[sqlite] 64bit DLL vs 32bit
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 supports > plug-ins, then at some point there is a DLL How does that follow? Any higher-than-C language has its own binding system, and SQLite is a module of some kind, where the C library is wrapped in the module that exposes its own API. If the module statically links in libsqlite3.a -- as, arguably, it should -- then there's no version ambiguity, no DLL, and no chance of conflict. --jkl
[sqlite] 64bit DLL vs 32bit
> 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 one- > another and the project compiles into one application without any libraries. > You do have to know some function-name conventions (e.g. Objective-C > functions really start with an invisible '@' and C++ functions end with an > invisible '_') but once you've figured that out it works. Of course. DLL means windows; on Unix it would be .so or something else. 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. > From what you wrote about Windows uses the library calling convention as a > standardised way for one code in one language to call code from another. Correct. The very first release of Windows had DLLs with an table of entry points and a mechanism to load them dynamically and call them using a C-style API. That same mechanism is alive and well today. The file layout still has the same MZ signature from Mark Zbikowski, an MS-DOS developer. Regards David M Bennett FACS Andl - A New Database Language - andl.org
[sqlite] 64bit DLL vs 32bit
> 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 > having trouble getting simple clear answers on this thread -- your problem is > 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 supports plug-ins, then at some point there is a DLL and if the OS is x64 and any of the tools are x86 then there is a good chance of getting a combo that doesn't play. Add that to impenetrable error messages and limited diagnostic tools and it's hair-tearing-out time again. It definitely isn't a problem caused by Sqlite, but being able to reliably source both x86 and x64 DLLs (and a way to tell them apart) would certainly help. Regards David M Bennett FACS Andl - A New Database Language - andl.org
[sqlite] 64bit DLL vs 32bit
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. > > Correct. > > The SQLite tools do not use a DLL. Ah. If only the download page made that clear! I'm quite used to downloading other apps which come with an assortment of DLLs (and need them) so I just assumed that was true here too. Thank-you for allowing me to simplify things. -- Jeremy Nicoll - my opinions are my own.
[sqlite] 64bit DLL vs 32bit
> 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 >> having trouble getting simple clear answers on this thread -- your problem is >> 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 supports plug-ins, then at some > point there is a DLL 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 one-another and the project compiles into one application without any libraries. You do have to know some function-name conventions (e.g. Objective-C functions really start with an invisible '@' and C++ functions end with an invisible '_') but once you've figured that out it works.
[sqlite] 64bit DLL vs 32bit
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... > > maybe you have another compatible one in the path it's finding? > Because it's not Any CPU.
[sqlite] 64bit DLL vs 32bit
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.
[sqlite] 64bit DLL vs 32bit
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 library included in their own code, supplied as one .h one .c file. Since the compiler has access to the raw source code it knows which functions are called and doesn't have to include the others. This is true of almost all programs which use SQLite on all platforms. SQLite is provided as two C files (the amalgamation .c and .h files) and you are expected to include them in your project. That way you don't have to find the ideal DLL to match your requirements. If your compilation process targets 32 bit or 16 bit or a mobile platform or a different OS, when your own code is being compiled for it, so is the SQLite code included in your project. 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 having trouble getting simple clear answers on this thread -- your problem is more about DLLs than it is about SQLite. Simon.
[sqlite] 64bit DLL vs 32bit
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 fact that 32 / 64 > bit DLLs are not interchangeable. See > https://msdn.microsoft.com/en-us/library/windows/desktop/aa384231(v=vs.85).aspx Thanks for the link. I looked at the sizes of the DLLs and the tools .executables: 32-bit DLL 807 KB 64-bit DLL1644 KB sqldiff.exe 422 KB sqlite3.exe 661 KB sqlite3_analyser.exe 1912 KB 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. Is that likely? Or are the .exe's compressed? -- Jeremy Nicoll - my opinions are my own.
[sqlite] 64bit DLL vs 32bit
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? > No it means you're using 64 bit tools or 32 bit dll. I downloaded the only pre-compiled Windows binaries for tools that were listed on the downloads page. They're described as 32-bit, but the DLL I'd downloaded is the 64-bit one. It seems to work... Quite a lot of non-SQLite apps are 32-bit ones, and they work too. So, are you certain that this must mean that there's a 32-bit SQLite DLL somewhere on my system that I didn't know about? And if that IS the case, why doesn't the SQLite website offer pre-built 64-bit tools for use with the 64-bit DLL? -- Jeremy Nicoll - my opinions are my own.
[sqlite] 64bit DLL vs 32bit
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 clever trick in the tools to make that work? -- Jeremy Nicoll - my opinions are my own.
[sqlite] 64bit DLL vs 32bit
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 want > > to link their own apps statically. > > > > Not near a computer to confirm this, but I know for a fact that 32 / 64 > > bit DLLs are not interchangeable. See > > > https://msdn.microsoft.com/en-us/library/windows/desktop/aa384231(v=vs.85).aspx > > Thanks for the link. > > I looked at the sizes of the DLLs and the tools .executables: > > 32-bit DLL 807 KB > 64-bit DLL1644 KB > > sqldiff.exe 422 KB > sqlite3.exe 661 KB > sqlite3_analyser.exe 1912 KB > > 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. > Is that likely? Or > are the .exe's compressed? > I'm fairly confident they don't use 100% of the SQLite code in each, and I don't believe they are compressed. However, statically linking SQLite directly, particularly in amalgamation form, potentially opens up a lot of optimization opportunities that aren't available in a DLL where you don't know which APIs might be needed by any given program. -- Scott Robison
[sqlite] 64bit DLL vs 32bit
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 > > > some clever trick in the tools to make that work? > > > No it means you're using 64 bit tools or 32 bit dll. > > I downloaded the only pre-compiled Windows binaries for tools that were > listed on the downloads page. They're described as 32-bit, but the DLL > I'd downloaded is the 64-bit one. > > It seems to work... > > Quite a lot of non-SQLite apps are 32-bit ones, and they work too. > > So, are you certain that this must mean that there's a 32-bit SQLite DLL > somewhere on my system that I didn't know about? > > And if that IS the case, why doesn't the SQLite website offer pre-built > 64-bit > tools for use with the 64-bit DLL? 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 fact that 32 / 64 bit DLLs are not interchangeable. See https://msdn.microsoft.com/en-us/library/windows/desktop/aa384231(v=vs.85).aspx
[sqlite] 64bit DLL vs 32bit
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 system, > with the 32-bit tools. Does that mean that there's soe clever trick in > the tools to make > that work? No it means you're using 64 bit tools or 32 bit dll. > > -- > Jeremy Nicoll - my opinions are my own. > ___ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] 64bit DLL vs 32bit
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, not > a 32-bit application. I don't know what Windows' limitations are. n > 64-bit windows can you run a 64-bit application which uses a 32-bit DLL > ? Or does the fact that the application uses a 32-bit DLL mean that it > must be 32-bit itself ? > > Either way, what I found is that 32-bit apps run at expected speed if > they're just doing stuff internally. The delays come when you meet a > 32/64 interface, for example if a 32-bit application is constantly > fetching data from a 64-bit source supplied by the 64-bit OS. > Sorry for the late reply... Well, I can not use the SQLite 64bit DLL in a 64bit environment with a 32bit application. So, this answer your questions, at least as SQLite DLL is concerned. What I am trying to find out is the speed difference from both 32bit and 64bit environment. I will have to look deeper, but, there are definitely differences. I will come back later and let you know the outcome, if I can find it. Thanks for your support. jos?
[sqlite] 64bit DLL vs 32bit
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, edi) in x86 to 16 (i.e. rax, rbx, rcx, rdx, rbp, rsp, rsi, rdi, r8, r9, r10, r11, r12, r13, r14, r15). Generally the ABI (https://msdn.microsoft.com/en-us/library/ms235286.aspx) passes most arguments by register instead of by stack "The x64 Application Binary Interface (ABI) is a 4 register fast-call calling convention, with stack-backing for those registers. There is a strict one-to-one correspondence between arguments in a function, and the registers for those arguments. Any argument that doesn?t fit in 8 bytes, or is not 1, 2, 4, or 8 bytes, must be passed by reference." 32 bit apps are a tiny percent slower than 64 ... or rather the same speed they always were and 64 bit is a tiny percent faster because of the above reasons.
[sqlite] 64bit DLL vs 32bit
> 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 Windows' limitations are. > n 64-bit windows can you run a 64-bit application which uses a 32-bit DLL? Not in-process. The in-process cpu mode must be the same. You cannot load a 64-bit DLL into a 32-bit process nor a 32-bit DLL into a 64-bit process. > Or does the fact that the application uses a 32-bit DLL mean that it must be > 32-bit itself ? Yes. There is no in-process thunking. That technology was an IBM technology and remained IBM technology after the breakup of the IBM Microsoft JAD in which OS/2 3.0 became also known as Windows Net Technology. > Either way, what I found is that 32-bit apps run at expected speed if > they're just doing stuff internally. The delays come when you meet a > 32/64 interface, for example if a 32-bit application is constantly > fetching data from a 64-bit source supplied by the 64-bit OS. Never experienced this myself. Except of course for COM and DCOM crap, (and dotNOT), where it is to be expected. I have never seen or experienced this with proper applications however. > Simon.
[sqlite] 64bit DLL vs 32bit
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 Windows' limitations are. n 64-bit windows can you run a 64-bit application which uses a 32-bit DLL ? Or does the fact that the application uses a 32-bit DLL mean that it must be 32-bit itself ? Either way, what I found is that 32-bit apps run at expected speed if they're just doing stuff internally. The delays come when you meet a 32/64 interface, for example if a 32-bit application is constantly fetching data from a 64-bit source supplied by the 64-bit OS. Simon.
[sqlite] 64bit DLL vs 32bit
> 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 you mean that running 32-bit application on a 64-bit OS is slower than the same application run on a 32-bit OS. Generally speaking this is not the case unless you are spending a significant portion of the execution time in non-optimized thunking code, which only exists when transitioning between "user" mode (32-bit) and "supervisor" mode (64-bit). What in particular is slower? And what versions of Windows are you comparing?
[sqlite] 64bit DLL vs 32bit
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 > application. Anyone thinks otherwise? Yes. When you call a 32bit DLL or run a 32bit program from a 64bit operating system constant translation between the two word sizes is taking place. Not everything needs to be translated but enough of it has to be done that not only do you have the bottleneck of 32bit speed of the DLL, but you also have to spend extra time getting stuff to it and from it. Simon.
[sqlite] 64bit DLL vs 32bit
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?
