5 interesting things about the Chrome source code
I have been browsing through the Chrome source and found 5 interesting things:
- One of the tool projects is build in C# - that’s super cool.
- They seem to create some ActiveX shims for plugins. I wonder if that has been added to support the IE plugin model.
- The website on debugging has a VB.NET code sample that is apparently used as a makro to enable some kind of debugging features for the Chrome source code.
- Google reversed some of the IE structures to do importing of settings. There are even comments in the source code who say that specific structures have been reverse engineered.
- Last but not least: the whole application is build in Visual Studio 2005 and compiles very fine there. Upgrading to Visual Studio 2008 is only a few clicks when opening the solution in Visual Studio 2008.
It seem that Google uses a lot of Microsoft (Visual Studio, VB.NET, C#) technologies to create the Chrome. Quite cool and funny. 
What did you find while browsing through the Chrome source code?
Published on Sep 7th, 2008 —
Tags: C#, Chrome, Google, VB.NET, Visual Studio 
Comments (1) 
digg it!
kick it
Babylon.NET - translating software made easy
A friend of mine (and former boss… oh yeah, quite some time ago), Martin Geier, wrote a nice application that allows you to translate .NET resources from one language to another. The program is called Babylon.NET and has been released at redpin.eu.
The application targets one specific problem: translation of applications. I don’t know how often you had to do that but I’m from a region where a lot of people speak German and Italian. We, therefore, know both languages and have the benefit of publishing software for both languages. But translating software (even that it has gotten better with the advent of Visual Studio .NET, 2005, 2008) is still a very tedious and error-prone task.
Babylon.NET focuses on .NET projects created in Visual Studio. It offers features that are tailored to support developers or translators during their tasks while translating projects hat have been created in Visual Studio and are managed with Visual Studio. Some of these features are:
- Directly reads Visual Studio project files to start a new translation project.
- Synchronizes changes in the Visual Studio project with the translation project at any time.
- Writes localized resource strings directly to the Visual Studio resource files.
- Keeps track of the translation status for every single resource string in every locale.
- Supports the reviewing process of the localization by keeping track of the quality status for every single recource string in every locale.
- Automatic verifier checks for common problems during localization such as inconsistent translations, string.Format placeholder errors or punctuation errors.
- Separate, restricted “Translator” editition can be given to every translator working on the project.
- Offers a modern, simple and intuitive user interface tailored to the localization process.
These are only some of the interesting features in Babylon.NET that you might find interesting when translating a piece of software. For more information please visit the website at redpin.eu. They have also a trial version for download.
Published on Aug 31st, 2008 —
Tags: .NET, .NET Framework, Babylon.NET, C#, Software translation Comments (1) digg it!
kick it
Implementing the IDisposable interface
First it seems that the IDisposable interface is really easy to implement. It has only one method and how hard could it be to implement one method?! Soon after the first random exceptions happen you might realize that the IDisposable interface is a tough one.
There are a few things that should be considered when implementing the destruction process of a .NET class:
- Make sure you have a destructor in the class: to ensure that unmanaged resources get cleaned up.
- Try to follow a pattern that you can easily apply to all the various classes that need disposal.
- Try to follow the guidelines for the .NET IDisposable interface.
Looking at the samples you will see that Microsoft usually implements a method that can be called form both, the destructor and the IDisposable’s Dispose method. I usually follow that and create a second (and private; could also be protected) Dispose method that takes an argument saying it was called from the destructor or the IDisposable’s Dispose.
In that overloaded Dispose method I make sure that during a call from the destructor no managed class gets touched at all. That’s important because during garbage collection managed class instances get destroyed in a random order. It’s not guaranteed that any of the managed instances that you hold inside your class (as class fields) is still alive during a destructor call. This is one of the most important things to keep in mind when implementing the IDisposable interface.
I pointed out “managed classes” because pointers to native code are still alive (the GC ignores them). You need to manually clean them up inside of the overloaded Dispose method.
My code snippet for an implementation looks like this:
{
// this field is true when the class has been disposed.
private bool _disposed;
/// <summary>
/// Destructor of the Foo Class.
/// </summary>
~Foo()
{
// call the dispose method with false since
// the garbage collector is destroying the
// instance.
Dispose(false);
}
/// <summary>
/// Disposes the current instance of the class.
/// </summary>
/// <param name="disposing">True when this method is
/// called form the dispose method of IDisposable.</param>
private void Dispose(bool disposing)
{
// return if this instance is already disposed.
if (_disposed)
return;
if (disposing)
{
// it is save to access member variables (class fields)
// inside of this block. This block is only entered
// when the Dispose method of IDisposable is invoked.
// you should dispose (call the Dispose method) of
// member variables (class fields) inside of this block.
}
// outside of the "disposing" block it is only save to
// release native (unmanaged) resources. If you have
// class fields holding a pointer to a native piece
// of memory you can safely free that.
// it is not save to access other managed classes from
// here. They might have been destroyed by the garbage
// collector already! There is no way to force the GC
// to destroy objects in a certain order.
_disposed = true;
}
#region IDisposable Members
/// <summary>
/// Disposes the current instance of the class.
/// </summary>
public void Dispose()
{
// call the dispose method with true, since
// we are inside the Dispose method of IDisposable.
Dispose(true);
// make sure the GC is not going to call the destructor
// of this class again. This saves time during garbage
// collection.
GC.SuppressFinalize(this);
}
#endregion
}
Enjoying the C++ interop C# fun
A master thesis makes you do quite a lot of new things; and try new out. The goal for my thesis is to detect skin. I want to write the whole algorithmn in C++ (I need as much speed as possible and assembly is out of scope ;-)) and give it two kinds of “UI”: one is a Windows application and the second one is a web application. The whole concept should be extenable: this means that another UI could be written later on.
An interop between C# and C++ seems to be the solution to go. WPF and C# for the UI and C++ for the raw image processing and analyzing. But how to do that?
Nothing easier than that! First a solution with a C# project and a C++ DLL project (select Win32 in the C++ node in Visual Studio and then in the wizard DLL) needs to be created. That’s what needed to be ready to start with coding.
The most important thing is to make the functions in the DLL exportable, so that PInvoke (platform invoke) calls work on them. If methods are not exported VC++ gives them some random names (like, for example, ?MethodNameXDPADF) and it’s getting hard to access them. Luckily for us it’s easy to set a method as exported rather easy. The method needs only to be decorated with the __declspec(dllexport) attribute. I also added the extern “C” keywords to make it exportable as a C method.
Since the C++ DLL should do most of the work I thought of giving to the native method only the path to the video file (let the platform open the files) and make the method notify me about the progress. That means I want to register a method that is invoked when progress is made. And that method should be implemented in C# (for the Windows client); to allow me to show a progress bar or something similar; even displaying the current frame would be awesome.
Luckily specifying a callback method is an easy task. The whole thing (in C++) looks like this, where the first argument is the path of the video file and the second one is the notation for a function pointer:
{
int CurrentFrameIndex;
int TotalFramesCount;
};
// Processes the given video file.
extern “C” __declspec(dllexport) void ProcessVideo(char* path,
void (_stdcall *func)(ProcessingData))
{
for(int i = 0; i < 1000; i++)
{
// debug output the path to the file.
// fake some processing data for testing purpose.
ProcessingData data;
data.CurrentFrameIndex = i;
data.TotalFramesCount = 1000;
// invoke the function pointer and pass the
// data structure.
func(data);
}
}
You might also notice that the callback function takes a structure as argument. This structure can contain whatever is required to notify the client about the progress.
As mentioned I’m using PInvoke to invoke the C++ DLL. The C# code looks like this:
{
// structure that’s passed with the callback.
[StructLayout(LayoutKind.Sequential)]
public struct ProcessingData
{
public int CurrentFrameIndex;
public int TotalFramesCount;
}
// delegate used for the call back.
public delegate void CallBackMethodDelegate(ProcessingData data);
// exported method of the C/C++ DLL.
[DllImport(“TestDLL2″, ExactSpelling = true)]
public static extern void ProcessVideo(string path,
CallBackMethodDelegate del);
}
You might notice that the structure that is used to notify the client has been duplicated in the C# code. Also, I have created a delegate that looks exactly like the function pointer definition in C++. To invoke the ProcessVideo the typical PInvoke DllImportAttribute is used.
From there on invoking and getting the results is straight forward. It’s awesome to see how much speed improvements are gained by something as simple as this and how easy it is to interact with C/C++ code from C#
Microsoft Source Analysis for C#
Microsoft has released a source analysis tool for C#. The tool analyzes the source code of your C# solution and validates it against a set of rules. A set of rules is perhaps a little bit an understatement: it’s a huuuuge mass of rules.
The tool integrates into Visual Studio 2008 or Visual Studio 2005 and can be executed from there. The official blog posting about the release sums it up as follows:
We are very excited to announce the release of a new developer tool from Microsoft, Source Analysis for C#. This tool is known internally within Microsoft as StyleCop, and has been used for many years now to help teams enforce a common set of best practices for layout, readability, maintainability, and documentation of C# source code.
Source Analysis is similar in many ways to Microsoft Code Analysis (specifically FxCop), but there are some important distinctions. FxCop performs its analysis on compiled binaries, while Source Analysis analyzes the source code directly. For this reason, Code Analysis focuses more on the design of the code, while Source Analysis focuses on layout, readability and documentation. Most of that information is stripped away during the compilation process, and thus cannot be analyzed by FxCop.
The ultimate goal of Source Analysis is to allow you to produce elegant, consistent code that your team members and others who view your code will find highly readable.
It’s interesting to note that the tool has been in use by Microsoft for several years. Still, it seems to have some issues; I don’t know if these issues are just in the public release or have also been in the private one. Another reason might also be that I’m just to dumb to understand how to use it…
For me the bugs are the following: It seems as if the tool doesn’t scan all the files of the solution. Also, it is impossible to make it scan each project independent. There is a menu entry to do that (right click on the project to get there) but the tool seems to ignore what has been clicked. It outputs the scan results of a random files scan.
Another thing that bothers me very much is that the rule that doesn’t allow you to use tabs as way to indent code (the rule fires for each indent that you did by using a tab and tells you to use spaces) is enabled by default.
What a pitty! How can somebody rely on spaces as way to indent code… I never understood that and that’s also the first thing that I always have to change after having installed Visual Studio. Tabs are way more customizable. Spaces suck because you can never customize the space they indent. With tabs you set the tab size and you are done. People who like (or even need; not all see like a hawk) a bigger indentation are lost with spaces (they are lost in spaces, hehe). Not to mention that with spaces everybody in the team needs to use the same amout of spaces for the indention! It’s a shame the more you think about it.
I hope these are issues that get fixed very soon; and since the project has been published in the MSDN code gallery we are all free to share the feedback with the team.
Published on May 23rd, 2008 —
Tags: C#, Microsoft, Source Code Analysis, Visual Studio Comments (2) digg it!
kick it
What’s the Micro Framework?
Will and I had the chance to speak with Rob Miles and Dave Baker. They talked us into the .NET Micro Framework and showed us what you can do with C# on small devices (really really small devices) that could be embedded everywhere. Some of these devices are so small that their only reason to live is to work for us as a sensor somewhere.
It was really amazing to see how easy it is to use the Micro Framework and C# to create a solution that runs on a device that’s just as big as my old Nintendo(r) GameBoy (and with a cover would also look exactly the same).
Tune in if you like to program for embedded devices and ever wanted to see your code running in a toaster!
Published on May 11th, 2008 —
Tags: C#, Micro Framework, Smart devices Comments (2) digg it!
kick it
Collection initializers: adding multiple values
Collection initializer are a wonderful feature in C# 3.0. Instead of calling the Add method of the collection for each item that should be added to the collection it’s possible to add the items in curly brackets after the constructor call; the approach looks very similar to how to initialize arrays with a fixed set of values:
var list =
This code is unfolded by the C# compiler to something like this (not exactly like this but very similar):
var list =
// add the items to it.
list.Add(1);
list.Add(2);
list.Add(3);
list.Add(5);
// …
This pattern works wonderful with a list that exposes an Add method that expects only one argument. But does this model also work with, for example a Dictionary<K, V>? The dictionary class has an Add method that expects two values: a key and a value.
The answer is yes; the scenario extends also to a dictionary. The code to initialize a dictionary with values looks very like the mathematical notation for a set holding sub sets:
var dictionary =
{
{ “Hello”, 1 },
{ “World”, 2 }
}
After having found out that this works I went curious and tried the notation (the embedded curly brackets) also with the list class:
The C# compiler doesn’t create any warning or error for this piece of code. It seems as if you can always put the items that are added to a list also into the curly brackets.
Now, this made even more curious and created a class that has an Add method that expects three arguments:
{
public void Add(int index, string key, string value)
{
// code to add the item to the list
}
}
To add items to the FooList I added the following code to the application:
var foo =
{
{ 1, “key1″, “value1″ },
{ 2, “key2″, “value2″ }
};
… and the unexpected happened: this piece of code didn’t compile. But it wasn’t the initialization that gave me a compiler error but it was the implementation of the FooList.
The C# compiler wanted me to implement the IEnumerable interface into the FooList; otherwise the collection initializer isn’t allowed. This makes sense because all lists (or collections for that matter) need to implement the interface and collection initalizer should only be available for data structures that are implemented to hold a set of items.
After adding the IEnumerable implementation the code looked something like this:
{
public void Add(int index, string key, string value)
{
// code to add the item to the list
}
#region IEnumerable<KeyValuePair<string, string>> Members
public IEnumerator<KeyValuePair<string, string>> GetEnumerator()
{
// code to implement the enumerator.
}
#endregion
#region IEnumerable Members
System.Collections.IEnumerator
System.Collections.IEnumerable.GetEnumerator()
{
return this.GetEnumerator();
}
#endregion
}
I like the collection initialization pattern very much. But more than that it is really cool that the C# team made them very flexible. This allows the developers to use it in a varity of scenarios and doesn’t limit it to the initialization of lists with just one value! Great job, great feature!
Delegates vs Lambda Expressions
What the difference between
{
// check whether the current value should be returned.
return (value > 5);
}
// … other code
// return all values higher than 5.
List<int> result = list.FindAll(
and the following lambda expression
List<int> result = list.FindAll(value => value > 5);
for the .NET CLR (common language runtime)?
Answer
None! The C# compiler converts the second snippet into the same code that is found in the first one. That’s done because the CLR doesn’t know anything about lambda expressions. They are only a language construct and therefore converted to a delegate call and a method by the compiler.
The following is a Reflector screenshot that shows the lambda expression how it is translated by the C# compiler:
Published on Apr 20th, 2008 —
Tags: .NET Framework, C#, delegates, lambda expressions Comments (1) digg it!
kick it