We're moving to Visual Studio 2017 and VS2017 prompts us to retarget the projects for 2 things: Windows SDK Version and Platform Toolset.
Currently our application can run on older Windows versions (at least to Server 2003, possibly older), and we need to retain the same (I know they're not supported anymore, but that's the customer's requirement).
Assuming that our code (which is all C++ in case it makes a difference) does not use any APIs which are only available on newer versions of Windows, will re-targeting to a newer version of the Windows SDK restrict or limit the versions of Windows that our app will run on?
And while on the subject, will re-targeting to a newer version of the Windows SDK have any pros or cons (ex. performance) (again, assuming we don't use any of the new APIs that are only available on newer Windows)?
No, using a newer SDK allows use of newer funcntionality but it does not require doing so. So long as you are careful to only use functionality that is present on the version of windows you are interested in your program will continue to work. You will, however, likely need to install the vs2017 runtime on the client systems.
You will need the VC++ runtime for the development kit that you are building from. Statically linking this library will remove this requirement, as the runtime is embedded in your binary.
Related
I would like to be able to compile C and C++ code under the Windows environment without using an IDE, just by using the Windows Command prompt (cmd.exe).
I come from Linux, where you are be able to install the gcc package with just a command in the terminal:
$ sudo apt install gcc
I wonder if there is a C/C++ compiler collection in a package inside the Windows install folders, just like the ones in Linux, I just need to install.
What also gives me a reason to ask this question is:
Since the kernel of Windows and the Windows API are written in C, and many of the high-level applications of the actual Windows 10 release are written in C++, it would be reasonable to also directly provide a suitable compiler suite. This is my thought modell, does not need to match reality.
Thanks for your help.
Since the kernel of Windows and the Windows API are written in C
Microsoft doesn't ship a compiler, or the required Windows SDK headers/libs (also includes a bunch of other useful development tools) for Windows in the installation.
Microsoft Visual C++ (part of Visual Studio) would be the equivalent "built in" choice although I am not sure if Microsoft ever specify exactly which version they use for a given Windows build and it is common to have lots of software built with different compilers/versions (including the various non-Microsoft ones).
As well as the full Visual Studio package with the IDE and other tools. Microsoft provide some components separately, such as the Build Tools for Visual Studio 2019.
I am sure this is for many reasons like most users not being interested in compiling their own software, and Microsoft still sells Visual Studio separately to larger organisations (historically to most serious users, but "Community" edition is now pretty nonrestrictive for individuals and small business).
Strangely enough it doesn't come with a C compiler, we need to install one, Mingw-w64 is allways my choice, you will need to add the path in environment variables (step 12), if you want to use it anywhere. You can then use the gcc command where it's more convenient like in Linux, don't forget to open a new cmd after the changes for them to take effect.
Unfortunately, Windows doesn't have the command line tools for installing/removing stuff and the great repository infrastructure we know and love from Linux.
You will need two things:
The command-line build tools. These can be found on the Visual Studio Downloads page under Tools for Visual Studio -> Build Tools for Visual Studio. This will include the compiler (cl.exe) and linker (link.exe) for the MSVC build toolchain.
The Windows SDK. The latest version of the SDK can currently be found here. This page has a tendency to move around, but googling for Windows SDK usually gives you the right page immediately. The SDK contains all the headers and libraries required to build Windows applications and make use of the Windows native API. The Windows SDK contains a lot of stuff which you may or may not need. You will almost certainly want to install the Windows SDK for Desktop C++ x86 Apps and Windows SDK for Desktop C++ amd64 Apps components. Most of the other stuff should be optional, but some of it is nonetheless highly useful.
You may want to download additional packages such as the Windows Debugger (which is an entirely different application than the Visual Studio debugger) or the Driver SDK, depending on what kind of things you want to develop.
Note that even if you don't intend to use the IDE in the end, installing the full Community Edition of Visual Studio is a far more convenient way to get a working build environment, so unless you have a really good reason not to, just go with the full package and choose to never open the IDE.
The built in compilers available on Windows 10 are for VisualBasic, C#, JScript.
To improve speed & performance of apps, "ngen.exe creates native images, which are files containing compiled processor-specific machine code, and installs them into the native image cache on the local computer. The runtime can use native images from the cache instead of using the just-in-time (JIT) compiler to compile the original assembly".
For low level programmers, ilasm.exe (IL Assembler) ships with Windows, which also facilitates "tool and compiler" development; so you could even create your own language or build a better compiler for a current one, or "debug your code at low level and understand how .NET deals with your high level code", or "write your own compiler for a new .NET language."
For web programmers, AspNetCompiler precompiles server-side ASP.NET web-applications, therefore helps application performance because end users do not encounter a delay on the first request to the application.
All Compilers & assemblers come as builtin with Windows without IDE and can be run from "the Windows Command prompt (cmd.exe)", so no extra downloads necessary; located in folder: C:\Windows\Microsoft.NET\Framework\vx.x.xxxxx\ .
Note: C# is based on JScript.
Compilers:
vbc.exe
csc.exe
jsc.exe
ilasm.exe
ngen.exe
aspnet_compiler.exe
Addendum:
If you still are looking for a C compiler to handle some C source codes you already have spent your life on, then (without downloading) you can make/write a C compiler, in a high level language, then optimize it with a low level language.
This guide will "introduce you to the high-level architecture, theory, and .NET Framework APIs that are required to build your own .NET compiler" in C#.
You can to use gcc for windows. For e.g. mingw, tdm-gcc, mingw-68, Cygwin etc. Each of them allows you to work on c/c++. But if you are not sure about the installation process, and don't want to do all the work by yourself, the easiest solution is to download something like dev-c++ or code-blocks.
cygwin: https://cygwin.com/
mingw-64: http://mingw-w64.org/doku.php
Downloadable file can be found here (for mingw, dev-c++): https://sourceforge.net/
You can also install Microsoft compiler. I usually do it by installing the whole visual studio.
Are the dynamic runtime libraries for Visual C++ (more specifically 2008) part of the Windows OS nowadays? I noticed that at least on Windows 8 you no longer need to ship these with your application or have the user install the redistributable package from Microsoft.
Is this true? If so, for what Windows versions and for what versions of Visual C++ does this apply to?
No, they've never been part of the Windows distribution. Deploying them yourself is a hard requirement.
It certainly may seem that they are. Starting with msvcrt.dll in the system32 directory, it has the same name as the C++ runtime dll in Visual Studio versions prior to VS2002 (VS6 and earlier). It is however a private copy of the CRT that is used by Windows executables. And protected by the File System Protection feature in Windows, preventing old installers from destroying the operating system.
It certainly often works by accident. There are many programs that need the Microsoft CRT so it isn't unlikely that the user has run an installer before that got the DLLs installed. Clearly you cannot depend on that common accident.
Similarly for Windows 8, the pre-installed Microsoft.VCLibs.110 package matches the package you need for a Store app written in C++. But that's for the same reason as above, Microsoft Store programs were also built with VS2012, just like yours. What's going to happen in the upcoming VS2013 is a bit muddy right now, we'll know soon.
In my opinion, the answer would be both: Yes and No.
Yes: More recent Windows OS are generally shipped with VC runtimes pre-installed (along with more recent versions of the .NET framework). It is because Microsoft uses the latest/newer Visual Studio before they release VS to the public (or even to MSDN subscribers). If not this way, whenever you install some application (legacy application or some downloaded application), the setup would anyway install the required VC++ runtime. Another way is through automatic updates.
No: In case where none of the above mentioned rules applies. Or, when the VC runtime shipped with a new service pack or a patch. You might have developed your application with newer patch/SP, and that must be installed (as Side-by-Side, of course).
In particular we are developing for Intermec CK30/CK31 running Windows CE. We have an existing C++ project that also targets newer devices (running Windows Mobile 5/6).
The guy who has left this with us, just used to use both environments to develop the one set of source. But I would rather ditch one and develop for all in one environment.
You should be able to use VS2008 for all your development. You'll need to install the platform SDKs for the Intermec and WM versions (WM 4.2 and 5.0 standard should be there by default). VS2010 doesn't yet support Windows Mobile/CE development.
If you are using different environments with different versions of visual studio, you might want to have a look at the cmake builder.
It is a meta-build program, in that it creates a requested build environment (eg. VS2005 or VS2008) for you. You maintain one set of source code and then choose what IDE/compiler to use to build/modify you code. And each developer can choose a different IDE/compiler.
This would be a good compromise, as you are separating your code from your compiler/IDE, and cmake makes it no effort to drop/revive a target compiler/IDE should you wish to later.
I've been looking online and at my registry and I think not, but it would be nice if we could get a definitive answer on here.
Just the run time, as in for re-use on the client side.
I see it is possible for VC10, http://blogs.msdn.com/b/astebner/archive/2010/05/05/10008146.aspx, but prior to that we need to call the MsiQueryProductState API. Perhaps just give all the clients MSVCR100.DLL already?
The most common practice is to install the CRT your application was built with, regardless.
I think this practice comes from the v90 and lower CRTs, because there were multiple versions of each redistributable that could be installed, and though MSVCR90.DLL exists on the system, it may not be the version your application uses.
I believe this was changed with the v100 CRT, and now Microsoft guarantees that newer versions of the CRT will be usable in place of an older version, but I would still attempt to install the CRT your application was linked with.
It is still possible to do a private install of the Dll's into the application's folder. I recently installed 3 different version of the VC9 runtime when I was setting up my Visual Studio Express environments. All show up in Control Panel and appear to be readily removable.
For that reason I believe the current best practise to be to perform a private install (I think that is the terminolgy MS uses) of the required DLL's (for managed code you need the managed DLL and the native version) in tha app's folder.
I've built a C++ application using MSVC 2010, default compile settings (note: Using "Multithreaded" instead of "Multithreaded DLL" to avoid the Microsoft C++ runtime being needed).
I used only the STL and a few, old functions from the Win32 API (Windows.h).
Where will my app run? (98-7?)
Can the be any differences on how my app works on different PCs? As said: It's only a simple console app.
I'd be glad if you could add some additional information if you have it!
The Simplest answer is: Your app will run on Windows versions 5.0 and later - depending on what other APIs YOU use.
the hard limit of 5.0 is introduced in Visual C++ 2008 that stamps a 5 into the minimum OS version field in all the PE headers of all the executable files it produces.
As Windows NT is the only desktop OS with version's 5 and higher, this means that Windows 95, 98, ME cannot run programs made with VS 2008 and VS 2010. Windows 2000 is actually Windows NT 5.0, so it can be targetted. XP is 5.1, Vista 6.0, and in a twist of idiocy, Windows 7 is actually version 6.1 of Windows NT.
Take a look at "Using the Windows Headers" at MSDN. It describes how to configure the windows header files to support various mixtures of OS's.
I think you have to think about it the other way, what versions of Windows do you need to support, and then you can check if the APIs you need are supported or if you have to find workarounds.
After seeing Chris' comment about Win9x no longer being supported I took a look and discovered that the 2010 redist package only supports WinXP and upwards, so you might not be able to compile for Win 2000 either now?