Code for Concinnity

Meteor gets $9M in funding — by reinventing a 10 year old technology

Meteor, a JavaScript framework that allows you to rapidly create “real-time” Web application (think AJAX-y), just got $9M in funding. So it’s all cool and good, and it feels like how Ruby on Rails removed the pain out of doing Web CRUD apps half a decade ago.

But… why not Flash?

If you showed Meteor’s screencast to a semi-techy friend, you might get asked that question. Sure, Meteor makes your Web app look cool and slick with all the real-time updates and stuff.

But actually, deep down you know that Flash could already do that ten years ago. I mean, even Java Applets could do “real time” dead reckoning a decade ago. You may argue that we couldn’t have done it in a Web browser 10 years ago — but in terms of actual functions performed, it’s difficult to get any solid arguments.

But Flash requires a plug-in!

Typical arguments against Flash:

  • It requires a plug-in — before Steve Jobs banned Flash for political reasons, its penetration rate was 95%+
  • It’s proprietary — as is Windows, Photoshop, and even iOS.
  • It impedes SEO — as if a dynamic Web application is very SEO friendly.

Lesson Learned?

So what can we make of it? Flash more or less killed itself when acquired by Adobe which led it down the path of stagnation and non-innovation.

Of course, it’s not like getting $9M in funding is a success measure in and of itself. Definitely not fair where Flash is a solid revenue generating product vs Meteor a “welfare” project. So we’ll see…

Published by kizzx2, on August 13th, 2012 at 10:54 pm. Filled under: UncategorizedNo Comments

Local/project-based .ackrc

If you use Ack, you may be annoyed by the fact that it only reads $HOME/.ackrc but not the project-local ./.ackrc.

It turns out it is quite easy to do it yourself by creating a simple shell script wrapper and then aliasing the ack command:

if [ -f ./.ackrc ]
  ackrc=$(tr '\n' ' ' < ./.ackrc)
ack $ackrc $*
# ~/.bashrc
alias ack="$HOME/bin/"

That’s it! Now I can create a .ackrc file at project root like this:


Now using this technique, one can easily create a wrapper than reads both $HOME/.greprc and ./.greprc and you get Ack’s functionality in grep! Now you wonder if we really need Ack at all 😛

Published by kizzx2, on July 11th, 2012 at 9:36 pm. Filled under: UncategorizedNo Comments

WinDBG + SOS: Failed to load data access DLL, 0x80004005

Today I received a dump file from a client. I fired up WinDBG and met this dreaded error. If you stumble upon this post you have probably tried all the other Google solutions (such as updating to the latest WinDBG).

Here are what I tried, and failed:

> .cordll -ve -u -l
CLR DLL status: No load attempts

> .exepath+ C:\path\to\mscordacwks.dll (No use)

Here is how I solved it:

  • First, I run the .cordll command that everybody recommends

> .cordll
CLR DLL status: ERROR: Unable to load DLL mscordacwks_x86_x86_2.0.50727.3625.dll, Win32 error 0n87

  • The client was running Windows Server 2003 SP2. The mscordacwks.dll I have in my Windows 7 box was 2.0.50727.5448

> !sym noisy
> !clrstack

CLRDLL: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscordacwks.dll:2.0.50727.5448 f:0 doesn't match desired version 2.0.50727.3625 f:0 SYMSRV: c:\symcache\mscordacwks_x86_x86_2.0.50727.3625.dll\4E154C985a9000\mscordacwks_x86_x86_2.0.50727.3625.dll not found SYMSRV: not found SYMSRV: C:\SymCache\mscordacwks_x86_x86_2.0.50727.3625.dll\4E154C985a9000\mscordacwks_x86_x86_2.0.50727.3625.dll not found SYMSRV: not found CLRDLL: Unable to find mscordacwks_x86_x86_2.0.50727.3625.dll by mscorwks search CLRDLL: Unable to find 'mscordacwks_x86_x86_2.0.50727.3625.dll' on the path

  • So, it looks like this DLL is actually missing on MS’s server.

  • In a desperate atttempt, I tried to search the file in Google

  • To my surprise, I found the file in a security update

  • I downloaded the x86 file, opened the file in a zip and scavenged the required DLLs from there.

  • I had to rename the DLL files. In particular, I needed to duplicate mscordacwks.dll to mscordacwks_x86_x86_2.0.50727.3625.dll to please WinDBG

  • Load SOS manually .load C:\newly\downloaded\sos.dll

  • .sympath+ C:\newly\downloaded; .reload

  • (You may encounter an error if you have 2 SOS loaded at the same time. .chain, .unload should take care of stuff)

  • Volia! Now the game begins 🙂

Published by kizzx2, on February 12th, 2012 at 9:18 pm. Filled under: UncategorizedNo Comments

