In my application I need to check windows version. I'm using Version Helper functions in Visual Studio 2013 (v120) platform toolset. But then the program does not work in Windows XP. error is:
'xxx.exe' is not a valid win32 application
So I changed platform toolset to Visual Studio 2013 - Windows XP (v120_xp). But in this case application will not compile.
The error is:
error C1083: Cannot open include file: 'VersionHelpers.h': No such file or directory
What can I do? Can I use old GetVersionEx function? MSDN says:
GetVersionEx may be altered or unavailable for releases after Windows 8.1. Instead, use the Version Helper APIs
But may be I should use it for now!
I've managed to solve it using Remmy Lebeau's comment.
I copied VersionHelpers.h from C:\Program Files (x86)\Windows Kits\8.1\Include\um and winapifamily.h and sdkddkver.h from C:\Program Files (x86)\Windows Kits\8.1\Include\shared into my project and changed some includes in them.
Now it compiles with Windows XP toolset.
I've tested it and it's working as expected in all versions of windows.
How about this: try to link the functions manually with GetProcAddress to see what is available, If the new API is not, then the old must be, so you can use the one you managed to link without errors.
I am assuming you are building 32bit or 64bit and the OS in both cases is compatible.
EDIT:
GetVersionEx(), here is exported from kerner32.dll in XP, so you can try to link it using
GetProcAddress() here also has a suggestion by Microsft using "GetNativeSystemInfo".
The new API function
IsWindowsXPOrGreater() // also exported from kernel32.dll and ntdll.dll
can also be linked the same way using GetProcAddress(). This function will return an error if the function you are trying to link is not found, so you will know which one you have available. Then you call the available one and get the version info you need.
You only need to define the function prototypes yourself instead of using the headers, then define two function pointers, one for each, then assign them a NULL value initially until you try to link the functions. Then one pointer (or both) will end up with a value, and you can use the latest one available to call the linked API.
Related
I had to switch to Office 64 bit (2019, Professional Plus). I have a large number of VBA scripts and most of them make calls to an old 32 bit dll written in plain C language and compiled with the very old Developer Studio 97. I managed to recompile it with Visual Studio 2019 as a C++ dll at 64 bits and I faced 2 problems: the function MessageBox (and MessageBoxA) is flagged as "undefined". Workaround: I temporarily replaced them with OutputDebugStringA and the DLL compiles fine.
Calling the function from VBA, it fails to load. Thanks to ProcessorMonitor I found my dll tried to load VCRUNTIME140D.dll and UCRBASED.dll. I downloaded them from the internet and I discovered I must place them in C:\Program Files\Microsoft Office\root\Office16. But that was not enough! VCRUNTIME140D.dll must be placed in C:\WINDOWS\SYSTEM32 too!
At that point, my DLL works fine as 64 bit dll.
Next surprise was that, after a reboot, it once again failed to load due to missing VCRUNTIME140_APP.dll (please note no "D" after "140")! Downloaded and placed in C:\Program Files\Microsoft Office\root\Office16, the DLL works fine as expected.
I tried to compile it as "static" ('Code Generation' -> 'runtime library' -> 'multithreaded' instead 'multithreaded dll') but I got the error:
MSB8024 Using static version of the C++ runtime library is not supported.
Somewhere I read that VCRUNTIME140 is related to Visual Studio 2014... strange, but may be I miss some .obj from that version too in order to statically link? Why do I need elements from an older system?
Back to the MessageBox problem, I tried a simple c++ 64 bit console application and the exact same function is accepted and works as expected, so I guessed was some #ifdef in the header files that excludes the declaration in a dll. Moved the MessageBox declarations in my header file, the compilation is successful, but (as I could guess) a linker "unresolved external" for MessageBox shows up.
At this points, my questions are:
-Is it possible to create a 64 bit static .dll?
-Is it normal I have to download the above 3 dll's from the web and copy them in some directories?
-It it possible to use the plain MessageBox (handle, text, caption, buttons) in a 64 bit dll?
Thanks.
Finally, thanks to rustyx's intuition, I discovered I was using a "Solution" suitable for "app" development. (The string _APP inside the called dll name indicated just that!) I managed to switch to "Desktop" solution, and now the dll's loaded are without the _APP suffix. The MessageBox function works fine, without the need of any particular settings in libraries.
VCRUNTIME140D.DLL (debug version) and VCRUNTIME140.DLL (release version) are present in my installation installed while they are part of Visual Studio 2019 (as well as 2015 and 2017).
Finally, it is now possible to generate a static dll in this case, VCRUNTIME140.DLL (and many more) is not loaded at runtime but the same code is statically linked. Dumpbin shows it.
Dynamic linking:
USER32.dll
VCRUNTIME140.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
KERNEL32.dll
Static linking:
USER32.dll
KERNEL32.dll
All problems solved!
I am dynamically loading (server) jvm.dll into my 64-bit Visual Studio 2013 C++ application using LoadLibrary(), in order to execute native Java code using JNI.
In the VS debugger, I am getting a number of access violations as the dll is being loaded (yet things seem to work if I 'continue' after these); and then a hard crash when some JNI calls are being invoked. I have tried jvm.dll's from Java 1.7 and Java 1.8, with the same issues.
I suspect the issue to be runtime library incompatibility. Dependency walker indicates that even the latest jvm.dll depends on msvcr100.dll (from Visual Studio 2010). I have heard dire warnings of the consequences of using incompatible runtime versions; and have seen the results first hand in other instances.
Has anyone else run into this problem? Is there any version of jvm.dll available that is compiled against Visual Studio 2013?
Thanks,
Dan
Just recently (Feb 2015) I compiled a JNI application which invokes the JVM to run a Java program. I used the most recent JRE version (1.8.0_31) and Visual Studio 2013. I am also loading the jvm.dll at runtime. Take a look at this post if you want to see how I setup my JNI calls.
So it is possible...
Make sure that the JRE containing jvm.dll is built for the same architecture (32bit or 64bit) as your Visual Studio project. If you are using 64bit, you may need to add the x64 as your configuration. To do this go to:
Solution --> Properties --> Configuration Properties
Also make sure your includes/libraries are correct.
For my project, I needed to include the following:
C:\Program Files\Java\jdk1.8.0_31\include
C:\Program Files\Java\jdk1.8.0_25\include\win32
Also, I needed to include jvm.lib which is located at:
C:\Program Files\Java\jdk1.8.0_31\lib
Make sure you also add the jvm.lib to your linker input. Alternatively you can use the preprocessor:
#pragma comment(lib, "jvm.lib")
Hopefully, this should help get your project configured right. If you are still having errors, I would recommend uninstalling Java completely, and re-installing after. Perhaps the same with Visual Studio 2013 as well...
I'm new in Visual Studio and I tried to compile a code which uses the VirtualProtect function. Compilation failed, I was expecting a linking issue first but after further investigation, even the function's constants weren't initialized, so the problem seems to came from the header.
I've found the header file of VirtualProtect function (memoryapi.h included by winbase.h included by windows.h), and the function's declaration depend to this statement :
#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
It seems it's a macro used to define what APIs the compiler should use according to the platform.
Then, how can I change the configuration of my project to set it as a pure desktop app ? I don't know why VS insists to create a Windows Phone version of everything I'm compiling...
You may have taken the wrong Express: According to this page, there are "Express 2013 for Windows" and "Express 2013 for Windows Desktop"; you need the latter.
I need to modify the C runtime which ships with VS2010 because the 2010 CRT relies on functions released in Windows XP SP2, and I need to be able to deploy to Windows 2000.
Specifically, I need to remove any and all calls to EncodePointer and DecodePointer.
The source for the C runtime is included in C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\crt\src, so it seems like it should be possible to build the runtime after slightly modifying the source.
Oh, I don't need to be able to build the dynamic versions of the runtime -- static versions only. (I cannot rely on the user installing the CRT on their system either).
With VS2008 and earlier, there was a tutorial in MSDN describing how to build the CRT, but I can't seem to find it for 2010.
Is such a thing possible?
Here's an MSDN link. It looks like you have to do it yourself in VS2010.
You can use the following compiler and linker options to rebuild the MFC, CRT, and ATL libraries. Starting in Visual C++ 2010, scripts for rebuilding these libraries are no longer shipped.
If it is a option, I would consider using the VC++ 2008 toolset within VS2010 instead of building a custom CRT. The procedure is explained here.
"Oh, I don't need to be able to build the dynamic versions of the runtime -- static versions only."
Since you only need static linking, you can try this trick to provide implementations of EncodePointer and DecodePointer.
I'm fixing a bug with Windows Vista 64 bits of a 32bit application, when I try to use the function Wow64DisableWow64FsRedirection(...) the compiler says 'undeclared identifier...'.
I'm including the Windows.h header file and set _WIN32_WINNT to 0x0501.
Any ideas?
Thanks.
EDIT: We're using MS Visual Studio 2003
Your platform SDK files are probably too old to have that function. That function first appeared in the XP 64 bit platform SDK. You can get the latest SDK here: http://www.microsoft.com/downloads/details.aspx?FamilyID=e6e1c3df-a74f-4207-8586-711ebe331cdc&displaylang=en
Even though it says it's "The Windows SDK for Windows Server® 2008" it is just the latest SDK and will have all the backwards compatible files you need.
After you install it, depending on your compiler you'll probably have to point the include directory to it.
Can you see this API in the header file? May be the Visual Studio you are using is not having updated header file, in which case you will need to do a LoadLibrary for Kernel32.dll and then GetProcAddress for the required function.
If your application needs to work on Windows XP 32-bit or Windows 2000, you should use LoadLibrary() and GetProcAddress() as Canopus suggested, because Wow64DisableWow64FsRedirection() and Wow64RevertWow64FsRedirection() were not added until Windows XP 64-bit and Server 2003 SP1 (according to the documentation).