Deep Insights in Microsoft .NET

I found an interesting idea today - this is something which most people do wrong in software. Sometimes we want to display information differently than what we have already shown on the screen - most developers just simple change the UI code directly to change the way it renders on the screen. This may not be the best approach to handle this situation. If the display is complex enough, it might be better to simply create a data structure of the same data, tuned to showing it in the different way. Then you just create the data structure, populate it and rendering it becomes easy. I used a similar technique in another more complex project as well. There data coming from disparate sources had to be shown in a unified manner in a grid. Rather than getting raw data and squeezing it to show the information directly on the screen - I developed a domain model which directly represented the generic model of the disparate data. Then the work of showing this on the UI became significantly...

http://arstechnica.com/information-technology/2014/04/how-has-an-increase-in-system-complexity-affected-new-programmers/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+arstechnica%2Findex+%28Ars+Technica+-+All+content%29

This is really a setting for a "quantum" a.k.a the amount of time a thread is permitted to run before it is pre-empted (not a problem for fibers). If you set it to programs/ applications it is a small value like 2 clock intervals. If you set it to background services, it is a large value like 12 clock intervals. The value for background services is larger and meant for server OS because throughput and performance are more important. Shorter quantums would mean more context switching and worse performance.

You would have seen this from SQL Server preferences. This could have come with the .NET framework at some point in time, but they kept it separate. http://stackoverflow.com/questions/796217/what-is-the-difference-between-a-thread-and-a-fiber This link is mostly correct. But not fully correct though. Windows NT will interrupt threads so that multiple threads can execute at the same time - true. But this will not cause any problems in normal course because if that was the case, half the programs in the world would not work properly. In reality, it is able to easily manage swapping one thread from kernel to user mode and vice versa along with loading all the data to and from the registers without losing information. In the C++ world, you have a lot of control and can change lots of stuff all over the place which can cause problems and data corruption.

http://blogs.msdn.com/b/phkelley/archive/2013/05/29/server-workspaces-vs-local-workspaces.aspx - Just use the classic server workspace which is much faster if your projects have greater than 100K items.

When the managed thread is aborted, an exception is introduced at the thread's current instruction pointer. This allows the finally blocks to execute as the thread winds down. The runtime is also aware of code that are performing non-interruptable operations like manipulating system state and so it will delay introducing the abort exception until a safe point has reached. Terminating a native thread does not free the user-mode stack. The thread can hold onto locks that after termination will remain in the acquired state. This thread could also have been modifying critical system state which gets corrupted when interrupted. If you terminate a native thread, you should probably be terminating the process as well.

This is a good one which is very useful: for ( int i = 0 ; i < 100 ; ++ i ) { Console . Write ( "\r{0}" , i ); } http://stackoverflow.com/questions/888533/how-can-i-update-the-current-line-in-a-c-sharp-windows-console-app