EFS causing lsass.exe Local Security Authority Process using 100% CPU

So I was using Windows EFS the other day to encrypt some files. This is surprisingly easy to use and beats TrueCrypt and Mac’s disk encryption in the usability department:

cipher /E /S:MyFolder

I encrypted AppData, which is a good thing to do since many applications leave its trace there. When I rebooted and logged in, I got lsass 100% CPU and a black desktop.

TL;DR If you changed your password via MMC, you need to re-import your EFS key

The way that EFS works is by protecting your EFS certificate with your login password. That implies some work needs to be done when you change your password. MMC’s “Set Password” doesn’t do it (it warns specifically against this, but this is the first time I actually read what it says :P).

It turns out that EFS spends quite a lot of CPU cycles for the wrong password case. Because I encrypted AppData, lsass would just spin itself with the obsolete password, trying in vain to decrypt the EFS cert.

So the way out was to remove the EFS key from certmgr.msc, and then reimport it. You may need to refresh the credential cache by

cipher /flushcache

If it worked, you should be able to display some encrypted text files transparently:

type test.txt

Tip: Use another account to runas /user:Victim cmd to do the above.

It’s been reported that the 100% CPU usage be related to the large number of SID files in AppData\Microsoft\Protect. I suspect it’s another consequence of this cause.

(The correct way to change password is to select Change Password in Ctrl+Alt+Del. I don’t know of a command line way to do it :/ Feel free to post in the comments)

Published by kizzx2, on February 3rd, 2012 at 5:15 pm. Filled under: UncategorizedNo Comments

Binding C++ classes to Lua: a step by step example for beginners

Well, I lied. This isn’t step by step but I believe this commented source code dump should be more illustrative than any tutorial I’ve read, here we go 🙂

Published by kizzx2, on January 11th, 2012 at 10:32 pm. Filled under: UncategorizedNo Comments

Premake whopping rocks! (or how Boost Build whopping sucks, or how to build Luabind for iOS proper)

Last time I wrote about how to build Luabind on OS X. Well, it turned out that was only half the battle won. Building Luabind for iOS (ARMV7) architecture just plain doesn’t work. It seems like some people have managed to make it work but none of what I have found actually worked. If you are reading this, I suppose you are also tired of jumping through hoops just to compile the damn thing, well, Premake to the rescue.

Let me tell you, this is how building stuff in C++ is meant to work:

Just create a file premake4.lua

-- premake4.lua
solution "luabind"
    configurations { "Release" }
    project "luabind"
        language "C++"
        kind "StaticLib"
        flags { "Optimize" }
        includedirs { ".", "/usr/local/include", "/where/is/your/lua" }
        files { "src/**" }


$ premake4 xcode3
$ xcodebuild -sdk iphonesimulator -configuration Release -arch i386
$ xcodebuild -sdk iphoneos -configuration Release -arch armv7

Boost Build whopping sucks. Premake is written by one guy and this turns out to be so trivial (as it should be).

Hope it helps.

Published by kizzx2, on January 10th, 2012 at 11:25 pm. Filled under: UncategorizedNo Comments

Building luabind on Mac OS X

Update: Apparently it may be working now. See Socapex’s comment below.

$ # If you have used the Homebrew recipes -- they don't work
$ brew uninstall lua
$ brew uninstall bjam
$ # The current version of LuaBind doesn't compile with Clang.
$ Fortunately the GitHub HEAD does.
$ git clone
$ # LuaBind currently does not compile with Lua 5.2
$ wget $BOOST_URL
$ wget $LUA51_URL
$ wget $LUA_URL
$ cd /where/is/boost
$ chmod a+x tools/build/v2/
$ chmod a+x tools/build/v2/engine/
$ ./ toolset=darwin
$ cp bjam /usr/local/bin
$ export BOOST_ROOT=/where/is/your/boost
$ export BOOST_BUILD_PATH=/where/is/your/boost/tools/build/v2
$ cd /where/is/lua
$ make macosx
$ # We need these because LuaBind hard-codes the non-standard directory names
$ ln -s src include
$ export LUA_PATH=/where/is/lua
$ cd /where/is/luabind
$ bjam toolset=darwin link=static
Published by kizzx2, on January 9th, 2012 at 11:15 pm. Filled under: UncategorizedNo Comments

BOOTMGR is missing — totally demytisfied

A couple of years back I blogged about how I solved the frustrating and notorious “BOOTMGR is missing” error in Windows. Today I encountered it again and this time it seems to be more tenacious but I still tamed it after numerous trials. Here I document exactly what went wrong, why it happened and how to solve it.

Background information — how does Windows boot?

