ManualResetEvent vs AutoResetEvent

I want to signal all of my threads waiting for WaitHandle and move them from the Wait Queue to Ready Queue.

There is a small, but significant difference between these two. The main difference comes from the names, when in AutoResetEvent signales (releases) one thread, waiting in the Wait queue and then automatically returns to non-signaled state. Strictly said:
AutoResetEvent will pick and signal just for one thread of more waiting threads.

In the other hand, using ManualResetEvent, you have much more control over the situation. When some thread (producer) will signal (Set), all waiting threads are signaled (released) and enqued to the Ready Queue. Which means they continue from their Wait command.
In this situation you are getting more control in your hands to pick up, which of the waiting threads should take the resource, or process some workitem. The rest of threads can be put in consequent waiting if needed.

Example:

I have a bunch of threads, which are waiting for signal.

First lets try what happens with AutoResetEvent:

image
Clearly shows how just first thread is signalled

ManualResetEvent example

image
This looks much better, all the waiting threads received the signal

And finally, the code which produced this:

class Program
    {
        static ManualResetEvent mre;
        static void Main(string[] args)
        {
            mre = new ManualResetEvent(false);
            var maxT = 3;
            var threads = new List();
            for (int i = 0; i < maxT; i++)
			{
                var t1 = new Thread(Program.T1Proc);
                t1.Start(i);
                threads.Add(t1);
			}
            Thread.Sleep(1000);
            Console.WriteLine("Sleeping for 1 sec");
            Thread.Sleep(1000);
            Console.WriteLine("Setting..");
            mre.Set();
            Console.ReadLine();
        }
        static void T1Proc(object state)
        {
            Console.WriteLine(" thread " + state + " waiting");
            bool received = mre.WaitOne(5000);
            if (received)
                Console.WriteLine(" thread " + state + " received signal");
            else
                Console.WriteLine(" thread " + state + " not received signal");
        }
    }

How to reset OpenWrt root password

It turned out that after few months of using my OpenWrt properly, I have completelly lost my root password and couldn’t connect to my router’s OpenWrt LuCi.

Fortuantelly, OpenWrt has a failsafe mode, where you can set things back up.

