Wednesday, 7 May 2008

Getting rid of the annoying flash/shockwave commercial in MSN messenger

It started with web sites. They would put a small picture in the header of the site that on mouse over would fill the entire page with rubbish. We fixed it, usually, by using some utilities or by changing the ip of the offending ad to some non-sense ip.

Now they used the same ploy for Windows Live Messenger (formerly known as MSN). One could say that Microsoft doesn't need more money, but apparently they do. On YOUR expense! So, how can one get rid of the annoying flash ad at the bottom of MSN? Easy! Follow these steps (tested on version 8.5):
  1. Open folder Program Files\Windows Live\Messenger
  2. Copy file msgsres.dll to msgsres.dll.bak
  3. Find a text or hex editor that does not break a binary file on save (That means NO Notepad or Wordpad). Myself I used the text editor from FAR Manager, but there are tons of good freeware editors online. Just Google it.
  4. Open the msgsres.dll file with the text editor, look for
    <Element Id=Atom(AdBrowserCont) Layout=VerticalFlowLayout(0,0,3,0) Visible=false Padding=Rect(8,2,0,2)>
    and replace one letter from AdBrowserCont. I changed the A to an X, but it doesn't matter. What is important is not to change the length of the file; just replace, do not insert or delete anything.


That is all. The ad container will still appear and show the Windows Live Messenger window, but no ad will be loaded.

Of course, this is the do-it-yourself version. There is an utility that is largely recommended on the web to fix MSN, Windows Live Messenger and Yahoo Messenger ad issues, and that is A-patch, but I haven't tested it yet.

Tuesday, 6 May 2008

How to patch ASP.Net Ajax in order to work on servers that add stuff to your page automatically

Thanks for Raheel for presenting me this problem and the opportunity to fix it.

As you may know from a previous post of mine, Ajax requests differ from normal requests. At the Page level, the rendered content is changed to reflect only the things that changed in the UpdatePanels and the format is different from the usual HTML and it is also very strict. Any attempt to blindly add things to the string sent from the server will result in an ugly alert error. And who does indiscriminately add ugly content to your Ajax requests? "Free" servers that inject commercials in your pages!

So, what can you do? Patch the Ajax engine to remove the offending ads. Here is a simple example for a server that added crap at THE END of the content, crap that did not contain any '|' characters. This is important, as the patch looks for the last '|' character and removes all the things after it.

C# Code

private void LoadApplyPatch()
{
ScriptManager sm = ScriptManager.GetCurrent(Page);
if (sm == null) return;

string script =@"
if (window.Sys&&Sys.WebForms&&Sys.WebForms.PageRequestManager) {
Sys$Net$WebRequestExecutor$get_responseData=function() {
if (arguments.length !== 0) throw Error.parameterCount();
if (!this._responseAvailable) {
throw Error.invalidOperation(String.format(Sys.Res.cannotCallBeforeResponse, 'get_responseData'));
}
if (!this._xmlHttpRequest) {
throw Error.invalidOperation(String.format(Sys.Res.cannotCallOutsideHandler, 'get_responseData'));
}

var content=this._xmlHttpRequest.responseText;

// this is the added code, the rest is taken
// from the ASP.Net Ajax original code
var index=content.lastIndexOf('|');
if (index<content.length-1)
content=content.substring(0,index+1);


return content;
}
}"
;

ScriptManager.RegisterStartupScript(Page,
Page.GetType(), "adMurderer", script, true);
}

Saturday, 26 April 2008

Infected by Scott Sigler

The book is a classic American sci-fi book, including small town mentality, a sports and US centric view, lots of government agencies, all working for the good of the citizens, keeping them all safe and ignorant and the warped morality that tells people they should destroy before they understand, just because they fear it.

That is something to be expected from an American author, though, and the book itself is not bad. It felt like it was inspired a lot by Stephen King's Dreamcatcher, which featured a similar personal dillema of alien infestation while the gov'ment was on the chase, but that one had more oompf. Of course, you can't compare aspiring Sigler to King, but then again, King's writing was never so great to me to begin with.

What I found really astounding is that a civilisation that uses biological machines to create a beach head on another planet would be so easily thwarted by a college athlete, a trigger happy black ops CIA agent and about a doctor and a half. Oh, and some Apache helicopters. What bothered me to no end is that I also felt this was a plausible scenario. I hope I am just stupidly influenced by similar literature, but would it really help to destroy the enemy before you get to at least understand it? What about the technology that was so easily recognisable as foreign and above Earth's current scientific level?

As a conclusion to both book and my own feelings: it was a nice read; not spectacular, but good enough to keep reading till the end. It is also available in podcast format and I myself have read it from a text file saved from a PDF that was gracefully provided free of charge by mr Sigler on the Escapepod podcast site.

