Undocumented C#

Interesting (though useless) undocumented C# keywords (and corresponding IL instructions) described in Calling printf from C# – The tale of the hidden __arglist keyword on Bart De Smet’s B# .NET Blog.

Threading in C#

Joseph Albahari, the author of C# 3.0 in a Nutshell, C# 3.0 Pocket Reference, and LINQ Pocket Reference as well as LINQPad, has very nice Threading in C# article (well, it is 77 pages long and available in PDF format as well). As the author says, “[it] tackles difficult issues such as thread safety, when to use Abort, Wait Handles vs Wait and Pulse, the implications of Apartment Threading in Windows Forms, using Thread Pooling, Synchronization Contexts, Memory Barriers and non-blocking synchronization constructs.”

PostSharp 1.5 RTM

PostSharp 1.5 has been RTM-ed! Will have to try it in next project.

Exceptions in C++

In Google C++ Style Guide they state that they are not using exceptions in C++ code at Google. They have reasons for it (“historical” mostly, as usual), but I do not necessarily agree with their view on it. Anyway, exceptions are quite a controversial topic in C++ community, and a must-read C++ Exceptions: Pros and Cons article at CodeProject goes deeper into the subject.

Personally I think that exceptions are really great, although I see how people can get things messy/wrong when using exceptions in inappropriate contexts and/or in inappropriate ways. Recipe to avoid problems? My own short list:

• Use exceptions when they are really needed, i.e. when something exceptional happened
• Understand Exception guarantees AKA Abrahams guarantees (see more at Exception-Safety in Generic Components – Lessons Learned from Specifying Exception-Safety for the C++ Standard Library by David Abrahams)
• Follow Resource Acquisition Is Initialization AKA Resource Initialization Is Acquisition (or RAII/RIIA in short) principle

Styling a ScrollViewer/Scrollbar in WPF

In his Styling A ScrollViewer/Scrollbar In WPF article Sacha Barber explains how to do exactly what the article’s title claims. :)

.NET Events: Multithreading Issues

Threadsafe Events article at CodeProject explains problems one might encounter with .NET events in a multithreaded environment (not necessarily stating the absolute truth but still). Unfortunately, no-one has figured out the perfect solution, and we will have to choose “the best from all bad solutions” for some time still.

Asynchronous Callback Contexts article by the same author shows possible solution for event cancellation, particularly during object disposal: end-users do not expect components to raise events after they have been disposed or after they have unsubscribed from these events. The author refers to his Nito Asynchronous Library as a way to solve this issue.

Unattended .NET Installation

We needed to do unattended .NET 3.5 SP1 installation for our project, and at the same time we wanted to reduce the hard disk image size, so, after some Internet “crawling”, we found Silent .NET Maker synthesized – [a] script [that] builds custom .NET unattended, switchless, multimode installers/nLite addons, supporting all latest .NET framework versions, all its hotfixes and langpacks for win 2K/XP/2K3 x86 up to date. The thing really works, and we managed to get the size of full .NET 3.5 SP1 installer with all hotfixes down to something like 43MB (packed with 7-Zip) for 32-bit Windows XP. Not bad reduction! Aaron Stebner has also something to say about this topic.

Today’s Sites/Blogs

• Started to “bump” into the Smashing Magazine quite often nowadays. Usually it collects interesting Internet resources related to web development (notably CSS, HTML, AJAX, etc.) and design (user interfaces, fonts, new ideas, etc.), and also has some tutorial-like or how-to-like posts (e.g. about PNG optimization, common mistakes, etc.). Really nice! Webdesigner Depot, Line25 Web Design Blog, and Presidia Creative all have similar concept.
• Windows Presentation Foundation SDK by Windows Presentation Foundation SDK writers and editors. Might be more interesting, but OK nevertheless.
• Expression Blend and Design – The team blog of the Expression Blend and Design products

Today’s Sites/Blogs

• TomasP.Net blog by Tomas Petricek, author of Functional Programming for the Real World: With Examples in F# and C# (have not read this book yet, so no idea how good it is), features plenty of interesting information about functional programming in general, and in F# in particular.

WPF: Data Virtualization

