It seems that the 64 bits Sybase ASE drivers still consider the SQLLEN type as being 32 bits, whereas UnixODBC and pretty much every other driver want 64 bits. This is problematic for example for the strlen parameter in the SQLBindParameter function.
Although it is possible to hack this particular case by casting an SQLINTEGER array into an SQLLEN *, it would force me to make a particular ODBC call for Sybase, which defeats the purpose of a generic API.
Is this solvable? Has anyone managed to use the Sybase ODBC drivers on 64 bits Linux without these kinds of ugly hacks?
Looks like the answer is no. The Sybase API is compatible with the previous version of UnixODBC, 2.2.11, but is incompatible with UnixODBC 3.3 as SQLLEN has moved from 32 bits to 64 bits.
Solution is therefore to revert to UnixODBC 2.2.11.
Related
Is it possible to use sysenter in a 64 bits program on Linux ? Or is it impossible to adapt the use of sysenter with the SystemⅤ calling convention without getting other dynamic link libraries crashing (I know the 32 bits way won’t work but I just want to know if it’s possible to work around this like withint 0x80) ?
There is very few documentation around using sysenter in 32 bits, so I couldn’t found anything for 64 bits.
I know this not recommended but it’s the only opcode I can use to trigger a system call as part of bug bounty hunting exploit where the program need to exit using a special function that can be trigger only from normal execution.
It is possible to use them, but they use the 32-bit entry point of the kernel (check the code for more).
The actual location (and code) of this entry point depends on you kernel version.
For versions 4.2 and newer it is entry_SYSENTER_32.
For versions 4.1 and older it is ia32_sysenter_target.
Finally, SYSRET is not available at userspace (it can only be executed from ring 0). Check the Intel manual description of the instruction.
I've installed Activiz 5.8.0 on my project (I installed both 32 and 64 bits versions through the Nuget package manager).
I can import to the toolbox only the 32 bits RenderWindowControl component of Kitware.VTK.dll, when I try the 64 bits version it doesn't work (I can't even import it to the toolbox).
I'm using VS2012 64 bits edition.
Thank you for your help!
I'm using VS2008 and I know there are some issues with the form designer in 64 bits, but if you get your references right you should be able to compile your application in release mode using the activiz 64 bit. For debug stick to the 32 bit version.
I am trying to create a worker role to download data from RETS server using librets.net. librets.net is a wrapper on a c++ library librets. I tried both 32 bit and 64 bit version and followed this articlebut no success. I am still receiving
BadImageFormatException
How can i solve this issue?
BadImageFormatExceptions are almost always a 32 bit/64 bit incompatibility; If I were a betting man, I'd say you are binding the wrong version based on your Platform configuration in Visual Studio.
Choosing "Any CPU" will result in an assembly that will be JITted into a 64 bit version when loaded into a 64 bit process and a 32 bit version when loaded into a 32 bit process
Choosing "x86" will always result in a 32 bit assembly
I'd be willing to bet you've got:
"Any CPU" selected
A 64 bit computer
A 32-bit only version of the C++ library
Try switching everything over to 32 bit first; x86 for Platform, use the 32 bit version of the library, etc.
My current understanding is
No 64-bit GHC, ticket #1884
The 32-bit GHC and the binaries it builds work just fine because the Windows OS loader converts OS calls and pointers to 64 bits. The same applies to DLLs
No mixing 32 bit and 64 bit code (ie. your 32 bit Haskell DLL isn't going to be friends with the 64 bit program that wants to use it)
Latest discussion is a thread started on May 2011
Is this correct? Are there any pitfalls to watch out for, particularly as an FFI user? For example, if I were to export some Haskell code as a 32 bit DLL to some Windows program, should I expect it to work?
Edit: looks like you'd need a 64 bit DLL to go with a 64 bit process
I don't know if anyone's actively working on a 64-bit codegen right now, but 32-bit haskell will work just fine as long as you're only talking to 32-bit FFI libraries (and/or being embedded in 32-bit host programs). If you want to interact with 64-bit programs, you will need to use some form of IPC, as 32-bit and 64-bit code cannot coexist in one process.
64-bit windows is supported now. There is binary a distribution of 64-bit GHC.
No 64-bit Haskell Platform yet though.
We are running 64 bit windows 7 with 64 bit office 2010. We have a custom 32 bit OLEDB driver installed but it doesn't show up in the list of data providers when trying to import data into Excel.
I've heard that 64 bit and 32 bit don't go well together and that you need to run 32 bit drivers inside the wow64 emulator but how can we get this to work from within Excel?
Thank you
You are correct that you can't mix 32 and 64 bit dlls in the same process. So your options are:
Run the 32 bit version of Excel (probably the easiest choice). This will work under 64 bit operating systems and can load 32 bit dlls (but not 64 bit ones, obviously).
Use a 64 bit version of your OLE DB driver (possible if you develop it in house, if its 3rd party then bug the vendor).