I have following 2 questions wrt to Windows SDK and Platform toolsets and C/C++ runtime library.
a) What is the relation of Windows SDK with C/C++ runtime and platform toolset?
Is it correct to say that BOTH C++ runtime libraries & platform toolsets are provided by Windows SDK?
Since we mostly deal with Platform toolsets from within the Visual Studio project settings, so want to understand that whether under the hood does the Visual Studio controls the C++ runtime library and platform toolset versions by installing the required version of Windows SDK?
b) Another thing i wanted to clarify was that if it is correct to say one version of platform toolset can work with different version of Windows SDK OR these are totally unrelated?
eg. in my Visual Studio i see that 'Windows SDK version' is Windows 10 and Platform toolset is v142. Can i set the 'Windows SDK version' to Windows 8.1 and keep the toolset as v142? If yes, then what does it mean?
This is confusing me a lot and i can't seem to get the correct picture with so many different explanations from different people.
TL;DR: If you are using Visual C++, and use the standard REDIST instructions from Microsoft Docs, then these details shouldn't really matter to you.
With VS 2015 and later, the "C/C++ Runtime" has been refactored into three pieces:
UCRTBASE.DLL is part of the OS and serviced through Windows Update. There are 'down-level' versions of it included in the Visual C++ REDIST package, but generally you should think of this as the "OS" part. This is the "C Runtime". These headers, import libraries, and are in the Windows 10 SDK. You can find the source for it there as well C:\Program Files (x86)\Windows Kits\10\Source\<version>\ucrt.
MSVCP*.DLL This is the "C++ Runtime" library, basically stuff like std::vector et al. The headers, import libraries, and such are in the Visual C++ product. You can find the source to it on GitHub per this blog post.
VCRUNTIME*.DLL has the entry-points needed at runtime for the Visual C++ compiler language features.
There are also a few auxiliary libraries as well for specific scenarios:
VCCORLIB*.DLL is used for C++/CX extensions (a.k.a. /ZW)
VCAMP140.DLL is used for C++ AMP
VCOMP140.DLL is used for OpenMP
CONCRT*.DLL is used to implement C++11 <thread> on Windows XP (not used on newer versions of Windows; it's delay loaded if required)
See this blog post and this one.
Essentially the C runtime (the UCRTBASE) part is a simple extern "C" interface so the ABI is well-defined, and thus is usable with multiple versions of Visual C++ and even other compilers. Exactly which version of the UCRT you are using is therefore primarily depending on the OS and the Windows 10 SDK you are using via WindowsTargetPlatformVersion. You can applocal deploy UCRT as well per this blog.
The C++ Runtime (MSVCP*.DLL) includes a lot of inlines and exposed memory layouts, and historically there was a breaking change between between Visual C++ versions. That said, for VS 2015 Update 3, VS 2017, and VS 2019 the VC team has made a point of keeping 'binary compatibly' here meaning that if you have a static library that uses C++ std namespace components from a PlatformToolset of v140/v141, it will successfully link with a later version of Visual C++ up through v142. It's not clear that this will hold in the future, but it is true for this particular set of releases per Microsoft Docs.
The VCRUNTIME*.DLL needs to match the version of the Visual C++ compiler you are using to build the final link, so this is very much intended to match your PlatformToolset.
I've been looking around to see how I'd accomplish that which is described in the title. That is, I'd like to create a C++ GUI application that:
is portable (no installer)
is cross-platform (Qt solves this)
is open source
works out of the box (i.e. no C++ redistributable installs needed)
I've run into several issues trying to accomplish this. I've narrowed it down to using Qt and NOT using the Visual Studio compiler. Let me explain.
Using Qt would fulfill the cross-platform requirement; it's also highly acclaimed in regard to C++ GUI applications. The issue lies with portability and not having a ton of dependency packages to install before being able to use the application. My goal would be for someone to download a .zip file containing an .exe (and I'd be willing to include other support files e.g. DLLs if necessary) and be able to extract and run that exe out of the box without having to do anything else.
And here's another kicker: as much as I'd like to use Visual Studio (with the Qt Visual Studio Add-in), it just doesn't seem feasible given my requirements. This post covers my issues pretty nicely. Simply put, if I use the Visual Studio compiler, I'd need to either create an installer (no longer a portable app), redistribute some Microsoft DLLs with the app (possible licensing and redist issues here?), or statically link the Visual C++ libraries into the executable (frowned upon technique).
Is there any way to be able to use Visual Studio and fulfill the requirements listed above? Visual Studio is just too fully-featured to pass up. If it's not possible, I think the only other alternatives would be to use a different IDE and/or compiler. For example, I could use QtCreator with MinGW, but then I'd be losing out on some awesome VS debugging features.
My main questions:
Is there any way I can fulfill the requirements above and still use Visual Studio?
Am I wrong about QtCreator not being as fully functional as Visual Studio?
What would be the best way to approach fulfilling my application requirements?
Thanks in advance.
I think your best bet would be to use QT with the MinGW environment. It allows you to create a portable application that supplies runtime DLLs by itself, with added bonus of being completely open source. The QT online installer gives you the option to install the complete MinGW system, and it will work out of the box, not much setup needed.
You could still use Visual Studio for development; there even is a QT plugin for it (I am not sure if VS2015 is supported, but if not that should only take some time).
QTCreator is actually a quite nice IDE, but it cannot stand up to Visual Studio. It is obviously optimized to cater to the needs of QT programmers, but I found that it is quite clunky from time to time. If your project is small it could be a viable choice, but since Visual Studio 2015 Community is basically free I would opt for that. The VS plugin will still use QTCreator's GUI editor though (which is really good)
I write the plugins for AutoCAD. If I write the managed (i.e. .net) plugins, then I can use any Visual Studio version which can work with .NET Framework version which are used by AutoCAD (it is very convenient):
AutoCAD 2009 can use .NET 3.0, 3.5
AutoCAD 2010 can use .NET 3.5.
...
AutoCAD 2016 can use .NET 4.5, 4.5.1
So, through Visual Studio 2013 I can write the .net plugins for AutoCAD 2009-2016.
But sometimes I need to write unmanaged plugins for AutoCAD, because its managed .net API covers unmanaged API (ObjectARX SDK) not complettely. ObjectARX is API for C++. At this case I can't use the same Visual Studio for each AutoCAD version. For example, I am to use VS 2005 for AutoCAD 2009 plugins writting. Therefore I have installed VS 2005-2013 on my virtual machine. It is very unconvenient in my opinion.
I know, this problem exists because the standard of C++ functions naming is not exist and each version of VS has own rules of the name generation for the functions which aren't marked by external "C".
But why this standard is not exist still? What the reason of it? I am sure this reason is exists. Such behaviour is unconvenient is not for me only (I asked other programmers about it). But they don't know why each new VS version has own rules of C++ function naming and why standard of nameing of C++ functions is not exist.
Thank you.
A standard does exist, see https://mentorembedded.github.io/cxx-abi/abi.html#mangling
But not all compilers use it, because they have their own mangling conventions that they have used for many years, and they don't want to change them for various reasons.
In your case the differences between different versions of Visual Studio are not just name mangling, there are changes in the C++ runtime library and the standard library.
I know it's possible to do since I have seen some internet articles about it, but none specifically outline the process.
I would like to compile MIT MEEP to Visual C++ to use the libmeep libraries in a .NET CLR application. The source provided includes the associated build scripts for a GNU toolchain, but given that I am using Windows, these are unavailable. As well, it requires some dependencies such as blas, fftw, and optionally libctl and hdf5.
I'm not super experienced on this issue. How would I manually configure Visual Studio to build? What would be the specific process?
I searched around for the answers to these questions, but I have had little luck. So, I thought I would post them here to get some clarification. If this is a duplicate, please let me know, and I will close this.
Okay, with that said, I would like to begin learning C++. I come from a C# background and I have a great respect for Visual Studio and what it can do. Now, my question is. How well does Visual Studio's compiler work for C++ as opposed to a non-Microsoft version (such as MinGW)?
My thing is this. I have nothing wrong with Microsoft, but I would really like to learn C++ in a "pure" form and not scewed by any particular implementation. How reliant is Visual C++ on the .NET Framework? Can a "pure" C++ application be created through Visual Studio without any .NET usage or overhead? Does the Visual Studio compiler compile C++ into CIL like it does with C#/VB, or does it compile it all the way down as others do?
Thanks for any help anyone can provide!
The Visual C++ compiler will compile C++ code into standalone EXEs that have nothing to do with the .NET framework.
The only way to get the .NET baggage thrown in is to compile the C++ as "managed".
If you create a new project (File|New|New Project) Then choose "Win32" from the Visual C++ submenu in the project types and choose "Win32 Console Application" Visual studio will create a simple project with a couple of source files that will compile to a little executable.
Most of the time, Visual C++ is very similar to other compilers. Avoid #pragmas, microsoft libraries (MFC, ATL) and you should be fine.
Edit (thanks Cheeso) - Documentation of where Visual C++ diverges from standard.
In general I would advise using boost libraries for threads and networking because they work on many platforms (i.e linux). Also if your code can compile in GCC and Visual Studio then you are doing a good job keeping it portable.
The most recent versions of VC++ have become significantly more compliant to the C++ standard, so it's not really an issue to write "pure" C++ using Visual Studio, presuming that you stay out of the Windows API, COM+ and ATL. In fact, the documentation with Visual Studio is very rich, with details on the standard libraries and the STL, so it can help you learn a great deal. It can't teach you everything, but it's certainly loaded up with a wealth of information that is portable to any compiler and it is very easily accessbible inside the IDE.
If you create a new solution you should choose new Win32 Project, or Win32 Console Application, and check the 'Empty Project' option. Then you can add a main.cpp file, and add your standard C++ code.
If you like Visual Studio, go ahead and use it to learn C++ -- I haven't used the very latest version, but even the previous one was pretty standards-compliant, C++-wise, and I assume the latest one can only have gotten better. You can have many different kinds of project in Visual Studio, including "console apps", which are the "plain vanilla" kind you could make on any platform, and also many other kinds, such as, windows apps using the good old win32 api, ones made with MFC or other frameworks older than .NET, .NET ones using "managed code", etc.
Just make sure you always work in a "console app" project, and you'll be operating pretty closely to how you would be on other platforms and/or with other C++ IDEs.
If you limit yourself to writing ANSI C++ compliant code then what you write in VS will work in other compilers, until you have to interact with a graphic interface or IO. Then you need to make certain that you are using something that is portable, such as OpenGL, and not DirectX.
To set your project the steps here may be useful:
http://bytes.com/topic/net/answers/447572-strict-ansi-c
Microsoft Visual Studio 2005 comes with a very good, C++98 standard compliant pure C++ compiler. If you are interested in pure C++, don't forget to disable language extensions in project settings and you are good to go. Nobody is going to force you to use .NET framework, MFC or anyting like that. Just pure core C++ language and C++ standard library.
Of course, just like any other compiler, it has known non-compliance issues, but in general it is, again, surprisingly good. Older versions of their compiler (MS VS 6.0 specifically) suffered from many non-compliance problems and could not even compile its own header files with language extensions disabled. In 2005 version they fixed a lot of these issues.
After creating a standard Win32 project, you can turn up the compliance a bit more. On the project properties sheet, there's a C/C++ category, with a Language entry. This lists a number of cases where VC++ can differ from the standard. Here, you'd want to turn OFF language extensions, and turn ON "wchar_t as built-in type", "for-loop conformance" and "RTTI support".