WPF: Data Virtualization article at CodeProject shows a different approach to the data virtualization for WPF ItemsControls – a collection class providing data virtualization with large data sets.

“Bit Twiddling”

Needed to do some “weird” things recently that involved bit operations, e.g. to create masks with certain number of bits set. During my “research” I found few interesting places:

• Bit Twiddling Hacks – lots of snippets related to bit operations, e.g. counting, reversing, swapping, interleaving, testing, etc., etc., etc.
• Creating multiple numbers with certain number of bits set – this was the answer to my need, clean and simple
• Technical Interview Questions – has a lot of interesting topics, nicely categorized, although not all-encompassing, if comparing to the first link above

WPF: A Graph Control

WPF : A graph control by Sacha Barber at CodeProject is a very nice article showing how to build a graph control in WPF, in a very detailed and elaborated way. The control looks great, by the way :) .

WPF Video Playback Problems

There is one severe problem with video playback in WPF/Silverlight that, for some reasons unknown to me, is getting very little (almost none) attention from both the community and Microsoft. Basically, it boils down to WPF being absolutely unable to properly play video content. Let me explain by using the following diagram:

First line shows video frames as they are in the video content. Second line depicts variable frame rate of the WPF renderer – as you know, WPF is changing the frame rate dynamically, and CPU load will affect frame rate too. There are two possible outcomes:

1. WPF is using vsync (version 1), i.e. it synchronizing rendering to the screen with the screen refresh frequency. This is what you will get on Vista, and sometimes on XP (normally XP video drivers are not using vsync). The resulting video shown on the screen will have variable duration of frames, and the viewer will be present with artifacts like skipped video frames, “jerky” playback, where motion is not “smooth”/uniform, etc.
2. WPF is not using vsync (version 2). It is the case normally seen on XP. The resulting video is even worse, as there is the tearing effect present now – upper and lower parts of the displayed video frame are not matching. This problem is not present on some XP machines, e.g. I do not see it on my home PC, while it is present on 100% of other machines.

This is a bit oversimplified picture, but good enough for our purpose. In reality, the resulting on-screen picture will depend also on the screen refresh frequency, but artifacts will be more or less the same. In both cases the video playback it totally unacceptable though.

The issue is very serious, and, unfortunately, it is unsolvable in terms of today’s WPF. I think it will be not solved in the near future either, as solving it would require WPF to adopt constant-frame rate rendering paradigm, and synchronizing it with the display refresh rate. This is not likely to happen, as it is a drastic change to the fundamentals of WPF, and, at the same time, it will waste resources in non-video related applications (now WPF can decide what frame rate it will use, and can dynamically change it, e.g. dropping frame rate for “still” scenes and increasing it when animations start).

In our software we had to go through a lot of extra pain to “overcome” this issue – we render video using DirectShow by incorporating Win32 host into our WPF application and implement all kinds of “tricks” to allow WPF content to get into the video window airspace (to display OSD’s, menus, etc.) by using e.g. clipping regions (say Goodbye! to transparency though). There are a few third party projects out there (WPF MediaKit by Jeremiah Morrill is an excellent example) that allow one to mix DirectShow and WPF, but none of them will fix the above mentioned issues, as the resulting picture is rendered by WPF renderer and all the artifacts will be there still.

Probably, for majority of people this is not really an issue (at least until you point them to it; after that they can see it on their own and they become very annoyed), especially if you are playing some kind of home-made content from the YouTube (although YouTube has HD content nowadays too), but it is completely unacceptable for people at least somehow concerned about the video playback quality. DVD/DivX player costing $30 will not have these problems, so it is difficult to explain why $1000 machine (33 times more expensive!!!) cannot produce even remotely as good video playback on $2000 HD TV set.

In addition to these video playback problems, WPF on XP suffers from the tearing issue not only during video playback, but also during “normal” WPF animations. And this has even more profound effect, as it makes it impossible to implement animated WPF applications on XP.

