It’s not a symptom, it’s a feature

Medical science has developed amazing tools to examine the human body over the years. Petri dishes, incubators, and various types of cultures identify infections. Ultrasound, X-rays, CT, MRI, FMRI and PET use different kind of technologies to give doctors a better view and understanding of our inner working. In extreme cases, ever advancing surgery techniques provide hands on approach.

Most of us will only get to use these when seriously ill or seriously rich and paranoid. Despite all those mind-boggling technological innovations, when Joe sick-pack goes to the doctor he gets examined with a stethoscope, wooden stick, thermometer, analog sphygmomanometer and a whole lot of MD fingers. Verbal inquiring is another characteristic instrument doctors wield at medical proficient Joe sixth-pack, who is prone to lies of shame. It seems development of widespread diagnostic equipment available at doctors’ disposal has reached a stall a few decades ago. Funds keep flowing into research for ever more powerful drugs and fancier high-end diagnostic machines, promoting production of solve-all power tools or solutions for high profile diseases affecting only a fraction of the population. When all you have is a broad-spectrum antibiotic and ancient diagnostic equipment, everything looks like a superbug. Ironically, overuse of broad-spectrum antibiotic is a catalyst of superbug evolution. Other risks of antibiotics include side effects and an allergic reaction, yet antibiotic medicine is still one of the most powerful tools available at doctors’ disposal.

Absence of efficient analysis methods leads not only to over reliance on solve-all power tools, but also avoidance of the real issue at hand by both doctors and patients. Falling back to symptom treatment rather than going head to head with the real issue is the simpler choice, especially when facing rudimentary findings that can only be supplemented with extensive and cost-inefficient tests. Such a misinformed treatment could subject the patient to unnecessary side effects and hide the underlying illness by removing its symptoms, allowing it to stride on and mature, reducing chances of early discovery and treatment that can be sometimes save a life. It can also subject the patient to unnecessary dangerous operations where a simpler solution might exist.

It’s easy to blame doctors and the pharmaceutical industry for pushing drugs on unsuspecting patients, but both are just doing their jobs while trying to keep up with overwhelming crowds of sick, aching and impatient masses. Patients get no more than a few minutes each and are handled with archaic diagnostic equipment, forcing workarounds or guess work and hand-offs to busy specialists. It would seem our healers are doing the best they can under the circumstances, developing and distributing powerful drugs that work for most cases while favoring side effects over precise treatment in the name of cost efficiency and large scale medicine.

An analogy can be drawn to the computing world and specifically to debugging. Bug squashing consists of the same steps as illness treatment – discover symptoms, analyze, hypothesize, apply fix, rinse and repeat until symptoms disappear. Quality relevant analytic tools and deep understanding of the code make analysis easier and improve chances of spotting and fixing the bug faster; removing the need for quirky workarounds. Powerful and accessible tools like symbols, windbg, sysinternals, virtual machines, logs facilities, scriptable environments and automated test scenarios shed light over system internals and allow extensive yet concise overview of the issue, quick theory debunking, solutions for common issues, and easy verification of solutions. Imagine how powerful a vital signs logging facility would be at detecting anomalies, how much simpler analysis would be with body part isolation by virtualization, how less stressful it would be if every piece of the human body was marked with an appropriate name regardless of its current location, how enlightening it would be to view processes in a streamlined graph, and how relaxing it would be for the patient to know all is well on the spot instead of waiting for the test results.

Sci-fi inspired whole body scanner with shiny lasers able to detect the issue in a few seconds, fix it with a different color of laser and then make coffee will probably not be invented for a few more centuries, but there’s no need to get carried away. When debugging a system, human or digital, every little diagnostic tool should help. Cheap discrete heart monitor for rhythm irregularities detection, microbiological culture device with the ability to identify common infections with no need for a microscope, common antibodies detector, or a portable x-ray device would all reduce the burden and encourage better solutions overall.

Hopefully, the recent rise in biotechnological studies over the last few years will show its affect soon and shift focus from drugs to widespread diagnostics and narrow treatments.

2012 bug

I recently watched a trailer for the new 2012 movie. It seems like a pretty decent apocalyptic movie written and directed by the same guy behind two other similar movies – Independence Day and The Day After Tomorrow. Famous actors, staggering visual effects and the genre-mandatory destruction of the White House by a ship are all included. It was enough to get me hooked, fully hoping for another immersing experience and the nightmares that will surely follow.

