Zach Saw's Blog

StreamReader.Peek can block - Another .NET framework bug

2011-07-28T19:53:00.001+10:00

There are so many bugs in the .NET framework that existed since the very first version and remains not fixed as of version 4.0 (see some of my other blog posts). Here's another one that I discovered a long time ago but did not have time to write about - StreamReader.Peek can block for Process.StandardOutput / Process.StandardError.

There's even a Microsoft Connect entry that has been filed since September 2005! And a several blog/forum posts [1: Jay R. Wren] [2: MSDN] [3: StackOverflow] about it. What has Microsoft done about it? Nothing! Is it surprising? Not at all - none of the bugs I've blogged about has been fixed so far, critical or not. All they did was whinge about how hard/expensive it is to fix.

So here it is Microsoft, I've come up with a solution for you (feel free to rip me off).

Essentially, what Microsoft needs to do is change Process.StartWithCreateProcess such that standardOutput and standardError are both assigned a specialised type of StreamReader (e.g. PipeStreamReader).

In this PipeStreamReader, they need to override both ReadBuffer overloads (i.e. need to change both overloads to virtual in StreamReader first) such that prior to a read, PeekNamedPipe is called to do the actual peek. As it is at the moment, FileStream.Read() (called by Peek()) will block on pipe reads when no data is available for read. While a FileStream.Read() with 0 bytes works well on files, it doesn't work all that well on pipes! In fact, the .NET team missed an important part of the pipe documentation - PeekNamedPipe WinAPI.

The PeekNamedPipe function is similar to the ReadFile function with the following exceptions:
...
The function always returns immediately in a single-threaded application, even if there is no data in the pipe. The wait mode of a named pipe handle (blocking or nonblocking) has no effect on the function.

There you go. It looks like Microsoft forgot about the PeekNamedPipe WinAPI that the other Microsoft team wrote. Wow! That's embarrassing!

Website Moved

2011-07-06T22:17:00.002+10:00

To all my followers,

I've moved my website across to www.zachsaw.com from the .co.cc domain which Google has banned from their index. So please update your bookmarks.

Website: http://www.zachsaw.com
Forum: http://forum.zachsaw.com
Blog: http://blog.zachsaw.com

Thanks everyone for your continued support.

Win7 SP1 OS bug - Do we need Windows 8 now?

2011-02-23T23:03:00.005+11:00

It's the same Windows 7 x64 (WOW64) bug I reported in November last year (2010) - see the entry in Microsoft Connect.

And the new Windows 7 Service Pack 1 *HASN'T* fixed it! It doesn't only affect Windows 7 though, it goes back all the way to the very first version of x64 Windows - XP 64-bit.

There's no way to workaround this problem in user code. It is a fundamental design flaw in the very first version of 64-bit Windows. This makes it very hard (expensive) for Microsoft to fix - a proper fix requires a redesign of the whole emulation layer of 32-bit apps on 64-bit Windows. Microsoft charges a minimal sum for their OSes (sarcasm), so it's not like they have the resources to work on anything that doesn't affect everyone. It's very likely that Windows 7 will be forever plagued with this bug as it would seem to be easier (cheaper) to start from a clean sheet with Windows 8. Then again, why bother? It's not as if Microsoft has any real competition at all in the x64 OS market - they own more than 80% of the pie!

From the feedback of my previous post, the problem appears more widespread than Microsoft would want to acknowledge - see Discussions about the Boehm Garbage Collector (Boehm GC). Hopefully this bug gets fixed sooner rather than later.

In the meantime, if you want to test it out yourself, you can download this (extract all and run Tester.exe). Usually running it for a few minutes will get it to crash on x64. Give it 30 minutes if it doesn't. If it doesn't crash (i.e. on 32-bit OS), you'll have to kill the app via task manager after you've tested it though (an unrelated bug in the tester application prevents it from shutting down completely - the app will appear closed but the process remains running).

Fast memcpy for large blocks

2010-11-24T23:15:00.000+11:00

Memory copy of 8MB blocks can be quite slow.

I found that both memcpy and CopyMemory won't utilize the full bandwidth of your RAM due to memory controller bottlenecks (I suspect the memory controller isn't smart enough to prefetch the right data). So this implementation by William Chan issues SSE2 prefetch instructions and gets the memory controller to literally stream the data back and forth from RAM in the fastest manner.

Note though, that you'll need to give it 16-byte aligned memory and it copies in 128-byte blocks.

The result is here (on my Core2Duo Wolfdale CPU @ 3.6GHz, dual channel DDR2 @ 800MHz):

memcpy/CopyMemory:
1871.775MB/sec

William Chan's SSE2 memcpy:
3540.471MB/sec

That's nearly double the speed of the naive memcpy!

Reporting a bug against Windows OS - possible?

2010-11-13T21:26:00.005+11:00

Is Microsoft so arrogant that they think their OS is bug-free and that no one should ever need to report a bug against their OS?

There doesn't seem to be a way to report a bug against the Windows OS (no such category in Microsoft Connect). 2 years ago, I tried to report a bug against Vista - TreeView Indent in Vista causes HitTest to fail. The closest way would be to report it against VisualStudio. Surprise surprise, the VS product team closed it as external and did absolutely *nothing* after that. Sure, they redirected me to a non-existent website, which was supposed to be the MSDN forums, but that was where I was redirected to MS Connect in the first place! Talk about going around in circles... This really reminds me of Telstra (the ex-government owned now privatized biggest telco in Australia).

With regards to the bug that I've just reported, I'd expect them to do the same, and close it as external, not knowing which department they need to talk to. Microsoft is so big, dumb and slow that its right hand really have no idea what the left hand is doing! Sad really...

* Edit: Looks like I'm not the only one complaining:

Reporting a bug in Vista 64 WOW64
How do you file a bug report for Windows?
Problems with comdlg32.ocx, Windows Vista and long file names/extension´s

WOW64 bug: GetThreadContext() may return stale contents

2010-11-13T17:07:00.004+11:00

My GC app runs perfectly fine under native x86 OS's starting from XP.

I've installed Windows 7 x64 recently (I've always used Win7-x86 due to 64-bit being in its infancy yet for the stuff that I do on my desktop) and to my dismay the app fails after a few minutes of running.

After hours of debugging (GC is never easy to debug, let alone a hypothesis that involves a bug in WOW64 which has been used by millions since XP-64), I found that WOW64 clobbers the ESP value (as returned by GetThreadContext(), of which the the GC thread in the app relies upon to get the current stack pointer of mutator threads) when it does a call out to long mode. I also found that ESP is always restored upon returning.

Prior to calling GetThreadContext(), the GC thread suspends all mutator threads. If it just so happens to suspend the mutator thread while it's running long mode code in user mode, the ESP value gets changed to a value indicating a higher address than the actual stack pointer (remember on IA, stack 'grows' downwards). I've seen this happen for SetEvent() and SwitchToThread() (as these are the most frequently called kernel functions in the app).

This means that either SuspendThread is suspending a thread in an incompatible way to native x86, or the thread's context in WOW64 is not being protected when the code jumps to translation mode. Either way, I was sure it's a bug.

I then found this article (difference between WOW64 and native x86 system DLLs) and while the article isn't exactly addressing the issue I'm facing, I found it very useful because this guy (Skywing from Microsoft) certainly knows WOW64 very well. I proceeded to email him and he replied with the following:

[...] there’s an issue with get and set context operations against amd64 Wow64 threads returning bad information in circumstances when the thread is running long mode code in user mode. This relates to us [Microsoft] pulling the Wow64 context from the TLS slot (as described in the [this] article) before that context structure has been updated with current contents.

That sounded very much like the issue here. So, I decided to dig deeper and put a few software traps to try and catch it in the act.

This is what I found.

The stale contents from GetThreadContext() actually came from the previous system call out (a looong way up the stack really - it's not as if it's a few instructions ago). It should've returned contents from the *current* system call out instead (or to be precise, just before the call out to long mode took place). Like Skywing said, they pulled the context before it's updated with the current contents.

With that said, we can now conclude that it is indeed an OS bug (Win7 SP1 hasn't fixed it).

* I'd like to thank Skywing for his effort in assisting me to root cause this issue.

BCC32 the Optimizing Compiler?

2010-10-21T22:48:00.010+11:00

We all know asking the bcc32 compiler team to do put more effort into making the codegen generate more efficient / optimized asm is a *BIG ASK*, seeing how they haven't even got the basics (compiler bugs that Microsoft VC++ compiler fixed since MSVC 2005) working correctly. VC++ 6 was worse than C++ Builder 6, but since then, Microsoft have worked hard and fixed up their compiler, made it fully optimizing and generate one of the fastest and most efficient code in the world. It is also now one of the most compliant C++ compilers of all.

Let's compare the following code sample.

For the uninformed, the following usage pattern is found in a lot of expanded template code (I'm using it a lot in my GC framework and Boost uses it too).

#include <tchar.h>

struct foo
{
    inline operator bool() const
    {
        return false;
    }
};

int _tmain(int argc, _TCHAR* argv[])
{
    if (foo())
        return 0; // *see footnote
    return 0;
}

*footnote: usually this is something more meaningful, but here I'm trying to illustrate how massively unintelligent bcc32
is.

bcc32 (C++ Builder XE) command line:

    bcc32 -O2 -Hs- -C8 -v- -vi test8.cpp

generated asm:

push ebp
mov ebp,esp
add esp,-$08
push edi
lea edi,[ebp-$08]
xor eax,eax
mov ecx,$00000008
rep stosb
lea eax,[ebp-$08]
xor edx,edx
test dl,dl
jz $00401201
xor eax,eax
jmp $00401203
xor eax,eax
pop edi
pop ecx
pop ecx
pop ebp
ret

cl command line:

    cl /Ox /Ot test8.cpp

generated asm:

xor eax,eax
ret

BCC32 generated 18 lines of useless opcodes when really only 2 are required. With BCC32, your code would be a few hundred times slower (taking into account of memory access latencies).

SerialPort IOException Workaround in C#

2010-07-06T12:26:00.016+10:00

As promised, I've whipped up a quick workaround to fix the problem as described here.

Here's the code:

using System;
using System.IO;
using System.IO.Ports;
using System.Runtime.InteropServices;
using System.Text;
using Microsoft.Win32.SafeHandles;

namespace SerialPortTester
{
    public class SerialPortFixer : IDisposable
    {
        public static void Execute(string portName)
        {
            using (new SerialPortFixer(portName))
            {
            }
        }

        #region IDisposable Members

        public void Dispose()
        {
            if (m_Handle != null)
            {
                m_Handle.Close();
                m_Handle = null;
            }
        }

        #endregion

        #region Implementation

        private const int DcbFlagAbortOnError = 14;
        private const int CommStateRetries = 10;
        private SafeFileHandle m_Handle;

        private SerialPortFixer(string portName)
        {
            const int dwFlagsAndAttributes = 0x40000000;
            const int dwAccess = unchecked((int) 0xC0000000);

            if ((portName == null) || !portName.StartsWith("COM", StringComparison.OrdinalIgnoreCase))
            {
                throw new ArgumentException("Invalid Serial Port", "portName");
            }
            SafeFileHandle hFile = CreateFile(@"\\.\" + portName, dwAccess, 0, IntPtr.Zero, 3, dwFlagsAndAttributes,
                                              IntPtr.Zero);
            if (hFile.IsInvalid)
            {
                WinIoError();
            }
            try
            {
                int fileType = GetFileType(hFile);
                if ((fileType != 2) && (fileType != 0))
                {
                     throw new ArgumentException("Invalid Serial Port", "portName");
                }
                m_Handle = hFile;
                InitializeDcb();
            }
            catch
            {
                hFile.Close();
                m_Handle = null;
                throw;
            }
        }

        [DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)]
        private static extern int FormatMessage(int dwFlags, HandleRef lpSource, int dwMessageId, int dwLanguageId,
                                                StringBuilder lpBuffer, int nSize, IntPtr arguments);

        [DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)]
        private static extern bool GetCommState(SafeFileHandle hFile, ref Dcb lpDcb);

        [DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)]
        private static extern bool SetCommState(SafeFileHandle hFile, ref Dcb lpDcb);

        [DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)]
        private static extern bool ClearCommError(SafeFileHandle hFile, ref int lpErrors, ref Comstat lpStat);

        [DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)]
        private static extern SafeFileHandle CreateFile(string lpFileName, int dwDesiredAccess, int dwShareMode,
                                                        IntPtr securityAttrs, int dwCreationDisposition,
                                                        int dwFlagsAndAttributes, IntPtr hTemplateFile);

        [DllImport("kernel32.dll", SetLastError = true)]
        private static extern int GetFileType(SafeFileHandle hFile);

        private void InitializeDcb()
        {
            Dcb dcb = new Dcb();
            GetCommStateNative(ref dcb);
            dcb.Flags &= ~(1u << DcbFlagAbortOnError);
            SetCommStateNative(ref dcb);
        }

        private static string GetMessage(int errorCode)
        {
            StringBuilder lpBuffer = new StringBuilder(0x200);
            if (
                FormatMessage(0x3200, new HandleRef(null, IntPtr.Zero), errorCode, 0, lpBuffer, lpBuffer.Capacity,
                              IntPtr.Zero) != 0)
            {
                return lpBuffer.ToString();
            }
            return "Unknown Error";
        }

        private static int MakeHrFromErrorCode(int errorCode)
        {
            return (int) (0x80070000 | (uint) errorCode);
        }

        private static void WinIoError()
        {
            int errorCode = Marshal.GetLastWin32Error();
            throw new IOException(GetMessage(errorCode), MakeHrFromErrorCode(errorCode));
        }

        private void GetCommStateNative(ref Dcb lpDcb)
        {
            int commErrors = 0;
            Comstat comStat = new Comstat();

            for (int i = 0; i < CommStateRetries; i++)
            {
                if (!ClearCommError(m_Handle, ref commErrors, ref comStat))
                {
                     WinIoError();
                }
                if (GetCommState(m_Handle, ref lpDcb))
                {
                     break;
                }
                if (i == CommStateRetries - 1)
                {
                     WinIoError();
                }
            }
        }

        private void SetCommStateNative(ref Dcb lpDcb)
        {
            int commErrors = 0;
            Comstat comStat = new Comstat();

            for (int i = 0; i < CommStateRetries; i++)
            {
                 if (!ClearCommError(m_Handle, ref commErrors, ref comStat))
                 {
                     WinIoError();
                 }
                 if (SetCommState(m_Handle, ref lpDcb))
                 {
                     break;
                 }
                 if (i == CommStateRetries - 1)
                 {
                     WinIoError();
                 }
            }
        }

        #region Nested type: COMSTAT

        [StructLayout(LayoutKind.Sequential)]
        private struct Comstat
        {
            public readonly uint Flags;
            public readonly uint cbInQue;
            public readonly uint cbOutQue;
        }

        #endregion

        #region Nested type: DCB

        [StructLayout(LayoutKind.Sequential)]
        private struct Dcb
        {
            public readonly uint DCBlength;
            public readonly uint BaudRate;
            public uint Flags;
            public readonly ushort wReserved;
            public readonly ushort XonLim;
            public readonly ushort XoffLim;
            public readonly byte ByteSize;
            public readonly byte Parity;
            public readonly byte StopBits;
            public readonly byte XonChar;
            public readonly byte XoffChar;
            public readonly byte ErrorChar;
            public readonly byte EofChar;
            public readonly byte EvtChar;
            public readonly ushort wReserved1;
        }

        #endregion

        #endregion
    }

    internal class Program
    {
        private static void Main(string[] args)
        {
            SerialPortFixer.Execute("COM1");
            using (SerialPort port = new SerialPort("COM1"))
            {
                port.Write("test");
            }
        }
    }