Microsoft’s reaction to the tearing issue on XP is problematic. We have tried to approach them via all possible channels – Microsoft Connect program, Microsoft Metro program, newsgroups, personal contacts, everything. They either deny the issue, or say that it is unsolvable for XP in general case, so they are not going to solve it (but they could easily solve it for something like 95% of all XP installations by solving it at least for ATI and Nvidia cards), or they say that they will not solve it for XP anymore, as XP is not available so nobody cares. And this last reaction is problematic again, as the issue is present not only on Windows XP Home/Pro, but on Windows XP Embedded and Windows Embedded Standard as well. These OS’s will be around for some time still, and Windows 7 Embedded will not come before 2010 and, being Vista-based, will be a resource hog – something not necessarily good for embedded system.

Managed Windows API

Managed Windows API is a collection of C# components that wrap Windows API functionality – a nice addition to pinvoke.net.

JavaFX

It seems that Sun can say now, “rumors about my death were greatly exaggerated”. Recently they rather quietly released JavaFX – a rich client platform (what has happened to thin client dreams of Sun and alike? huh? ;) for creating and delivering rich Internet experiences across “all the screens of your life” (they are using this phrase all over the place, and it sucks, to be honest, but go figure).

From what they show in their videos, it looks rather like WPF/Silverlight for Java. In other words, it is the presentation layer for the Java platform. Performance-wise it looks rather good (OK, no idea what hardware was running those demos). For example, they were playing 9 (yes, nine!) video streams simultaneously, but then, who the f#$k needs 9 videos playing at the same time!? It is the same f#$*%ng old useless BS that Microsoft is showing all the time! Of course, it remains to be seen if it can play all this video content without framerate issues that plaque WPF/Silverlight. JavaFX Script is a declarative scripting language behind JavaFX.

Sun is promising to make JavaFX multiplatform, capable of running on desktop, mobile, TV and other Java-enabled consumer platforms, but so far they have desktop version only. Then, as far as I understand, development tools are not necessarily ready yet (judging from their sentence “JavaFX technology will provide a suite of tools and authoring solutions that enable unprecedented collaboration between designers and developers”). If they will deliver all these promises, Microsoft might get into deep trouble with WPF, as Java’s inability to provide good UIs were one of the main reasons why many were choosing .NET over Java on the client side (I am not discussing platforms – .NET 3.5 vs Java 6 – just presentation parts). What Sun has already made right, in my opinion, is their selection of Adobe PhotoShop and Illustrator as a designer tools, as these are light-years ahead of Microsoft Expression Designer.

Future will show, what will come out of all this, but the good point is that Microsoft will get some competition in this field, and might eventually do something to fix its platform’s shortcoming (though unlikely – so far they are taking extremely defensive and ignorant stance regarding WPF/Silverlight problems).

WPF Blogs

• DevDave – Dave Relyea’s Silverlight Blog by Dave Relyea [MSFT]- really much info about Silverlight and WPF, including layout and panels
• Ruurd Boeke Enterprise development and technobabble – layouts, panels, controls, etc.

.NET/WPF Obfuscators

We have recently purchased PreEmptive Solutions Dotfuscator (which sounded like a good idea when we were making decision about it), but to be honest I am not very happy about it: it cannot properly handle WPF projects and you have to perform a lot of “voo-doo dances” to get at least some protection there (and all that while costing s|-|1t-load of money). This pushed me to do a new round of evaluations of competing products, and I have found few that are really interesting:

• .NET Reactor (about 150€) is a really powerful tool with lots of features (code and resource protection, code encryption, support for .NET 1.1, 2.0, 3.0, 3.5, CF 1.0 and 2.0, ASP.NET, Mono, can merge assemblies, remove IL code, generate native executables, etc., etc., etc.). Additionaly there is a licensing system, but I have not tried it yet. Despite it claims supporting .NET 3.5 I did not manage to protect our WPF assemblies with it, but all other assemblies were protected like a charm.
• DeepSea Obfuscator (about 200€). This obfuscator’s list of features is not much shorter, but few outstanding points are support for WPF assemblies, and declarative obfuscation, where the obfuscation process can be controlled by applying obfuscation-related attributes to your code. I managed to protect our WPF assembly with it, but resulting assembly is crashing when I’m entering one specific screen. I guess this crash can be eliminated by using attribute-based obfuscation and removing some properties/classes from the protection process (which is not that good, to be honest, as it means extra work, howewer small it is).
• {smartassembly} (about 350€-650€, depending on version) looks really impressive as well. It was able to protect WPF assembly and, it seems that the abovementioned crash is not present here; well, it is with certain settings related to obfuscation, but it can be easily eliminated by tweaking settings. Control flow obfuscation seems to be much stronger than that of the DeepSea, and there are some additional protection settings that make lives of Reflector, ILDASM and others really miserable (e.g. invalid metadata streams).