Here is a quick rundown. Every step below could possibly go wrong:

  1. The BIOS loads the MBR of the booting disk by handing over control to the code residing there. MS’s MBR code will then load the boot sector of the active partition. (If something is wrong here, we need bootsect /nt60 X: /mbr).

  2. The boot sector looks for \Boot\BCD and loads boot information from there. The BCD contains where BOOTMGR resides. If this step is wrong, you will see the infamous “BOOTMGR is missing”. To fix this, we need to correct the BCD by bcdedit (see below).

  3. Finally BOOTMGR loads winload.exe. If the device or osdevice is set to the wrong partition, Windows may report that winload.exe is corrupt. Normally you fix this by bcdedit. In the rare events that winload.exe is really corrupt, you may need to do a Windows Repair.

Why did it happen?

The base case for this to happen is a multi-hard disk computer. Variations may include changing hard disks after installation, but the principle is the same.

Suppose we have a computer with 2 hard disks:

  1. HDD1 (SATA 1/IDE 1)
  2. HDD2 (SATA 2/IDE 2)

That is, HDD1 comes before HDD2 in BIOS.

Since Windows cannot determine your boot order from BIOS, it will always configures the MBR in HDD1, and configures the boot sector of the first partition of HDD1 and also put Boot\BCD in the first partition of HDD1. It will always be HDD1, no matter which disk you decide to install Windows on.

Suppose you have the following boot order in BIOS:

  1. HDD2
  2. HDD1

And suppose you have installed Windows so that:

  • HDD1 — bootloader code
  • HDD2 — actual Windows installation

Then booting will fail and you will see the notorious BOOTMGR is missing error. Another reason you may see this is that you remove HDD1 after some time, thinking that your Windows installation is nicely contained in HDD2.

Why is Windows Repair not enough?

If you use Winodws repair it will install the boot code in HDD1 and you are forced to adjust the BIOS to boot HDD2 through HDD1. For me, it was a purist’s reason to want to move everything to HDD2.

So here is how exactly I tacked it.

How to fix it

The following steps are assumed to be done in the Windows Recovery environment command line. Boot up your Windows CD and press Shift+F10 to call up the command prompt. We will assume:

  • E: to be where Windows is installed.
  • F: to be where BCD is set up.
  • X: to be the Windows installation CD

1) First, make sure you set the Windows partition as active. You can do this using various partition software or just Google how to do it. Here is an example session using diskpart. You need to replace 99 with the correct numbers:

    > diskpart
    > list disk
    > select disk 99
    > list partition
    > select partition 99
    > active
    > exit

2) Now we gotta make sure the MBR of HDD2 is good to go:

    > cd /d X:\Boot
    > bootsect /nt60 E: /mbr

3) Now migrate BOOTMGR and Boot from F: to E:

    > cd /d F:\
    > attrib -s -e -h bootmgr
    > move bootmgr E:\
    > move Boot E:\
    > cd /d E:\
    > attrib +s +e +h bootmgr

4) Now use bcdedit to fix up the BCD

> cd /d E:\Boot
> bcdedit /store BCD /set {bootmgr} device partition=E:
> bcdedit /store BCD /set {default} device partition=E:
> bcdedit /store BCD /set {default} osdevice partition=E:

5) That’s it!

How to fix it from scratch (what I actually did)

If in the process you think you have screwed up so bad that you want to start over, you don’t have to reinstall Windows:

  • It is save to wife out both BOOTMGR and the Boot directory. You can find BOOTMGR in the Windows install CD.

  • To recreate the Boot directory, run bootrec /rebuildbcd. Windows will insist on creating it in the first partition in HDD1. You can apply the above techniques to patch up the newly created BCD and then move it to E:. Alternatively you can create BCD from real scratch by using the UUIDs from bcdedit /enum all.

  • You should be able to get Windows booted with just the two files E:\BOOTMGR and E:\Boot\BCD. If that worked you will find that Windows boots with Vista style’s green bar. To fix it:

> bcdedit /store E:\Boot\BCD /set {bootmgr} locale en-US
> xcopy /e /h X:\Boot\en-us\ E:\Boot\en-us\

That should be it. Enjoy!

Published by kizzx2, on December 27th, 2011 at 10:23 pm. Filled under: UncategorizedNo Comments

Irrlicht vs. Ogre for mobile game development