Wednesday, 23 April 2008

Coma Light concert at Preoteasa in Bucharest

Coma is one of my favourite bands if not THE favourite. They are Romanians, I know them, they're cool guys. Recently they organised an unpluggish concert called Coma Light. This is one of the songs there, although I do encourage you to look at them all (YouTube links gracefully provided by Imig/Smallex under the video). Great job, guys! Most of the songs you played deserve an album of their own. Here is the video for Culori, high quality from MetalHead TV. from YouTube.



Links to all the songs in the concert:
Stai
Mai presus de cuvinte
Bizz
Culori
In mine in soapta
Hectic
Un loc sa ajung
Daddy
Morphine
Coboara-ma-n rai
Cine iubeste si lasa
Canta-mi povestea

Monday, 21 April 2008

Compressing UpdatePanel output

Update: I've posted the source and binaries for this control on Github. Free to use and change. Please comment on it.

This is the story of a control that shrinks the content sent from an UpdatePanel to down as 2% without using compression algorithms. I am willing to share the code with whoever wants it and I only ask in return to tell me if and where it went wrong so I can find a solution. Even if you are not interested in the control, the article describes a little about the inner workings of the ASP.Net Ajax mechanism.

You know the UpdatePanel, the control that updates its content asynchronously in ASP.Net, allowing you to easily transform a normal postback based application in a fully fledged Ajax app. Well, the only problem with that control is that you have to either put a lot of them on the page in order to update only what changes (making the site be also fast as you would expect from an Ajax application) but hard to maintain afterwards, or put a big UpdatePanel on the entire page (maybe in the MasterPage) and allow for large chunks of data to be passed back and forth and also other clear disadvantages, some detailed in this blog entry.

Not anymore! I have made a small class, in the form of a Response.Filter, that caches the previously rendered content and instructs the browser to do the same, then sends only a small fraction of the data from the server to the browser, mainly what has changed. There is still the issue of the speed it takes the browser to render the content, which is the same no matter what I do, like when rendering a huge table. It doesn't matter that I send only the changes in one cell, the browser must still render the huge grid. Also, if, for some reason, the update fails, I catch it and I send to the server that the updatepanel must be updated again, the old way.

Enough; let's talk code. I first had to tap into the content that was sent to the browser. That can only be done at Page render level (or PageAdapter, or Response.Filter and other things that can access the rendered content). So I did catch the rendered content in a filter, I recognized it as Ajax by its distinctive format, and I only processed the updatePanel type of token.

Here I had a few problems. First I replaced the updatePanel token with a scriptBlock token that changed the innerHTML of the update panel div element. It all seemed to work until I tested it a little. I discovered that the _updatePanel javascript method of the PageRequestManager object used by the normal ajax rendering on the browser was doing a few extra things, so I used that one instead of just replacing the innerHTML, resulting in a lower speed. But that didn't help either, because it failed when using validators. Even if I did replace the updatePanel token with a correct javascript block, it still got executed a bit later than it should have.

The only solution I had was to replace the _updatePanel method with my own. Itself having a small block of code that disposed some scriptblocks and some other stuff, then a plain innerHTML replace, I could not 'override' it, since it would change the innerHTML with some meaningless stuff (the thing I would send from the server), then I would parse and change the innerHTML again, resulting in bad performance, flickering, nonsense on screen, etc. So I just copy pasted the first part and added my own ApplyPatch function instead of the html replace code line.

Now, here I met another issue. The innerHTML property of an html element is not a simple string. It gets parsed immediately when set and it recreates when read, as explained in this previous article of mine. The only solution for that was create my own property of the update panel div element that remembers the string that was set. This solved a lot more problems, because it meant I could identify the content to be replaced by simple position markers rather than through regular expressions (as was my initial idea). That property would not get changed by custom local javascript either, so I was safe to use it.

About the regular expression engine in Javascript: it has no Singleline option. That means you can only change the content line by line. I could have used Steve Levithan's beautiful work, but with the solution found above, I would not need regular expressions at all.

The only other issue was with UpdatePanels inside UpdatePanels. I found out that in this case, only parent UpdatePanels are being rendered. That meant that the custom property I added to the child panel would disappear and break my code. Therefore I had to keep a tree of the updatepanels in the page and clear all the children cached content when the parents were being updated. So I did that, too.

What else? What if somehow the property would get deleted, changed, or something else happened, like someone decided to recreate the update panel div object or something like that? For that I made a little HttpHandler that would receive an UpdatePanel id and it would clear its cached content. Then, on return from the asynchronous call, the javascript would just push another update panel refresh using __doPostBack(updatePanelId,""). I don't particularily like this approach, since it could back fire with multiple UpdatePanels (as you know, only one postback at a time is supported), but I didn't find a better solution yet. Besides, this event should normally not happen.