It seems that to get decent level of protection we will have to use either {smartassembly}, or both .NET Reactor and {smartassembly} (in case {smartassembly} would be not able to provide the same protection level for “normal”=non-WPF assemblies as .NET Reactor does – remains to be seen).

A .NET Cryptography Primer

Found A .NET Cryptography Primer on State Street Gang blog. It is a four-part article:

• Part I: Background
• Part II: Hashing
• Part III: Symmetric Cryptography
• Part IV: Asymmetric Encryption

XAML Serialization

I am using XAML serialization instead of XML serialization more and more – IMHO it is much nicer and natural. There are few things to remember though, and XAML Serialization FTW does excellent job in enumerating those, although the list is not exhaustive.

Buffer Management for Networked .NET Applications

Found TCP: Buffer Management and related Async Sockets and Buffer Management and Async Sockets and Buffer Management [CTD] articles on Greg Young’s blog. These articles describe the problem and show the solution:

When you call BeginReceive/BeginSend on a socket, the memory that you pass to the method will be pinned for the duration of the call. This will lead to heap fragmentation and to make matters worse it will often be in your gen0 heap if you aren’t careful. This becomes especially true in the most common socket applications (request/response) as BeginReceive is often called and waits for a long time to receive data (by long time I mean a few seconds or more).

The blog itself is interesting on its own.

.NET 4 Code Contracts

Note My opinion is not based on some kind of “attachment” to Spec#. Everything I know about Spec# and Code Contracts I know from public sources, and myself I have not used either of these technologies.

