Archive for October, 2011

New Task Manager for Windows 8

Posted: October 29, 2011 in Operating System

Microsoft has released some pictures of the task manager in its new design for Windows 8. Below are some pictures.

New Task Manager showing 160 logical processor

New Task Manager showing 160 logical processor

Tooltip showing the logical processor ID

Tooltip showing the logical processor ID

Heat map scales to best fit, and a scroll bar appears as needed.

Heat map scales to best fit, and a scroll bar appears as needed.

Set process affinity from the Details tab

Set process affinity from the Details tab

Fewer details view

Fewer details view

More details view

More details viewGrouping by process type


The Nautilus file manager in Ubuntu features a search-for-document tool for quite a long time. However, its functionality is quite limited as it allows the user to search only for file name, but not the contents of the file. Personally, I was quite shocked because the ability to search for file contents has been available in its Microsoft counterparts since Windows 98.

Apparently, Linux users are more proficient at the command line. Grep is a command line tool that allows the user to search for specific pattern or text, given lines from the standard input or a file. Once you know grep, searching the content of files will become so easy as never before.

To search in a single file, use the following command. (Please do not type in the ‘$’, which is the prompt symbol for a terminal).

$ grep "Search text" filename.txt

Typically, we would like to look up the file contents of the whole directory. We can use the -r option to search recursively under a directory and use the -l option to suppress printing every matched lines and printing only the matching file names.

$ grep -r -l "Search text" dir

Or instead, if we wish to print every lines, the -n option can be used to print line numbers.

$ grep -r -n "Search text" dir

Besides, grep supports the use of regular expression by passing it the following options: -G (Basic RegExp), -E (Extended RegExp), and -P (Perl RegExp).

Below are some other usage of grep, which uses piping, i.e taking the output of another command and directing it back into the standard input, so that grep can search within the output. Some of us probably have known these commands before digging deep into grep, since these commands are so widely use.

$ lspci | grep 'Network'
$ egrep '(vmx|svm)' /proc/cpuinfo
$ ls -l | grep rwxrwxrwx
$ ps -A | grep -i firefox
$ du | grep 'mp3' | more
$ dmesg | egrep '(s|h)d[a-z]'
$ ps -ef | egrep '^root ' | awk '{print $2}'
$ lsof | grep -i TCP
$ lsof | grep ' root ' | awk '{print $NF}' | sort | uniq | wc -l

Finally, I would leave it for you, the reader, to figure out what each the above command does.

The very fundamental coordinate system in Microsoft Windows OS that every PC user should know has the unit of “PIXELS”. This is known as the Device Coordinate System, or more specifically Display Device (Screen) Coordinate System. In fact, many a Windows programmer has come to know only this specific coordinate system.

The coordinate system originates from the top-left corner of the screen. The X-axis extends in the positive direction when going towards the right of the screen; while the Y-extends increases in the positive direction when going downwards the screen. The direction of the y-axis is thus flipped in the opposite direction compared to the Cartesian system that we are familiar with. A “pixel” is the smallest unit representable on the screen, and it is therefore the unit used for this coordinate system.

The number of pixels that can be displayed on the screen is also referred to as the screen’s real-estate. It also depends on the resolution settings. A larger resolution (eg: 1920 x 1080) will give you more screen real estate compared to a smaller resolution (eg: 1024 x 768). However, the graphics and fonts will appear smaller if a larger resolution is used. A Windows application can query the screen resolution using the WINAPI functions such as GetDeviceCaps(HORZRES) and GetDeviceCaps(VERTRES), which would give the width and height, in pixels, of the screen respectively.

Screen coordinate system

The diagram showing the direction of x- and y-axis in the screen coordinate system

If your application only exists on the screen, that will be all you need to know. However, if you are dealing with real world dimensions, e.g: printing, I would like to introduce to you two new coordinate systems, which are the logical and physical coordinate systems.

The physical coordinate system corresponds to real world measurement units, which are gauged by two important set of standards, i.e the Metric system and the old Imperial system. The standard metric units are like millimeters, centimeters, meters, and kilometers; while the Imperial units are inch, foot, yards, and miles. The measurement values may contain floating-point values (or decimal values), e.g: 1/2 inch, 3.65cm, 1.8 miles, etc, since we can never expect real world measurements to be consisting of round values (or integers) only. Of course, these physical units are units that can be measured using physical tools, and their applications are almost seen everywhere –  trade, design, manufacturing, construction, aerospace and all sorts of engineering.