While the movie will probably be a blockbuster and deserves its credit, the concept behind it – an apocalypse occurring on December 21, 2012 predicted by the Mayan; is a misunderstanding at the very least. The Mayan, as any other respectable civilizations, had a calendar of their own to keep track of time. In particular interest is the long count – a cycle of approximately 5129 years. According to it, a day is called k’in. 20 k’ins are one winal. 18 winals are one tun. 20 tuns are one k’atun. 20 k’atuns are one b’ak’atun. Each b’ak’atun is 144,000 days, or approximately 394 years. A long count cycle consists of 13 b’ak’atuns, or 5129 years. Day zero, believed to be the creation day, is August 11, 3114 BC. Mayan math is base-20 and so date can be represented by five digits. In ye olde times that would be five groups of a bunch of stripes and dots listed from top to bottom. To make things more manageable for us modern people, a series of 5 modern numbers separated by dots is used. Today, for example, is 12.19.16.10.16. That is 12 b’ak’atuns, 19 k’atuns, 16 tuns, 10 winals and 16 k’ins or 5125 years since day zero.

Through various reasoning, certain academic scholars have concluded that at the end of each such cycle comes a grand and possibly cataclysmic event. Mayan scriptures make no direct reference to such an event and my personal belief is that interpretation of 13-b’ak’atun-ia party invitations have gone seriously awry; but an even simpler explanation exists.

Much like modern day engineers, Mayans had to carefully balance versatility and resources and perform a cost-benefit analysis. Understandably, they decided including the long count index in every date would be a waste of resources. Instead of carving six digits, accommodating for multiple long count cycles, they opted for ambiguity by implying the long count cycle. Imagine the vast amount of stone that would have gone to waste should every contract, ticket, advertisement, news paper and document of Mayan times had included another digit, just so it could be valid 5000 years into the future long after they and everything they knew was dead. That brilliant decision probably allowed the construction of another pyramid or two.

In fact, the Mayans are to be admired. When our modern day engineers faced the same challenge, they opted for a century time frame in favor of resources thus unleashing the infamous Y2K bug onto an unsuspecting world. It was believed date ambiguity would cause banks to fail, computers to crash and burn, zombies to overrun the streets and anniversaries to be forgotten thus eliminating any possibility of further human reproduction. Much of the same and more is being predicted for 2012 with the same reasoning. The apocalypse is looming at an arbitrary date due to green and efficient Mayan engineering. But despite widespread usage of technology and date abbreviation in our days, short of a few minor glitches, nothing occurred on January 1, 2000. Considering the 2012 bug concerns ancient technology no longer in use, the idea seems even more absurd.

Therefore, assuming you are not using Mayan computers, live in a mortgaged Mayan pyramid or somehow related to Indiana Jones; you’re welcome to join me for a Mayan themed end-of-the-world movie marathon on 0.0.0.0.1, or December 22, 2012.

Russian Conversation Synthesizer

Inspired by our dear friend Ilya, my friend Ron has engineered a little Python script to simulate Russian phone chats with a little help from Microsoft Sam. Ron has slaved over this task for a whole grueling 5 minutes. We proudly named our magnificent product RCS – Russian Conversation Synthesizer.

Not for the faint of heart…

import random
import win32com.client

speak = win32com.client.Dispatch('Sapi.SpVoice')
speak.Volume = 100
speak.Rate = 6
speak.Voice = speak.GetVoices('Name=Microsoft Sam').Item(0)

while True:
  speak.Speak(random.choice(["blat", "huui", "suukkaa"]))

This lovely script would typically generate an authentic conversation such as:

suukkaa blat blat huui blat suukkaa

Debug Xen Hosted Windows Kernel Over Network

Read the original at my company’s blog.

Blue screens are not a rare commodity when working with virtualization. Most of the times, full crash dumps do the trick, but sometimes live kernel debugging is required. Hard disk related crashes that prevent memory dumping is a good example where it is required, but there are times where it’s just easier to follow the entire crash flow instead of just witnessing the final state.

Type 2 (hosted) virtualization usually comes with an easy solution. But type 1 (bare metal) virtualization, like Xen, complicates matters. Debugging must be offloaded to a remote Windows machine. The common solution, it seems, is to tunnel the hosted machine’s serial connection over TCP to another Windows machine where WinDBG is running, waiting anxiously for a bug check. There are many websites describing this setup in various component combinations. I have gathered here all the tricks I could find plus some more of my own to streamline the process and get rid of commercial software.

Lets dive into the nitty gritty little details, shall we?

Hosted Windows

Kernel debugging requires some boot parameters. Windows XP includes a utility called bootcfg.exe that makes this easy.

