First look at MOKA5 - not impress

A colleague of mine drew my attention to this little seemingly cute piece of software called MOKA5, which was touted to allow you to carry the OS around in your portable devices, such a USB drive, etc.

It also has a familiar name called LivePC, which UBuntu uses to allow potential users to boot the machine up on a CD ROM to have a taste of UBuntu prior to committing oneself. This is a very nice feature but don't let the UBuntu's LivePC be confused with this LivePC.

To be a true portable piece of software for portable device, it has to

1. behave something like Torpark, Portable FileZilla, or anything from Portable.com that you do not need to install anything in a pc.
2. that, it must be able to run in LUA because you do not have administrative rights in Internet Cafe, public PC or corporate desktop.

These are my guidelines to evaluate this product.

So what better person to check this out than a LUA-devotee. To save you from the suspense, I can tell you that I am sorely disappointed because this thing will not run without administrator privileges. So it is wrong for calling this a piece of software for portable devices.

Below are some of the investigation into why it needs administrator's privilege and that it is not a software for portable device or portable software.

At the core of it, is that it demands administrative rights to start LivePC, even after installation. Hence it fails the above 2 conditions completely.

Evaluation of the product

The installation of the downloaded package livepcengine-setup-1.0.8949.exe proceeded fine in LUA because I was installing this to a portable device. However, it was stopped because I was installing this to a portable hard drive with NTFS and standard user did not have rights to create files in the root directory.

This program placed autorun.inf, m5launch.exe, m5launch.log, and m5uninstall.exe in the root directory. To help this program to install and to learn what else this needed, I decided to open up the ACL for this to allow user full rights to the root directory - dangerous but what the hack.

It also created the mok5 directory and placing "program files" and "document and settings" underneath it. Of course they did not possess the same ACLs as the real ones.

Since I'd developed a healthy distrust of autorun even prior to the Sony Rootkit saga, I did not have to eject and reattach that drive to fire up the autorun. It wouldn't work anyway.

When I ran m5launch.exe manually, it told me that it needed administrative rights to install VMWare Player. Oops! The penny dropped. Could this be just a dodgy way of running VMWare Player, which was free, and a way to hoodwink people into subscribing the VMWare images? What is the license implication of the OS in those images?

Anyway, of course it did not start and I thought it must be because I did not have VMWare Player installed. At this point it became very clear that this was not a portable software, even ignoring the security demands. Or even software for portable devices.

It should be 'installed' (almost like xcopy) onto a portable device, plugged that device into any machine and it should run without any problem, even in LUA. But this thing would not meet this demand.

Since I was interested to see what it was doing, I ran the m5launch.exe from an administrator's account and this triggered the installation of VMWare Player. I could watch before my eyes with Process Explorer the installation and starting of the following services:

• VMNet.exe
• VMNetDhcp.exe
• VMWare-authd.exe

They were required to provide internet connectivity. Without them started LivePC would still start, of course in administrator's account, albeit without network connectivity.

Eventually, LivePC fearless browser came up and inviting me to participate to a survey. Of course why would I miss an opportunity to provide some truly garbage!

The other thing that I dislike LivePC's installation was that it forcefully installed the VMWare Player to my C:\.

The other area that I thought LivePC did poorly was that it could not run in LUA. There did not appear to have good reason requiring administrative rights after everything was installed. VMWare Player ran fine in LUA. Streaming down image from their server should work in LUA, if you avoided writing to the real "Program Files" or updating HKLM.

I did not have any trouble running VPC or VMWare to host OS in my standard user account, including creating images. Perhaps the LivePC developers should try to develop this in non-admin account and it might then be able to run in LUA.

When I finally terminated the LivePC it asked me if I wanted to uninstall VMWare Player. I presumed it would do that cleanly if I said yes but I did not.

The bottom line is that, it is no different than you carrying around VMWare images on a memory stick and run it on a PC with VMWare player installed. It is NOT a portable solution or solution for mobile warrior.

Time to uninstall this thing.

Using NUnit without installation

