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.)
Related
The title may not be the most descriptive at first:
I have a program that utilizes a call to "Wow64EnableWow64FsRedirection" function which is required when the software runs on a Windows 7 and Windows 10 64-bit platform.
However, the same application must also be able to run on a 32-bit Windows XP platform. The problem is, kernel32.dll for the Windows XP platform doesn't have the entry point for the Wow64 Redirect function and my application fails to execute at all.
Within the application, I have a check for the OS version and I handle the method calls separately based on the version; in other words, if the application is running on the 32-bit system I never attempt to call the WoW64 Redirect function.
I am unable to compile a platform-specific version for the 32-bit and 64-bit OSes.
Is there anything I can do to support the application on both platforms?
Try hModule = LoadLibrary("kernel32.dll") and func = GetProcAddress(hModule, "Wow64DisableWow64FsRedirection") if header file is not available for specific platforms.
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've installed wmware player on my pc (I have windows vista 32 bit). The virtual machine that I need to use is has linux. I've set the shared folder and I go to it with my virtual machine.
The problem is that linux doesn't compile my cpp file. I write:
g++ helloworld.cpp -o helloworld
and nothing happen.
I don't know why. The only error given is when I start the virtual machine, it says:
Binary translation is incompatible with long mode on this platform. Long mode will
be disabled in this virtual environment. Applications requiring long mode will not
function properly as a result. See http://vmware.com/info?id=152 for more details.
You are trying to run a 64-bit VM on a machine that doesn't support 64-bit. Which makes sense, since 32-bit Windows isn't a suitable host for a 64-bit VM - although technically it would be possible to create such a system, it's full of messy situations that are much easier to deal with if the host system has at least as many bits as the VM.
You either need to get a VM that is a 32-bit install, or upgrade your windows to 64-bit (assuming you have a 64-bit capable processor, of course!)
I am wishing to debug 32 bit nacl exe on mac platform. I couldnt debug it out since on mac platform i couldnt find a 32bit nacl-gdb. Has anyone successfully done it?
GDB for Native Client was released in Pepper 23, so first check that you're using the Pepper 23 version of the NaCl SDK or newer. (To download any new versions of the SDK, issue ./naclsdk update from your nacl_sdk directory. When it's done, you should see a pepper_23 directory (or newer). Use the tools in that directory.)
In the SDK the GDB binaries are in these locations (example based on Pepper 23):
nacl_sdk/pepper_23/toolchain/mac_x86_glibc/bin/i686-nacl-gdb
nacl_sdk/pepper_23/toolchain/mac_x86_glibc/bin/x86_64-nacl-gdb
nacl_sdk/pepper_23/toolchain/mac_x86_newlib/bin/i686-nacl-gdb
nacl_sdk/pepper_23/toolchain/mac_x86_newlib/bin/x86_64-nacl-gdb
The two i686-nacl-gdb are in fact just symbolic links to the two x86_64-nacl-gdb. The x86_64-nacl-gdb binaries will allow you to debug both 32-bit and 64-bit x86 NaCl targets. On the Mac, though, Chrome is always 32-bit and will always run the 32-bit .nexe, even if your OS or machine is 64-bit.
Both the newlib and the glibc toolchain contains a complete set of tools; this is why you have two x86_64-nacl-gdb binaries. Currently, these two do not differ, but for your own sanity it's probably easiest to use the GDB in the same directory as the tools used for your build.
There is some additional guidance at https://developers.google.com/native-client/devguide/devcycle/debugging#gdb. The all-important thing is to pass the flag --enable-nacl-debug to Chrome or activate it under about:flags in Chrome. This will cause Chrome to wait for the debugger to connect before executing Native Client content.
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.