Been trying for 2 hours now, and theres no luck. I wanna make it so I got templets for a win64 app (Not .net) but I can't find where to add platforms. Please help?
There is no "Win64" API. There are just 32-bit Win32 apps and 64-bit Win32 apps, and the only difference is a compiler/linker option which compiler/linker are used (different directory).
The Win32 templates work just fine for 64-bit development.
While (much) earlier versions of Visual C++ shipped with a private copy of SDK headers, VS2010 installs a version of the Windows SDK and uses an environment variable to find SDK headers during build. So installing a new SDK, as long as it updates your environment variables, is automatically found by Visual C++ projects at build-time. (With the old Visual C++ versions, the SDK installer was supposed to edit the tool paths in the Visual Studio section of the registry, which could occasionally fail)
Related
Some libraries are available to download as pre-compiled binaries, usually in specific architecture (x32 or x64) but I have also noticed that some pre-compiled binaries are splitted based on visual studio version, for example: vc17_x64. Let's assume that I use visual studio 2019. Does it mean that I have to use binaries precompiled for vc2019 or build a library from source when apropriate version is not available ? It's not clear for me because some pre-compilied binaries don't contain information about visual studio version.
If a pre-compiled library has Visual Studio version info you should use that version of Visual Studio to work with the library. This is not always the case though, as often enough happens that an older (with respect to VS version) library contains code that is a subset of the newer VS's header and runtime SDK files (.NET, C/C++, Windows SDK, etc). The other way around, when the library is newer can also work but it's far less frequent. You can try, if it doesn't work for your particular library and VS version then you should consider matching versions, rebuilding not always works for the same reasons of code changes.
If a library doesn't contain VS version info then it's reasonable to assume that it's portable/compatible up to operating system (Windows, Linux, etc) and programming language version (C++ 11, C++ 14, C# 7, C# 8, etc). However, VS version comes into play here as well, not every VS runs in every Windows, neither it supports the same runtimes, SDKs, and language(s) version. You should always check the library documentation for recommended working environment, if this info doesn't exist then it's trial and error and/or community consulting.
Is there any compatibility matrix as to what Visual Studio Versions (Say, ranging 2005 - 2017) are compatible with which Windows SDK Versions?
Should any Windows SDK be fully compatible with "any" C++ compiler, or are the different Windows SDK versions bound to certain compiler versions?
For example(!), we have a legacy C++ application that is still compiled with VS2005. We found that we'd like to use GetDpiForMonitor from this application. But to use this function, would require to use the headers+libs from at least an SDK supporting Windows 8.1 (e.g. the 8.1 SDK headers at C:\Program Files (x86)\Windows Kits\8.1\Include\um)
Generally, should a developer expect to be able to switch to a newer Windows SDK version without upgrading his compiler / Visual Studio?
Please refrain from suggesting to upgrade VS: This question tries to establish what you should do when upgrading VS is not an option for now, but you want to use stuff from (and depend on) functionality only available in newer Windows (SDK) versions.
concerning the "compatibility matrix": I don't think anybody made the effort to up to create one, also I'm not sure if this is really needed.
Rule of thumb: those API headers don't change quite often, and when they do, they are usually pretty much backward compatible.
The tricky part may be to teach your older VS to get along with a new SDK, you may need to change the VC+ include/source/lib directories for your solution/project manually.
(if it complies & links in your old VS, you should be fine)
Running the WindowsSdkVer.exe shipped with Platform SDK 7.1 does not work.
None of the .BAT files in VS 2005 get updated.
can anyone please tell me how to correct this?
Also, how do I verify that VS2005 is using Platform SDK 7.1?
There are several articles for this in MSDN but none of them for above configuration.
Also, none of them describe the concrete way / definate way of verifying this
You could try to manually set the include and lib paths of the VS environment under
Tools->Options->VC++ Directories
or something like that (it's been a while).
For verification, you can add the /showIncludes parameter to the additional compiler options of the project, and /verbose:lib to the additional linker options to double check that the correct headers/libraries are being used when compiling/linking the project.
IIRC there was some kind of incompatibility between one of the newer versions of the SDK (could have been version 7) and using VS2005, but I can't recall off hand what that was.
You can use below method for using Windows SDK 7.1 with Visual Studio 2005.
Configuring Visual Studio for Visual C++ Development with the Windows SDK
In the link , you can find the contents with
"To use the Windows SDK Configuration Tool in Visual Studio 2008".
Even though it has such title, you can use the same procedure also for VS2005.
Start the Windows SDK Configuration Tool by clicking Start, then All Programs, then Microsoft Windows SDK v7.1, and then Visual Studio Registration.
Right-click Windows SDK Configuration Tool and then click Run as
administrator.
In the Windows SDK Configuration Tool, in the list, select v7.1.
Click Make Current.
Question from a Linux/Mac developer: I have compiled a 32-bit .dll (release flavor) under Windows 7 using Visual Studio 2010. Should this .dll be usable under all flavors of Windows 6 (a.k.a. Vista, if I'm not mistaken)?
Many thanks and RTFMs appreciated,
John Clements
In general: yes.
All current versions of the .Net framework run on both Vista and Win7.
Note that if you make calls into the native platform, either directly or via the Windows API Code Pack, you could have portability problems if you use functions available only in Win7. But for just straight .Net development, you should have no issue in running on any supported version of Windows.
Yes, the dll format didn't change for Windows 7. Only thing to remember is that if it's a .Net dll, the target system must have the proper .Net installed or the appropriate C/C++ runtime.
You're supposed to #define the _WIN32_WINNT macro to tell what version of Windows you want to support. The default in the SDK that ships with VS2010 is 0x600 which avoids you ever linking to an API function that is not available in Vista. So, yes, you're probably good to go.
I have several C free software/open source libraries that I develop on Linux and OSX with the GNU toolchain (automake, conf, flex, bison, gcc, ...) but I occasionally get requests to provide Windows DLLs. I'd like to be able to provide those without having to spend a lot of time and money with Windows Visual Studio development. I do have a Windows XP virtual machine available and I also know the software is portable as occasionally I get patches to make it build in on windows.
What approaches or tools should I be using? Cross compiling on Linux? using Visual Studio Express or something else? I would prefer something that is fully automated from a SVN repository. I do not count cygwin as a solution since that does not seem to provide what Windows developers need, as far I understand the issues - linking and DLLs.
You can try Mingw with MSYS, Visual Studio (Express) with SUA (subsystem for unix application) or Cygwin to compile programs that are automake/autoconf based (./configure && make to build under linux).
Unfortunately usually the lib file they create is not compatible with other compilers, so if you want your library to work with an application that is developed using Visual Studio, then you should use the VSC++ approach. Usually a lot of GNU projects (check gnuwin32) actually have VC compatible build scripts too, than can be compiled using "nmake"
You could use MinGW or install the MSVC command line tools from Visual Studio Express.
Either of those can be driven by command line scripts.
I imagine a cross compile from Linux would also work, but I have no idea how easy (or painful) that might be to get going.
This short article shows a simple cross compile of a Windows application & running that app under Wine:
http://www.linuxjournal.com/node/1005753
The Windows Software Development Kit includes Microsoft's C/C++ compiler (command line only with no visual tools), so you don't even need Visual C++ Express Edition. The Windows SDK is a free download from Microsoft.
If you're using http://www.cmake.org/, cmake can create the Makefile (for Unix) and project file (for Visual Studio). This is what for example the KDE project is using.
Visual Studio's compiler can be started from a Windows command line with 'devenv /build debug project.csproj' on the cmake generated file. This does however require a Windows (possibly in a VM) with a (potentialy free) Visual Studio installed.