Not sure how many people aware, but .NET runtime will terminate process when background thread raises exception that is not handled. Reason behind that if exception is not handled, then this situation was not tested and can lead to program corrupting its state and it is much better to just terminate it. This reason definitely has some sense and normally I would agree with it. Application will crash, mini dump will be created and sent to Microsoft. Then you can have access to these crash reports and analyze them. But this approach has some issues.

First issue. In reality, corruption is extremely rare. For example, in our application I never heard about corrupted files. Still possible, just very rate. But

As you may guess, this blog is hosted somewhere. I do occasional backups, but usually I do backup quite rare. Usually once per few months unless I deploy some changes. There are few reasons why it happens. Firstly, I wasn’t sure that I will do blogging, secondly, I kind of forget. I believed that I deployed my blog and hosting company will make sure that data is still there, and I totally forgot about it. I did backup in kind of habit but because I was busy it happens rarely.

And few days ago, hosting company became victim of ransomware. All files were encrypted. Moreover, because some critical OS files were also encrypted, I don’t even able to see name

Traditionally in Windows there is standard message loop that consist of GetMessage, TranslateMessage and DispatchMessage. There are variations but most cases it is like this. One popular case is to use PeekMessage instead of GetMessage. Usually this message loop is in center of your application and in many modern frameworks it is not even visible. It is mostly hidden from developer.

But in some cases, it is required to create your own message loop. There are many cases when it is beneficial to do. As result there is main message loop that processing messages and in a reaction on some message, second message loop is started. Then in reaction on

Recently I got new computer and I prefer to install everything by myself. On of the programs I use is FAR. Basically it is file manager. It is quite powerful application and it is mostly used by people who work professionally on computer. It resembles old good Norton Commander and it is console application.

Anyway, after I installed it, I found that colors are weird. Initially I thought it is something in video driver settings but after some time I found that all other colors look correct.

Here how it looks on new PC:

And here how it looks on old PC:

Firstly, I would like to setup context. Few years ago, in company where I work decided to upgrade 256GB SSD to better ones. I did research and found that 512GB Samsung 850 EVO. This is great SSD and it works quite well for like 4 years. But eventually it filled up and I had to move some stuff to HDD and finally I decided enough is enough and ask our IT department to buy 1TB disk. I specifically asked for 860 EVO 1TB disk. After one week I got my disk and was happy user since.

Later I was asked to investigate problem with checking out data from one of our source control servers. At the same time, I got

Monitors

For very long time computer screen had ratio of width to height equal to 4:3. Common resolutions were 640x480, 800x600, 1024x768. Every person who works with computer knows the more you can fit vertically the better. You can fit more text when you type or when you read. If you edit pictures, they also tend to be close to 4:3 ratio. But 24” monitor with 4:3 ratio requires much more pixels than say 24” with 16:9 ratio. About 15 years ago LCD panels were expensive. Nobody wants to buy panel with defective pixels and the less pixels the more chance to have no defective pixels. And manufacturers started to sell widescreen monitors. As result when consumers see 24” monitor

Many of you seen code like this:

public async Task Func()
{
    await SomeFuncAsync().ConfigureAwait(true);
    SomeOtherFunc();
}

Let’s assume that this code is executing in main application thread. Is it possible that SomeOtherFunc will be executed not in main application thread? Answer is yes. Let me explain why.

Here is really really simplified version of what compiler will do with our function:

public Task Func()
{
    Task task = SomeFuncAsync();
    SynchronizationContext context = SynchronizationContext.Current;
    task.ContinueWith(finishedTask => context.Post(state => { SomeOtherFunc(); }, null));
    task.Start();
    return task;
}

It actually looks completely different but from point of SynchronizationContext it looks close enough.

In short, when task will finish, it will execute provided callback in

Today I would like to talk about window message queue. Many developers for Microsoft windows familiar with this subject. There are many books about this subject and honestly, I was under impression that each window has own message queue. I even asked many developers around me and most developers were telling the same story. Some believe that there is one message queue for process and some even believe that there is one queue for whole session.

Today I will try to get to bottom of this. If we read here https://docs.microsoft.com/en-us/windows/win32/winmsg/about-messages-and-message-queues you will see this: “The system maintains a single system message queue and one thread-specific message queue for each GUI thread”. Just to be clear GUI thread is

Recently I did watch one video about scams in Facebook (sorry I didn’t remember whom I did watch and actually I forgot about that story for quite some time). Basically, one guy found many scams on Facebook that sell some products like notebook but very cheap, like 10% of original price. One example was Microsoft Surface for $50. Another one was Samsung watch for $30. And these scams are using original product texts, images, videos etc. Obviously if you will buy one, you will get some cheap fake. But for unexperienced person these products look legit.

Anyway, that guys reported these scams to Facebook and provided statistics in his youtube channel. And results do not look good for Facebook. 75%