Sunday 19 July 2015

Windows keyboard stops working

If your keyboard in Windows ever just stops working, but it's clearly not a hardware problem as you can still log-in - it just doesn't work once you have - look for an icon in the bottom-right (the notification area) called FilterKeys.

Double-click the icon, turn off all its nonsense, and the keyboard should start working again.

Wednesday 15 July 2015

Visual Studio to English translation

In Visual Studio, if you get an error that reads:

"This project doesn't contain the Configuration and Platform combination of Debug|Win32"

and you're not even building Debug or Win32, what Visual Studio is actually trying to tell you is:

"This project has a dependency project that isn't loaded in the current solution."


Monday 13 July 2015

Jenkins CI on Windows - Git can't access remote submodules - even public ones.

I'm setting up Jenkins on a windows machines, looks great. But after setting up all the credentials, projects with Git submodules cause a problem - we get git authentication errors.

These errors go away if you set the environment variable HOME to the parent of your .ssh directory. There's also a JENKINS_HOME variable. Possibly setting this and copying the .ssh directory to Program Files (x86)/Jenkins might have the same effect, but I've not tested that yet.

Multi-platform CMake

The latest CMake 3.3 allows you to separately specify the generator (i.e. what compiler to make projects for) and the platform, using the -G and -A command line parameters respectively. That's especially good for Visual Studio, as you can do something like this:

cmake -G "Visual Studio 11 2012" -A x64 -D CMAKE_MAKE_PROGRAM=C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe "C:workspace\source_dir"

 Even better, the -A switch recognizes "x64" as a platform, even though the generator is officially called "Visual Studio 11 2012 Win64". So that will play nicely with environment variables, e.g.
SET PLATFORM=x64

Thursday 2 July 2015

Subtle problems linking dll's built with different compilers

You should generally try to link DLL's and exe's built with the same compiler. I recently had an issue where I redirected C++ std::cout and cerr in my exe, but got no apparent output from these functions in my linked DLL.

Turns out, the exe, being new, was built with the Visual Studio 2013 (v120) toolset, while my DLL's, for backward compatibility, were using v110_xp - the Visual Studio 2012/Windows XP-compatible toolset. And because they used the MD dynamically linked runtimes, they were silently, and happily, loading two different versions of the runtime libraries.

Therefore, my redirects (std::cout.rdbuf() etc) were working on the exe's copy of the runtime, and of course, not on the DLL's, entirely different, runtime library.