* Use Firefox to copy and paste the code above. Formatting won't be preserved if you use IE (IE bug).

.NET SerialPort Woes

2010-07-01T18:23:00.008+10:00

Preface

This is a very long post articulating the .NET SerialPort bug and the proposed fix for Microsoft to implement in its post .NET 4.0 framework. An interim fix that doesn't involve Microsoft is also available.

Introduction

The built-in serial port support in .NET has been a major let down (which has remained largely unchanged since its introduction in v2.0 to the latest v4.0). Posts on MSDN have suggested that a lot of people (both C# and VB users alike) are in fact facing some form of difficulties using System.IO.Ports.SerialPort:

IOException when reading serial port using .NET 2.0 SerialPort.Read

Port IOException

SerialPort.Close throws IOException

IOException when SerialPort.Open()

WinCE 5.0 - IOException when serialPort.Open()

WARNING! SerialPort in .NET 3.5

... and many more, but take the last one with a grain of salt.

Yet Microsoft could't seem to be able to reproduce the bug, or worse, brushed it aside thinking it's a problem with users' code. That is likely due to the noise (i.e. incorrect answers accepted as correct answers) introduced by the forum's serial port expert pretenders (a lot of them Microsoft support staffs) - so far none of the posts were answered correctly, yet were all marked as correctly answered! Yay to the quality of MSDN forum - a forum where n00bs answer questions by other n00bs. The truth is, there's only one similarity in all of the posts - they all encountered IOException.

The Problem - IOException

To understand why IOException occurs in SerialPort (or rather, SerialStream to be exact), one would only need to look as far as the WinAPI Comm functions. SerialStream calls several comm APIs to get the real job done and when the API functions fail and return an error, SerialStream simply throws an IOException with the message returned by FormatMessage with the error code from GetLastError.

So why does the WinAPI function fail? From the posts, they all have a common error message:

"The I/O operation has been aborted because of either a thread exit or an application request." (error code 995)

While a thread exit will also cause an overlapped (asynchronous) function to implicitly abort, in this case it's aborted because the serial port is in a mode where any errors encountered by the UART chip would trigger the abort flag causing all current and subsequent serial port related calls to abort. Errors include parity error, buffer overrun, etc.

Some developers have even encountered IOException as soon as they call SerialPort.Open(), especially in slow devices such as handhelds running .NET CE. Some encounter it when the garbage collector disposes the serial port. Some encounter it when they call SerialPort.Read().

They're all due to a mistake in .NET's SerialStream implementation - neglecting to set the fAbortOnError flag in the DCB structure when initializing the serial port.

This negligence on Microsoft's part means every time you run your application you could potentially encounter a different behavior (this flag is persistent across app runs and the default is determined by BIOS and/or UART hardware vendor). Some claim that it only happens in one machine and not others. This also explains why it has remained such a pesky problem for both developers and Microsoft since the first incarnation of the SerialPort class.

When fAbortOnError flag is set to true, this is indeed the expected behavior - but is this the desired behavior Microsoft intended for its users? No. System.IO.Ports.SerialStream was never meant to work with fAbortOnError set to true, because the ClearCommError WinAPI function that goes hand-in-hand was nowhere to be found among its methods. Clearly, whoever wrote SerialStream made a mistake (and needs to be shot).

The Solution

It took me an entire day to root cause this problem. Luckily the solution is much simpler.
Here's what Microsoft needs to do to fix the problems (in reference to the .NET 4.0 source):

1) In InitializeDCB, SetDcbFlag for bit 14 to zero - this sets fAbortOnError to false. Also, retry GetCommState and SetCommState if it fails with error 995 (call ClearCommError() before retrying).

2) In SerialStream's c'tor, move InitializeDCB to the line before GetCommProperties. This fixes the problem for the folks who've been getting IOException when calling SerialPort.Open(). The reason SerialPort.Open() only failed on slow devices because between the port's CreateFile and the time GetCommProperties() is called, a comm port physical error might have already occurred.

The reason some people have claimed that their app simply crashes out when their application terminates is due to DiscardInBuffer() in SerialStream.Dispose() throwing IOException because PurgeComm failed with error 995, likely because of buffer overrun as their serial devices would've been sending and filling up the input buffer before user closes the app. And mind you, Dispose() at that point would've been called by the garbage collector thread - hence a try-catch would've been ineffective, unless of course, you've manually disposed the object prior to closing the app - causing the app to hard crash with unhandled exception.

How do you fix it in the interim? Simple. Before you call SerialPort.Open(), simply open the serial port by calling CreateFile and SetCommState's fAbortOnError to false. Now you can safely open the serial port without worrying that it might throw an IOException. I've whipped up a sample workaround in C# that you could use as a reference.

Anonymous methods / Lambda expression variable capture scope in C#

2010-05-23T11:25:00.005+10:00

Let's face it, at some point or another, we've come across the problem in C# where you pass a for-loop variable into an anonymous method without redeclaring it and find that it doesn't behave expectedly. Once we get used to the idea of always redeclaring a variable you're going to use in your lambda expression though, you tend to ignore the fact that there is actually no reason why it should be the way it is.

At least, I find it hard to explain to a junior team member the reason behind this implementation where the compiler would not consider a for-loop variable as a local variable to its scope when it comes to anonymous methods. In case you're wondering, this is the reason why we need to redeclare 'var s' in the following example:

foreach (var s in Names)
{
    var temp = s; // redeclaration

    criteria = criteria.Or(x => x.Name == temp);
}

The above example is very obvious, no doubt. But, throw in some code refactoring (out to a separate method and merging inline again etc.) and more complex lambda expression, you'll find that it is quite easy to forget that 'temp' variable. A bad language is one that requires you to 'tip toe around a field of land mine' when you're using it - which defeats the whole selling point of C# (or at least what Eric Gunnerson was selling when he first introduced C# to the world).

Like I said, there's really no reason why the compiler shouldn't consider 'var s' as the local variable of the foreach block - there's no way you could access variable 's' outside of it anyway. In this case, variable 's' isn't local enough to be captured by the lambda expression, but isn't any more global than that either!

My suggestion to Microsoft is to have the compiler automatically insert the redeclaration (as a quick and simple fix). I really can't think of a genuine use-case where one would actually desire the behavior without the redeclaration. In fact, if that is truly what is intended, then wouldn't this make more sense and a LOT more readable (read: maintainable)?

var s = Names[Names.Length-1];

for (int i=0; i<Names.Length; i++)
{
    criteria = criteria.Or(x => x.Name == s);
}

rather than,

foreach (var s in Names)
{
    criteria = criteria.Or(x => x.Name == s);
}

Rad Studio IDE Changes System Wide Timer Resolution

2010-01-26T19:07:00.005+11:00