I have been using NUnit 2.2.6 for quite some time now and want to upgrade. The fact that I have to remove my NUnit 2.2.6 and install the new version and then to choose which version, .Net 1 or .Net 2, sort of put me off.

Then I came across this discussion thread on the NUnit forum with a lot of recommendations from Charlie Poole, the key developer/architect of NUnit that completely dispelled my concern and worry. It shows how to 'install' NUnit without installation and supporting both versions.

Essentially, you can use NUnit without installation and you can also have NUnit 2.4.1 for .Net 1.1 and .Net 2 co-existing on your machine without conflict.

This is how to do it:

1. Download from NUnit project on SourceForge the version you want. Let say NUnit 2.4.1 for .Net 1.1. Instead of downloading the msi version, take the ZIP file (not the source). In this case, it will be NUnit-2.4.1-net-1.1.zip
2. Create a distinct directory for this file, say NUnit-2.4.1-1.1 and unzip the content to it preserving the folder structure.
3. Create a short-cut on the desktop to bin\NUnit.exe and label it accordingly.
4. Then go to the Visual Studio Command prompt and in the bin directory run the GacUtil /I to install the nunit.framework.dll to the GAC.
5. Repeat steps 1-4 for NUnit 2.4.1 for .Net 2 making sure that this version is placeed in a separate directory.

Because the nunit.framework.dll is in the GAC, as Charlie recommends, VS will not perform local copy.

If you have to develop the project at different places, say at work and at home, where the locations of the NUnit are different, then you are recommended to define the location of the NUnit's bin directory to VS project using the "Reference Path" setting.

Reference Path settings are not saved with the csproj file but is in a user file, csproj.user, and this is not source controlled either. Hence moving the csproj around will not require one to change the csproj file.

Now on my work station I have NUnit 2.2.6 so that old projects continue to work and NUnit 2.4.1 for .Net 1 and .Net 2. The only trouble with this arrangement is that your project source control does not contain a version of the nuit.framework.dll.

This blog message explains why there are two versions of NUnit. In fact, one can simply lauch NUnit.exe with the /framework switch instead of changing the .config file.

Ungreyed the OK button in Firefox's download dialog box

Firefox is a great product and I use it wherever a web site does not spill out FF-unfriendly pages.

However, there is a bug in FF (version 2.0.0.3) that calls for some radical way to deal with it. Do not apply this technique to other Windows applications.

In a normal FF, it is set to download to the desktop and that for a file type (more correctly MIME Type) of say PDF, it is set to invoke the viewer automatically. This kind of setting is stored in a file in your Windows profile area under the tree
"Application Data\Mozilla\Firefox\Profiles\[a unique FF profile directory]". For those .Net Programmers, it is kind of like Isolated Storage. FF generates a unique directory name for your FF profile.

In there you will find a file called mimeTypes.rdf.

Now, here are the steps to reproduce the bug. Since this is an experiment and that you may like to restore to the original state, you should take a copy of the file mimeTypes.rdf to a safe place. When you have finished with this experiment, simply overwrite the mimeTypes.rdf with the original copy and you would not know that you have mucked around with FF.

Now open FF and go to the Tools | Options... to bring up the Options dialog box.

• In the Main section, set the download option to "Always ask me where to save files".
• In the Content section, click the "Manage..." button for the File Types. You should see a list of types in Download Actions dialog box. Look for PDF type and click on it. The "Remove Action" button is then ungreyed. Click it to delete the PDF from the list.

Now close that dialog box to return to FF. Navigate to a web site where you find a PDF to download.

If you simply click on that link for the PDF, FF will bring up a dialog box asking you what action you would like and it looks like this. If you do not get this, restart FF.


I have actually find this dialog box extremely handy. See the greyed out "OK" button circled in red. According to Mozilla, this is a bug and is caused by some kind of corrupted mimeTypes.rdf file.

Don't be fooled by this greyed button, which in normal Windows UI indicating that it has been disabled. Far from it, in FF-land and is very much alive and kicking.

