My Windows driver has a .sys file and a .dll (which I'm guessing is the programming interface to the driver?). Anyway, I need to compile the driver to run on Windows 7 64-bit. I have downloaded the DDK and am able to compile everything, but my application still won't work with the new driver.
If the application is a 32-bit application, does the driver DLL need to be compiled as a 32-bit DLL, and the .sys file a 64-bit file? Or do the SYS and DLL files both need to be 64-bit?
On a 64-bit system:
driver should always be 64-bit
an application can be either 32-bit or 64-bit
a DLL used by an application (that is, a DLL an application links with) should be 32-bit for a 32-bit application and 64-bit for a 64-bit application
If a DLL is engineered to communicate with a device driver, it should be carefully written to use the same data type definitions as the driver. It's best if both the driver and the DLL avoid using data types that are defined differently for 32-bit and 64-bit (e.g. size_t) in structures that are used for communicating with each other.
However, this does not mean that the DLL should be built as a 64-bit DLL (i.e. using the x86-64 instruction set). It should use whatever instruction set the application linking to it will be using.
The DLL has to be 64 bit too.
Will try to find a reference.
Got one
Since a 64-bit program can't call a 32-bit Dynamic Link Library (DLL)
This is why no 32 bit driver works on 64 bit and why they are always separate downloads
Related
Just when I thought I understood Microsoft's confusing naming with regard to WIN32 and WIN64 registry and folders I read this article (Using 32-bit or 64-bit ActiveX Components on x64 Windows) and find myself still a bit confused on how to properly register 32 bit and 64 bit OCX controls on the same WIN64 computer. From the article it says that on a WIN64 system the default regsvr32 is for registering 64 bit OCX controls and to register 32 bit versions of the OCX control I should use C:\windows\syswow64\regsvr32.exe. The thing is I've been registering my WIN32 OCX control using the default regsvr32.exe (in C:\windows\system32) and it seems to have been working fine when I run my 32 bit app which uses the 32 bit OCX. I have the following questions:
Q1 How has registering WIN32 OCX with default regsvr32 been working given what I read in the article.
Q2 I want to register both the WIN32 and WIN64 versions of the OCX control on a single computer. From the article it seems like I should use the two different versions of regsvr32.exe from syswow64 and system32 for WIN32 and WIN64 versions respectively. Is this correct?
Q3 Can the GUID for the OCX be the same for both the WIN32 and WIN64 versions? I'm thinking it can be the same since a different portion of the registry is used to register for each of these architectures. Correct?
Q4 Where do I look in the registry to confirm that both 64 and 32 bit versions of the OCX have been registered to confirm that registering the 2nd one didn't overwrite the first one?
Per suggestion in comment by Andrew here is my comments as an answer.
A1 & A2 Well since no one has replied to this I'll add what I've learned since posting. It seems the article I referenced is misleading in describing how to run 32 and 64 bit regsvr32.exe. From my own testing it seems that the default 64 bit regsvr32.exe can be used to register both 32bit and 64bit OCX controls. It seems regsvr32 (the 64 bit version at least) looks at the target OCX or DLL file and determines if it is 32 or 64 bit and installs it in the appropriate registry. There doesn't seem to be any need to use the 32 bit version of regsvr32 on 64bit windows.
A3 Yes both 64 and 32 bit versions can be registered which use the same GUID.
A4 For 32bit OCX in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID area of the registry and for 64 bit its in
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID
I have been playing with the {$IMAGEBASE} directive in Delphi but I can see that I can only put a value lower than $FFFFFFFF (32-bit).
I'm compiling as x64 and I need to set an image base bigger than 32-bit but Delphi ignores the higher 32-bit DWORD in my 64-bit ImageBase.
Has anyone managed to set a value higher than $FFFFFFFF as ImageBase for Delphi?
I need it because I need to test my application in "high" ImageBase (due to some hook tests, etc)
Thanks!
The Delphi linker does not support large image base, although there are new PE optional headers that allow large image base values to be specified.
So I think that until Embarcadero introduce any such functionality, you would need to use a third party tool to rebase the executable file after it has been built. For instance EDITBIN with the /REBASE option from the MS toolchain.
I took a simple 64 bit VCL program, built with XE7, and rebased it like this:
editbin /rebase:base=0xffffff0000 Project1.exe
I confirmed using Process Hacker that the image base was indeed as specified.
WoW64 makes it possible to run 32 bit applications on 64 bit Windows. If the conversion from 32 bit instructions to 64 bit instructions can be made at runtime, why can't we convert the executable itself to 64 bit?
That is because WoW64 doesn't convert 32bit instructions to 64bit.
Your 32bit executable is run in 32 bit mode by switching your CPU to compatibility mode. There are some conversions inlined for API/driver calls, but most of the code is not converted.
*This is only true for the x86-64 architecture. The IA-64 architecture doesn't support this, so WoW actually converts your code to 64bit, but with a significant performance penalty.
*.NET code compiled to MSIL is JITted to the correct architecture. Probably the same happens with other architectures with an Intermediate Language like Java, but i'm no expert there.
Yes, Wow64 lets you run 32-bit programs but they still run in 32-bit mode - no code alterations are performed. Such automatic translation would be impossible for a native application.
The number one problem is that native applications have no annotations explaining what the code does. Just one example: the compiler compiles pointer manipulation code and uses a 32-bit register to hold this pointer value on 32-bit platform and emits bare machine code for that - the runtime will have no idea that this was a pointer and it needs to be placed in 64-bit register on 64-bit platform.
Managed environments such as Java and .NET can deal with it - the compiler emits "intermediate language" code with necessary annotations that is then compiled for the target platform before the code is first run.
We have an Delphi application that has a built in com object. When compiled in Delphi XE3 (Windows 8) we can't reference it from Visual Studio C#. However, an older version that was compiled in Delphi 2010 (Windows 7) works as expected.
The com object registers without errors and i can access it by using VBA script in Excel. Has anyone come accross something like this?
The most likely explanation is a bitness mismatch. I'm assuming that the COM server is 32 bit since you have been compiling it in Delphi 2010.
Suppose that your COM server is an in-proc server. Then I guess that your failing host is a 64 bit application. If so then you need to make the bitness match. Most probably by switching your host to be 32 bit by targeting x86.
If the COM server is out-of-proc then the issue is with registration rather than executable bitness matching. It will be registered in the 32 bit registry view, but your 64 bit host is looking in the 64 bit view. This would explain why your 32 bit Excel VBA code can find it. You need to register the server in both 32 and 64 bit registry views. Or switch the host to 32 bit.
We have a windows service that uses dlls produced from a bunch of different .NET projects. One of those projects has a dependency on a dll that was compiled on 32 bit machine.
We have just moved the windows service to a 64 bit machine. By default .NET projects try to run as 64 bit assembly (because they are being run on a 64 bit machine). However, I can force individual projects to run as 32 bit assembly by specifying the Platform Target as 'x86' rather than 'Any CPU'.
My question is: do all the .NET projects need to be forced to run as a 32 bit assembly? Can 32 bit assembly and 64 bit assemblies be run together?
I think as long as you're not using native modules or anything, you're probably fine, though you can still have bugs in your code if you assume the size of a pointer, etc., anywhere.
"If you have 100% type safe managed code then you really can just copy it to the 64-bit platform and run it successfully under the 64-bit CLR."
http://www.hanselman.com/blog/CommentView.aspx?guid=4099df2d-ef01-4f70-a7f7-829eabc36afc
If there is no unsafe code and/or references on the unmanaged dlls you can safely compile everything with the target Any CPU.
The result of compilation is then CPU agnostic - the resulting IL is JIT - compiled by the CLR on the target machine, whatever the machine will be.
If the box is a 64 bit box it will be compiled to the by the 64 bit CLR to the 64 bit instruction set and will be happily run in the native 64 bit mode