How to get to OpenWrt Failsafe mode:

  1. Reset the router
  2. Wait for the DMZ light (Second left light started blinking)
  3. Hold Router reset button for 2 seconds
  4. Connect your’r PC‘s Ethernet Cable to Router’s WAN port (You cannot access Failsafe when connected to any of LAN ports
  5. Set your PC IP Address to 192.168.1.2, NetMask to 255.255.255.0, GW to 192.168.1.1
  6. ipOpen Telnet connection to 192.168.1.1
  7. openwrt_failsafeType mount_root to mount your Router’s FS to Read/Write mode
  8. Type passwd to change root password
  9. openwrt_passwdSwich your LAN Ethernet cable from WAN port on Router back to some LAN one
  10. Restart the router

Deploying Express.js on Cloud9

Express.js (and probably most of other servers on Cloud 9) are being shielded by Cloud9 proxy. You usually cannot access them directly.
Anyway, according the Cloud9’s helping artice Can I use Cloud9 to do X the solution is following:
Start the ExpressJS to listen on Local IP and Local PORT, which are available, to start Express to listen use this:


// Cloud9 specific - needs to use defined port to listen
console.log("Starting to listen. ")

app.listen(process.env.PORT, process.env.IP);

You can then start Express.js normally like:

node myserver.js

I am starting server usually in new terminal window in Cloud9 and use bottom mini-terminal for tests, like:

markcz@demo-project:~/597752 (master) $ wget http://$IP:$PORT/getangularusers
--2013-09-11 07:06:12-- http://127.4.253.1:8080/getangularusers
Connecting to 127.4.253.1:8080... connected.
HTTP request sent, awaiting response... 200 OK
Length: 14 [text/html]
Saving to: “getangularusers.1”

100%[==============>] 14 –.-K/s in 0s

2013-09-11 07:06:12 (1.08 MB/s) – “getangularusers.1” saved [14/14]

Which successfully downloaded the response from private binding fine.

To test public available uri, you can easily open web browser using following format:

http://projectname.username.c9.io

My rest GET api path is /getangularusers and in my case it is publicised as

http://demo-project.markcz.c9.io/getangularusers

You cannot go inside C9 on different port then standard 80. And its being redirected to your local binding.

Please notice, that I am talking about standard HTTP port (80), in preview, you can get direct links to files hosted on Cloud9, but these are NOT your HTML pages hosted on a web server (Express).

 

 

I am going to describe in next article how to conigure static routing in Express to host your HTML files.

Summary:

1. Use Cloud9 predefined IP and PORT to point where Express is going to listen

2. To access from outside of Cloud9, use standard HTTP on 80, and with 3rd domain like hostname
(like http://demo-project.markcz.c9.io/getangularusers)

 

signtool.exe returned error 0x800700C1

To sign our binaries with Authenticode I am using Microsoft’s signtool. Unfortunatelly, it is not really descriptive in some error codes it returns.
In my case, I have been replacing resources in some native binaries, which were already signed. Of course, this will break existing Authenticode signature, but the signature is still there.
Signature is just one of sections in the EXE/DLL file and this section stays there, even if the file signature is invalid.

Signtool unfortunatelly cannot resign an file which is already signed and is always returning same error 0x800700C1.

SignTool Error: SignedCode::Sign returned error: 0x800700C1

This error is in fact ERROR_BAD_EXE_FORMAT.

So, I needed to remove existing signature from an binary file.
One interesting tool called delcert is already writen and works pretty nice to solve this and has source code included:

http://forum.xda-developers.com/showthread.php?p=2508061

After quick look into the C++ source, it is in fact does nothing magic. It is using Win32 API from ImageHlp library (which takes case of loading of binaries).
Interesting functions there are: ImageRemoveCertificate, which needs to be followed by MapAndLoad/UnMapAndLoad pair to clear section from PE headers.

After removing signature, signtool has no complains and signs the file nicely.

One step back to the ERROR_BAD_EXE_FORMAT error code
In your Microsoft SDK Program Files, you will probably have X86 and x64 versions of signtool (one in Program Files (x86), another in Program Files).
So depending on your binary bitness (32bit vx 64bit) you have to call proper signtool, otherwise you will get the original error.

To check the bitness, you can use dumpbin.exe which comes with Visual Studio (VC\bin folder) when you start it with
dumpbin.exe /headers myapp.exe
you should see a line like:
14C machine (x86)
or for 64bit version:
8664 machine (x64)

How to change Windows 8 product key

The way where in Windows 7 you could change your product key is not working anymore.

Instead, you need to use command line to change your product key in Windows 8:

open cmd.exe as Administrator (go to the start metro screen and search for cmd, then right click on cmd and in the bottom select Run as Administrator)

then type following:

slmgr.vbs -ipk PUT-YOUR-KEY-HERE

then, you should have your new key set properly. You can go ahead and try activation then.

Automating Chrome Browser from C#

Chrome Browser supports less known API called Remote Debugging. It is a JSON/WebSockets based protocol, which is basically used by Chrome Developer Tools to attach to a remote web page.

Note:

You can read more about this protocol at official page http://blog.chromium.org/2011/05/remote-debugging-with-chrome-developer.html

Setting up environment

To enable Remote Debugging, you need to start chrome with a parameter, enabling Chrome to listen on a specified Tcp port:

chrome.exe --remote-debugging-port=9222

Also, please ensure, that you dont have firewall blocking traffic to that port.

Once, you have Remote debugging enabled in Chrome, to check whether everything is working fine, we might want to start another Chrome session. This time, it has to be a session for a different user. To start chrome under different user, please start another chrome with these parameters:

chrome.exe --user-data-dir=C:\myChromeUser

You might want to change the directory to some other temp directory of client user.

Once you start client Chrome for the different user, you just go to the url:

http://localhost:9222

Which will basically open a webpage, offering you to select which tab in Chrome you want to debug remotely.

The page might look like:

Note: You should been opening this page with Chrome, because other browsers does not support Remote Debugging.

Selecting a Page, you should have Debugging Tools open for the page. It looks similar to the local Debugging Tools:

Then, just to try simple command, we might want to test alert being invoked in the debugged browser, simply switch to console and like on a local environment use:

alert('Hello World');

That was the simple test.

Lets return to automation. Chrome Remote Debugging page describes the protocol as JSON based, with some examples. I wanted to catch some traffic flowing from Remote Debugging Chrome page going to debugged Chrome. To that, I have used Fiddler2 Http Proxy, once I set that to my system proxy, I was able to catch the initial protocol flow. The rest of the protocol flow goes over WebSockets.

WebSockets in place

When you look at the result in fiddler, (or simply use your browser and go to http://localhost:9222/json. Note: When you dont see WebSocketDebuggerUrl in response, you are probably connected to RemoteDebugging endpoint with a different client) you will see something like:

[ {
   "devtoolsFrontendUrl": "/devtools/devtools.html?host=localhost:9222&page=1",
   "faviconUrl": "http://s2.wp.com/i/favicon.ico?m=1311976027g",
   "thumbnailUrl": "/thumb/http://markcz.wordpress.com/",
   "title": "Martin Kunc's blog",
   "url": "http://markcz.wordpress.com/",
   "webSocketDebuggerUrl": "ws://localhost:9222/devtools/page/1"
} ]

As you can see, this is pure Json. Anyway, what we are interested in the most is

   "webSocketDebuggerUrl": "ws://localhost:9222/devtools/page/1"

This element points to WebSockets endpoint, where Chrome is willing to listen for Json formatted requests.

The problem here is that currently Fiddler does not have nice support for WebSockets. Even if they goes over same ports, they are socket based. Fiddler beta has preliminary support for it in its Log tab, but its not so fancy formatted.

WebSockets in .NET

I had troubles with looking for a nice WebSockets Client implementation and then finally I found WebSocket4Net, which is WebSocket client implementation primarly used for SuperWebSocket server, but works pretty nice here.

Preparing Json commands for Remote Debugging protocol

Using the fiddler and its Log tab I was able to see enough samples of Json commands, which Remote DP is using. It is also described here. I have used v 0.1 of it, because I currently have Chrome 17.

Finally driving Chrome

Here is my snippet how I am driving Chrome in C#:

var chrome = new Chrome("http://localhost:9222");
var sessions = chrome.GetAvailableSessions();
Console.WriteLine("Available debugging sessions");
foreach (var s in sessions)
  Console.WriteLine(s.url);

if (sessions.Count == 0)
  throw new Exception("All debugging sessions are taken.");

// Will drive first tab session
var sessionWSEndpoint = sessions[0].webSocketDebuggerUrl;
chrome.SetActiveSession(sessionWSEndpoint);
chrome.NavigateTo("http://www.google.com");

var result = chrome.Eval("document.getElementById('lst-ib').value='Hello World'");
result = chrome.Eval("document.forms[0].submit()");

Console.ReadLine();

Thats basically all, it is just a proof of concept application.

Sources are available on the GitHub link: https://github.com/markcz/automate-chrome

What are BingBar applications

The Bing Bar for Internet explorer is packaged with standard applications shown on the picture (like FaceBook, BingRewards, Weather, ..)

The buttons on the bar, called Bing Bar Applications can be developed in HTML + javascript and this post should show how you can create your own like this sample one. To demonstrate collaboration with Internet Explorer, when you click on the Hello World text, you get Bing homepage opened in the new IE tab.

Bing Bar Applications basics

Applications are packed in zip packages having predefined structure and manifest file. Each package has its internal ID (a GUID without dashes). You can see the default Facebook BingBar app structure by downloading it from this link:

http://az15112.vo.msecnd.net/apps/facebook_76c7b5062c4e4be69d843ace834517ec/versions/7.0.853/ar-ploc-sa_et-al/facebook.bingbarapp

Applications are developed in html + javascript. They have loosely coupled dependencies as services. An application can provide or consume multiple services. Because they runs in local context, they can take advantage of local filesystem and also services provided by BingBar.

Default package structure shows this picture:

Applications supports internationalization and by default the culture is en-us. The localized content is stored in the loc folder.

In the root of the package is the manifest file and also default .html code. For the Facebook the root contains two files

  • appmanifest.xml
  • facebook.html

Application manifest is also in the localization resources directory (loc).

AppManifest.xml file is the starting point

For the test app I have created for this post, the manifest looks like following:

<?xml version="1.0"?>
<AppManifest Name="TestApp" Publisher="Microsoft Corporation" Copyright="© 2011" Description="Test" Version="7.0.822" MinRuntimeVersion="7.0" MaxRuntimeVersion="7.0" Locale="EN-US" TargetFolder="TestApp" Id="63630244A02F4E4CB6CB9B09B2F886F4">
	<Button Icon="images\icons\tempIcon.png" Tooltip="Teest"/>
	<AppServices>
		<Script>js\json2.js</Script>
		<Script>js\serviceutility.js</Script>
		<Script>js\instrumentation.js</Script>
		<Script>js\common.js</Script>
		<Script>js\service.js</Script>
	</AppServices>
	<AppUI Html="helloworld.html" Width="546" Height="308"/>
</AppManifest>

Where

  • AppManifest Name describes name of your application
  • Button Icon is icon of your bar app
  • AppUI Html is the html file being rendered when your application is opened by clicking on the button. the file I have used is helloworld.html and by default it lies in root of the package.
  • AppManifest ID attribute is the GUID of your application without delimeters.

Services element describes required service dependecies.

Markup and JavaScript parts of the app

As any other html page, which Bing Bar App is it uses HTML and JavaScript (and images, CSS etc..) So you “could” manually open default html page, which is described in manifest (helloworld.html) in our sample. Only difference is that it uses other BingBar JavaScript dependencies (from AppServices element), which wont be loaded just by opening the HTML in IE.

In this small sample, I have just prepared some DIV elements with IDs and JavaScript called helloworld.js is going to use jQuery, which might be a part of your scripts to work with the app. I am just handling click event of my content element to open another page using this JavaScript method:

    $("#content").click(function (e)
    {
        Instrumentation.trace(InstrumentationEvents.clickCurrentConditions);
        instance._navigatePage('www.bing.com')
    });

Which is pretty standard jquery method for handling click. I have used another method for opening a page in IE tab, which looks like this:

HelloWorldApp.prototype._navigatePage = function (url)
{
    bingclient.ui.browser.session(bingclient.context.browserSessionId).create(encodeURI(url));
    bingclient.flyout.close();
}

The bingclient object is an service for bing bar related operations.

How to deploy the testing application

BingBar stored all its applications in local user path similar to this one:

c:\Users\Martin\AppData\Local\Microsoft\BingBar\Apps\TestApp_63630244a02f4e4cb6cb9b09b2f886f4

Please mention, that the application folder name has application ID (defined in manifest above) in it.

To deploy the testing app, just extract the attached zip with sample into your

c:\Users\[USERNAME]\AppData\Local\Microsoft\BingBar\Apps\

and then open Internet Explorer with installer BingBar, click on the Three points in the right side to add new Application and select Test App and move it to toolbar.

Digging deeper into deployment

The system is currently using Microsoft cloud servers to check for new BingBar apps, but they actually have pretty much the standard applications deployed.
Currently available applications list in xml form in the cloud can be discovered by opening this url:
http://65.52.193.252/catalogs/getcatalog?Version=7.0.822.0&Market=en-us&Brand=BB07&Flight=prod-en-us_prod&FlightRevision=0&Id=12381649D8CF4400A8073830FD52882E-1

The available applications are structured as so called catalog.xml format, which is what you can see on the link above. Catalog has its local copy and on each start of IE with BingBar is checked that location to get new applications.