Is there such a word as 'besting'?

I was reading an article on IE8 from InformationWeek and came across this usage that makes me feel uncomfortable:

NSS Labs released an independent study early Thursday showing IE8 significantly besting Mozilla Firefox, Apple Safari, Google Chrome, and Opera in catching and blocking malware. With its SmartScreen filtering, IE8 Release Candidate 1 caught 69% of malware, while Firefox 3.07 caught only 30%.

Emphasis is mine.

Is there such a word called 'besting'. I know Good, Better and Best but Besting? Come on! Surely geek writing does not mean bastardization of English.

First look at IE8

I have expressed my dissatisfaction with IE7 on this blogs for several occasions and offering my conclusion why IE7's uptake fails to materialize and yielding market shares to Firefox.

There are two issues I am really interested in IE8 and they are:
1) I failed to understand Microsoft's irrational pursue of demanding WGA validation during the installation of IE7. Even more distasteful was Microsoft allowed IE7, not an insignificant amount of bytes, to be downloaded without WGA validation then failing the installation on WGA validation failure. This was mean and wasting bandwidth. So I am interested to see if Microsoft wanting to continue this irrational pursue of WGA validation in IE8 that would only further erode its market shares.

2) I want to see if I can still use IE8 in an LUA arrangement as an Windows Explorer with Admin privilege. IE7 can't. This to me is probably less important than say the item 1). If IE8 can be installed without WGA bothering, I will overlook the short comings of this issue because I can almost invoke every control panel applets or MSC files from administrator's console.

It is delightful to see Microsoft has learned a lesson from the IE7 irrational pursue of WGA validation and there is no bothering of WGA validation in IE - downloads or installation. Well done Microsoft.

This is the right thing to do if Microsoft is genuinely keen on protecting users from the evils of the Internets. Besides you can't buy IE even if you want to pay. Let's hope that Microsoft will begin to push this down to Windows users via the Windows Updates.

Actually I tell a small lie. If you are running XP SP2 and that you have not installed the KB932823 update, the IE8 installation insists on you having this update installed. This update is only available to those meeting the WGA validation requirement. In short, IE8 is not fully so generous as Firefox. However, that requirement can easily by-passed. Once that update is installed, IE8 is happy to install it on XP-SP2.

Those with SP3 need not worry and IE8 is very generous in that regard.

It will remain to be seen whether this direction will arrest the erosion of IE market shares by other browsers such as Firefox, Opera and Safari. With the demand for KB932823 meeting WGA validation as mentioned above, I have doubt that IE8 can arrest the erosion.

However, IE8 behaves much like its older sibling and fails to work as a Windows Explorer with administrative privilege, a feature of IE6. As said, I can put up with this mild inconvenience as I can invoke all but a few control panel applets from administrator's console. What I will miss most is the UI to change the ACLs. Fortunately, complex operations requiring the UI support are rare and the use of CACLS command is adequate for most of the usage.

Hence the lack of WGA bothering is more than compensation for the failure to act as a Windows Explorer.

Will I jump back to IE8? Not too sure yet. This is not a matter of performance but more on my fondness for the vast collections of Add-in offered by Firefox. It is like a kid deserting a well-stocked lolly shop - not willingly and likely without dragging kicking and screaming.

I did venture into the IE8 Add-in gallery but it looks very poorly stocked. May be over time, this will change and let's hope so.

So beautifully put

I've come across a poem by Janet Minor that sums up so beautifully and entertaining the danger of trusting blindly your spell checker in your word processor and it is reproduced here:

I have a spelling checker
It came with my PC;
It plainly marks four my revue
Mistakes I cannot sea.
I've run this poem threw it,
I'm sure your pleased too no,
Its letter perfect in its weigh,
My checker tolled me sew.

I have seen this kind of malpractice in software development where developers cannot tell the difference between a piece of compiler-happy code and run time logically correct piece of code.

VB.Net can block pass by reference parameter - Is it real?

I was browsing around some MSDN materials in VB.Net and came across this puzzling claim "How to: Force an Argument to Be Passed by Value".

The obvious question that sprang to my mind was: Is this real? I know nothing in CLI that supports this kind of thing. There is also confusing statement in that reference

If a parameter is declared ByRef, Visual Basic expects to pass the corresponding argument by reference. This allows the procedure to change the value of the programming element underlying the argument in the calling code.

If the "value of the programming element" means the object reference or memory address, then that statement is true.

