Matt Godbolt has announced today that the Visual C++ compiler is finally available on Compiler Explorer (https://godbolt.org/). Compiler Explorer is a website where you can write C/C++/Rust/Go/D code, compile it with various compilers and settings and see the resulted assembly code.

The version available is 1910, i.e. VC++ 2017 RTM (the exact version number is 19.10.25017.0). The following targets are available:

  • x86: x86 CL 19 2017 RTW
  • x64: x86-64 CL 19 2017 RTW
  • ARM: ARM CL 19 2017 RTW

To give it a try, I compiled the following program:

The result may look at little bit surprizing, as it totals over 5000 lines of assembly code, as oposed to gcc 7 or clang 4 that only produce 42.

, , , Hits for this post: 462 .

I’m working on a project to port a 32-bit application for the x64 platform. The first errors that came up when building for x64 were related to inline ASM code, which is no longer supported in VC++ for x64. VC++ has an inline assembler built within the compiler, so you could write assembly code directly in C++ without the need of an external assembler (such as MASM). However, this works only on x86. For x64 and IA64 this is no longer possible. There are several workaround for this:

  • put the assembly code into a separate file and use MASM for x64
  • use compiler intrinsics, which are functions that basically wrap assembly instructions or sequence of intructions
  • rewrite in C++, use Windows APIs, etc.

One error that I had was related to this assembly code:

This was used to generate a breakpoint. This can be easily replaced with compiler intrinsic __debugbreak(), which has an identical effect, except that is available on all platforms.

Other errors I had were due to assembly code used to retrieve the value of the EIP and EBP registers. They were used for walking the stack.

The naked specifier is another thing that is not supported on x64. One way to retrieve the value of these registers that works both with x86 and x64 is using RtlCaptureContext, except that this won’t work on operating system previous to Windows XP. In you don’t care about those operating systems, you could write something like this:

Attention, on x64, register EBP (actually RBP) is no longer used. You should use RSP for getting the stack frame.

However, if you want to build a portable stack walking, use StackWalk64. Despite the 64 suffix, this function works on all platforms (x86, x64, IA64). Here is an article that shows how to walk the stack using StackWalk64.

, , , Hits for this post: 45692 .

When you create a WPF application, the start-up window is by default one from the same project (by default called Window1.xaml).

But what if you want to use a window from another project (class library)? The pack URI scheme, used by WPF, allows you to identify and load files from:

  • the current assembly
  • a referenced assembly
  • a location relative to an assembly
  • the site of origin for the application

The format of the pack URI is pack://authority/path. The authority identifies the type of package and the path the location of a part inside a package. There are two authorities supported by WPF:

  • application:/// identifies application data files (known at compile time)
  • siteoforigin:/// identifies site of origin files

To use resource files from a referenced assembly you need to use the application:/// authority, and the path must have the form AssemblyShortName[;Version][;PublicKey];component/Path. Version and PublicKey are optional.

Let’s say you want to use a XAML called SampleWindow.xaml from a referenced assembly called WpfDemoLib. The App.xaml file should look like this:

You can learn more about pack URIs in WPF from MSDN.

, , , , Hits for this post: 48165 .