Today, almost every of the above industries uses software. It is really important that we could represent physical dimension on screen as accurately as how we could draw it on paper. Software needs to know physical dimensions.

The logical coordinate system is introduced not without reason. Back in the days when Windows 3.0 was first released, floating-point computing power is not as abundant as in today and some computers do not even have a floating-point coprocessor. Certainly, integer operations are more preferred and that is why all WinAPI functions specify integers as parameters. This includes all drawing and GDI-related calls. In order to overcome the limitation of representing physical units in integers, the logical units have come to be introduced.

The physical length that corresponds to a logical unit depends on the mapping mode used. Each device context (or drawing surface) in windows can be set to its own mapping mode.

Mapping mode Meaning
MM_HIENGLISH Each logical unit is mapped to 0.001 inch. Positive x is to the right; positive y is up.
MM_HIMETRIC Each logical unit is mapped to 0.01 millimeter. Positive x is to the right; positive y is up.
MM_LOENGLISH Each logical unit is mapped to 0.01 inch. Positive x is to the right; positive y is up.
MM_LOMETRIC Each logical unit is mapped to 0.1 millimeter. Positive x is to the right; positive y is up.
MM_TEXT Each logical unit is mapped to one device pixel. Positive x is to the right; positive y is down. (This is the default.)
MM_TWIPS Each logical unit is mapped to one twentieth of a printer’s point (1/1440 inch, also called a twip). Positive x is to the right; positive y is up.

Now, an application can draw in physical dimensions, using the mapping mode defined by its own. The application also needs to store dimension data. It is thus necessary that the programmer recognize the coordinate system used for storing the data and maintain uniformity throughout his application in order to avoid confusion. Typically, only one set of coordinate system (physical or logical, but not device coordinates) will be used for the actual storing of data. The reason device coordinate system not being used is that the measurement is device-dependent.

With logical coordinate system, you can print out a perfect 3cm x 3cm square by setting the width and height to 300 x 300 logical units, assuming you are applying the MM_LOMETRIC mapping mode.

However, there is one caveat. Using logical coordinates will let you print out accurate dimensions on paper but on screen, it gives you proportional size but doesn’t guarantee accurate dimensions. Why would you need that after all? As long as the application display a virtual ruler containing the correct scale, you wouldn’t take a ruler to measure the dimension of an object on screen, or would you? Recall that Microsoft Word also features two sets of ruler (one vertical, one horizontal), and that would tell you the real measurements of every object on the document.

Another reasoning is that Windows knows nothing about the size of your screen. What it can do is basically assume the number of pixels that makes up a logical inch. Typical this value is set at 96, and in the unit dpi (dots per inch). Hence, if your screen has a resolution of 1280 x 800, Windows assume that your screen has a virtual size of (1280/96)” x (800/96)”  = 13.333″ x 8.333″, whereas in reality your screen might be smaller, e.g:10.25″ x 6.40″ . That’s why you couldn’t display real dimensions on screen. With printer, however, the dpi of the printer device itself is usually fixed at 600 dpi or 1200 dpi, thus Windows has no problem printing out an accurate dimensions.

Back to our topic on logical units, there is one more mapping mode worth mentioning, i.e: MM_TWIPS. Each logical unit is mapped to one twip, the equivalent of 1/20 point or 1/1440 inch.

1 pt = 1/72 inch

1 twip = 1/20 pt = 1/1440 inch

These units belongs to the units that describe font size, e.g: 12 pt . Thanks to Steve Job for taking calligraphy classes and introducing fonts in the first Macintosh computer, today we can have wonderful and attractive fonts in our computers.

Font Height Measurement

Font Height Measurement

A font has several height attributes (as shown above). Try guess which attribute would represent the font size in points. Guessing net height? Yes, you’re right. Actually, The point size corresponds to the difference between tmHeight and tmInternalLeading, i.e net height. For instance, with the MM_TWIPS mapping mode in effect, a selected 12-point font might have a tmHeight value of 295 logical units and a tmInternalLeading value of 55. The font’s net height of 240 corresponds to the point size of 12 (since 12 pt = 240 twips).

After all, why should I dig myself into all these? There are many applications that simply fail to realize the relationship between the different coordinate systems. This causes the WYSINWYG (what you see is not what you get) problem- what you see on screen, you won’t definitely get it on printer. The hardest part is probably to handle the conversion between point size and pixels or  between point size and physical units. Therefore, when you are going to implement printing in your application next time, make sure you do it perfectly.