So, the mechanism was all in place, all I had to do was make the actual patching mechanism, the one that would find the difference between previously rendered content and current content, then send only the changed part. First thing I did was remove the start and end of the strings that were identical. As you can imagine, that's the most common scenario: a change in the UpdatePanel means all the content up to the change remains unchanged and the same goes for the content after the change. But I was testing the filter with a large grid that would randomly change one cell to a random string. That meant two changes: the previous position and the last. Assuming the first change was in one of the starting cells and the last was in one of the cells at the end, then the compression would be meaningless. So I've googled for an algorithm that would give me the difference between two files/strings and I found Diff! Well, I knew about it so I actually googled for Diff :) It was in the Longest Common Substring algorithm category.

Anyway, the algorithm was nice, clear, explained, with code, perfect for what I wanted and completely useless, since it needed an array of m*n to get what I needed. It was slow, a complete memory hog and I couldn't possibly use an array of 500000x500000. I bet they were optimizations that covered this problem, but I was miserable so I just patched up my own messy algorithm. What would it do? It would randomly select a 100 characters long string from the current content and search for it in the previous content. If it found it, it would expand the selection and consider it a Reasonably Long Common Substring and work from then on recursively. If it didn't find it, it would search a few times other randomly chosen strings then give up. Well, actually is the same algorithm, made messy and with no extra memory requirements.

It worked far better than I had expected, even if it clearly could have used some optimizations. The code was clear enough in detriment of speed, but it still worked acceptably fast, with no noticeable overhead. After a few tweaks and fixes, the class was ready. I've tested it on a project we are working on, a big project, with some complex pages, it worked like a charm.

One particular page used a control I have made that allows for grid rows and columns to have children that can be shown/hidden at will. When collapsing a column (that means that every row gets some cells removed) the compressed size was still above 50% in up to 100 patch fragments. When colapsing a row, meaning some content from the middle of the grid would just vanish, the size went down to 2%! Of course, putting the ViewState into the session also helped. Gzip compression on the server would complement this nicely, shrinking the output even more.

So, I have demonstrated incredible compression of UpdatePanel content sent through the network with something as small and reusable as a response filter that can be added once in the master page. You could use it for customers that have network bandwidth issues or for sites that pay for sent out content. It would with sites made with one big UpdatePanel placed in the MasterPage as well :).

If you want to use it in your sites, please let me know how it performs and what problems you've encountered.

Saturday, 19 April 2008

innerHTML and the rearranged attributes

I have been working on an idea, one that assumed that if you remember the content sent to an UpdatePanel, you can send only the difference next time you update it. That would mean that you could use only one UpdatePanel, maybe in the MasterPage, and update only changes, wherever they'd be and no matter how small.

However, I also assumed that if I set the innerHTML property of an HTML element, the value will remain the same. In other words that elem.innerHTML=content; implied that elem.innerHTML and content are identical at the end of the operation. But they were not! Apparently the browser (each flavour in its own way) interprets the string that you feed it then creates the element tree structure. If you query the innerHTML property, it uses the node structure to recreate it.

So comparing the value that you've fed it to the actual value of innerHTML after the operation, you see quoted attribute values, altogether removed attributes when they have the default value, uppercased keywords, changed attribute order and so on and so on. FireFox only adds quotes as far as I see, but you never know what they'll do next.

On the bright side, now that my idea had been torn to shreds by the browser implementation, I now have an answer to all those stuck up web developers that consider innerHTML unclean or unstructured and criticize the browsers for not being able to render as fast when using DOM methods. The innerHTML property is like a web service. You feed it your changes in (almost) XML format and it applies it on the browser. Since you pretty much do the same when you use any form of web request, including Ajax, you cannot complain.

Thursday, 17 April 2008

Angelina in all her machine glory

This is a little YouTube video that shows a photoshoot of Angelina Jolie's when she was a teen. As you will see, she is a lovely looking girl, but that is not the reason I am posting this in my blog. The reason is the feeling that I am having watching this: dread. Here is a 16 years old girl, faking all the emotions in all the pictures that are made of her, with an ice cool professionalism, chewing gum when the film is being changed in the camera. You can imagine what kind of pictures will result from this shoot, when all of this is probably filmed in a small humid room with people watching TV at its more stupidest. Can you imagine trying to concentrate with that noise around? If you ever thought Angelina got to where she is because of her looks only, think again. This little human robot has good programming.


Angelina Jolie - Bikini modeling from 1992 (Photoshoot)