I do not believe that this is caused by a corrupted mimeTypes.rdf file. I have successfully demonstrated with a brand new installation in an environment that I have manually cleaned up every scrap of Mozilla stuff. By following my steps above, I could reproduce this.

I have further proof that it is most likely a coding or logic bug inside Mozilla's GUI engine in dealing with button and activation process. Here are the ways to ungrey that button to get to that PDF file you want.

1. The simplest of the lot is alt-tab away from FF and alt-tab back. The greyed OK button now become ungreyed and you can select it.
   
2. For those using tablet PC, it can be very inconvenient to perform alt-tab. So tap or click on the greyed OK button (didn't I say radical way before as you would be a fool to do that to a Windows application?) once and it will become ungreyed. A second tap or click on the OK button select the action.

In Windows, if a button is greyed (disabled) your program will not receive any button click message. Hence clicking it will not do anything at all. Since I am not familiar with the internals of FF and in particular its GUI engine, I wouldn't know where the fault actually is.

As demonstrated, it is not random and it can be reproduced consistently. So Mozilla engineer should be able to home in to the trouble.

IE7 Uptake stagnant - that's obvious.

Recently PC World reports that the uptake of IE7 has stagnant even with the release of Vista.

It does not really need much to work out exactly why. If MS wants everyone to move over to IE7, all it has to do is to remove the WGA check on installation. The slimy thing is that its Windows update downloads IE7 first before asserting if the Windows is WGA compliant.

To me it seems like a deliberate act of wasting people's Internet bandwidth.

Removing that check may restore some fondness to upgrade to IE7. Besides who needs IE7, those failing WGA check are mightily happy with Firefox and I am sure that they are promoting Firefox willingly rather than IE7.

Even on my WGA compliant machine, I do not install IE7 for good reason.

Full mark for thinking outside the box (or rather inside?)

In the cat-and-mouse game of defeating the HD DVD protection reminiscence of the cold war, nice to see some application of thinking outside the square approach:

The latest attack vector bypasses the encryption performed by the Device Keys—the same keys that were revoked by the WinDVD update—and the so-called "Host Private Key," which as yet has not been found. This was accomplished by de-soldering the HD DVD drive's firmware chip, reading its contents, and then patching it. Once that was done, the firmware was soldered back onto the drive.
[...]
"They cannot revoke this hack," said forum member arnezami, who has been at the center of much of the AACS cracking recently. "No matter how many Private Host Keys they revoke we will still be able to get Volume IDs using patched xbox 360 HD DVD drives."

Well done!

Microsoft's UAC & Sudo

Mackenzie recently blogged about the history of Sudo and the similarity to Vista's UAC

What makes this whole thing funny, though, is something I saw a couple days ago. Head over to Builder-AU and listen to Peter Watson from Microsoft. He says, User Account Control is a great idea and strategically a direction that sort of all operating systems and all technology should be heading down Excuse me

My brief encounter with Ubuntu and the chanced encounter of the dialog box seeking my root password stunned me of the close resemblance to ME II's UAC.

All about a GUID

What's such a big deal for a GUID that every COM programmer is so used to?

What's such a big deal with this particular GUID:
09f91102-9d74-e35b-d841-56c5635688c0

Apparently someone, very touchy organisation like AACS LA causes a storm in Digg when someone rewrote the GUID by removing the separators and posted it on the Internet.

If someone like say AACS LA finds publication of a GUlD offensive, every com programmer should better check their GUID with AACS LA before they publish it in the type library or IDL. I suggest every com programmer just sends e-mail to AACS LM requesting permission to publish the GUID in the IDL.

This is stupid. As Ed Fulton rightly says, no one should be allowed to own an integer - a GUID is just a 128 bit integer!

Would they get upset if these special "AACS offensive" numbers were published in the form of a COM type library?

As Bruce Schneier once said in relation to using DRM to protect digital materials: it is like "making water not wet"

Some one is touchy! If they try to take down this kind of stuff, smart people can write materials carrying double, triple or n-possible meaning to conceal the true meaning or intend. How can anyone police that? The Chinese were doing this centuries ago before computer were even in the vocabulary.