bootcfg /copy /id 1 /d "kernel debug"
bootcfg /raw "/DEBUG /DEBUGPORT=COM1" /id 2 /a
bootcfg /raw "/BAUDRATE=115200" /id 2 /a
bootcfg /copy /id 2 /d "kernel debug w/ break"
bootcfg /raw "/BREAK" /id 3 /a

This assumes you have only one operation system configured in Windows boot loader. If the boot loader menu shows up when Windows boots, you might need to add the flags on your own to C:\boot.ini.

Xen Host

Windows will now try to access the serial port in search of a debugger. Xen’s domain configuration file can be used to forward the serial port over TCP. Locate your domain configuration file and add the following line. The configuration files are usually located under /etc/xen.

serial='tcp::4444,server,nowait'

Debugger Machine

The server side is set and it’s time to move on to the client. As previously mentioned, WinDBG doesn’t care for TCP. Instead of the usual TCP to RS-232 solution, named pipes are used here. I wrote a little application called tcp2pipe (download available on the bottom) which simply pumps data between a TCP socket and a named pipe. It takes three parameters – IP, port and named pipe path. The IP address is the address of the Xen host and the port is 4444. For named pipe path, use \\.\pipe\XYZ, where XYZ can be anything.

tcp2pipe.exe 192.168.0.5 4444 \\.\pipe\XYZ

All that is left now is to fire up WinDBG and connect it to \\.\pipe\XYZ. This can be done from the menus, or from command line.

windbg -k com:pipe,port=\\.\pipe\XYZ

To make this even simpler, you can use kdbg.bat and pass it just the IP. It assumes WinDBG.exe is installed in c:\progra~1\debugg~1. If that’s not the case, you’ll have to modify it and point it to the right path.

tcp2pipe

Source code is included in zip file under public domain.

Download tcp2pipe.zip (mirror).

Happy debugging!

SourceForge tracker and SVN integration

TortoiseSVN and some other Subversion clients have a cool feature for integration with issue trackers. By setting a few properties for a project, you can have automatically generated links to tracked issues directly from SVN commit messages. TortoiseSVN also supports a special input method for issue numbers in commit boxes for easier integration.

The basic property that must be set is bugtraq:url which lets SVN know how to form a URL from an issue number. This is a bit difficult with SourceForge, where there are in fact at least three trackers and each with its own URL scheme including the tracker identifier in the URL. Toying with the URL and removing both group and tracker identifiers results in an error. After playing around some more, I found the following URL that works like a charm for every group and any tracker so there isn’t even a need to figure out the group identifier.

http://sourceforge.net/support/tracker.php?aid=%BUGID%

It took me a while to figure out and I couldn’t find any mention of it online, so I thought I’d post it here to help others.

For more information on all of the related properties see TortoiseSVN’s page.

Lorena Kichik

I don’t know why or how, but Google seems to think my little blog is worth something. Terms like “quake flag”, “triple double u”, “the green wire” , “atomic codes” and even “mr. angry pants” return some of my posts in the top 10 results and sometimes even as the first result. NSIS seems to share the same glory with terms like “java runtime download”, “strstr”, “exch”, “createmutex”, “iis version”, “messagebox”, “steam account” and even “windows critical update”. This Google love is very nice and helpful for NSIS but it doesn’t get too much of my attention span when it comes to this blog. People searching for my name or nickname find it as the first result and that’s good enough for me.

However, out of pure curiosity, I’ve decided to perform a little Google experiment. Searching for “kichik” results in my blog and some pages concerning a beautiful actress named Lorena Kichik. Her profile states she’s latin or middle eastern, so I’m not so sure how she ended up with Hungarian or Pakistani last name, but that’s another story. I’m not exactly sure what I’m going to figure out here, but I wanted to know what happens if I directly mention her in my blog. Will this post show up when searching for her name? Will it show when searching for mine? Which would come first – my post or her Facebook or IMDB profile?

Let the games begin!

Pragmatic variant

As mentioned in my previous post, I have been working on incorporating some more features into WinVer.nsh. Every little change in this header file requires testing on all possible versions and configurations of Windows. Being the Poor Open Source DeveloperTM that I am, I do not have sufficient resources to assemble a full-blown testing farm with every possible version of Windows on every possible hardware configuration. Instead, I have to settle for a bunch of virtual machines I have collected over the years. It is pretty decent, but has no standards and doesn’t cover every possible version. Still, it does its job well and has proven itself very effective.

Obviously, be it a farm or a mere collection of virtual machines, testing on so many different configurations carries with it a hefty fine. Testing a single line change could waste almost an hour. Imagine the time it would take to test, fix, retest, fix and retest again a complete rewrite of WinVer.nsh. As fascinating as that empirical scientific experiment would have been, I was reluctant to find out. Laziness, in this case, proved to be a very practical solution.

