Rss Feed
Tweeter button
Facebook button
Technorati button
Reddit button
Myspace button
Linkedin button
Webonews button
Delicious button
Digg button
Flickr button
Stumbleupon button
Newsvine button

Posts tagged: Visual Studio

Changes to how we build our software

By , January 4, 2015 8:25 pm

Starting with our first software release of 2015, we will start shipping software that uses the Visual Studio 2010 C runtime and MFC libraries. The purpose of this article is to explain why we’re making this change and how this will affect users of our software.

Some of our past choices have been about technology and some about ease of doing the work. If the operating system or development environment fights you, you are less likely to use it.

Compiler History

When we started the company the current version of Visual Studio was Visual Studio 6.0. So naturally our software shipped with C runtime and MFC libraries for Visual Studio 6.0.

We didn’t really like the direction the Visual Studio team went in with subsequent releases,in particular with some subtle changes to the debugger that, it seems, many people have never noticed. These changes removed a particular feature from the debugger that we find very useful (drag an address to the disassembly view and automatically get the disassembly displayed – the workaround to do this in current versions of Visual Studio is clumsy, error prone and occasionally fails). Because of this we continued using Visual Studio 6.0 to build our software. Anything requiring support for more recent versions of Visual Studio would be built using that version of Visual Studio (library stubs, Visual Studio editor support, etc).

When we started exploring 64 bit support we started with Visual Studio 2008 because that was the current toolset at the time. Our 64 bit tools ship with the Visual Studio 2008 C runtime and MFC libraries.

For our .Net tools we’d be using Visual Studio 6.0 for the GUI, but Visual Studio 2010 (or 2012) for the profiler backend.

This resulted in our routinely using multiple versions of Visual Studio to do development.

OS History

Historically we have supported all operating systems from Windows NT 4 onwards. We have always wanted to support our customers using Windows NT 4 and Windows 2000. Many people using Windows embedded are still on old versions of Windows.

We made the rather unusual decision to develop on Windows XP x64 but to test on Windows 7 and Windows 8. This decision was mainly due to UX blunders Microsoft had made with the Start Menu on both Windows 7 (no fly out start menu) and 8 (no start menu!), and also to the file search functionality which is very easy to use on XP x64 and very hard to use from Windows Vista onwards.

These may seem like trivial things but we use file search a lot and often the Visual Studio file search is not the tool you need. Simply put we found XP much, much easier to be productive with compared to anything that came after.

Reason for change

Since April 2014, Microsoft no longer supports Windows XP. From a security standpoint this isn’t good. For us, or for you (if we get compromised, how can you rely on us?). As such we had to move away from Windows XP x64 whether we wanted to or not. We’ve written some tools to allow us to do fast easy searching without needing to go near the UX disaster that is the current version of Windows search. The removes one of our main objections to working on Windows 7 or Windows 8 on a daily basis.

We also tested a lot of start menu replacements. We finally settled on Classic Shell as this not only provides a very useful start menu on Windows 8 but also allows you to have a proper fly out menu (like XP) rather than the cramped and very awkward to use compressed menu you get with Windows Vista/7 (no wonder Microsoft’s UX metrics showed start menu use was down – they’d made it too hard to use).

So that’s the two UX reasons out of the way, what about the software?

We would also like to take the software tools in new directions – to support .Net alongside C++ rather than in separate tools. This can be done using our current arrangement but it’s harder than necessary. In particular it makes automating our builds harder. Visual Studio 2010 is a lot easier to control from the command line that Visual Studio 6.0. So moving to one Visual Studio for this is a major bonus. Also, debugging software built using multiple different versions of Visual Studio, some of which can’t read debug info from other versions of Visual Studio, that is horrible.

We noticed that no one has discussed Windows NT 4 or Windows 2000 with us for quite some time so we decided to drop support for Windows NT 4 and Windows 2000. Removing this constraint meant we could move to the Visual Studio 2010 runtime and thus use one main version of Visual Studio to do most development work.

The reasons the Visual Studio 2010 runtime is important is because this is the most recent runtime that supports Windows XP and many people are still using Window XP.

Implications

An unfortunate consequence of this change to Visual Studio 2010 runtimes is that if you are using more than one of our 32 bit tools or more than one of our 64 bit tools then you will need to install new versions for all of the 32 bit tools (or all of the 64 bit tools). The reason for this is due to DLL dependencies and memory allocated by DLLs all needing to come from the same allocator. Mixing VS 2010 built DLLs with VS 2008 built DLLs or VS 6 built DLLs will give unspecified results.

We realise this is inconvenient and certainly not ideal. We won’t be changing the runtime we use again until none of our customers need support for Windows XP. We anticipate people using XP for many years into the future (based on comments made to us by customers).

The Future

We aim to roll all the functionality of our .Net tools into our C++ tools. C++ Coverage Validator will be able to collect coverage data for .Net code, C++ Memory Validator will be able to collect and analyse .Net memory data, C++ Performance Validator will be able to profile .Net code. The .Net specific tools will then be phased out.

If you are using our .Net tools, you will still be supported – we’ll move your .Net licences to the C++ licences where you will get the .Net data previously provided by the .Net tools.

If you are using our C++ tools, you will get additional .Net data in the tool.

The intention is that the tools will simply get better. We aren’t going to damage the C++ side of the tools to provide the .Net support. I mention this because we’ve had some questions from customers asking about this (having seen what some of our competitors did when they decided to support .Net).

Visual Studio

We will continue to support every version of Visual Studio from Visual Studio 6 through Visual Studio 2013 (and what comes after it, Visual Studio 2014 CTP, now renamed Visual Studio 2015 CTP) and future versions.

Windows NT 4, Windows 2000 support

If you need support for Windows NT 4 or Windows 2000, please contact us. We will be able to support these operating systems, but only via a special build facility.

Share

Visual Studio 2014 CTP

By , August 12, 2014 3:54 pm

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.

Share

What will Visual Studio 2035 be able to do?

By , March 17, 2010 12:53 pm

Will Visual Studio 2035 exist? Will we design and write software the same way in the future?

Read Bruce Eckel’s thought provoking article about “Programming in the mid future”.

Share

Panorama Theme by Themocracy