# Code for Concinnity

## Install Passenger nginx on OS X with Homebrew

A clean and hack-less way to do it.

If you got the Undefined symbols for architecture x86_64: "_pcre_free_study", this is for you:

# Let Homebrew install the required dependencies
$brew install nginx # Remove it because we're using Passenger's ngnix$ brew uninstall nginx

$sudo mkdir -p /opt/nginx$ sudo chown -R $(whoami):admin /opt/nginx$ LIBRARY_PATH=/usr/local/lib CC=gcc passenger-install-nginx-module

# Done!

## 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:

#!/bin/sh
# ack.sh

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

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

--ignore-dir=tmp
--ignore-dir=logs
--ignore-dir=vendor


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: http://msdl.microsoft.com/download/symbols/mscordacwks_x86_x86_2.0.50727.3625.dll/4E154C985a9000/mscordacwks_x86_x86_2.0.50727.3625.dll 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: http://msdl.microsoft.com/download/symbols/mscordacwks_x86_x86_2.0.50727.3625.dll/4E154C985a9000/mscordacwks_x86_x86_2.0.50727.3625.dll 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/**" } That is ALL THERE IS TO IT! $ 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.

## 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 https://github.com/luabind/luabind.git

$# 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/bootstrap.sh$ chmod a+x tools/build/v2/engine/build.sh
$./bootstrap.sh 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

## 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:

• 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!

## 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.