OS X 10.10 Yosemite on Virtual Machine

Apple just announced next version of OS X and I wanted to give it a try. Beta will be available for first million subscribers or you can get it from third party sites. I couldn’t wait for notification mail from Apple so I got my copy from here. Since this is a beta I didn’t want to mess up my current system so virtual machine was better choice.   I’ve used Oracle Virtual Box for OS X but it works with VMware Fusion or Parallels as well. Basically it’s an upgrade of you current OS X system so you will need running OS X virtual machine. There is a ton of tutorials how to install OS X on virtual machine. I’ve had OS X 10.8 and upgrade went smoothly. Simply extract and copy installer to your virtual machine and run it. It will restart two times and that’s about it.

I’ve used my 2011 iMac as a host with Intel Core i5 processor so experience is not that impressive. It is obvious that system is still in Beta. On the other hand UI looks pretty nice in my opinion but with all that translucency it’s starting to look very much like Windows.

Here are some screenshots of running system.

1. Login Screen

1. login screen     

2. Apple ID

2. appleid


3. Desktop & Screen Saver

3. Desktop background



4. Show all


4. System Info

5. System Info

5. 6. Safari Safari




6. Spotlight 8. Spotlight


7. Lunchpad

9. Lunchpad

Qt: Detect in the .pro file if compiling on 32 bit or 64 bit platform


Couple of months earlier I wrote how to compile Qt projects (.pro files) from command line both on OS X  and Windows. Basically it comes down to calling qmake executable and passing path to your .pro file and path to make spec file for specific compiler. It goes something like this:

C:\QT5_build\bin\qmake.exe [Path to your .pro file] 
-r spec C:\QT5_build\mkspecs\win32-msvc2010

I am using shared .pri configuration files which I later include in my .pro files to have consistent settings across different project. In my base .pri settings files I define where are shared libraries, include files, platform specific compiler flags.

One of the things I want to control is where should output go, namely DESTDIR. I wanted to for my 32 bit builds to land in Output folder and 64 bit in Outputx64, both on Windows and OS X. Here is my shared configuration .pri file:

BUILD_TARGET = SimpleProjectName





CONFIG(debug, debug|release): CONFIGURATION = Debug
CONFIG(release, debug|release): CONFIGURATION = Release


# set intermediate directories


With this configuration my project files are normally under "Source" folder and then I will get to right next to it Output or Outputx64 depending on -arch I am using. Inside Output folder there will be Debug or Release folder, based on configuration I am compiling. Next to Debug and Release there will be folders for Temp and Generated files. Something like this:

build output

Key lines for mac OS X are number 11 and number 15. macx-clang is 64bit build configuration and macx-clang-32 is 32 bit build configuration. On line 21 I set Windows build configuration based on $$(Platform) variable. This will in case of 64 bit build add “x64” to “Output”. This flag works only for windows as far as I know. 

Note: In order to be able to build both 32 and 64 bit executables with Qt on OS X platform Qt must be also compiled for desired architecture.  To be able to build Qt on OS X for 32bit architecture Qt build must be configured with -platform macx-clang-32 flag before calling make command.   For example:

./configure -opensource -confirm-license -platform macx-clang-32 -debug-and-release -no-compile-examples ….

Fix for Intel C++ Compiler XE 13.0 error: unable to obtain mapped memory (see pch_diag.txt)


CPlusPlusStudio_productVery annoying error when trying to compile C++ project with Visual Studio 2010 and Intel Compiler XE  13.0 (btw, it’s also reproducible with Intel Compiler 12 and 14). With Microsoft compilers projected compiles without warning but with Intel this error message comes up: 

error : unable to obtain mapped memory (see pch_diag.txt)

Intel suggest here that this is the problem with precompiled headers but it turns out problems is in icl.exe (Intel compiler). It needs admin rights. You can either give it explicitly to icl.exe or start Visual Studio as Administrator.

Check if an executable or DLL is build in Release or Debug mode

Recently I ran into problem when I tried to pass std::string and std:wstring types between DLLs. Simply hardcoded const std::string passed from one DLL to another gets completely wrong transmitted. It looks like something with encoding is wrong but it turns out somehow I had compiled those two DLLs with deferent configurations. One was Debug another was Release build. Since I had over 50 executables and libraries, static and dynamic, interlinking with each other I had to find out quickly which ones were build wrong configuration.

.NET offers very nice helper class FileVersionInfo with FileVersionInfo.IsDebug property.

The FileVersionInfo properties are based on version resource information built into the file. Version resources are often built into binary files such as .exe or .dll files; text files do not have version resource information. Version resources are typically specified in a Win32 resource file, or in assembly attributes. The IsDebug property reflects the VS_FF_DEBUG flag value in the file's VS_FIXEDFILEINFO block, which is built from the VERSIONINFO resource in a Win32 resource file.

I’ve wrote very simple C# console application that accepts directory path as input parameter. It iterates trough all .exe, .dll and .lib files and writes out to .txt file if it was build with Debug or Release configuration.

Here very short and simple code listing:

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.IO;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace ConfigChecker
    class Program
        static void Main(string[] args)
            string inputPath = string.Empty;
            if (args.Length == 1 && Directory.Exists(args[0])) 
                inputPath = args[0];    
                Console.WriteLine("Input path does not exist. Check input arguments.");

            string[] searchExtensions = { ".dll", ".exe", ".lib" };
            var files = Directory
                        .GetFiles(inputPath, "*.*", SearchOption.TopDirectoryOnly)
                        .Where(file=> searchExtensions.Any(ext => file.ToLower().Contains(ext)))

            uint releaseCount = 0;
            uint debugCount = 0;
            StreamWriter sw = new StreamWriter("output.txt", false);
            foreach (var file in files)
                FileVersionInfo fileVersionInfo = FileVersionInfo.GetVersionInfo(file);


                if (fileVersionInfo.IsDebug)
            sw.WriteLine("Debug: " + debugCount.ToString());
            sw.WriteLine("Release: " + releaseCount.ToString());

            Console.WriteLine("Output successfully written to: " + new FileInfo("output.txt").FullName);

Here is output when we call it with “C:\Windows\System32” parameter for example:

C:\Windows\System32\XAudio2_7.dll		Release
C:\Windows\System32\XAudioD2_7.dll		Debug
C:\Windows\System32\xcopy.exe		Release
C:\Windows\System32\xinput1_1.dll		Release
C:\Windows\System32\xinput1_2.dll		Release
C:\Windows\System32\xinput1_3.dll		Release
C:\Windows\System32\XInput9_1_0.dll		Release
C:\Windows\System32\xlive.dll		Release

About me

Bizic Bojan is Co-Founder of Amida IT-Services GmbH and Software Architect with focus on .NET, C++, Python and Cloud Native solutions. 



The opinions expressed herein are my own personal opinions and do not represent my employer’s view in any way.

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.