Nowadays, a lot of time is spent by Microsoft people telling us how cool the new .NET 4 will be (if I would be in bad mood now I would say that they should f$#@ng go and fix .NET 3.5 SP1 as well as billion other broken things they already have before starting to work on “newer and more improved” stuff). Three most prominent features talked about are support for dynamic languages, addition of the dynamic type to C#, and something called Code Contracts. While I do not have anything to say about dynamic languages (as I do not use them, and, to be honest, do not see much value in them, but this is completely irrelevant to this post and in general – I am not interested in flaming here), and about the new dynamic type in C# (which by the way is not bad, but I am a bit afraid of the extent of its potential misuse), I do have an opinion about the Code Contracts.

Microsoft Research has technology called Spec#. It is fairly stable and developed programming system that consists of programming language, its compiler, and static program verifier, and allows design-by-contract approach (I would say much like that of Eiffel, or even more powerful) among other offered features. Spec# team says, “A unique feature of the Spec# programming system is its guarantee of maintaining invariants in object-oriented programs in the presence of callbacks, threads, and inter-object relationships”. Spec# language is similar to C# (well, it is C# with some extensions indeed, and there is even “C# compatibility mode”, so that Spec# program can be compiled by “normal” C# compiler).

So, what’s the deal? Instead of sticking to Spec#, and finalizing its development and support in tools (especially that Spec# was really warmly accepted by development community), Microsoft invented the Code Contracts. And nothing would be wrong if it would offer anything new or improved compared to Spec#. Unfortunately, quite contrary, it is really big step backwards. The biggest problem in the Code Contracts, as I see it, is that contracts are specified in the method bodies, completely missing the whole point of design by contract how it is understood by e.g. Eiffel or Spec#. For example, how in heaven are you going to specify contracts for interfaces? (you cannot have method bodies in interfaces, right?) Of course, Microsoft guys will come with some ugly trick/hack here, and will allow contract specifications in interfaces, but how ugly that solution will be?

Then, there come aesthetic factors, closely related to code readability. A quick demo…

   string GetDescription(int x)
   {
      Contract.Requires(x > 0);
      Contract.Ensures(Contract.Result() != null);
      ...
      return SomeString;
   }

That was Code Contracts. Yay, how beautiful! (NOT!!!!!) Compare to the same in Spec#:

   string! GetDescription(int x)
      requires x > 0;
   {
      ...
      return SomeString;
   }

First of all, here the contract is clear from the method declaration, and there is no need to read the method body to get it. Notice string! syntax which specifies non-nullable string (all types can have ! added to them to specify that declared objects cannot be nulls) and eliminates the need for Ensures clause, and then clean and concise requires x > 0 clause. That’s it! Nothing more is needed!!! And here is a bit more elaborated sample, which shows both requires and ensures clauses:

   void int BinarySearch (int[]! a, int value)
      requires a.Length > 0;
      ensures result < a.Length;
      ensures a[result] == value;
   {
      ...
   }

Cool, isn’t it? Add to it invariants:

   class Word
   {
      private string! line; int start, length;
      public string ToString()
      {
         return line.Substring(start, length);
      }
      invariant 0 <= start && 0 <= length;
      invariant start + length <= line.length;
   }

ability to specify contracts on interfaces (look at those forall and old things!):

   interface IList
   {
      int Count { get; }
      T this[int i] { get; }
      public void Add(T x)
         ensures Count == old(Count) + 1;
         ensures forall{int i in (0:old(Count)); this[i] == old(this[i])};
         ensures this[old(Count)] == x;
   }

and other nice and powerful features, and you have really nice development environment that simplifies your life and helps you to write verifiable and correct code. But no! That would be way too simple and way too good, and instead we will get ugly Code Contracts. AAAaaa!!! I want Spec# baaaack!!!!

Now, as I said in the beginning of this post, I do not have hands-on experience with either of these technologies. But I believe that being more or less 20 years in the software development business is giving me enough experience to make a “high-view” judgment on technologies based on minimal data and “6th sense” (or gut-feeling, or instinct, or …). And my 6th sense is telling (yelling?) me that Code Contracs as they are proposed by Microsoft are not something that I will ever become excited about (as opposed to Microsoft’s Spec#).

Webcam Control with WPF

Webcam control with WPF or how to create high framerate player with DirectShow by using InteropBitmap in WPF application by Tamir Khason shows how to do exaclty what it claims to show :) in a way alternative to what Jeremiah Morrill is proposing (now, I do not have an opinion as of which is better or worse – they both have their uses).

Side Note Unfortunately, you cannot play decent quality video in WPF application (meaning in WPF “airspace”) no matter what you do – it has to do with non-constantness of the WPF rendering frame rate (and, on XP, add here WPF tearing artefacts), and I do not see how it can be fixed in the future as this problem is rooted extremely deeply in the core of WPF rendering pipeline. Microsoft knows about this issue, but does nothing to fix it.

Today’s Blogs

Found these blogs today:

• Essential WPF by Tomer Shamam – WPF-related info, including localization
• Just Code by Tamir Khason – WPF and not only…
• IEnumerable<Stuff> – much of functional-style programming in C#, generics, closures, etc.

SciTech .NET Memory Profiler

Schitech .NET Memory Profiler has plenty of features that will make your life easier when you try to fight memory-related problems in your .NET applications. Nice touch – it is able to track unmanaged resource usage (e.g. HWND, HBITMAP and unmanaged memory) and present it together with the .NET memory information. Just this single feature alone saved my day when I had to find unmanaged memory leak in the mixed-mode .NET app (C# and C++), and all other profilers just $@% badly – I had the bug fixed in less than one hour after I downloaded the trial version of the tool (that 1 our included “learning curve” as well!!!). Recommend!

Crack.NET

Crack.NET is a runtime debugging and scripting tool that gives you access to the internals of a WPF or Windows Forms application running on your computer. It nicely rounds the Snoop and Mole for Visual Studio group, as it allows you to “walk” the managed heap of another .NET application, and inspect all values on all objects and types. In addition, you are able to write and execute IronPython scripts that run inside the target application.

Josh Smith is the author, and has a nice introductory page for the tool.