I have been evaluating several 3D frameworks for cross-platform mobile game development lately. Here’s my findings. To stay objective, I am just going to state a couple of hard facts as conclusion:

  • Irrlicht is smaller than Ogre. I did an actual experiment using both. I compiled both into static libraries (required for an iPhone deployment). A “Hello World” app with just one line of irr::createDevice (to get stuff statically linked) results in an 4MB executable; the same app with one line of new Ogre::Root results in an 6.5MB executable. The Ogre one is already heavily optimized by disabling FreeImage and some other components. (For the record, Cocos3D’s “Hello World” app demo is 2.5MB, but it is not cross platform at the moment).

  • The Ogre-iPhone “branch” is official; the Irrlicht OGL-ES branch is not official (yet).

  • Ogre-iPhone can do shader programming (OpenGL ES 2.0). There are OpenGL ES 2.0 files in the Irrlicht OGL-ES branch but I have not played with it and don’t know how mature it is.

That’s it. The size point might not be that relevant for desktop development but definitely is when it comes to small game developments. I actually prefer Ogre’s “more complicated” “syntax” (a much touted disadvantage by Irrlicht’s community) better but for this one I think I’m going with Irrlicht.

Published by kizzx2, on November 20th, 2011 at 12:55 pm. Filled under: UncategorizedNo Comments

Sencha Touch vs jQuery Mobile — a first look

Most people compare Sencha Touch to jQuery Mobile. My general impression from reading the Web is that Sencha is more heavy-duty, faster than jQuery. My actual experience, however, reveals that they are actually vastly different.

I recently started using PhoneGap to do mobile development. The idea of using Web technology to write cross platform apps is just so great!

The natural thing to do with PhoneGap would be to use a framework. There are many, just to name a few that I tried:

  • xui: Lightweight and fast, just as what you’d expect — jQuery on diet. I am not sure I am unlocking its real potential since examples/demos are non-existent at the time I write this. But this gets the job done.
  • Senca Touch: Claims to be “the best HTML5 mobile Web app framework”. The demos are polished and attractive.
  • jQuery Mobile: Good old familiar jQuery. The demos feel a little sluggish but overall still look good. It has less “widgets” than Sencha.

So let me get to the point of this post: I tried Sencha first and then tried jQuery. I will tell you that Sencha has slightly better performance but it’s approach really disappointed me.

Let me quote a snippet of Sencha Touch code from the PhoneGap tutorial on its Web site. This is how a typical Sencha Touch “class” look like:

app.views.ContactDetail = Ext.extend(Ext.Panel, {
  dockedItems: [{
    xtype: 'toolbar',
    title: 'View contact',
    items: [
        text: 'Back',
        ui: 'back',
        listeners: {
          'tap': function () {
            //  controller: app.controllers.contacts,
            //  action: 'index',
            //  animation: {type:'slide', direction:'right'}
        id: 'edit',
        text: 'Edit',
        ui: 'action',
        listeners: {
          'tap': function () {
            //  controller: app.controllers.contacts,
            //  action: 'edit',
            //  id: this.record.getId()
  scroll: 'vertical',
  items: []

Whew, that’s quite a lot of stuffs. Let me compare that with a selected part of a jQuery Mobile tutorial:

$('#buttonOK').click(function() {
  return false;      
$('#form1').submit(function() {
    var err = false;
    // Hide the Main content
    // Reset the previously highlighted form elements
    // Perform form validation
    if($(this).val()==null || $(this).val()==EMPTY){  
        err = true;
      err = true;
      err = true;
    // If validation fails, show Dialog content
    if(err == true){            
      return false;
    // If validation passes, show Transition content
    // Submit the form
    $.post("/forms/requestProcessor.php", form1Var.serialize(), function(data){
    return false;      

This looks so familiar. It’s just our good old jQuery. And the page was formatted with standard, vanilla HTML5.

The difference should now be apparent — jQuery Mobile is a real “moving the Web development experience to mobile platforms”, whereas Sencha is “moving ExtJS to the mobile platform”.

If you look at the code, you’ll find that the typical Sencha Touch application bears no resemblance to how a Web app looks like — it feels like writing Java view classes. Unless you were already an ExtJS expert, it’s like going to learn a whole different ecosystem. Maybe it’s just me, but I find that way more difficult to adjust the layout than HTML or using XIB GUI editor. Writing layouts in “plain text” feels like something from the 90’s, seriously. Every other GUI toolkit I know of has a GUI editor, and plain HTML has the advantage of being ubiqutous. I can already imagine tearing the manual while writing GUI in Sencha Touch — not particularly attractive.

Using jQuery Mobile, links are automatically “hijaxed” into AJAX-y links, without you having to define these ‘tap’ actions whatsoever. The other good thing about it is that it works in a desktop browser by default, whereas Sencha Touch’s tutorial app just gives me a blank page when viewed from Firefox.

My general feeling is that if I am going to use yet another framework, I may as well go native or use Titanium which gives me native performance. For the moment I am going to stick with jQuery Mobile. f

Published by kizzx2, on October 28th, 2011 at 12:19 pm. Filled under: UncategorizedNo Comments