This one had me scratching my head for a long time. Apparently, the CodeGear / Embarcadero RAD Studio IDEs (I've tested 2007 and 2010) exhibit this behavior - it calls timeBeginPeriod to change system wide timer resolution to 1ms when it starts and timeEndPeriod when it quits.

What's the problem then?

For starters, this means that simple code such as:

while (!Terminated)
{
    if (Poll())
        DoSomething();

    Sleep(1);
}

will behave very differently with and without the IDE running. You may end up polling a lot slower than you expected when you deploy your applications and may cause DoSomething() to not get called in-time. The evil is in the fact that when you are developing the application, DoSomething() always gets called as you would have expected. But when you deploy your application (or hands it over to the testers for testing), you'd soon realize something is amiss. Everyone knows Windows is not a real-time OS, so no one would expect Sleep(1) to actually sleep for 1ms. But while developing the application, you had found that it is actually quite close.

Well, surprise, surprise! Without the IDE running, Sleep(1) would actually wait for 15.625ms by default - that's more than 15 times slower than what you were expecting.

The Sleep Function documentation from MSDN really doesn't do a good job at explaining the Sleep function. In DOS, I would've expected the system ticks to be at a default of 15.7ms. But I had expected Windows starting from Windows 95 to have a default system tick of 1ms. I was wrong (well, not really, see my comment #1).

Regardless, this is a serious problem with all of RAD Studio's IDEs. I am sure hardly anyone knows about this and at one point or another, you would've been bitten by this, even if you didn't know it - except that your application failed on the day of demo at your client's site. Just your luck again.

Microsoft's Visual Studio IDEs (tested 6, 2005, 2008) don't do this.

Also, it's never a good idea to change the system tick resolution - from MSDN, "(The timeBeginPeriod) function affects a global Windows setting. Windows uses the lowest value (that is, highest resolution) requested by any process. Setting a higher resolution can improve the accuracy of time-out intervals in wait functions. However, it can also reduce overall system performance, because the thread scheduler switches tasks more often. High resolutions can also prevent the CPU power management system from entering power-saving modes. Setting a higher resolution does not improve the accuracy of the high-resolution performance counter."

Perhaps the OS should have simply fixed it at 1ms. To allow processes to change system timer resolution that affects global system settings does not make much sense in a multitasking environment.

Component / Control with TPropertyEditor in DesignEditors

2010-01-20T18:18:00.004+11:00

If you include <designeditor.hpp> and try to use TPropertyEditor in C++ Builder, you'll run into BCC32 errors complaining about multiple declaration for 'IPropertyDescription' and ambiguity between 'IPropertyDescription' and 'Designintf::IPropertyDescription'. This is true for every version post-BCB6, including the latest CB2010.

The namespace ambiguity problem is an inherent problem with C++ Builder because every HPP file that is generated from Delphi includes the namespace in the header file. We all know that's *BAD* now, but it's a decision that dates back to the first version where even the std namespace was implicit included. Now that we've found ourselves too deep in the rabbit hole, there's really no easy way out as far as backward compatibility is concerned.

But, for this particular problem, there's a solution.

Before you include DesignEditors.hpp, you should first include PropSys.hpp, such as,

#include <propsys.hpp>
#include <designeditors.hpp>

class PACKAGE TMyComponentEditor: public TPropertyEditor
{
// ...
};

Perhaps the better way would be for DesignEditors.hpp to include PropSys.hpp at the very top of the file, so anyone who uses DesignEditors.hpp doesn't need to remember including PropSys.hpp explicitly. That one's for Embarcadero to decide.

Upgrading VCL Apps to C++ Builder 2010

2010-01-20T18:14:00.002+11:00

If you run into the following error, here's what you need to do.

[ILINK32 Error] Error: Unresolved external 'wWinMain' referenced from C:\PROGRAM FILES\EMBARCADERO\RAD STUDIO\7.0\LIB\C0W32W.OBJ

Open your main cpp file and look for this line,

WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)

Change it to,

WINAPI wWinMain(HINSTANCE, HINSTANCE, LPWSTR, int)

This is to do with the Unicode support in the new IDE (starting from CB2009).

IDE Regex Replace: char to wchar_t string literals

2010-01-20T18:08:00.001+11:00

While upgrading your apps to use wchar_t* instead of char* string literals, you'll find that you need to change a string such as "This is a string" to _T("This is a string"), as well as character literals such as 'c' to _T('c').

Well the good news is there's a quick way of doing this.

The C++ Builder IDE has always have a Regex (Regular Expression) based search and replace function. All you have to do is enable it in the Replace Text dialog, under Options | Regular expressions.

These are the corresponding Regex you'll need.

For string literals,

Text to find: "{(\\"|[^"])*}" (include the double quotes)
Replace with: _T("\0")

For char literals,

Text to find: \'{\\[^']|[^']}\'
Replace with: _T('\0')

* Note: Do not blindly replace all. You may end up replacing the text inside a string, such as "I can see 'u' from here". If anyone has any suggestions on how to correct this, I'd appreciate it (note that the IDE regex replacer does not support backreference). You may end up replacing strings that aren't string literals, such as #include "myfile.h".

The reason you'd want to use the _T(x) macro is because it's faster when you do an assignment to UnicodeString (which is typedef'd to String). The _T(x) macro maps to L##x - i.e. _T("text") == L"text". The String and _T(x) macro pair is compatible going from a compiler that supports Unicode to one that doesn't as String will map to UnicodeString in the former and AnsiString in the latter, which is the same for the _T(x) macro mapping to L (L"string") and nothing ("string") respectively.

String fromAnsi = "text";
_UStrFromPChar, which ends up calling MultiByteToWideChar. It is a Windows API that converts Ansi strings to Unicode strings, and as fast as it may be, it's bound to be slower than a straight memory copy.

String fromUnicode = L"text";
All else being equal (allocate memory and finding string length), this is much faster as it's basically just a straight memory copy.

FastMM - Slow in multithreaded apps on multicore CPUs

2010-01-15T17:58:00.019+11:00

There's something wrong with FastMM4's (i.e. the default memory manager of Delphi / C++ Builder starting BDS2006) usability on multicore systems, especially running multithreaded apps in a GC/managed environment. The result of this is that when multicore is enabled, performance suffers by up to 5 folds. So, not only that FastMM would not scale, your multithreaded apps will run tremendously slower on a multicore system - up to 5 times slower on a dual-core machine vs a single-core one at the same clock speed of the same architecture.

That's 500% performance drop going from single-core to dual-core! Comparing the dual-core performance of FastMM4 and TBBMM, the latter is 9 times faster!

This test is meant to show just that. Download Test (updated 27/01/2010) (see readme.txt for instructions) *** WARNING: Incompatible with x64 OS due to an OS bug.

It runs through a variety of algorithms in multiple threads (in a threadpool of the framework, similar to .NET's ThreadPool) consisting of a mix of GC list, GC dictionary, and GC string unit-tests.

Keep in mind that this is an app written using a GC framework, which means allocations usually happen in multiple threads concurrently while de-allocations are done in specialized garbage collector threads. This may be the reason FastMM breaks down (a general-purpose memory manager shouldn't break down given any usage patterns).

Notice that when you run the FastMM Test with CPU Affinity set to just one CPU, you'll end up with nearly the same performance as TBBMM. Once you enable multicores though, you'd immediately lose performance once again, running slower than with just one core.

Note: You'll find that the FastMM BorlndMM.dll is different from the default Rad Studio 2010 one. This is due to the changes added to support the GC framework, but at its heart, it's simply making calls to GetMemory, ReallocMemory and FreeMemory (as oppose to WinMM's version of HeapAlloc, HeapRealloc and HeapFree respectively, with all else
being equal). The WinMM version is initialized with the LFH (low fragmentation heap) flag.

Here are some results from my own tests:

Test results in ops/second (10sec average), listed in the following order:
1) TBBMM (what is TBBMM?)
2) WinMM
3) FastMM

Core2Duo E6550 2.33GHz (Conroe) - XP SP3
Both cores enabled
1) 1785
2) 1230
3) 250

Single core (via CPU affinity mask)
1) 930
2) 650
3) 950

Core2Duo E6550 throttled to 1.33GHz - XP SP3
Both cores enabled
1) 730
2) 520
3) 180

Single core (via CPU affinity mask)
1) 410
2) 275
3) 395

Pentium M 1.2GHz (Banias) - XP SP3
CPU is Single core
1) 395
2) 340
3) 395

Core2Duo E7200 3.6GHz (Wolfdale) - Vista
Both cores enabled
1) 2595
2) 2080
3) 290

Single core (via CPU affinity mask)
1) 1450
2) 1180
3) 1405

As you can see, the results are quite consistent. On a dual core machine, the performance of FastMM is terrible. From 2.33GHz to 3.6GHz, there's virtually no increase at all in speed! In fact, when the test was running, the CPU wasn't even fully utilized (with more than 50% of CPU spent in kernel time), whereas the other memory managers had the CPU pegged at 100% and nearly no kernel time.

If you wish to try it out on your system, download this GC speed tester (updated 27/01/2010) and unzip it to a folder of your choice. Then, run "Run All Tests.bat" and follow the on-screen instructions. Note that the GC Speed Test app will run indefinitely, so once you take note of the speed (ops/sec), you can quit the app to move on to the next test.

I'd appreciate it if you could post your results here in the comments in the same format as the ones above - i.e. CPU make (I'd love to see how AMD CPUs fare) and model number as well as the frequency, OS / service pack, and the results.

My advice? For an all-rounded memory manager, use the Windows default one. It may be a little slower than FastMM on a single core, but it certainly scales very well on multicore systems. Alternatively, the Intel TBB allocator has a near perfect scaling and is the fastest memory managers around. Only thing is, it consumes more RAM.

Regardless, I'd stay away from FastMM4 (thus the default memory manager of Delphi / C++ Builder).

C++ Builder 2010 Optimizing C++ Compiler

2010-01-14T18:22:00.007+11:00

I'm pleasantly surprised after giving C++ Builder 2010 a quick spin. It's much better at optimizing code than its predecessor CB2007 (I skipped CB2009 altogether as it was and still is completely broken).

CB2010 vs CB2007:

AnsiString test:
6938ms vs 6765ms

GcString test:
420ms vs 1734ms
(yes, that's 420ms, it's not a typo)

In the AnsiString test, things got just a bit slower (about 2% - nothing to worry about). But the big surprise here is my GcString test, which is over 400% FASTER!

Code for the test above (executed on Core2Duo 2.33GHz with TBBMM):

void __fastcall RunTest()
{
   const int TEST_COUNT = 10;
   const int TEST_SIZE = 10000;
   const int LOOP_COUNT = 1000;

   {
       // RefCounted String Test
        AnsiString strings[TEST_SIZE];
       for (int i=0; i<TEST_SIZE; i++)
       {
           strings[i] = "test";
       }

       DWORD start = GetTickCount();
       for (int x=0; x<LOOP_COUNT; x++)
       {
           AnsiString temp;
           for (int j=0; j<TEST_COUNT; j++)
           for (int i=0; i<TEST_SIZE/2; i++)
           {
               temp = strings[i];
               strings[i] = strings[TEST_SIZE-1-i];
               strings[TEST_SIZE-1-i] = temp;
           }
       }
       ShowMessage(IntToStr((int)GetTickCount() - (int)start));
   }

   {
       // GcString Test
        GcString strings[TEST_SIZE];
       for (int i=0; i<TEST_SIZE; i++)
       {
           strings[i] = "test";
       }

       DWORD start = GetTickCount();
       for (int x=0; x<LOOP_COUNT; x++)
       {
           GcString temp;
           for (int j=0; j<TEST_COUNT; j++)
           for (int i=0; i<TEST_SIZE/2; i++)
           {
               temp = strings[i];
               strings[i] = strings[TEST_SIZE-1-i];
               strings[TEST_SIZE-1-i] = temp;
           }
       }
       ShowMessage(IntToStr((int)GetTickCount() - (int)start));
   }
}

As you may have noticed, it is simply an array reversal test. And yes, the GcString version was 4 times faster even in CB2007. In CB2010, GcString is now a staggering 16.5 times faster than AnsiString!

Internal Compiler Error (ICE) in BCC32 of C++ Builder 2010

2010-01-14T18:18:00.001+11:00

An excellent write-up of ‘What is an Internal Compiler Error?’ by David Dean (an Embarcadero C++ QA Engineer) is a must-read if you do not know what an ICE is, apart from it giving you error message such as this, “[BCC32 Fatal Error] FileA.cpp(56): F1004 Internal compiler error at 0x59650a1 with base 0x5900000”.

CB2010 seems to be more prone to encountering ICE, for reasons which are beyond my understanding. However, with a lot of struggle and time spent to get my projects compiled, I’ve found a few settings that are vital to avoid ICE.

The first thing I’d do is disable smart cached precompiled headers (command line: -Hs-). I’ve found that this option, combined with Debugging | Expand inline functions and/or Optimizations | Expand common intrinsic functions (implicit via Generate fastest possible code) is the root of all evil. Disabling the former will allow the latter two to be enabled, thus taking advantage of the new optimization featured in BCC32 v6.21 of CB2010. In fact, I’ve made all my projects default to this configuration. If you still get ICE, then start disabling the other two as well. Even if you get it to compile after disabling either or both of them, you’d still want to submit a QC entry (a bug report). To do this, follow the instructions in the above link (David Dean’s page about ICE).

ATI DXVA with Arcsoft - Still Behind nVidia with Anything

2010-01-07T23:39:00.003+11:00

Happy New Year 2010 to all my readers!

First post of the year. And it's bad news for ATI, yet again.

*note: this post is a follow-up to my post here.

With the recent changes (additions) to the popular open-sourced H.264 encoder, x264, encoding at ref 16 with b-pyramid normal and weighted-p 2 (which is default), playback on ATI cards with the Arcsoft decoder will exhibit bad artifacts, as if using MPC-HC's internal DXVA decoder on ref 16 encodes. Meanwhile, it's all well and dandy over at the green camp. nVidia owners will find that their cards can decode these streams without even the slightest artifact, and with just about any DXVA decoders you could get your hands on - even the Win7 Microsoft DTV-DVD. If you intend to encode with b-pyramid normal + weighted-p 2, you should reduce the ref to 12 (haven't tried anything in between) to ensure artifact-free DXVA playback with ATI+Arcsoft.

So there you go, even with the best combo, ATI still looses out to nVidia. So again, my advice is, sell your ATI cards and stick to nVidia.

Let's see if this is the year ATI catches up (My bet is on NO. Perhaps never. Frankly, ATI doesn't care about the HTPC scene).

A Precise Garbage Collector for C++ Builder

2009-12-04T17:44:00.007+11:00

Ahh... Nothing rivals the feeling of success!

I've finally devised a precise garbage collector (note: a precise GC is very different from conventional GCs such as BoehmGC - a precise GC does not suffer from ambiguities) for C++ Builder that is faster than boost's shared_ptr.

That's a bold claim indeed! And, by claiming that it is faster than shared_ptr, I'm also claiming that I can create a String class that is similarly faster than Delphi string, which is also reference counted like shared_ptr. And yes, the gc_ptr is thread-safe too.

The trick is in the pointer assignment. In my precise GC, a pointer assign is no more expensive than its native equivalent - both are a single instruction operation, whereas a ref counted pointer requires a locked instruction and a refcount check, both of which are *very* expensive on any processors, especially modern multicore ones. Most precise GC source codes you can freely download from the net get the assignment operator correct. However, the part where they lose out big time is in the gc_ptr's constructor and destructor with lock instructions and what not for multithread support (note that some don't even support multithread). These are often non-trivial and is the biggest cause of performance bottleneck.