WinVer.nsh tests do not really need the entire operation system and its behavior as it relies on nothing but 4 parameters. All it requires is the return values of GetVersionEx for OSVERSIONINFO and OSVERSIONINFOEX. For nothing more than 312 bytes, I have to wait until Windows Vista decides it wants to execute my test, Windows NT4 gracefuly connects to my network, Windows ME wakes up on the right side of the bed and doesn’t crash, Windows Server 2008 installs again after its license has expired and Windows 95…. Actually, that one works pretty well. So why wait?

Instead, I’ve created a little harvester that collects those 312 bytes, ran it on all of my machines and mustered the results into one huge script that tests every aspect of WinVer.nsh using every possible configuration of Windows in a few seconds. It required adding a hooking option to WinVer.nsh, but with the new !ifmacrondef, that was easy enough.

Currently, the script tests:

  • Windows 95 OSR B
  • Windows 98
  • Windows ME
  • Windows NT4 (SP1, SP6)
  • Windows 2000 (SP0, SP4)
  • Windows XP (SP2, SP3)
  • Windows XP x64 (SP1)
  • Windows Vista (SP0)
  • Windows Server 2008 (SP1)

If you have access to a configuration not listed here, please run the harvester and send me the results. More specifically, I could really use Windows 2003 and Windows Vista SP1. My Windows Vista installation simply refuses the upgrade to SP1. Again.

The test script also includes a hexdump of those 312 bytes for every configuration so anyone performing similar tests for another reason doesn’t have to parse the NSIS syntax. Feel free to use it for your testing.

Voodoo fabrication

Last week I’ve decided it’s time to apply a few long overdue patches some people have submitted. The main issue with patches is that the patch submitter and patch applier are never the same person, unless you’re on lithium in which case the code is bound to be intriguing any way you spin it. But the lack of clear coding guidelines or my code review process is a whole other topic.

One of the patches was Anders’ WinVer.nsh patch for Windows Server 2008 support along with some other nifty little features. You would think this would be a pretty simple patch, but Microsoft had a surprise for us in this case. I admire Microsoft for their dedication for backward compatibility and basic API coherence, but in this case of version detection, they got it a bit mixed up. There are three API functions to get the version, two of them work on all versions of Windows and one of them has two operation modes. To get special features information there’s another completely unrelated inconspicuous function. The format of the returned data depends on the version and on operation mode used. In short, it’s a bag full of fun and games and there’s never a dull moment testing every little change on every possible configuration of Windows.

For the original version of WinVer.nsh, I used the simplistic GetVersion API which requires about 3 lines of code. Later on a patch was submitted to support verification of service pack numbers which required the usage of GetVersionEx’s two modes of operation. This required quite a bit more code, but that code was only used when SP were specifically checked. With the latest patch for Windows Server 2008 support, the simplistic API was no longer enough and a full blown function using every possible API and doing a lot of math and bit shuffling was required. And therein lies the catch.

As we yet to have developed real code optimization mechanisms, code duplication makes the installer bigger and bigger is not better in this case. The code could go into a function which will be called by every usage of WinVer.nsh, but that would mean a warning will be generated in case the function is never called because it can’t be optimized. A requirement to declare the usage of WinVer.nsh could be added, but that would break the number one rule I’ve learned from Microsoft – backward compatibility. All three issues are on the top 10 frequently asked questions list and getting my costumers a reason to ask them even frequently-er is not in my wish list.

As the code size grew bigger WinVer.nsh, I started pondering of a way to solve this. The obvious solution would be adding code optimization and that’s already functioning neatly in my beloved nobjs branch that’s sadly not yet ready for prime time. And so I had to think of another idea that could work with the current branch and so Artificial Functions were conceived. Instead of letting the compiler create the function, I’ve used some of the lesser known features to create them on my own. A combination of runtime and compile-time black magia using both old and new features allowed me to get rid of the code duplication.

To make sure the code of the function isn’t inserted more than once, the good old !ifndef-!define-!endif combo is used. But the function can be called from more than one scope and so it must be globally locatable. Exactly for this purpose, global labels were added over six years ago. However, that’s not all as the function must somehow return control to the original code that called it. To do this Return is used at the end of the function’s code and Call is used to treat the global label as a function and build a stack frame for it. Last but not least, we have to do deal with uninstaller functions that can’t jump to code in the installer as they don’t share the same code. The new __UNINSTALL__ definition saves the day and helps differentiate installer’s and uninstaller’s code.

