Why I need “Reveal in Finder” and browsing from window title bar on the Windows platform

Every platform has its good side and bad side. With recognition of that, I prefer Mac platform with good reason. Big features are easy to be appreciated. However there are very small features people forget but very beneficial.

Because I use the Visual C++ very frequently, the most lacking feature on Windows I can acknowledge are :

1. Reveal in Finder
2. Browsing from the title bar

The first feature, Reveal in Finder, relieves headache of opening the Explorer window and browsing it. Try locating a source file or a built binary in the Explorer. You know where they are. So, you browse into the folder which contains the files. However, how many steps do you need? Also, one thing bad on Windows platform is that it can’t handle two different files with the same name. Especially with the VC++, it is somewhat difficult and inconvenient to confirm where the file is.  It depends on how to setup “window display” mode. If you use the tab mode, it is easy. You just need to put the mouse pointer on the tab. Then it will display the path. However, if you choose the other option, it can’t.

However, on the Mac OS X, almost all programs support “Reveal in Finder”. If you choose a file in the Xcode project or the iTunes and choose “Reveal in Finder”, it will open the folder in which the file is and it automatically select the file for you. Also, some supports “Open the containing folder”. It is almost same.

With this feature, you don’t need to open as many folder window, because you can always access that folder very easily. Especially when there are so many different projects, you will appreciate the feature. Take a look at my drive.

Second one, which is “browsing from the title bar”, is also very useful. Let’s say that you open a file in the MS Word. You want to know where the file is. Probably you want to check other files there also. Then “comand+click” on the title bar which displays the file name. Then you can browse into one of its containing folders. Very handy, isn’t it?

On the Windows, MS Office products have one serious defect. If there are two files with the same name, you can’t open the other file, when you already open one. In that case, you sometimes don’t know which file you opened. If the Windows supports the two really good features of the Mac OS X, there will be no such confusion.

Using bootcamped Windows without any key mapping

There are many people who complains about different key mapping on Windows and Mac, and non-existent keys on Mac keyboards for the Windows.

With extended keyboard, which most people use, there is no such issue. Because the current Macintosh keyboard except for the small wireless keyboard that doesn’t have extended part.

So, many people try installing key mappers on the Windows. However, Apple provides good information on how to use their keyboards with the Windows. They have very nice pictures of variable Apple keyboards including the small Apple Wireless keyboard.

If you click links on “Note:” line, you can find specific information on each keyboard type.

However, if you are a MacBook user, not a MacBook pro user, you will ask, “How about my MacBook?”, because they don’t have any explanation for the case of MacBook. The Wireless keyboard looks exactly like the MacBook’s. Well, information on that “note” link explains quite useful key mappings, but not all. For example, Start, End, PageUp and PageDown are what I use very frequently when I write codes on the Windows. ( I don’t like the position of those keys, though. Like the Mac OS X, “Command-<left arrow>”, “Command-<right arrow>”, “Command-<Up arrow>”, “Command-<Down arrow>” are more intuitive and more convenient to use. So, here is the good news. On bootcamped Windows, you can use “fn” + <arrow keys> for those. You cand find more information on those on the page for MacBook Pros. The MacBook follows MacBook Pros as far as the keyboard mapping is concerned.

 

Weirdness of the High Resolution Counter, i.e. QueryPerformanceCounter()

For the most of time, using clock() for measuring performance for a block can be enough.
However, there are some cases where you want to compare two logically identical but differently implemented blocks.
Let’s assume that you want to compare performance of intrinsic version of strcpy and your own implementation of strcpy block written in SIMD instructions.
In most case, the clock()-based functions, like clock() and GetTickCount(), will not reveal the difference between them.

So, you decided to use high performance, or high resolution timer. The Windows supports these two functions for that purpose.

1. QueryPerformanceCounter( LARGE_INTEGER *pVal )
This function is like the clock(). the value returned in a location pointed by pVal is the number of counts, just like that the clock() returns number of ticks.

2. QueryPerformanceFrequency( LARGE_INTEGER *pVal )
This returns how many times it ocillates per a second.

So, the duration of time can be obtained by

    LARGE_INTEGER aVal, aFreq;
    __int64 durataion_in_time;

    QueryPerformanceCounter( &aVal );
    QueryPerformanceFrequency( &aFreq );
    duration_in_time = aVal.QuadPart / aFreq.QuadPart;

However this has some glitches with contemporary CPUs.

Before mentionting the glitch, let’s take a look at how the LARGE_INTEGER is declared.

typedef union _LARGE_INTEGER {
    struct {
        DWORD LowPart;
        LONG HighPart;
    };
    struct {
        DWORD LowPart;
        LONG HighPart;
    } u;
    LONGLONG QuadPart;
} LARGE_INTEGER;

The LONGLONG is __int64 type. So, if your compiler and CPU supports 64bit data type, you can access the content of the LARGE_INTEGER with the QuadPart.

The 1st glitch is that the returned value easily exceeds the boundary of the 64bits for the QuadPart, because current CPUs are so fast.
(If you search on the Google, you will find some web pages on which people explain that it exceeds the 32bit boundary.
And they recommend to use 64bit data type. Well, actually it even exceeds the 64bit boundary. )
So, probably you can use unsigned __int64 instead.

The 2nd glitch is that you can’t print them out properly when you use %I64d for aVal.QuadPart/aFreq.QuadPart.
Even %Lf doesn’t solve the problem. They are all for 64bit integer and real numbers. Then how to display them properly?

printf("%f", (double)aVal.QuadPart/(double)aFreq.QuadPart);

double is also 64bit real number type, and it works.

The 3rd glitch is the real glitch.
Let’s take a look at this screenshot from real invocation of the code.

Hmm… Why the high performance counter is not reliable?
By searching on the Google, I found a clue that it was due to the speed-step or similar technology which changes the CPU speed on demand.
Because it has very high resolution, it has the glitch.
I read somewhere in Intel’s forum that Intel or MS was working on making the call to measure on the FSB side instead of inner core of the CPU.
By doing so, it is said that the function would return more reliable value even when battery-saving technology in a CPU is used.

I assume that the GetTickCount() Win32 API function is also based on the clock(). However, it displays somewhat expected result seemilgy reliably.
The clock()/CLOCKS_PER_SEC displays 2 and 1.9… from time to time.

Probably the GetTickCount() has the lowest resolution.
However, one convenient side of using the GetTickCount() is that it returns a value in millisecond, if you want “time” instead of number of ticks.
So, you don’t need to divide it by some constant like CLOCKS_PER_SEC. Then it should be renamed to GetTickTime().
Well.. the function name again misleads, but it is the brain-child of the MS.

Finally, here is a screenshot when all of them return good results.