With a minimal c'tor and d'tor for my gc_ptr, I end up with an insanely fast precise GC engine which runs a .NET like framework in pure native mode. How about that - a managed framework that runs natively. None of the pain (both literally and performance-wise) of pinning objects and marshaling data going in and out of the managed world (anything that interfaces with the real world cannot have a non-fixed address - e.g. it's impossible to write a driver that allocates a .NET managed non-fixed buffer and let your system's DMA fill it up). Looks like .NET's GC team is paying the price of betting on the Stop-And-Copy algo (yes, the .NET GC is nothing more than an advanced version of the Stop-And-Copy GC) - Update: *Correction, I was wrong. The CLR GC is very similar to what I have implemented - in fact, even more so now that I have finished the generational version of the GC. Only notable thing is that my GC does not compact the heap after the sweep phase and does not support weak references or resurrection. Also, it relies on an external memory allocator.

Update 1: GcString is 16.5 times faster than AnsiString in an array reversal test in CB2010 - more info here.

Update 2: FastMM (Rad Studio's default memory manager) is excruciatingly slow in a GC / managed app in multicore systems - more info here.

LANBench - Network Benchmark

2009-11-10T17:28:00.004+11:00

Folks,

I've just released the first version of LANBench here - http://www.zachsaw.com/?pg=lanbench_tcp_network_benchmark

Created it very quickly recently to find the maximum bandwidth of my gigabit switch / NICs in my LAN. LANBench mainly tests your network bandwith, but also to a certain extent gives you an idea of how much CPU is being spent in just transferring data back and forth between your machines.

LANBench takes the HDD subsystem out of the equation and lets you test the raw speed of your network.

Head over and check it out for more info.

DynamicArray causing memory leak in C++ Builder

2009-10-16T16:16:00.003+11:00

Recently I came across a memory leak which CodeGuard reported was due to DynamicArray.set_length(...).

Well, DynamicArrays are referenced counted, exactly the same way as AnsiStrings / UnicodeStrings so really there's no way you could've missed free-ing it... ... or is there?

From experience, the first thing that came to mind was that since it's a referenced-counted container - and as with the rest, it's prone to circular-references.

Consider the following code:

#include <vcl.h>
#pragma hdrstop

#include <iostream.h>


struct TCircularRef
{
    DynamicArray<TCircularRef> refs;

    ~TCircularRef() { cout << "here" << endl; }
};

#pragma argsused
int main(int argc, char* argv[])
{
    DynamicArray<TCircularRef> base;
    base.set_length(1);

    base[0].refs = base;
    base.set_length(0);

    return 0;
}

With the 'refs' member of DynamicArray<TCircularRef> base referring back to itself (base[0].refs = base), we ended up with a circular-ref. Yes, the cirular-ref in the above example is easy to spot and would probably never occur in the real world as well. In reality though, the circular-refs are much harder to spot and assignments change during run-time, depending on the code branch and/or timing. What's worse is that the reference could be held by an object of which you pass to another library written by someone else...

Notice that the above sample code tries to break the circular-ref such that it would get cleaned-up with the line base.set_length(0)? Alas, that was to no avail as its ref-count prior to set_length would be 2, which leaves us with a ref-count of 1 after that. Can we call set_length(0) again then? No. Why? Because 'base' no longer knows about the object it once held as the first set_length(0) would've set it to point to the new memory location allocated by set_length(0).

Is there a way out? There're a few. But none to my liking. (You could Google for 'circular-reference' if you're interested to find a solution to this but it's not the intention of this article).
As I have a garbage collector library ready to be used in any projects I create with C++ Builder, that was the solution I took. I simply replaced all DynamicArray with gc_array and allocated it with gcnew_array. With that, I no longer had to care about the hairy problem of who owns the object, who's responsible to free it and whether there's a potential circular reference problem in my code. What's more, it's thread-safe, unlike DynamicArray. But that's a topic for another day.

In short, this is my advice: Avoid DynamicArray at all costs!

Stepping into a Delphi package while debugging in C++ Builder

2009-10-14T13:59:00.007+11:00

Well, you really should debug a Delphi package in Delphi. But once every so often, you'll find yourself using the Delphi package (controls / components) in C++ Builder and in need of tracing into the package while you're debugging your main application. By default, even if you compile the Delphi package in Debug mode, you won't be able to step into the Delphi source codes. These are the settings which will enable that (this guide is for CB2007 but it shouldn't be too different for other versions of C++ Builder):

Go to the project options of the Delphi package.

Select the Compiler view on the left pane.

Set the build config to Debug mode.

Code generation:
Optimization = off
Stack frames = on
Debugging:
Debug information = on
Local symbols = on
Assertions = on
Use debug DCUs = on
Now select the Linker view on the left pane.

Map file:
Off
EXE and DLL options:
Include TD32 debug info = on
Include remote debug symbols = on
Linker output:
Generate all C++Builder files (you should already have this selected)

You're done with the settings.

Rebuild your package and your main app and you should now be able to step into the Delphi source.

Watching HD Video in MPC-HC DXVA for ATI HD 4000 Series Card Owners

2009-08-18T17:22:00.007+10:00

It's widely known that ATI card owners do not have the luxury of Nvidia card owners when it comes to playing HD video in MPC-HC in DXVA mode. With the built-in H.264/AVC video decoder, HD video such as 1920x800 with reference frames of 6 and above (i.e. L5.0 / L5.1 AVC streams) won't play (actually, it usually plays but with corrupted blocks and/or video freezing after a few seconds).

What I've gathered from the comments of the readers of my original post about this issue and from months of testing using a plethora of mixing and matching on my own HTPC, I thought it'll save everyone some time for me to post a summary of what settings worked with Media Player Classic - Home Cinema. I previously said it's necessary to use PowerDVD 9 for DXVA with ATI HD 4000 series (such as my ATI HD 4350) but that is no longer true and that a better combination has been found thanks to those who contributed in my previous blog post. This is only for ATI card owners with UVD 2 (or newer) though. HD3000 series owners, you guys are out of luck unfortunately (you have AMD / ATI to thank).

Here are some settings I've tested and their results:

