分类： 操作系统

I wanted to talk about this for a long time, however, the key points were not clear until recently I ran into the pipeline concept in PowerShell.

When you do pipeline in PowerShell, you’re passing not a text stream from the left command to the right command, but rather, you’re passing a .net object.

When I read this from TechNet, I smiled to myself, yes, this is typical Microsoft!

Windows PowerShell provides a new architecture that is based on objects, rather than text. 
The cmdlet that receives an object can act directly on its properties and methods without 
any conversion or manipulation. Users can refer to properties and methods of the object by
 name, rather than calculating the position of the data in the output.

And I said to myself, now I know what I wanted to say.

One key difference between Windows and Linux is, Windows always tries to be smarter, where GNU Linux tries to stay plain and humble. Pipeline in scripting is just one recent example.

Linux has been using text configuration files. Windows came along and said, we need something better. That’s how Windows Registry came about.

Linux has been using pipeline for IPC. Windows came along and said, we need something better. That’s how COM came about.

Linux has been using lock files to prevent processes to start another instance. Windows came along and said, we need something better. So they use Kernel Object instead.

Linux has been using permissions as a basic security measure. Windows came along and said, we need something better. So they do everything using ACLs.

Linux has been using symbolic links. Windows came along and said, we need something better and introduced short cuts.

…

To be fair, not all of them are bad ideas.

Despite its complexity and awkward configuration, COM gained such popularity that it became the basic foundation of modern Windows. Open registry in any Windows that has been used for a while and chances are the biggest tree is HKLM\Classes\CLSIDS. (One of the key reasons why you Windows becomes slower as you install more and more software).

Kernel Object is much more reliable than lock files. ACLs indeed provide much flexibility in terms of access control. Linux is also doing it now.

However, we all know that Windows have record of being smart in cheap ways and then fail pathetically. (SilverLight is the one that came into my mind as I write this) To me, this idea of passing objects through pipeline looks like just another one that will fail.

Having said that, I have to admit that, this difference between Windows and Linux is also not surprising.  Linux is developed by community led by technical experts. Introducing new features always involves extensive discussions between these experts.That’s why Linux has a bad reputation of not listening to its users.

Where as for Windows, most likely, new features are proposed by requirement collection team and developer team, then the list of new features have to go through rounds of prioritization processes. If there are disputes, then there will be escalations and some manager will decide. Once decided, then features still in the list will be implemented. Period.

Now, it is actually surprising that Microsoft actually made some key decisions right, right? 🙂

Windows has long been complained of performing slower and slower as being used. This essay tries to explain how and why.

Before we go into details, let’s make it clear that we’re talking about the architecture design of Windows that makes it not performing in certain situation. So this is consistently measurable performance difference. We’re not talking about bad performance because of wrong configuration. Nor are we going to talk about performance of a specific program.  A specific instance of slow down, for example, your notepad will performance slower when you have a lot of other programs running, is not what we’re going to talk about.

First of all, there’s no reason Windows should perform worse (or better) if you just spend more time on it. If the installation keeps the same, the size of your computer keeps the same, Windows should perform the same.

However, if one of your running programs or a device driver has memory leak, then it will eat up more and more memory as time pass by. That will slow down your Windows. The unique thing about this type of performance issue is, after a fresh restart, Windows should perform well. In the early days, memory leak was a common issue on Windows. That attributed much to the common belief that you should restart your Windows once in a while to keep better performance. Now, most commonly used program is mature enough to be free of memory leak, Windows should perform just the same as time goes by.

However, as time goes by, you’ll probably keep installing new software on your Windows. This could indeed slow down your computer. The reason is, by installing any non-trivial software, you’re not only copying files to the disk, but also registering COM components to Windows. These registry key/values will be keep in memory. So the more software you install, the less memory your program will be able to get.

As an example, after you install a program that is able to open a new file format, chances are:

• You’ll not be able to see a thumb nail that shows the content of the file in Explorer;
• You’ll see this program listed in the pop-up menu of this file type;

They were made possible using COM technology that depends heavily on Windows Registry.

The problem is, this registry keys/values won’t get cleaned up when you uninstall the software. So Windows registry keeps growing and growing, your programs have lesser and lesser memory to use.

The other factor that would for sure slow down your computer is disk fragmentation. Disk fragmentation affect performance not only when your program does disk IO. If your page file is fragmented, paging operation will be slow. That will cause noticeable sluggish. Also remember that all executable files and dll files become memory map files, so if they are fragmented, your program will be slow not only during start up, but also in running phase.

Bloated registry and disk fragmentation are the two reason that your Windows slows down in the long run. In some of my Windows computers, I actually create separate partitions for page file, for outlook pst file and Windows tmp file. These techniques worked quite well.

I had suffered from this annoying problem for a long time – Every time I opened the compmgmt.msc file, and tried to check the system log (or application log, or any other log loged by Event Log), I could open the event property windows normally by double click on a log entry. But as soon as I closed the event property window, the whole application got frozen. That is, I can move the main windows, maximize it, minimize or restore it, but the content of the window became blank. Soon after that, the title bar of mmc told me that the application stoped responding.

I couldn’t figure what’s happening until one time, I used SystemInternals’ process explorer – I love this tools – I found that there’s a new thread being spawned when I opened the event property window. Yet when I closed the window, the thread didn’t terminate. Just a desperate move in order to solve this problem, I killed the thread using procexp. Magically, the mmc window restored to its normal state!

I tried to reproduce this scenario, some time it works, other times it failed.

Yesterday, when I got an error, I check the log and got stucked, again! When I fired process explorer and trying to kill the stuck thread, this time, the worst thing happened, process explorer got stuck!

Finally, I would have to solve the whold problem. I launched visual studio, and created a new project, and attach to mmc.exe process. I waited for all the symbols got loaded and paused the process.

There they were! In the thread window, there were four threads, I repeated the resume and pause for some time. Everytime the process pauses at the same thread. So I can assume this thread was busy doing something. The call stack show that this thread is doing somthing with the IME engine – I’m working on an simplified Chinese platform.

There was another thread with a paused flag, I switched to this thread, call stack show it was paused in a WaitForSingleObject function call. It must be the main thread. A peek at The bottom line of the calling stack confirmed this.

So, could it be the IME engine causes this frozen?

I investigated the loaded modules of the process, and the imsc12.ime seemes suspicious. It was the module sit on top of the call stack of the busy thread.

I opened the c:\windows\system32\ folder and found the file. In the security property of the file, I denied everyone from accessing this file. After that, I opened the compmgmt.msc and double clicked on an event. With cautious and anxiety, I closed the window… IT WENT WELL! THE PROBLEM GOT SOLVED!

ps, I searched the net with all the possible keywords combination. It seemed nobody else ever had this problem.