I am going to make a device driver for 64 bit platform (i.e. Win7) and I would also like to expose device APIs in DLLs which could be distributed to users writing their applications.
The question is, how could I build such DLLs both for 32bit and 64bit applications?
The problem here is actually only about 32 bit one.
could I just write DLL and compile it in 32 as well as 64bit?
Or do I really need some IPC to wrap 64bit dll so that 32bit application can indirectly invoke device driver?
The translation between 32 and 64 bits should take place at the existing user-kernel layer. Your DLLs will use IOCTL commands to communicate with the driver, and the 32-bit DLL will have to use 64-bit IOCTL structures when the driver is 64-bit.
There's no need to add a second IPC layer.
Related
Can functions in a 32 bit dll be called from a 64 bit dll using the LoadLibrary function?
Technically, it happens all the time when 32-bit processes are running on a 64-bit Windows. There's 64-bit ntdll.dll, which loads Wow64 layer DLLs and 32-bit ntdll.dll.
So it is hypothetically possible. If OS does this, you also should be able to do this.
In practice this may be not feasible without OS internals knowledge. Use a 32-bit process for that 32-bit DLL, and some sort of inter-process communication.
I have a 32-bit dll that I have gotten from a third party. They have no 64 bit version. I wish to load this dll into 64 bit python. To do this, I need a 64 bit dll. Is there a tool to convert a 32 bit dll to a 64 bit dll or is this impossible? If it impossible then I must use 32 bit python I guess.
Only the vendor can do this, unless you get access to the DLL's source code. It must be recompiled for 64 bit.
I guess you'll have to use 32-bit python...
32 and 64bit DLLS have different ABIs and calling conventions. You just can't load a 32bit DLL into a 64bit process or the other way around.
As mentioned in the comments, you have to recompile from source.
You can't create a 64-bit DLL from 32-bit one without the source code.
But you can create an adapter as a native 32-bit application that loads the 32-bit DLL and provides access to it's functions via some kind of inter-process communications (e.g. named pipes)
Of course, that's may be senseless in some cases and you may prefer to use 32-bit python.
So it depends.
Before I ask my question, here's some background information so that you might have a better understanding of what I am trying to accomplish. I have searched around and found similar questions but none that are specifically what I am asking.
I am trying to port over a modified 32-bit PLX Pci9056 device driver to 64-bit. I also have a few User apps that utilize the driver. PLX provides a complete SDK, including the PLX API in a dll, driver source code, and tools to create and debug user apps. It uses the Windows DDK build environment to build the drivers. The following is how they all interact:
User app --> PLX API --> PLX Pci 9056 driver --> PLX chip
The 32-bit driver has been tested on Windows 7 32-bit and works properly. I believe I should be able to simply rebuild the driver in the 64-bit Windows DDK build environment (Of course after handling any pointer casting. Please correct me if I am wrong.) At this point the driver should run properly on a 64-bit Windows 7 machine.
I understand that usually 32-bit apps will run fine on a 64 bit machine, but in this case the User app is using the PLX API which was initially built only to support 32-bit. Will my User app still work in a 64-bit OS without updating it, or will I run into issues?
The PLX PCI SDK (now Broadcom PCI/PCIe SDK) has supported both 32b/64b drivers with the same source code for many years now. Special macros are used when required, etc. In Windows, your 32-bit app will work fine due to WOW layer. The PLX IOCTL structures always store pointers in 64-bit fields to ensure the structure does not vary if you build a 32-bit app. The SDK also provides 64-bit build of the API library, so you can also build your app as native 64-bit. The same app level source code, for the most part, should work in both Windows & Linux. The samples provided in the SDK are all identical source for both Win/Linux.
Here's my scenario: the company I work has applications deployed to a 32bit Windows 2003 server and they want to move to a Windows 2008 Server that is 64 bit. It has been noted that these 32bit custom developed applications will not run on a 64 bit machine. I was not aware of this.
I have always thought that 32bit software CAN run on a 64 bit OS and just use the 32bit address. A 64 bit software on the other cannot run on a 32 bit OS. On a 64 bit, one does have to create 64 bit software but can and still also create software that is designed for 32 bit machines.
Can someone please elaborate on this?
In general, 32-bit applications will run under a 64-bit Windows (This is technically called WOW64 - Windows On Windows). This applies to all 64-bit Windows version to date, including Server.
WOW64 processes are marked in task manager with *32, For example: chrome.exe *32. Sysinternals' Process Explorer has a separate column for this: Image Type (64 vs 32-bit).
If the app has components hosted inside other processes, then those components must accommodate processes they're hosted in. Examples:
Shell extensions are hosted in explorer.exe, whose bitness matches the OS' bitness. Therefore, you should compile the extension in both 32- and 64-bit, and register the one matching the OS' bitness during installation.
Kernel-mode driver are hosted in the Kernel, whose bitness also matches the OS' bitness. So, the above applies.
Winsock LSPs (Layered Service Providers) are hosted in all processes, both 64-bit (native) and 32-bit (WOW64). Therefore, you should compile the LSP in both 32- and 64-bit, and register both in their respective catalogs during installation.
There are also considerations regarding file redirection (System32 / SysWOW64 / SysNative) and registry redirection (Wow6432Node), which I will not go into.
In general, 32-bit applications will run under a 64-bit OS. If your app relies on a 32-bit kernel driver (say, a VPN client), then you will have to port to 64-bit.
I have been checking out some info about 64-bit driver development; I found that drivers have to be re-written in order to be compatible with a 64 bit OS. However, I was wondering if this also holds true for User-mode drivers.
The reason that I am asking this is because my understanding is that user mode drivers pass through the Win32 API, so in theory they should be able to run on top of WOW32.
Is this true?
Thanks,
Jaime
User mode drivers can be either 32 or 64 bit, but note the following:
User-mode drivers must be 64 bit for print, scan, and camera.
Legacy APIs (that are specific to Windows NT® 4.0) are not allowed.
http://www.microsoft.com/whdc/driver/kernel/64bit_chklist.mspx