Common settings:
Pentium 4 HT 3.0GHz (underclocked to 2.0GHz, DDR2@222MHz (444MHz effective), HT disabled)
ATI HD 4350 (Asus) - 512MB RAM @ 400MHz DDR2 (800MHz effective)
Windows XP SP3 (latest Windows Update as of 18 August 2009)
ATI Catalyst 9.7
Media Player Classic - Home Cinema Build 1237 x86 (download here)
Haali Media Splitter externally installed (i.e. not using MPC-HC's one)
DirectVobSub

Here's what I've found.

So long as you have the DXVA decoder output pin directly connected to the renderer, you'll get proper working DXVA decode with up to 16 ref-frames for full HD streams (1920x1080) regardless of the renderer (well, almost):

VMR7 (Windowed) = OK
VMR9 (Windowed) = failed (pink vertical stripes with Motion Vectors)
VMR7 Renderless = OK
VMR9 Renderless = OK

For the sake of discussion, let's use the VMR7 (Windowed) renderer. It has been proven to work with both Cyberlink's PDVD8 AVC decoder and ArcSoft's Video Decoder. With MPC's DXVA decoder, video with ref-frames of 12 and above will freeze after a few seconds of playback. Cyberlink's decoder suffers from occassional judder while ArcSoft's Video Decoder plays up to 16
ref-frames in DXVA mode perfectly. The results vary when other renderers are used. For example, the combo of VMR9 Renderless + MPC's DXVA decoder yielded the same pink vertical stripes.

I still have not found a combination that would get subtitles working without causing issues with DXVA decode. Under VMR9 Renderless + ArcSoft + MPC-HC internal subtitles renderer, the video would playback in like half the speed! Frames are decoded and rendered correctly though. If anyone has any idea how to solve that, I'd be all ears!

Update: With ATI Catalyst 9.8, the combo of "VMR9 Renderless + ArcSoft + MPC-HC internal subtitles renderer" now works properly. Although with DirectVobSub, the half-frame-rate playback issue is still there.

Update 2: It appears that, in order to get the results I've published here, you'll need to 'initialize' the ATI driver for proper operation of DirectX by opening the Catalyst Control Center each time you start / restart your PC (not sure about stand-by / hibernate). I was taken by surprise yesterday for not doing so - I got a blank white screen instead of the normal proper video playback. Once I opened the CCC (and closed it), reopening MPC-HC and the video then worked fine. *Bravo ATI!* You've got my standing ovation.

Anyway, this is the settings that I've found to work under MPC-HC without subtitles:

MPC-HC settings:
Renderer - VMR7 (Windowed)
Auto load subtitles - false (see Update above)
DirectVobSub options - disable autoload subtitles
Use ArcSoft Video Decoder as your AVC/H.264 decoder
Use AC3Filter directshow decoder

Again, make sure your DXVA decoder's output pin is connected directly to the renderer's input pin. This means under your DirectVobSub filter options, make sure it never loads subtitles and that it is blocked under your MPC-HC external filters page. The following is what I've configured under that page:

Arcsoft video decoder - preferred.
AC3Filter - preferred.
DirectVobSub - blocked.

NTFS A Journaling File System

2009-06-10T18:24:00.004+10:00

If NTFS is a journaling file system (if you don't know what it is, I suggest you read it up first before continuing) then why do we have to perform such an extensive chkdsk (checkdisk or scandisk) every time the system does not shutdown cleanly (due to a power or system failure)?

A journaling file system should always have their file system in a consistent state. For example, the MFT (Master File Table) should never indicate a cluster as being occupied while it in fact isn't. But so often when we don't cleanly shut Windows (2k or XP for that matter) down, the checkdisk that runs when Windows boots up again will find the exact inconsistency as described above.

Q: So is NTFS a journaling file system?
A: Yes.

Q: Then why is NTFS inconsistent?
A: NTFS is ONLY inconsistent (or unsafe) when an unclean shutdown occurs if you are running Windows 2K or XP. Microsoft for some reason (most likely performance related) chose not to enable the journaling function for non-server version of Windows. Windows Vista, however, enables it by default (I'm assuming Windows 7 does as well).

Q: Should I enable NTFS journals then?
A: It's up to you really, but personally I have a higher preference for the safety of my data, and I can't tell the speed difference between having it enabled / disabled on my hard drives, so it's a definite Yes for me.

Q: How do I enable NTFS journals?
A: Go to command prompt and run the following command for each NTFS partition:

fsutil usn createjournal m=1000 a=100 C:

Q: How do I check if my NTFS partition has journals enabled?
A: Run the following command:

fsutil usn queryjournal C:

Q: Does that mean I don't have to run chkdsk any more?
A: Not really. Just that you don't have to do it every time you fail to shutdown your computer properly. You should still do it occasionally (like defrag).

Q: How do I disable chkdsk on start-up?
A: http://www.raymond.cc/blog/archives/2008/02/23/disable-or-stop-auto-chkdsk-during-windows-startup/

Catalyst 9.6 ATI 4000 HD Series Still Behind NVIDIA For HTPC

2009-06-10T18:07:00.004+10:00

ATI is still behind NVIDIA for HTPC even with the latest leaked Catalyst 9.6 - It still fails to decode L5.0 / L5.1 high profile AVC video in DXVA mode (using MPC-HC for example). This means that for HTPC, a NVidia 8600GT / 9400GT would be the better choice over ATI HD 4800 / 4700 / 4600 / 4500 / 4300 series.

If you're looking to build a HTPC, go for NVIDIA.

While ATI heavily promotes its HTPC capabilities, the truth is it is still very far behind NVIDIA.

NVIDIAusers have been enjoying this for about 6 months.

@NVIDIA marketing, you could consider starting a "The way it's meant to be watched" program. Doesn't look like ATI has anything left in them to pose a threat whatsoever.

ATI HD Hardware Accelerated DXVA for H.264 AVC L5.0 / L5.1

2009-06-02T14:40:00.019+10:00

HOW TO: Get hardware accelerated DXVA playback of HD AVC High Profile L5.0 / L5.1 MKV / MP4 Files on ATI HD Series.

Well, technically speaking, not DXVA, but hardware accelerated playback of L5.0 / L5.1 files nevertheless. (update: it *is* DXVA - not sure just yet why some decoders work and some don't - possibly because some decoders send more compliant bitstream?)

I've recently built a HTPC from an old Pentium 4 HT. I know it has not enough grunt to decode AVC High Profile video, so I bought an ATI 4350 HD in the hope that it'll do all video decoding on its GPU (or UVD).

To my disappointment, I found this (ATI does not support AVC with High Profile above L4.1) after I bought the card. All my encodes are done with L5.1 as my other PC is a Core 2 Duo which has an NVidia 9600GT. For some reason, the NVidia driver is able to support DXVA for AVC High Profile L5.1, so I simply assumed ATI would be the same. Turns out that the maximum the ATI would do is L4.1 (There's a Quantum of Solace trailer encoded at L5 to test here - http://nunnally.ahmygoddess.net/watching-h264-videos-using-dxva/).

Regardless of which decoder I use, my P4 HT simply isn't powerful enough to playback these files (CPU hits 100% all the time and frames drop very frequently).

Luckily for us ATI owners, there is a solution. With PowerDVD9 and Catalyst 9.5, I finally found a combination that would get 1920x1080 HD videos with ref-frames > 4 to play without taxing my CPU. In fact, I was pleasantly surprised when I reran the Quantum of Solace test video -- my CPU remained at 2% utilization!

I recommend the following setup for ATI users:

PowerDVD 9 build 1530 ==> Must be this build! Other builds will not work
ATI Catalyst 9.5 (non-hotfix version)
AC3Filter
Haali Media Splitter (to playback MKV files) ==> version 1.9.42.1 (or later)

*** New:

If you prefer to use Media Player Classic - Home Cinema (MPC-HC), see this.

*** Note1:

Rename .MKV to .MP4 to get PowerDVD to playback MKV files.

*** Note2:

Important - No other filters (e.g. FFDShow / CoreAVC / Codec Packs) should be installed in your system!

Try it out yourself (you could download the trial version of PowerDVD 9).

MAKE SURE you DO NOT have any other filters installed (for example, CoreAVC or FFDShow which may have a higher merit than PowerDVD's own filter) or PowerDVD will not use its internal H264 decoder. Also, when opening MKV files, PowerDVD will complain that xvidcore.dll could not be found, but will continue playing the video just fine. If you want to suppress the error message, simply download xvidcore.dll and put it in the same folder as the PowerDVD executable (e.g. c:\Program Files\CyberLink\PowerDVD\).

Leave a comment to let me know if it does / doesn't work for you with your card's configuration and OS, for example:

HD 4350 PCIe x16 512MB
WinXP SP3

*** Update 1:

This clip (the 'Bird Scene' from Planet Earth) is the ultimate L5.1 super high bitrate MKV sample. On my nVidia 9600GT setup with a E7200 CPU @ 3.6GHz, it uses 50% of the CPU (playback using MPC - Home Cinema with driver supporting L5.1 bitstream DXVA). On my Pentium 4 HT (single core CPU) and the HD 4350 setup, I get 25% CPU usage. That is simply mind-boggling! What can we conclude? ATI is A LOT better at decoding H264 streams?

*** Update 2:

I've found that PowerDVD has a problem with H264 encoded files that have been tagged with the wrong IDC. For example, if the file actually contains a high profile L5.1 bitstream but its IDC tag is marked incorrectly (e.g. L4.1), you will get stuttering problems. If that happens, you'll have to change the file's IDC tag back to L5.1 using IDC Multi Changer.

*** Update 3:

While testing my configuration with a ref-frame 12 encode at 1920x800, I found that certain scenes (usually panning slowly) would judder (i.e. a couple of frames get dropped) and they always happen at the exact same time code. I tried remuxing the .mkv file to .ts / .m2ts but to no avail. I also increased the input buffer size to 100000KB from 8192KB in the Haali Media Splitter settings, which also did not help. Having spent a few hours on it, I finally decided to look at PowerDVD's settings itself. Apparently, under Advanced Video Preferences (Right-click Main Screen, click on Configuration, select the Video tab, click Advanced...), there's a group box called Video Quality. I had Normal Mode selected from before when I was using PowerDVD without AVIVO. Setting it to Best Mode solves the problem. GPU and CPU usages remain unchanged at 6-8% and ~12% (DTS is being decoded in software) respectively.

I can only make an educated guess on the reason behind the judder. Video Quality relates to the post processing / de-interlacing / pulldown settings. The judder which I picked up on slow panning scenes are probably due to the lack of pulldown under Normal Mode. When set to Best Mode, pulldown (what is this?) is activated to match the 24fps source to my 1080i LCD panel (1920x1080 at 30Hz).

*** Update 4:

A full update on this topic has been posted here.

Cracking Signed ActiveX Controls

2009-03-25T18:35:00.007+11:00

Ever come across an ActiveX control you can't afford to buy but wish to use for your own little pet project? Especially those readily available for download, but annoys the hell out of you when you try to use it as it keeps painting "Evaluation Version" all over itself?

Well, from time to time, I develop pet projects to keep myself entertained. Being a perfectionist, I just can't stand to see the "Eval Version" message appearing on my applications. Yes, the sole purpose of these apps are just so I could marvel at myself when I finish them, but how would I be able to do that if I leave the "Eval Version" message lying around? I want that newly polished, super shiny feeling you get when you finish something you can be proud of.

So I set out with a mission - to crack the ActiveX control that is sprinkling all those "Eval Version" on itself.

Surprisingly, cracking the several ActiveX controls I've used isn't all that hard - so long as you know a little x86 ASM and have the right tools (such as the W32Dasm for Windows). Most ActiveX controls are smart enough to prevent simple cracks such as looking up the "Eval Version" message and skipping them via a jmp, but in order to draw the text on the screen, the message would still have to be decrypted somehow and placed in the memory. And, THAT is usually the weakest link. What I usually do is, I'd change the opcodes directly in the memory while I step through the ASM in an IDE (I use CodeGear RAD Studio 2007) so I could see the effects immediately. If things go wrong, I'd simply break out of the debug session and restart.

Once you have cracked it, use a hex editor to change the bytes you've changed in the IDE - you'll have to note down a few instructions before and after the ones you're about to change when you were debugging in the IDE, as there may be more than one occurrence of the bytes you search for. For example, there could be numerous occurrences of "33C9" hex, which translates to "xor ecx,ecx".

For normal exe / dll files, patching the file and then doing a final test would've been the end of it. With a signed ActiveX file, however, you'd find that if you try to use the ActiveX in your IDE, it'll complain that the ActiveX cannot be loaded. That simply means that the hash (usually SHA1) in the ActiveX no longer matches the file - and rightly so! This is easily circumvented though - all you need to do is re-sign the file, and then re-import that into your IDE.

Lucky for us, there's no need to un-sign the ActiveX file before re-signing it with our own cert. Here's a link with step-by-step guide for signing an ActiveX file - http://www.pantaray.com/signcode.html

In the next installment, I'd probably blog about cracking signed .NET assemblies, if responses are good for this one.

WinAPI functions and GetLastError / WSAGetLastError

2009-03-18T10:49:00.001+11:00

Having been using WinAPI for more than a decade, I was surprised with myself for not being more careful with the return value and GetLastError's error code following a WinAPI call. Granted the bug I was facing was not easy to root cause, but that was no excuse as I should've been more careful when coding. We all make mistakes but the difference between a good and bad programmer is that the former is constantly alert of the pitfalls when coding (read: edging toward paranoia) while the latter simply hacks away hoping things will work out fine.

The thing to keep in mind is WinAPI functions don't set Last Error Code unless the function's return value is FALSE (zero) even if GetLastError sometimes returns ERROR_SUCCESS (e.g. TlsGetValue) - it does NOT mean that WinAPI functions will set Last Error Code to ERROR_SUCCESS regardless. If you've made the assumption that all WinAPI function calls will reset Last Error Code to ERROR_SUCCESS (or NO_ERROR) following a call, then chances are your code will work fine so long as the function has not encountered an error, but will fail as soon as it does, because subsequent calls to the function will appear like an error if you rely on just GetLastError for the result. You should ALWAYS read the documentation of each function as their Return Value varies and remember that there will be one scenario where Last Error Code won't be set.

Avoid AMD at all costs (and Gigabyte too)

2009-02-22T18:25:00.003+11:00

This goes for everything - GPU / graphics cards, CPU, software, and even shares.

I recently got my first AMD graphics card and found it to be extremely bad in quality - both the hardware itself as well as the drivers.

My first card was from MSY (VIC Australia) - it was a Gigabyte 4350 (AMD / ATI card). Plug it in to my old machine which was sidelined recently due to an upgrade, but had been running ECS nVidia 9600, I found that the GDDR2 chips are defective. In fact, booting into Vista caused the graphics card to lock-up entirely. After some investigations, I discovered that there are a few frequencies that the card chooses depending on the state of the card - it boots up with a 200MHz GDDR2 RAM frequency (400MHz effective) and runs 3D (load) with a 500MHz (max default) frequency.

Keep in mind that this is the default frequencies (read: NON-OC'ed) from Gigabyte. Just to get a closure and confirm that it is in fact defective RAM as I had suspected, I flashed the video card BIOS with one that runs the RAM at a lower speed and found that it worked. The maximum speed I could get it to run at was 300MHz - a far cry from the advertised 500MHz (1000MHz effective)! Heck, 300MHz? My OLD machine is running 800MHz DDR2 (1600MHz effective). And to put that into perspective, my nVidia 9600GT works perfectly with an overclocked GDDR2 at 1200MHz (2400MHz effective)! Gigabyte and AMD - shame on you!

I'd also avoid Gigabyte at all costs. So far I've owned 5 Gigabyte motherboards - none of which I could go to the shop, purchase it, and plonk in a CPU and install OS. Gigabyte = troublesome. I'd have to return it and get it exchanged for a new one. It's not the 2nd board that'll work but the 3rd! Most won't even get past POST. Apparently, it's no different with a graphics card.

Back to the graphics card issue - this time the shop ran out of the graphics card - so I got to the 2nd, and that did not work either. Eventually we settled for a refund. I immediately drop by Centrecom and got myself an Asus 4350. Dropping it into my system and it immediately worked - 3DMark06 ran flawlessly (discounting the performance of course).

Then, I decided to watch some blu-ray contents and to my surprise, it stuttered like mad. Why? Because it's using my old CPU to decode in software - no UVD! Keep in mind this is with Media Player Classic - HC, which used to accelerate blu-ray with my nVidia 9600GT (which was running a BETA driver, as opposed to the AMD 4350 which was running the official Catalyst 9.1).

After spending days reinstalling Windows and drivers, I still had no luck. Eventually, I stumbled upon AMD's own forum while looking for solutions and found that people have been complaining about the same thing - Catalyst 9.1 broke all DXVA support in Windows XP! I immediately did a driver feedback via their website and told them the issue.

A month later, Catalyst 9.2 was released. Still broken!

I bought this card for the sole purpose of accelerating HD contents - if the card can't do it, then stop advertising it! At least in Australia, the law protects consumers in this regard - we can return it if we find that it does not do what it's advertised to. I'm sure in US consumers have no rights whatsoever and get lied to with false advertisements.

My advice, stick with Intel and nVidia. Heck, even Intel's G45 integrated gfx would've been a LOT better - yes there're some issues with 24Hz playback (1920x1080p 24Hz that is, and not all TVs support that) but for all other modes, it accelerates HD contents flawlessly, just as advertised.

But, with that said, I'd like people (read fanboys) to continue buying AMD just to keep Intel and nVidia in check (quality, performance and price). :-)

Performance Monitor / Counters not working in XP

2009-02-17T18:47:00.002+11:00

Strangely enough, the XP machine I use in the office has never had the performance counters working.

If you tried running SysInternal's pslist (I use it mostly so I could do pskill for the issue I blogged about here), you'll get a message saying, "Processor performance object not found on Run Exctrlst from the Windows Resource Kit to repair the performance counters."

Or, if you try running the Performance MMC snap-in (In XP it's under Control Panel --> Administrative Tools --> Performance), you'll get no response for a minute or two, and when the window appears, the red line in the graph will not move (and you won't be able to add any graphs for monitoring either).

Or, if you try to use performance counters in .NET (e.g. for CPU Usage monitoring), you'll get an exception complaining performance counters are not available.

What's the problem? To be honest, I don't know and I don't care enough to find out, but I do care enough to make it work.

Here's how:

Install Windows Support Tools which could be found on Microsoft's website (here's the XP SP2 version which will also run in SP3 - http://www.microsoft.com/downloads/details.aspx?FamilyID=49ae8576-9bb9-4126-9761-ba8011fabf38&displaylang=en)
Once you've installed it, run exctrlst.exe
Make sure that PerfProc and PerfOS have their Performance Counters enabled (select the entry and verify that the "Performance Counters Enabled" option is checked)
Once you've done that, close the window and run PsList again to see if it works
If not, continue reading. You'll need a copy of Windows installation CD for the following steps

PsList is still not working:

What we'll be doing is manually replace some of the files with the original ones (I'm guessing at some point, Microsoft released a hotfix which broke the files).

Go to the I386 folder on your Windows CD
Make a backup of C:\Windows\System32\perfc009.dat and C:\Windows\System32\perfh009.dat (we'll be overwriting them)
Expand perfc009.da_ to C:\Windows\System32\perfc009.dat (expand perfc009.da_ C:\Windows\System32\perfc009.dat)
Expand perfh009.da_ to C:\Windows\System32\perfh009.dat (expand perfh009.da_ C:\Windows\System32\perfh009.dat)

Try running PsList again - it should work now.

If all of the above failed, there's one other resource you could read up - How to manually rebuild Performance Counter Library values.

Windows hangs while debugging - How to regain Windows GUI responsiveness

2009-02-17T18:32:00.004+11:00

Following up on the issue I blogged about a while ago about Windows locking up while debugging multithreaded applications under CodeGear RAD Studio, someone from the CodeGear IDE forum suggested that Command Prompt would still work responsively. Some guessed that it could be due to Windows running out of GDI handles (how that is related to the debugger is beyond me, so if someone cares to explain, I'm all ears) and this proves to be quite correct.

Apparently, this problem has been confirmed on Microsoft Visual C++ 6 up to Visual Studio 2003 (have yet to heard anyone commenting about 2005 or 2008, so they could also be affected) and Borland C++ Builder 6 up to CodeGear C++ Builder 2009. So far I've gathered that this happens on both Windows Server 2003 and XP, regardless of the level of service pack installed.

In order to get your machine responsive again, you'd have to kill the debugger (which is BDS.exe / BCB.exe for CodeGear / Borland and MSDEV.exe / DevEnv.exe for Microsoft). The painful way is to bring up Windows Task Manager (Ctrl+Shift+ESC to save you a few minutes of right-clicking on the taskbar and waiting for the GUI to appear) and select the process to terminate. Going through that process will take you somewhere around 5 to 10 minutes. There's a simpler way though (courtesy of Ingo Zettl - thanks!), which requires less than 5 seconds if you have everything setup before starting your debug session:

Install SysInternals PsTools which could be found here http://technet.microsoft.com/en-us/sysinternals/bb896649.aspx
Start command prompt, go to the PsTools folder and leave the command window open
Start debugging
Once you hit the OS+debugger bug, Alt+TAB straight to the command window (beware: if you inadvertently Alt+TAB to the wrong window, you'll waste a few minutes waiting for Windows to respond)
Run PsList - you should get a list of processes running on your machine
Lookup the Pid (Process ID) of your debugger (e.g. BDS.exe)
Run PsKill e.g. - pskill -t [pid]

At this point, your machine should regain responsiveness.

We all have Microsoft to thank for this 'little' inconvenience which makes life 'fun' for us Win32 software developers.

Debugging multithreaded applications in CodeGear hangs Windows XP Kernel

2009-02-05T11:42:00.005+11:00

When debugging a multithreaded application in CodeGear under Windows XP, users have found that the debugger locks up the Windows kernel frequently (twice a day for me). When the Windows kernel locks up (actually slows to a crawl), if you hit CTRL+SHIFT+ESC to bring up the task manager, it will not come up until after a few minutes. While waiting, hit CTRL+SHIFT+ESC say 50 times. You'll get 50 task managers appearing after the first one pops up.

At this point, Windows XP kernel is still painfully slow - Task Manager shows no CPU usage, kernel's just 99.9% locked up. With that 0.1% responsiveness, you'll be able to slowly terminate bds.exe and again, wait ages for the confirmation window to pop up. Once bds.exe is terminated, your system will be fully responsive again. You'll be left with the above screen shot.

Good job CodeGear, for your ability to bring XP kernel to its knees...

* Update: Just upgraded to XP SP3 from SP2, and problem persists.

Turning C++ into C#

2009-01-23T18:27:00.002+11:00

Can you really turn C++ into C#?

The answer is yes to a certain extent, but you'll need certain C++ keyword extensions which are readily available in C++ compilers such as BCC (Borland / CodeGear C++ Compiler), namely indexed properties (VC++ does support properties via the __declspec(property) extension but does not support indexed ones).

What I've found really interesting is that it is quite possible to write templates and turn C++ objects into fully 'managed' - e.g. garbage collected, arrays are range checked and pointers are checked for null reference.

I've even went as far as to create templates for keywords such as C#'s 'using', 'foreach' and 'lock'. They behave exactly the same as their counterparts in C#, albeit with a little syntax difference for the 'using' and 'foreach' keyword.

The advantage of having a C# like C++ library will be greatly appreciated by programmers who love C# but would like their target application to run on non-dotnet platforms such as an embedded XP with limited RAM for cost reasons. Apart from that, applications based on this library will always outperform any C# applications since it's basically C++ with a garbage collector behind it. There are no managed / unmanaged switching penalty when pinvoking and the garbage collector is definitely more deterministic. I've made it such that it such that the code could temporarily disable the garbage collector. This makes real-time systems much more reliable than those using .NET.

With this library, it is a lot simpler to write high performance applications - glue logic could be written in C#Lib, and the core in pure C/C++ or ASM. With clear separation between managed and non-managed object within the same source code, the non managed part runs per usual, while the object itself could still be managed by C#Lib. The garbage collector also does not relocate objects - they rely on a low-fragmentation memory manager for memory allocations. The GC is a double edged sword in that it is faster and is also easier on the library user as calling into legacy code / APIs / code written in other languages for high performance as the objects always have a permanent address.

There are a few subtle things which C++ can't do but C# (or in a more generic term, .NET) can. For example, the multiple inheritance feature in C++ is rather limited. You can't explicitly override a method for a specific base class (even if it's implemented as an interface).

But the most important thing which C++ lacks is the garbage collector, which proved extremely useful in design patterns for the asynchronous (read multi/many core) future (actually, now). C#Lib bridges the gap and has proven to be extremely useful for me.

FastMM's Multicore Performance Scaling

2008-11-17T14:53:00.009+11:00

Having used .NET's asynchronous socket, filestream, WinForm's Invoke / BeginInvoke and fell in love with its design and knowing that it uses IOCP / threadpool WinAPI underneath the hood, I decided to write my own in C++, using C++ Builder. Everything went well until I started testing. I realised that my dual core machine doesn't seem to get full utilization when I'm running some of the most intensive tests, which easily causes the threadpool to spawn extra threads to serve the load.
I started investigating and eventually managed to reproduce the issue with just the following code:

void __fastcall TAnsiStringTesterThread::Execute()
{
     AnsiString str;
     for (int i=0; i<10000000; i++)
     {
          str = " something ";
     }
}

Delphi doesn't seem to suffer the same problem at first sight when I ran the above in its Delphi equivalent. That is until I tried the following (instead of assigning straight to a literal string, I did an IntToStr): procedure TAnsiStringTesterThread.Execute; var i: Integer; str: string; begin for i := 0 to 10000000 - 1 do str := IntToStr(10000000); end; The similarity in both these codes is that they both call LStrFromPCharLen, which eventually leads to a call to GetMem and when the string's ref count goes back to zero, a call to FreeMem. Could GetMem and FreeMem be the culprit? As it turns out, yes. To put the hypothesis to the test, I did a tight GetMemory / FreeMemory loop in 2 threads and observed the CPU usage. Unsurprisingly, only 50% of my dual cores are utilized, even though the utilization spreads across both quite evenly. In my search for a better memory manager, I came across the Intel Threading Building Block library. Among other useful things like parallel loops, concurrent hash maps and lock-free queue, it has a scalable memory manager. With that, I wrote a BorlndMM.dll wrapper and called it TBBMM. Here's the result:

In the single-threaded test, the TBBMM is only faster than FastMM by 20%. However, from 2 to 8 threads on a Dual Core machine, the improvements are from 2.25x to a staggering 2.5x.
For more information / to download TBBMM, visit my TBBMM webpage.

C++ Builder 2009 Compiler Bug Fixes... Finally!

2008-10-24T20:41:00.003+11:00

Came across this http://dn.codegear.com/article/38715 today and found that CodeGear has finally fixed all the compiler bugs I've filed in 2005 (3 years ago). Heck, if you do a search for "Zach Saw", you'll find that one of the entries has a path to my "My Documents" ;)

Anyway, kudos to Embarcadero to let the team work on these C++ compiler bugs which turned most of us away to the clutches of Microsoft Visual Studio / C# back then. These compiler bugs were by no means trivial - they were so nasty that they simply rendered any effort to create a stable 24/7 server impossible.

With all these bugs fixed, C++ Builder would now be the definitive tool to create a proper server (especially versus C#) - low memory usage, blistering fast and it shares most of its the design patterns with .NET (in fact, one would argue that C# is heavily inspired by Delphi / C++ Builder). I spent just 3 days writing a framework which is intimately similar to .NET's asynchronous IO design and its Control.BeginInvoke / Control.Invoke design. In case of the latter, I found that with C++, you get more type checking than you would with C# in passing parameters to the callback. In fact, even the return type for EndInvoke could be type checked with RTTI (during run-time unfortunately, but in any case, is automatic unlike .NET).

[ILINK32 Error] Fatal: Unable to open file .obj

2008-10-24T20:15:00.002+11:00

If you have been playing around with Delphi packages compiled for C++ Builder in Borland Developer Studio or CodeGear RAD Studio, you'll have undoubtedly run into this error message. You could also run into that if you are not dealing with Delphi packages (e.g. using a run-time package, static library).

Let's start with Delphi packages.

What is suspicious is the way the linker reports the error - such as [ILINK32 Error] Fatal: Unable to open file MyComponent.obj. You search the entire hard drive for MyComponent.obj only to find the closest thing to be MyComponent.dcu, which is compiled in Delphi from MyComponent.pas. So how and where do you get MyComponent.obj?

The answer is, this .obj file is actually in a container with the extension of .LIB. If your package with MyComponent.pas is called MyPackage.bpl, then you need to look for MyPackage.lib. While an installed package should get automatically added to the default list of included packages when you create a new project file, it doesn't always happen (i.e. bug). All you have to do then is manually open up your current project file (.cbproj) in a text editor and add MyPackage.lib into the tag. Reload your project and you should be able to link successfully.

If you are not dealing with Delphi packages and you get that error message, that means you're trying to use a static library, or a run-time package (and some times even design-time package which are not dropped onto a form / data module). This could easily be fixed and is the expected way linkers work. There are 2 ways you can fix this:

1) Add the lib file to the project (I don't like this, as you rely on the user of the static library to remember to add the lib file every time they use it in a new project)
2) Add the following line to a header file which is guaranteed to be included when the static library is used:
#pragma comment(lib, "your library name.lib")

That's it.

I haven't tried C++ Builder 2009, but I hope CodeGear have found a better way to do this. Actually, I'd suggest that they simply make all Delphi compiler generated C++ Builder files include that #pragma comment(lib, ...) line so that we never have to muck around with the .cbproj files any more. In fact, this would also mean that there will be no annoying messages that prompts you to remove packages you don't need when you create and try to save a new project.

BUG: April 08 Hotfix for CodeGear RAD Studio Skips Update

2008-10-08T16:37:00.003+11:00

I've run into yet another Borland / CodeGear bug - this time with the April 08 Hotfix installer. It says it has successfully applied the Hotfix but it really hasn't and you would have noticed that on the installation summary screen, it says "Current Hotfix Level: 1", instead of 0.

What happened?

Well, to begin with, you'll always run into this issue everytime you have applied this hotfix and then reinstalled CodeGear RAD Studio (i.e. uninstall and reinstall from the original DVD). The registry settings for the HotfixLevel doesn't get cleared.

Workaround is simple. Go to your registry (plenty of registry actions with Borland / CodeGear - I'm sure all of you are used to it by now), and open the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Borland\BDS\5.0

(Note: Assuming you installed RAD Studio for all users. If you've installed it for current user only, look into HKEY_CURRENT_USER and look for this key as well)

In there, you'll find an entry called HotfixLevel and it'll have 1 as its value. Change it to 0 and restart the hotfix. It now correctly detect that it hasn't updated the files and proceed to update them.

Delphi Packages not appearing in C++ Builder personality

2008-10-08T14:52:00.002+11:00

One of the new features in CodeGear RAD Studio 2007 (actually Borland Developer Studio which is the 2006 version of RAD Studio) is the ability to get the Delphi compiler / linker to generate all the files required by C++ Builder (.hpp, .obj, .lib etc.) for a Delphi package, without having to create the equivalent C++ Builder package.

Unfortunately, there's one ugly bug that has plagued this feature - you may find that the components in the package that you've installed does not come up in the designer's Tool Palette. This bug was first reported by yours truly against BDS 2006 and it appears that it hasn't been and won't be fixed even for RAD Studio 2009. That's more than 3 years since I've reported it in QC! Wow!

If you have left all settings to the default when you create a package in Delphi (which you most likely will), you will find that the components you've registered in the package won't appear in a C++ Builder project. That is simply because you have not specifically told the linker to "Generate all C++Builder files". So you would go back to the Delphi package and select that option in the Linker output and recompile / reinstall. This time, however, you would expect the installed components to appear in the Tool Palette when you try to use it in C++ Builder... Surprise surprise, it's not there!

It's as though once the IDE has decided that it is a Delphi-only package, it will remain a Delphi-only package forever. Note that if you uninstall and recreate and then reinstall the entire package, it will still be invisible to C++ Builder - that is, until you've renamed the package. That's because the IDE remembers the package name!

The other cleaner workaround would be to go to your registry via Regedit.exe and remove all the following entries to your package (say, MyPackage.bpl).

Key:
HKEY_CURRENT_USER\Software\Borland\BDS\5.0\Known Packages\
Entry:
Look for the entry with [path]\MyPackage.bpl and remove it

Key:
HKEY_CURRENT_USER\Software\Borland\BDS\5.0\Package Cache\
Look for the key called MyPackage.bpl and remove the entire sub-key

Key:
HKEY_CURRENT_USER\Software\Borland\BDS\5.0\Palette\Cache\
Look for the key called MyPackage.bpl and remove the entire sub-key

Remember to first shut down CodeGear RAD Studio before changing the registry keys. Once you have removed the entries, restart RAD Studio and this time, remember to select "Generate all C++Builder files" for all build configurations (e.g. Debug and Release) before you install the Delphi package.

And in the future, keep in mind to always set the linker to "Generate all C++Builder files" or set that as your default for all build configurations.

ps. Yup, they haven't rebranded it to CodeGear in the registry - it's still Borland as we know it! :)

QuickPHP v1.4 Adds Apache Mod Capabilities

2008-10-01T18:44:00.004+10:00

Those who are familiar with Apache mods will welcome this new addition to QuickPHP. What sets QuickPHP apart though, is that it uses PHP itself to implement the mods.
I've detailed its inner workings before on this blog here.
You can download QuickPHP here and read the mod documentation here.
While I've made the interface to create mods available, there isn't any mods available yet. This is the time QuickPHP could really use your contributions. Someone to write the equivalent of mod_rewrite, mod_log_referrer, mod_log etc. in PHP. Anything that might be useful to you, is potentially useful to others too. So don't be shy to contribute your code in the forum!

Project Offset will be Larrabee Exclusive

2008-09-11T16:55:00.001+10:00

It's been officially confirmed by one of the developers in the Project Offset Team (Paul Tozour) that Project Offset will be exclusive to a "select Intel-based platform".

From Project Offset's Forum:

"Right now, I can only pass on the official word:

Offset will be exclusive to select Intel-based platforms.

We look forward to being able to discuss more details in the future."

What this means is that Project Offset has been specifically designed to run only on Larrabee - utilizing every bit of the massive VPU to do graphics and physics that are traditionally impossible without heavy tweaking on the DirectX API.

But how is this game important? It's only one game. And more importantly - why is Project Offset a key player in the success of Larrabee?

Project Offset is firstly a game development tool / package with its own engine and secondly a game, much like the Unreal 3 Engine. Ageia employed the same strategy with its Physx and while its card has not been much of a success, the strategy worked - at the time of this post, there are 100 over games supporting Physx, with the majority of them based on Unreal engine. Intel has bought everything they need to own a game engine outright - first, they bought Havok, and early this year (February 2008), they bought Project Offset.

Larrabee was seen as a saviour for Project Offset's developers -- they were constantly wrestling with the DirectX API to get the effects they desire. They have also worked very closely with other renowned developers in the field to try and solve some of the problems they encountered but none came up with any good answers. This simply proves that there are more developers hitting the walls of limitations imposed by the DirectX API than we previously thought. Larrabee frees them of this struggle and gives them the freedom to implement anything they could imagine. While it is easy to see that the whole game industry is behind DirectX at the moment, you are completely restricted to the feature set it gives you. Even with the shaders becoming more powerful, it is nowhere near the prowess, flexbility and maturity of x86. Perhaps you could be arguing that nVidia's CUDA could accomplish the same thing. Maybe. But nVidia hasn't bought / started to develop its own game engine yet. Yes, they have the Unreal 3 Engine which uses Physx but it's bound by DirectX. A quick visit to the CUDA forum can confirm that no one has even started working on a custom graphics engine based on CUDA. So on the one hand, we have a plethora of DirectX games - almost every game engines out there are based on this API. Smaller game studios simply buy games engines to create games. We exclude these from the equation as they will adopt which ever standards the underlying engine relies on. So this leaves us with the major players - those who are creating their own engines and sell them for a profit. They're the ones who're being limited by the DirectX API at the moment. They're the ones hitting the walls of creativity set by nVidia, ATI / AMD and Microsoft. They spend years coming out with techniques that utilize the API to do forefront, eye-popping graphics engines. Imagine if they're thrown a life line. Imagine the day they don't have to trick the API to perform something clever. That's where Larrabee comes in.

Don't be fooled by the statement made by the architect of GTX 280. He said they've considered creating something like Larrabee but found that it's not a viable design. That could be true a few years ago or even now, but by next year, nVidia could be heading down an opposite path but ending up with the same design as Larrabee. GTX 280 contains a fair bit of general purpose cores, which sets it apart from the generations before. Larrabee's design is basically the natural progression of GTX 280.

Come next year, I wouldn't be surprised if nVidia's successor to the GTX 280 is somewhat similar to Larrabee - except perhaps the most obvious: it is not x86.

In any case, Intel's strategy at this point is nothing to scoff at - they've built a solid foundation for Larrabee. If anything, they're ahead of nVidia/CUDA at this stage of the game.

For those who are interested, reading through Project Offset's developer blogs and forums will give you an insight into the life as a graphics engine developer.

Using PHP Script as a Plugin

2008-09-05T17:40:00.004+10:00

A discussion in my QuickPHP forum has resulted in this new idea where PHP Script can simply be used to create a plugin. Rather than the conventional DLL plugins, we simply get the host to call into the PHP script and get the results back from it.
Of course, a DLL plugin has its advantages (i.e. compiled and runs faster), but in cases that require you to allow your user to configure part of your software with great flexibility, instead of using INI / XML files, a PHP file is definitely not a bad idea. That would bridge the chasm between a DLL plugin and a simple config file. What's more - you only need to deploy the php DLL file (e.g. php5ts.dll) along your software and that's it! You get PHP's powerful regular expression out of the box!
In the discussion, I suggested that PHP could be used to implement the entire Apache's mod_rewrite module, without the need for an external INI file with an input and output regular expression. Users would simply need to write PHP script to manipulate the client request info and return it back to the server. This also means that QuickPHP's mod_rewrite functionality could be so much more powerful than Apache's. In fact, I think one main PHP file is all I need - the main file, in turn could simply call into other modules to work its magic if it's required. If QuickPHP_ReqMod.php is not found, QuickPHP reverts back to its basic mode. No additional DLLs - no unnecessary memory usage.

Testing PHP on Windows - in 5 seconds! Without installing Apache, IIS or even PHP.

2008-08-29T14:52:00.001+10:00

Testing PHP on Windows in less than 5 seconds without installing Apache, IIS or even PHP. Is this possible?
Yes it certainly is - and it's FREE.
QuickPHP is designed spefically for this purpose.
Here are the steps to test PHP on Windows in less than 5 seconds:

Download QuickPHP WebServer (quickphp_webserver.zip) from http://www.zachsaw.com/?pg=quickphp_php_tester_debugger
Unzip the file into C:\QuickPHP
Run QuickPHP.exe from the folder
Hit Start.

That's it!
You can now test your PHP webpages by browsing to http://127.0.0.1:5723 and QuickPHP will run 'index.php' in 'C:\' folder (of course, make sure you have a file called 'C:\index.php' - if not, copy and paste the following code and put them into 'C:\index.php').
If you wish, you can change the webserver's root to your local webpage folder and the default document name to point to your own index file.
index.php:
<?php phpinfo(); ?>
If you need any help, you can visit the QuickPHP forum.

Larrabee with FPGA pledge

2008-08-20T15:35:00.000+10:00

Following up on my pledge to Intel for including a real-time reprogrammable highspeed FPGA on Larrabee, it looks like it's definitely very useful in a number of applications. With texture filtering being done in hardware with Larrabee running as a GPU, we could reprogram the FPGA to do motion search for H264 encoding. We're now going into a new era where computer engineers are very good in both software and hardware design.

I suggested the idea of including an FPGA as part of the CPU to a fellow employee / manager back in Intel but unfortunately, it never got any attention. That was back in year 2001. 7 years following that, we're now seeing companies making full use of FPGAs to accelerate applications that aren't efficient to be run on a CPU. Larrabee solves some of the things I said an FPGA would solve, but there are definitely several other applications out there that would benefit from an FPGA. I also pointed out that Intel should come up with a library (i.e. hardware design) that developers can simply load into the FPGA to accelerate specific types of algos.

Take a look at this.

Larrabee picks it up where CUDA fails

2008-08-20T14:50:00.000+10:00

Having read most of the publications by nVidia, ATI/AMD and Intel made available to SIGGRAPH, I have to say, I'm a believer in Larrabee. Most of the problems that plagued CUDA involves having to design and offload only certain parts of the algo which can be suited for GPU and which is small enough in terms of bandwidth utilization across PCIe over to the GPU, and then getting the results back from it via the same path.

The reason this is even being discussed lies in the fault of the whole GPGPU concept. The GPU is good at one thing - being fed textures (compressed) and command that are then pumped through its fat pipelines to get results (rendered image). Use it for something more generic, we have to deal with issues such as the PCIe bandwidth and having to feed the onboard frame buffer with enough contiguous data to work with. Say we have infinite video RAM. Even then, we'll still have to do some parts of the algo on the CPU as the GPU is just incapable of doing things like scalar operations and sequential branching algos (namely tree algos - heck, CUDA doesn't even do recursion) effectively. With a measly PCIe between CPU and GPU, any performance gained will most likely be offset.

CUDA is at best, a DSP SDK. nVidia's attempt at using its GPU as a very basic DSP. Nothing more. Yes, you may find that offloading some parts of, say, a H264 encoder will give you some gains. But if you go further, and implement say, anything beyond the baseline profile, you'll run into troubles. You'll get some gains no doubt, since the GPU is always a free agent if it's not being utilized. Is it worth the effort though? Hardly. The x264 developer has gone out to say CUDA is the worst API / language he's ever encountered (particularly with the threading model).

Larrabee, however, will change the landscape quite a bit. All the above mentioned problems, are exactly what Larrabee seeks out to solve. OpenMP for threading model, much higher level of abstraction between CPU and Larrabee (it's capable of running Pentium x86 instruction sets, so there's no need to go back to the CPU as frequently as GeForce / Radeon), and SSE vector instruction sets -- these are all directly targeted at the downfalls of CUDA!

When Pat Gelsinger said CUDA will just be a footnote in computing history, nVidia was a fool to laugh it off. It's already happening. Perhaps Wiki should start deleting their CUDA pages and start footnoting GPGPU pages with a short and sweet "meanwhile, there's CUDA" line. :)

Larrabee and TFLOPS SP / DP - the TFLOPS race BEGINS!

2008-08-14T15:41:00.000+10:00

There's much confusion over the upcoming Larrabee chip from Intel. It seems that most people who've tried to calculate the peak performance of the chip in terms of TFLOPS couldn't come up with the 2 TFLOPS Intel claimed Larrabee would achieve.

Larrabee's in-order cores are capable of processing a peak of 16 SP (single precision floating point) data per clock (512-bit VPU, hence 16 SP or 8 DP). At 2GHz, 32 cores, you only get 1.024TFLOPS SP (2GHz * 32 * 16SP). So how come Intel is claiming it is capable of 2 TFLOPS at that configuration?

Well, here goes. 1.024TFLOPS is the peak for most SIMD instructions, but if we take the MULTIPLY-ADD instruction into account (which Intel implemented recently in its SSSE3 - or SSE4 for the non-informed) then we would multiply 1.024TFLOPS by 2 - hence giving Larrabee a peak performance of 2.048 TFLOPs SP. Yes, it's Single Precision Floating Point (i.e. 32-bit) and not Double Precision (i.e. 64-bit) as some people are claiming it is. For DP, Larrabee would get a peak of 1.024 TFLOPs.

Before you go saying that Intel's cheating, the 4870 HD also implements the same instruction and its 1.2 TFLOPs SP performance is calculated for this specific instruction as well (same as Larrabee). A high end 48 core Larrabee would give a peak performance of 3 TFLOPs at 2GHz.

Interesting thing about the MULTIPLY-ADD instruction really - it's patented by 2 Japanese persons. This is a single cycle instruction that does multiplication and add - it's obviously very beneficial to vector calculations and applications like GPUs largely depends on this particular instruction.

I can see things shaping up quite nicely for Larrabee. Now that the GHz-race era is behind us, let the TFLOPS race begin!

nVidia gives Larrabee its blessing for CUDA and Physx

2008-08-14T15:39:00.002+10:00

Just a thought - nVidia has said that its CUDA will run on x86 too (duh, that would be simply an x86 C compiler wouldn't it?) and since Physx runs on CUDA, that means nVidia has (probably inadvertently) given its blessing to get Physx running on Larrabee. Now that wouldn't be a bad thing at all.

Very generous of nVidia. ;)

Highspeed FPGA to complement Larrabee

2008-08-14T15:39:00.001+10:00

Before I joined Intel, I've always had this idea in my mind - to have a highspeed FPGA as a coprocessor. I think this is a much better time to propose this solution to the world than it's ever been. With the buzz going around Larrabee and its need for a fixed function unit such as the rasterization unit for GPU, it would be so much more flexible if this is implemented as a block of FPGA. The driver is then responsible for converting this block into whatever the application sees fit. Anything that could not fit in that cGPU paradigm can be hardware accelerated via the FPGA block.

Any take on this, Intel?

About Intel Larrabee

2008-08-14T15:24:00.000+10:00

About Larrabee and Larrabee vs GeForce / CUDA or ATI / CTM (without repeating what you could look up on other sites):

1) Michael Abrash, Tim Sweeney and John Carmack are all on board Intel's software team for Larrabee. This should give them a pretty solid team (understatement) for driver development.

2) A quote from GCDC'08: multi-thread your DirectX code and drivers. "3. Direct 3D runtimes and drivers account for 25-40 percent of CPU cycles per frame. This needs to be reduced in order to push performance!"

The freedom of offloading these 24-40 percent to Larrabee and leave the CPU to process everything else is something quite significant. This is, however, something they're still working on, as some calls involve the OS kernel and is not the natural way things happen as it stands with Larrabee on PCIe. Again, the ultimate goal is to get Larrabee sitting on your motherboard running as a co-processor, in which case scheduling will be done by the OS just as it would for a normal processor. The design decision to use software task scheduling is obviously two-folds.

3) CUDA does not support recursion (among several other things) - and will not likely be implemented in the near future due to hardware limitation - and not unless they implement a sophisticated prefetch hardware like Larrabee, it will most likely never happen.

Developers look for free-lunch. CUDA doesn't seem to provide that very well as it requires the algo to be completely rewritten - see www.gpuchess.com for example. With that said, it doesn't mean that nVidia can't emulate some of these features through other means like what GpuChess has done in its compiler. But, that leads me to the next point.

4) CUDA is a C-like language. That's good - but, how do you get C++ / C# / VB / Delphi / Java etc. developers to code for it? Not unless nVidia starts writing their own .NET IL runtime libraries, and VCL runtimes for their hardware (read: doesn't make sense financially and impossible in the limited time frame before Larrabee debuts). Larrabee gets all of these, for free.

The final point is what I'm excited about - because you're not restricted to just CUDA-C. You're free to develop in whatever language you're most familiar with. The best part is, with the binaries compiled for Larrabee (if you don't go for the exotic mnemonics of course), it'll be possible to run it on a machine without Larrabee, albeit much slower - but, at least it will run. I don't see any developers (bar hobbyists) getting excited over writing the same algo 3 different ways - CUDA, CTM and x86.

I don't know about the rest of you, but this looks like a very good idea to me. When I was working in Intel, I was going to propose something similar to Larrabee, but a more hardware solution. Maybe it's still possible. I'll leave that for the next post.

DotNUTs Framework - DirectoryInfo.GetFiles and DirectoryInfo.GetDirectories Callback / Event

2008-07-29T14:41:00.000+10:00

The .NET framework is far from a refined / polished framework. It's nearly everything that I do in the .NET world, I run into a brick wall which eventually leads to writing my own wrapper around Win32.

Recently, I had to write a file searcher which is mainly used to look for files on USB hard drives. Each folder in the drive is made up of several tens of thousands of files and the drive is usually extremely fragmented (we're not talking about your conventional PC hard drive setup here). Using DirectoryInfo.GetFiles has a fatal flaw when it comes to enumerating files in a folder - it does not have a callback to report its progress, which means there's no way to cancel the search.

The Directory.GetFiles method works well for folders with not too many files but my case, enumeration can take up to a few minutes on a USB 1 connection. It doesn't matter if you implement this in the foreground or background thread - either way, your user will be forced to sit through the enumeration without any progress report or means to cancel the enumeration (unless you want to force a thread abort - still, there's no way to report progress).

So, WinAPI to the rescue, yet again. Using FindFirstFile and FindNextFile, we can easily achieve the same thing. The problem, however, is that in C#, you'll need to pinvoke these functions and the painful part is, you'll need to define everything that is simply a header file include away in C++. If that's not enough, you'll then need to verify that your definitions are correct in that it marshals the arguments back and forth properly.

Finally with all that out of the way, I stumbled upon yet another .NET framework bug in my unit test: DirectoryInfo.LastAccessTime LIES! (although I admit I don't need the LastAccessTime of a directory - but a bug's a bug)

Directory: C:\Windows\assembly
Date Accessed, as reported by Windows Explorer: 29/07/2008 2:08 PM
Date Accessed, as reported by WinAPI: 29/07/2008 2:08 PM (29/07/2008 2:08:38 PM)
Date Accessed, as reported by dotNUTs framework (DirectoryInfo.LastAccessTime): 29/07/2008 2:30:08 PM

It's not the LastWriteTime nor the CreationTime - that leads me to think that dotNUTs must have pulled the value out of its arse - which is not surprising given my experience with dotNUTs.

Does anyone else feel that the .NET framework is plagued with bugs? Or am I just a bug-magnet?

Or maybe someone should help Microsoft with their unit tests?

p.s. I'm not the first to coin the word dotNUTs.

Borland / CodeGear Delphi / C++ Builder

2008-07-13T17:25:00.001+10:00

It's sad really to finally see Borland closing a chapter on its very successful product - the VCL.
VCL has been the foundation of the .NET framework Windows Forms portion and in many ways still does a much better job - such as subclassing common controls, wrapping it into a 'drag-drop'-able control. Amazingly, Borland's core controls in the VCL has remained mainly unchanged since Version 5. With a few tweaks and additions to make it use Vista theme, it was made theme-aware in Vista.
What can we say about the .NET framework then? Well, as of Orcas (VS 2008 for the less informed), most controls are still not Vista themed - and most of the controls are around about VCL's version 3 standards in terms of features, bugs, and extensibility (ease of derivation, subclassing etc.).
Yeah yeah, there's WPF, but heck, some controls in WPF are even worse than their Windows Forms counterparts. And, using WPF simply means shooting yourself in the foot when it comes to finding the lowest common denominator - heck, I can't even run WPF apps at a decent speed on my 3 year-old laptop.
Microsoft's solutions - WPF or Windows Forms - are very half-hearted. They are neither very usable, or completely unusable. Most of the time, you'll have to invest a lot of your own time and resources into making something useful out of it.
Just for example, the TreeView control - both Borland (CodeGear) and Microsoft have it. Which is better? Borland (CodeGear) hands down (I expect Borland fan boys to cheer and Microsoft fan boys to boo now -- Darn those people - get a life!).
I worked with a guy with MCSE creditation last year (typical Microsoft fan-boy) and was told that anything I could do with Borland (CodeGear), I could do with Visual Studio / .NET framework. Sure. Try creating a multiselect TreeView that works in both Vista and XP, natively themed (i.e. Vista explorer mode theme and in XP, fall back to the active XP theme). In Borland (CodeGear), you'd simply drag-n-drop and set the multiselect property to true. Zero lines of code. I dare you - you know who you are, you Microsoft fan-boy - try doing that in Visual Studio and see how long it would take you to do something similar.
Yeah, sure, I did it eventually - check out my Advanced TreeView Control here - but it took me some time. And sure, the fan-boy could've simply said, well, I told ya, it could be done. And my reply would have been, "Yeah, it could've also been done in pure ASM!"
Good on ya Microsoft!

The Online Vultures

2008-07-10T12:30:00.001+10:00

I think I'm going to coin a new term here - The Online Vultures.

There are quite a few companies out there waiting for a domain, particularly a very highly ranked domain (in search engines) to

expire, and if the owner does not renew it, these companies pound on the domains, analogous to vultures ripping apart a dead

carcus. If you even try to get the domain back, you'll face the wrath of these vultures pecking you to death! Not that you should

let your domain expire, but that's a tale for another day.

How do these companies get money off sites like these?

Simple. They park a website on the expired domain, with a link oh-so-visible to "Enquire about the Domain". Following the link,

you'll be presented with a form which asks you for your contact details and the most important question of all, "How much are you

willing to pay for the domain?" (all these are provided by Domain Parking service).

Companies like the following is an example:

created-date: 2007-05-04 18:16:31
updated-date: 2007-09-06 13:48:52
registration-expiration-date: 2009-05-04 00:00:00

owner-contact: WA-VirtualStockLtd
owner-organization: Virtual Stock House LTD
owner-fname: Andrew
owner-lname: Waggins
owner-street: Midtown Building, 625, D.R. Walwyn Square
owner-city: Charlestown
owner-state:
owner-zip: 001
owner-country: SAINT KITTS AND NEVIS
owner-phone: +18696124652805
owner-fax: +18696124652805
owner-email: vsh.ltd@googlemail.com

This 'company' (whether or not it's real) owns 3,557 other domains.

Try www.micrusoft.com and www.micrasoft.com, or even www.iApple.com - they are all domain parked. Amazing.

Application Data - The WinForms Cookies

2008-07-08T12:02:00.000+10:00

The application data folder (%USERPROFILE%\Local Settings\Application Data) is guaranteed to be read-writable and furthermore, it is user specific. Compounded by the ease of use via the IsolatedStorage class in the .NET framework, this sounds like the ideal place to save all your user settings doesn't it?

It is. Just an example, Microsoft Visual Studio caches all your project assemblies there. If Microsoft does it, it has to be correct, right? Yes and no.

While this is one of the most convenient storage locations, there is, however, the issue of - when and how do we remove the data we have stored in app data folder?

Microsoft Visual Studio suffers from this exact problem with its project assemblies - it really shouldn't, but it does. And when that happens, it will drive you nuts. What am I talking about? Here goes.

When a solution is loaded, all the referenced assemblies which have their property "Copy Local" enabled will be cached in %USERPROFILE%\Local Settings\Application Data\Microsoft\VisualStudio\\ProjectAssemblies\. The next time you open the solution, Visual Studio will check the cache for the assemblies and will not recopy the assemblies even if they are out of date. This happens very frequently if you use any third party components / controls with designer support - every time you upgrade to a newer version, your solution breaks as you now have an older version of the assembly in your cache, while the designer expects to work with the version it gets installed with.

The problem arises simply because Visual Studio does not remove the cache when the user closes the solution. It really should not retain the cached assemblies simply because these files will then remain indefinitely in your application data. Imagine every single time you create a little application to test out the behavior of certain components / controls (be it built-in or third party), VS caches all the assemblies. If Microsoft insist on not deleting the files, at least have the courtesy of doing it properly - this is analogous to Intel's Nehalem processor (the successor of Core processor) using stale data from its L3 cache!

In the case of VS, the solution is simple - recopy the assemblies each time the solution is reloaded.

Users of IsolatedStorage though, have a bit more problem in that if we use IsolatedStorage for application settings, when do we clean it up? When the software is uninstalled? Seems like quite a hassle - in the uninstaller, figure out which subfolder is for the application we have installed, enumerate through all the user profiles and delete the data files.

OK. Before we go any further, how do we figure out the subfolder of which our application has used for IsolatedStorage? Is this relative location even the same for all the users? Where's the documentation for this?

Too much hassle means one thing - most developers / companies will simply leave the files in IsolatedStorage after the application gets uninstalled. I suppose that's a bit better than leaving the data in your Windows registry back in the old days.