!macro CallArtificialFunction NAME
  !ifndef __UNINSTALL__
    !define CallArtificialFunction_TYPE inst
  !else
    !define CallArtificialFunction_TYPE uninst
  !endif
  Call :.${NAME}${CallArtificialFunction_TYPE}
  !ifndef ${NAME}${CallArtificialFunction_TYPE}_DEFINED
    Goto ${NAME}${CallArtificialFunction_TYPE}_DONE
    !define ${NAME}${CallArtificialFunction_TYPE}_DEFINED
    .${NAME}${CallArtificialFunction_TYPE}:
      !insertmacro ${NAME}
    Return
    ${NAME}${CallArtificialFunction_TYPE}_DONE:
  !endif
  !undef CallArtificialFunction_TYPE
!macroend

When combined all together, it not only solves the code size issue for WinVer.nsh, but also rids the world of two very frequently asked questions about our standard library. It took a few good hours, but after converting FileFunc.nsh, TextFunc.nsh and WordFunc.nsh to use the new Artificial Functions; there’s no longer a need to use forward decelerations for those commonly used functions and calling them in uninstaller code is no different than calling them in the installer.

!include "FileFunc.nsh"
!insertmacro GetFileExt
!insertmacro un.GetParent
Section Install
     ${GetFileExt} "C:My DownloadsIndex.html" $R0
SectionEnd
Section un.Install
     ${un.GetParent} "C:My DownloadsIndex.html" $R0
SectionEnd

Goes on a diet and elegantly transforms into:

!include "FileFunc.nsh"
Section Install
     ${GetFileExt} "C:My DownloadsIndex.html" $R0
SectionEnd
Section un.Install
     ${GetParent} "C:My DownloadsIndex.html" $R0
SectionEnd

I love it. This trick is so sinister. It reminds me of the days Don Selkirk and Dave Laundon worked on LogicLib. Coming to an installer near you this Christmas.

Countdown

Memory is a fascinating mechanism. Electric currents running through biological matter draw input from sensitive organs and store anything from scents and pictures and all the way to logical conclusions. It’s the simplest time-machine implementation and it’s embedded in our brains, allowing us to travel back in to our history.

Commonly, it’s divided to short-term memory and long-term memory. Short-term memory is the working memory. It holds temporary but currently-crucial information retrieved from sensors, long-term memory or the result of a mental process. It is estimated that short-term memory is capable of holding up to seven items at any given time. As with many other areas in life, that number is magical and quite stubborn at keeping its status quo. To that end, common memory improvement techniques focus on methods of getting around that number instead of increasing it. A method I affectionately call “divide and conquer” suggests grouping items and memorizing the groups instead of the items themselves, so that more items can be memorized. It’s actually an expansion of the very basic naming method. Complicated items can be easily memorized when named — the very basic of all languages; allowing the commutation of complicated matters with simple words.

One of the most obvious implementations of these methods is known simply as “list”. By numbering and even naming large chunks of data, information could be efficiently conveyed and referenced. Under this principal books are divided into chapters, rules are presented as a list of do and don’ts, everything is divided to magical three items, and complicated ideas are abstracted and listed so that they may serve as a fertile ground for even greater ideas.

The problem with popular and useful methods is their wide abuse. Lately, I’ve witnessed an abundance of articles containing nothing but a list with sparse content and a very thin thread holding the bullets together. To help combat this epidemic, I hereby propose my list of list-don’ts.

  1. While a very good memory technique, a list without any content is worthless. Forging pointless data into a list will not breath life into it. At the very best, it’d help the pointless data being pointlessly forgotten.
  2. Lack of good transition between paragraphs qualifies for more content or some transitional devices and not a list.
  3. Bullets before the punch line won’t necessarily make it funnier. It will, however, make the journey leading to the punch line a boring one.
  4. There are rare cases where a list genuinely qualifies. There is no need to overstate this by noting it in the title.
  5. When already writing a list, keep it short and to the point. Three, seven, ten and thirteen are nice magical numbers. That’s not a good enough reason to pad lists.

Pixel shifting

Every picture is worth a thousand words, they say. In total, I’ve written the equivalent of 13 pictures in this blog. I thought I’d have at least 50, but apparently I don’t write that much. For the fourteen-thousandth word, I’ve decided to create an actual picture. Sadish’s MistyLook has served me well for a long time, but I felt it is time for a change and so this new theme was born. It’s not perfect yet and I’ll probably keep working on it, but I really like it and it fits me well.

It was quite fun to create this new theme. It allowed me to resurrect deeply burried skills I thought I’d never touch again. I’ve also learned that I need a Wacom tablet, Firebug is priceless, CSS is even more powerful than I remembered and Kim’s Lakers pen is a life saver.