Visual Studio 2014 CTP
A few months ago Microsoft released the Community Technology Preview of Visual Studio 2014, also known as Visual Studio 2014 CTP.
Installation
Because this is a community technology preview it only runs on Windows 8. Microsoft recommend that you do not install this on any machine that is important to you. This caused me some frustration. I had any number of Windows 7 machines I could have put this on, but Windows 8 machines – the ones we have are being used for important tasks. This meant creating a VM I could use. I spent probably the best part of 2 weeks futzing around before I finally got a Windows 8 VM working that would succeed in installing Visual Studio 2014 CTP. I tried creating virtual machines from other virtual machines, creating virtual machines from existing Windows 8 machines. All failed.
The only thing that succeeded was with a brand new Windows 8 install from DVD followed by installing Visual Studio 2014 CTP. And even then for the install to succeed it had to be a web install. The download and .iso, burn it and install from that always failed (just like for 2012 and 2013).
As with 2012 and 2013 before the install process is horrible and un-informative. Gone are the days of an install dialog that tells you what it’s doing and that has a useful progress bar. Now we have these “I’m doing something bars” which tell you nothing about how far through you are and only serve to tell you that the thread that is running the animation hasn’t crashed. I hate these things. I really do. It’s an awful user experience.
The install dialog does tell you what it’s doing at each stage – but nothing while it’s doing it, so you have no idea it’s progressing or has hung. I’ve had so many failures installing 2012, 2013 and 2014 that I don’t trust the installer. And trying to uninstall any of them, that always fails. I know 2014 CTP is a preview but 2012 and 2013, they are released software.
User experience
This is the next version of Visual Studio, following on from 2012 and 2013 and continuing with the same theme, that very toned down, hard to use, monotone look, although you can choose the “blue” theme. Why they do this I have no idea. Apple excel at UX and at one time it appeared Microsoft did, but now it’s make everything as hard to use as possible. Colours on icons add information, so don’t take that away! (*) They seem to have got the message on mixed case text though. ALL CAPS is gone.
* I gave up with my Windows Phone because of the icons, it was a great phone except for that crucial bit of UX – I was continually guessing at what the icons meant, I could never be sure – no ease of use.
Version Number
The version number for Visual Studio 2014 CTP is 14.0. This is a change to the natural sequence which would have been 13.0.
This means the C Runtime and MFC dlls end with 140.dll, 140u.dll, 140ud.dll, etc.
What’s new? C Runtime DLL
If you’re a C/C++ developer the big news is that msvcrNNN.dll is gone. The old naming convention for the Microsoft C runtime has been done away with.
The new C runtime DLL is appcrt140.dll (and appcrt140d.dll for debug builds).
Other DLLs that ship with it are desktopcrt140.dll, msvcp140.dll, vccorlib140.dll and vcruntime140.dll
Full list of candidate redist DLLs:
- appcrt140.dll
- desktopcrt140.dll
- msvcp140.dll
- vccrlib140.dll
- vcruntime140.dll
- vcamp140.dll
- mfc140u.dll
- mfcm140u.dll
- mfc140chs.dll
- mfc140cht.dll
- mfc140deu.dll
- mfc140esn.dll
- mfc140fra.dll
- mfc140ita.dll
- mfc140jpn.dll
- mfc140kor.dll
- mfc140rus.dll
- vcomp140.dll
What’s new? DTE
If part of your work involves getting the Visual Studio IDE to do anything you want, such as opening source files for editing then you’ll be working with the Visual Studio DTE. The new DTE number skips a version and jumps from 12 to 14. So you’ll want:
L"!VisualStudio.DTE.14.0:"
Debug memory guard structure, x86
The debug implementation of the C runtime heap uses a linked list with helpful debug information and two guard regions before the debug header and after the allocated data. The helpful debug information sits in the debug header with the linked list pointers. Beginning with the introduction of the 64 bit support this header was modified to swap two data members (size and blockUse) around to improve the memory usage for 64 bit systems (alignment on 8 byte boundaries). This was handled via conditional compilation so that the data members remained in the original order for use on 32 bit systems.
That conditional compilation element has gone! This now means code that inspects the debug heap for 32 bit systems needs to know if it’s working with a heap layout that pre dates Visual Studio 2014 CTP or is from Visual Studio 2014 CTP. Failure to understand this heap layout change will likely result in code that inspects the heap and reports incorrect block sizes and/or corrupt data blocks when the data blocks are not corrupt.
This is a serious change. It’s also an obvious step to take. Visual Studio 2014 CTP cannot read debug symbols created with Visual Studio 6. This layout change also puts paid to debug heap support from that era. Along with dropping (or trying to drop!) support for Windows XP this is another sign that although many people are still using older operating systems (*) (and compilers) Microsoft is sending a sign that they really do want to drop the older way of doing things.
(*) Every now and then we field support questions asking if we still support Windows 2000 (yes), Windows XP Embedded (yes) or Windows CE (no).
Low level detail
The compiler continues to create ever more optimized code. As with some of the Windows 7 service pack releases we’ve noticed some optimized code sequences that do things differently to before. Visual Studio 2014 CTP doesn’t ship with source or symbols to APPCRT140.DLL (although you can get the latter from Microsoft’s symbol servers) so it’s hard to tell what’s going on inside the new C Runtime. But it’s clear it’s a new architecture and way of doing things. Many functions that once would have been called by linking to them and the call being redirected through the Import Address Table are now passed to a lookup helper function that does some sort of encryption, calls GetProcAddress, does more encryption and then passes the function back to be called. Why do I mention encryption? Because the function names hint at that. It’s quite a change from how things used to be done. Why it’s being done I can’t say, we don’t have the source to examine and I haven’t tried to reverse engineer the functions. These are just comments about things I noticed while I was investigating some unexpected behaviour as we were adding support for Visual Studio 2014 CTP to our C++ tools.
Updated – A day later!
Just after we published this article James McNellis from the Microsoft Visual C++ Team Blog contacted us to let us know a few things.
- Apparently source code for the C Runtime is available but the reason you don’t see it in the debugger is because the symbols files on Microsoft’s symbol servers have been stripped – they only have function names but not filenames and no line numbers.
- A solution to this is to build your C/C++ application linked statically to the C Runtime. This gives you symbols to examine the C Runtime. We didn’t notice this because the only occasions when we ran into any problems with our ports was working with code dynamically linked to the C Runtime.
- Two articles detailing why the changes have been made have been posted to the Visual C++ Team Blog. These articles are worth a read and show that their thinking is looking forward many years into the future, mainly with an eye on improving things for developers and security issues. These articles are:
When you understand the refactoring and the desire for a wider platform support you can understand the reason for looking up functions by GetProcAddress() and calling the result rather than linking to them. Thanks to James for reaching out and letting us know their thinking.
From the above articles the standout thing for me is that most people will (for the short term at least) want to compile with _CRT_STDIO_LEGACY_WIDE_SPECIFIERS defined so that <tchar.h> continues to provide the string functions your code expects and not the C99 standard implemented in Visual Studio 2014.