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.
Related
I am compiling a dll in visual studio 2017 c++.
SDK: 10.0.17134.0
this project uses a template, that automatically creates 2 dll, one for 32 bit and one for 64 bit. I do have two machines that run the same software but have different hardware and OS.
First machine has a intel i7 and runs windows embedded standard 64 bit
the second machine has a intel atom and runs windows embedded standard 32 bit
On the 64 bit machine, both dll work. (32 bit and 64 bit), on the atom the 32 bit does not work tough. I do not have any error messages, the only thing i get from the software is that it is not compatible without any additional clues. The software is the same on both systems so I assume that the problem is related to the OS or the processor.
the software I am developing for is a vision system by omron so it is nothing that is available online or that can be shared here.
What could be the cause for this? If you need additional information just ask.
Generally, in order for an executable file (either an .EXE program or a .DLL support module) built using the MSVC C/C++ compiler in Visual Studio 2015 or later, to work on a target PC, you need to have the latest VC++ Redistributable run-time libraries installed on that PC.
See also this discussion on Stack Overflow.
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'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.
Can it cause any problem if I use 32 bit library on a 64 bit system?
What could be the incompatibilities?
I know this question is too vague. An example :
I tried to setup FreeGlut 32bit library with VS2010 on windows 7 64bit. There were a lot of issues at first.So, I was looking for 64bit of FreeGLUT, thinking 32bit FreeGlut might conflict with 64 bit windows. But later on I managed to run my 32bit FreeGlut with my 64bit windows without any problem.
Question is, if there are any thing in the program, that we should look into while using those libraries which doesn't match with the system. (32bit library on 64 bit OS)
64 bit Windows is fully capable of running 32 bit applications. In fact, the default configuration for Visual C++ is to build an x86 application regardless of the operating system it is running on.
There are some gotchas you have to be aware of when running a 32bit app on 64bit Windows. For instance, there's registry redirection (to avoid it you pass KEY_WOW64_64KEY to e.g. RegOpenKeyEx). There's filesystem redirection, too. These are important things to have in mind when you are reading system configuration values, for example.
Also, be aware that you can't mix 32 and 64 bitness in the same process. Your 32bit app can't use 64bit DLLs or static libraries.
Visual studio can compile for 32 bit or 64 bit based on the project setting.
Probably, Question you mean to ask is about Linking 32-bit library to 64-bit program
The answer is:
You can't directly link to 32bit code inside of a 64bit program.
The only option is to compile a 32bit (standalone) program that can run on your 64bit platform (using ia32), and then use inter-process communication to communicate to it from your 64bit program.
It's not about the operating system- Windows doesn't care if your code is 32bit or 64bit. It matters that your process is the same bitness as all libraries it cares to load- and they must all be the same bitness.
You might be interested in this link explaining common compiler errors when porting to 64-bit. It might help you solve your problem.
To try to answer your question more directly, there are things that might make 32 bit libraries break in a 64 bit environment, but that's too much information to share in a SO answer.
This link is the MSDN index related to development for 64 bit systems and might interest you as well.
Your question could be about how to develop specifically code that will run natively on 64-bit versus 32-bit hardware. There is info on that here. In particular you would have to follow the instructions here to enable 64-bit build tools.
If you are building 64-bit binaries, you will need to link with 64-bit libraries. Note that 32-bit binaries should run just fine on 64-bit Windows, so you may not need to go to this trouble.
Is there any way to build a VC++ project so that the dll/exe created by it will work as a 32 bit application on a 32 bit Windows OS and as a 64 bit application on a 64 bit Windows OS (not in WOW64).
I know that is possible for C# applications using the /ANYCPU option.
The CLR has special loader support for the /ANYCPU option.
If you really want to do this for native, the best way to do it is to:
Build your binary for both 32- and 64-bit
As part of building the 32-bit binary, include the 64-bit binary as a resource
On 32-bit machines, just run the 32-bit binary
On 64-bit machines, when the 32-bit binary runs, unpack the 64-bit binary resource, write it to disk, and run it from there
This is how the Sysinternals tools work (download Process Explorer onto a 64-bit machine and run it: you'll see that it writes procexp64.exe to disk and then runs it from there). It's a hack, but it works.
Not AFAIK - the problem is that
you'll need separate code; this works for C# because you're generating .NET IL which gets converted to native code on the target system
the windows PE format only has one image header and no way to chain through to another header later on to put both sets of code in the same library.
The best you could do for an .EXE was to ship a 32-bit .exe that checks if it's running WOW64 then spawns the 64-bit version instead. I can't think of an equivalent trick for libraries, though - it has to match the bits of the host process to load in the first place.