I'd like to develop a shell extension (context menu handler) compatible with both Windows XP SP2 (32-bit) and Windows 7 64-bit.
Is it possible to run 32-bit shell extensions in 64-bit Windows, or must the shell extension be ported/rebuilt to 64-bit to be used in Windows 7 64-bit?
Are there any disadvantages / known issues in using 32-bit shell extensions in 64-bit operating systems?
32-bit apps run just fine in 64-bit Windows, but I'm not sure about shell extensions, since, if my understanding is correct, shell extensions are in-proc COM servers loaded into Explorer process, which should be a 64-bit process in 64-bit Windows...or is a form of "32-bit emulation" provided for 32-bit shell extensions running in 64-bit OS?
A shell extension is just a DLL, and the rule is that 32-bit applications can only load 32-bit DLLs, and 64-bit applications can only load 64-bit DLLs. There is no way around this.
A 32-bit shell extension may still be useful on a 64-bit system as it means that any 32-bit third-party applications that load shell extensions will work. For example, TortoiseSVN ships with and installs both 32- and 64-bit versions, and so on 64-bit Windows you can still access TortoiseSVN context menus from 32-bit applications (like a third-party file manager).
But Explorer itself is 64-bit native on 64-bit Windows and so you need a 64-bit version of your extension if you want it to work in Explorer.
Shell extensions are COM components. If you install it as an out-of-process server, Windows (DCOM) should take care of all the 32 <-> 64-bit marshalling.
The MIDL compiler will then create the 64-bit stub which loads in process.
You can use a 32-bit explorer, like xplorer² in 64-bit Windows. They can handle 32-bit DLL extensions which may use for as searching content, preview data and those also display in context menu. The built-in explorer is 64-bit, which ignores 32-bit extensions.
Related
I load the odbccp32.dll from System32 and even tried to use from SysWow64. I use SQLConfigDataSource function to configure my System DSN for specified Driver. This function successfully configure drivers which are 32-bit, but does not do the same for 64-bit drivers. Does this dll only works for drivers which are 32-bit? When I ran ODBC Administrator tool (64-bit) I am able to see the 64-bit drivers and add them manually to System DSN, but I cannot do this using this DLL.
Only 64-bit applications can configure a 64-bit datasource using SQLConfigDataSource. If you application is targeting 32-bit Windows, it will modify the 32-bit data sources when calling this function. You need to configure the data source in a different way (from a 64-bit application, from the command line, modify the registry directly, etc.)
I load the odbccp32.dll from System32 and even tried to use from SysWow64. I use SQLConfigDataSource function to configure my System DSN for specified Driver. This function successfully configure drivers which are 32-bit, but does not do the same for 64-bit drivers. Does this dll only works for drivers which are 32-bit? When I ran ODBC Administrator tool (64-bit) I am able to see the 64-bit drivers and add them manually to System DSN, but I cannot do this using this DLL.
Only 64-bit applications can configure a 64-bit datasource using SQLConfigDataSource. If you application is targeting 32-bit Windows, it will modify the 32-bit data sources when calling this function. You need to configure the data source in a different way (from a 64-bit application, from the command line, modify the registry directly, etc.)
I am a self taught software engineer. I am building a desktop application that needs to work on 64 bit windows 7 system.
I am planning to integrate a third party library called FCL C++. In FCL's official documentation page it is stated that it can be built from source on unix or win32 systems.
My question is, if I build a win32 dll of FCl in Windows, would I be able to use it in my win64 application? If not then is there any other ways to go about this?
I am currently developing the software in windows 10, using CMAKE and Qt. Would developing in Linux would be better in this case?
Win32 is a legacy name of the the API set and platform. It applies to both 32 bit and 64 bit Windows. When you build the DLL, you can choose the output to be a it for 32-bit or 64-bit binary in Visual Studio.
While a 64-bit Windows OS can run a 32-bit program (EXE), a 64-bit process EXE can't load a 32-bit DLL. Just build a Win32 DLL for either 32-bit or 64-bit depending on what type of EXE you are building for.
If you are unsure, just build everything (DLL, LIB, EXE) for 32-bit since that runs everywhere.
I have 2 applications that uses global hooks, and its built for Windows 10 (64 bit). One is 32 bit and the other is 64 bit. I am able to compile them into 2 separate exe files that work independently. But since they have the same code, I wish to compile them into one exe file that will cater to both it's 32 bit and 64 bit responsibilities. Can I do that using Visual Studio or other means?
The Windows PE EXE format does not support multiple CPU architectures in a single binary.
The SysInternals tools embed the 64-bit .exe as a resource in the 32-bit executable and extracts and runs that if IsWow64Process is true. If you choose this technique you must also take into account that the recent ARM64 machines are Wow64 but only emulate 32-bit x86 applications.
Note: Windows Server Core can be installed without Wow64 support and you must also distribute the 64-bit binary if you support those systems.
I have Credential manager implemented in VC++ which captures credentials during login process. It works well in XP/Vista/Windows 7 32 bit env. But is not working in 64 bit.
Any idea ?
Thanks in advance for any help
If you want your DLL to be loaded by a 64-bit process, your DLL has to be compiled for 64 bits.
If you want your DLL to be loaded by a 32-bit process, your DLL has to be compiled for 32 bits. This is true on both 64-bit Windows systems and 32-bit Windows systems.
John gave you a useful link, even though John's wording is wrong. An application (exe) which is built for 32 bits will run in 64 bit Windows, but it can only load 32-bit DLLs.
Did you build for a 64-bit platform in Visual Studio?
A Visual C++ application which is build for a 32-bit environment won't work directly in a 64 bit environment. And although applications will work using the WOW64 compatibility layer, DLLs must be 64-bit if they are to be loaded by a 64-bit operating system.
Since that is indeed the case here, you need to build your project for a 64-bit platform (Visual Studio 2005 and later have a 64-bit compiler).
See the link http://msdn.microsoft.com/en-us/library/ms185328.aspx for more details.