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.
Related
I've written a 64-bit kernel module that works fine for 64-bit apps, but crashes for 32-bit apps. I need to figure out how how to make the module detect if a client is a 32-bit app, and, if so manage the conversion between the 32-bit struct and 64-bit struct in my module so the system calls work.
When the module is used by a 32-bit app, the recvmsg() function crashes if the msg has cmsghdrs, because the cmsghdr struct has different size in a 32-bit app.
My module doesn't provide a 32-bit compatibility layer explicitly, even though the kernel is configured to support 32-bit applications in compatibility mode.
The module implements a new protocol, defines struct proto_ops, but I don't see compat_recv in the proto ops.
The module acts as a proxy between the client and another application (64-bit), wherein it fetches responses to client requests from the backend using netlink messages as opposed to making __sys_socket*() calls.
compat_recv is not needed in proto_ops. 32 bit userspace call to recvmsg in 64 bit kernel should go through compat_sys_recvmsg, which set MSG_CMSG_COMPAT flag. That flag makes ___sys_recvmsg() do necessary conversions before doing callback to your proto_ops and before returning to userspace.
References (in kernel tree):
Compatibility System Calls (Generic) chapter of: /Documentation/adding-syscalls.txt
/net/compat.c
/net/socket.c
Regards,
Mateusz.
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.
I have two Linux C/C++ programs that communicate using shared memory (shm_open, mmap, etc.) with mutex (pthread_mutex_*) and conditional variables (pthread_cond_*) in that shared memory. If both programs are compiled (using gcc) and run in 32-bit Linux (RHEL) machines, they communicate successfully. If, on the other hand, one process is compiled in 64-bit machine, the other is still compiled in 32-bit machine (due to legacy code), and both are run in a 64-bit machine, pthread_cond_wait in the 32-bit process waits forever even after the 64-bit process does pthread_cond_signal. What am I missing here. Or is it impossible to use conditional variables and mutex between a 32-bit and a 64-bit application?
Is there some kind of secret to hooking both 64bit & 32bit process on a 64bit system?
In an application that I'm currently writing I need to be able to hook 64bit processes. Hooking 32bit processes works just fine on 64 & 32bit systems but, no messages are received when trying to hook 64bit applications.
Before anyone tells me that I shouldn't be doing something like this let me explain that this is a very necessary thing for me to do.. Without setting global system hooks my application would be useless/pointless.
This application is written in C#/WPF but, using a C++ dll to do the actual hooking. I've tried compiling the dll for 64bit systems although it still isn't doing what it's supposed to do. When compiled for and running on 32bit systems it works exactly as it should.
*Edit:: I am talking about hooking window messages - WH_CBT & WH_SHELL messages
In order to hook both 32-bit and 64-bit processes you need to make sure that:
You have 32-bit DLL to hook 32-bit processes and 64-bit DLL to hook 64-bit processes
SetWindowsHookEx() is invoked from 32-bit code to hook 32-bit processes and from 64-bit code to hook 64-bit processes.
The latter basically means that you have to create both 32-bit and 64-bit executable that both call SetWindowsHookEx(), providing 32-bit and 64-bit DLL respectively as an hMod parameter.
If you application is 32-bit, you will have to spawn 64-bit process that will call SetWindowsHookEx() and probably do nothing else until you unhook. Note that Windows will automatically unset hook when/if this process exits/terminates, so it has to remain alive all the time you need the hooks, probably, the whole lifetime you your application - in this case you can make your 64-bit process WaitForSingleObject() until your main application process exits/terminates and unhook and exit after WaitForSingleObject() completes.
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?