In .Net if the object being passed across is a reference object, no matter you pass use ByVal (in C# no qualifier needed) or ByRef (in C# with the ref qualifier), the called function can change the state of the object but only the reference or the memory address of the object can be modified if using ByRef.

So what has VB.Net invented that CLI does not support? Obviously this must be a source level construct and not IL construct. It turns out that there is really nothing new or to trumpet about.

According to the documentation, if you surround the argument, which is specified by the called function to have ByRef convention, with a bracket, you can prevent the called function from modifying the object address, like this:

 Dim a As DemoClass
 Dim b As DemoClass
 a = New DemoClass(10, "Jack")
 b = a
 Show(a, "Before")
 SomeFunctions.DoSomethingA((a)) ' L1
 Show(a, "After")
 Debug.Print("Are the same ? " & (Object.ReferenceEquals(a, b).ToString()))

Line L1 shows the protection syntax. The Debug.Print shows object a and b are occupying the same memory location. So the (a) syntax defeats the function's parameter's convention which is specified as:

    public static class SomeFunctions {
    public static void DoSomethingA( ref DemoClass a ) {
        a = new DemoClass( a.Number + 100, "Bye " + a.Name );
 }
}

So how can VB.Net defeat the convention specified by a C# function?

To answer this question you need to examine the IL code generated by VB to see if it is merely a trick. This is the IL code of the above VB.Net fragment:

  .locals init ([0] class [MySupport]MySupport.DemoClass a,
       [1] class [MySupport]MySupport.DemoClass b,
       // .....
       [4] class [MySupport]MySupport.DemoClass VB$t_ref$S0,
       [5] bool VB$t_bool$S0)
IL_0000:  nop
IL_0001:  ldc.i4.s   10
IL_0003:  ldstr      "Jack"
IL_0008:  newobj     instance void [MySupport]MySupport.DemoClass::.ctor(int32,
                                                                       string)
IL_000d:  stloc.0
IL_000e:  ldloc.0
IL_000f:  stloc.1
IL_0010:  ldloc.0
IL_0011:  ldstr      "Before"
IL_0016:  call       void TestParameterPassing.Module1::Show(class [MySupport]MySupport.DemoClass,
                                                           string)
IL_001b:  nop
IL_001c:  ldloc.0
IL_001d:  stloc.s    VB$t_ref$S0
IL_001f:  ldloca.s   VB$t_ref$S0
IL_0021:  call       void [MySupport]MySupport.SomeFunctions::DoSomethingA(class [MySupport]MySupport.DemoClass&)
IL_0026:  nop
IL_0027:  ldloc.0
IL_0028:  ldstr      "After"
IL_002d:  call       void TestParameterPassing.Module1::Show(class [MySupport]MySupport.DemoClass,
                                                           string)
IL_0032:  nop
IL_0033:  ldstr      "Are the same \? "
IL_0038:  ldloc.0
IL_0039:  ldloc.1
IL_003a:  call       bool [mscorlib]System.Object::ReferenceEquals(object,
                                                                 object)
IL_003f:  stloc.s    VB$t_bool$S0
IL_0041:  ldloca.s   VB$t_bool$S0
IL_0043:  call       instance string [mscorlib]System.Boolean::ToString()
IL_0048:  call       string [mscorlib]System.String::Concat(string,
                                                          string)
IL_004d:  call       void [System]System.Diagnostics.Debug::Print(string)

Notice the local variable 4, VB$t_ref$S0, a compiler generated auto-variable of the same type as the function's parameter. From line IL_001c to IL_001f, the IL code is to stash the object in a to VB$t_ref$S0 and then pass this temporary variable by reference to the called function. The idea is to let that function modifies a sacrificial object without harming the protected one inside the bracket, that is a.

You can achieve the same result in C# as follows:

   DemoClass a = new DemoClass( 23, "Peter" );
  DemoClass b = a;
  DemoClass tmp = a;
  SomeFunctions.DoSomethingA( ref tmp );
  Debug.WriteLine( String.Format( "Are they the same? " + Object.ReferenceEquals( b, a ) ) );

The variable tmp is the throw away one. So there is nothing new. It is just a simple convenience trick - nothing more and nothing less.

A first encounter with Google Chrome

For some time now, the media and blog-spheres are full of praises for Chrome and hence I have decided to dip my toe into the Chrome (version 1.0.154.48) to see what it is like.

1.   Chrome is not a unsual Windows program in that it does not require Administrative rights to install. It is more akin to a .Net ClickOnce deployed solution in which the solution is installed in the user's profile area. So if you, like me, has several accounts in an XP box, you need to install it with each account.

2. I was really interested in the much hyped feature of one tab page per process technique which protects the Chrome process (the one visible to the user) from being torn down by a crash when processing one page. Armed with Spy++ and Process Explorer, I began my exploration. What I can tell is:

• Yes, there is indeed one process (Chrome.exe) per tab page. Actually more than one process per page. 
• But all visual Windows belong to one process, the parent process of Chrome. 
• On the supporting processes, they seem to also host some dummy windows whose functions yet to be identified. They seem to be hidden windows of 0x0 size. 

After all, I have never heard of a way to marshal a window across processes. This makes sense, albeit a very blunt way of doing thing, of using process isolation to do all the polling, threading and interaction with remote internet sites and then rendering the data in one process.

This technique is nothing new and is a common idiom to provide the most robust defence against crashes.

One nice touch of Chrome is its support for Tablet PC without Add-in that is required in Firefox. Opera does not even support Tablet PC. Then again, does Chrome have add-in?

Chrome starts much much much quicker than Firefox and this, together with the support of Tablet PC out-of-the-box, Chrome may have won my approval for a switch.