I have 64-bit Linux OS, and would like to ask if I can use the following combinations:
64-bit application (java) using 32-bit shared object (C++) on 64 bit OS
32-bit application (java) using 32-bit shared object (C++) on 64 bit OS
64-bit application (java) using 64-bit shared object (C++) on 64 bit OS
Thank you,
Ran
You cannot mix 32 and 64 bit code in the same process. So option 1 is out but the other two are fine.
Related
A simple question (maybe) can a daemon coded and compiled as 32-bit be run on a 64-bit linux distro? I haven't seen the info anywhere where it can't be.
Yes, you can run 32-bit processes on a 64-bit Linux system. There's nothing special about daemons.
It depends both on architecture support (i.e. executing both 64-bit and 32-bit code) and on specific linux support (providing system calls to both 64-bit and 32-bit code). For amd64 linux, both are true. See, for example:
https://help.ubuntu.com/community/MultiArch
Similarly, ARMv8 supports both 32-bit and 64-bit modes:
https://en.wikipedia.org/wiki/ARMv8#ARMv8_and_64-bit
http://www.arm.com/files/downloads/ARMv8_Architecture.pdf
As long as the shared libraries are available in 32-bit, then a 32-bit daemon will run on a 64-bit Linux.
Can a COM 32 bit out of process server be used for GDI drawing on a 64 bit process?
Yes it can. For GDI object HANDLEs and window HANDLES, it's guaranteed that only the low 32-bits will be used in 64-bit mode, so it should be safe to pass these between 32-bit and 64-bit. Of course, the COM server must be out of process.
Quoting from this page
On 64-bit Windows, an out-of-process 32-bit COM server can communicate with a 64-bit client, and an out-of-process 64-bit COM server can communicate with a 32-bit client. Therefore, if you have a 32-bit DLL that is not COM-aware, you can wrap it in an out-of-process COM server and use COM to marshal calls to and from a 64-bit process.
Similarly, from this page
64-bit versions of Windows use 32-bit handles for interoperability. When sharing a handle between 32-bit and 64-bit applications, only the lower 32 bits are significant, so it is safe to truncate the handle (when passing it from 64-bit to 32-bit) or sign-extend the handle (when passing it from 32-bit to 64-bit). Handles that can be shared include handles to user objects such as windows (HWND), handles to GDI objects such as pens and brushes (HBRUSH and HPEN), and handles to named objects such as mutexes, semaphores, and file handles.
I am using 32 bit openSUSE OS, and I am using a cross compiler to build 64 bit application( it does not support building 32 apps) as our software will be deployed on a machine which is 64 bit OS. As testing on target is not always possible, is there anyway to run this applications on my 32 bit OS.
Use something like QEMU that can emulate a 64-bit processor.
Short answer: No, there is no way.
Longer answer: If you have a 64-bit CPU it may be possible to run a 64-bit virtual machine, even though your host OS is 32-bit. I'm not 100% sure about that, though, you'd have to try it.
This is only a half-way programming question. First of all I have a PCI-Express card and 32/64 bit drivers. The target operating system has to be a Windows 64 bit system. I read that under Vista64 all drivers have to be certified 64 bit drivers. Is this a general restriction under 64 bit operating systems and does this also apply to "XP 64" or any Linux system?
So for simplicity let's say I use a 64 bit driver for my PCIe card under Vista64 and have a bunch of 64 bit DLLs to use the cards functionality. On the other side there's a large, legacy 32 bit exe program which needs to use the PCIe device. Converting the program to 64 bit would be a really huge effort.
So what can be done to bring that 32 bit program and the 64 bit driver together? I read that mixing 32/64 bit binaries and DLLs is not possible at all but this is hard to believe for me. I'm sure you can print out a document under Vista64 from within a 32 bit app and Windows will somehow wrap this around to a 64 bit printer driver.
64-bit certification is only required under Vista; there is no certifying authority for non-Windows platforms, and I don't believe that XP or Windows Server checks for certification (not sure though, and it may depend on which service pack you're on).
If you're using the driver via the Windows API, then there shouldn't be any problem; Windows will do the 32<->64-bit translations in the kernel. If you're trying to load the driver inside your own process, that probably won't be possible. As Dirk says you'll have to run it inside its own process and communicate through a COM server. I'm not sure what hoops you'll have to jump through if you have to run your driver in a higher-privilege execution level and want to make calls to it from user mode.
Hopefully your 64-bit DLLs offer a 32-bit API, or Windows offers a standard driver interface (if it's a common I/O device like a display or network card).
Does your 32-bit application directly call the driver? (I'm guessing a simulator for the driver!)
The only way to communicate between 32-bit and 64-bit dlls is to write a COM server that manages the communication (read: wrap EITHER the applications calls OR the 64-bit driver responses) in between.
One thing that came back to bite me: When I first wrote this COM server (yes, I too had to bear many sleepless nights before I came to know of this trick) I only built the 32-bit version of the (auto-generated) proxy/stub dll. Another bout of sleepless nights ensued before I came to know of the solution: Build the proxy/stub dll for both 32-bit and 64-bit. The 32-bit side deals with the 32-bit side (in your case the application) and the 64-bit with the 64-bit side (the driver). COM manages how the differnt versions of the proxy/stub talk to each other. And oh, do get the server registered on your system. Easy, right?
I think the whole point of a driver is to abstract away the actually workings of the hardware and present a common interface to the software. In this case, the PCIe driver needs to be 64-bit so that it can act as a go-between for Windows and the hardware, but I would think that a 32-bit application could then access the device without any troubles at all.
What's meant by that incompatibility you read about is that 32 and 64-bit assemblies can't be part of the same application - an application has to target either one or the other, though 32-bit application will generally run fine on Windows x64 using WoW64, which just acts as a translator.
Are you currently experiencing problems, or are you just asking hypothetically?
I have just installed a build server with a 64 bit windows server 2008 for continuous integration.
The reason I choose a 64 bit server was to have more than ~3Gb of RAM. I had hopes that this machine would provide blazing fast builds.
Unfortunately, the result are lacking greatly to say the least. My desktop provides faster builds than this server equipped with a Xeon quad core, 15k RPM SAS and 8 Gigs of RAM.
We use Visual C++ 2005 to compile our 32 bit application with Cygwin.
Could the WOW64 emulator be the bottleneck that is slowing down the build process?
Any pointers, comments would be greatly appreciated.
Regards,
We use Visual C++ 2005 to compile our
32 bit application with Cygwin.
I think that's the problem. I like Cygwin a lot, but it is really slow when it comes to file I/O. It helps a bit to deactivate the NTFS filesystem feature to keep track of the last file-access.
To get a better speed boost port your build-script / makefile to use the native command shell if pssible and only call cygwin-tools if there is really no replacement available.
If you use the gcc compiler try the mingw version. That one is a lot faster.
WOW64 is not an emulator on x64. The processor natively executes 32-bit x86 code. At the bottom of the user-mode stack, under kernel32 et al, are DLLs which map system calls to the 64-bit call interface.
See WOW64 Implementation Details.