Engineer Boyfriends are the best!!!!

Top 3 Reasons why Engineer Boyfriends are the Best!!!

1. Secure lifestyle

An engineer boyfriend can provide you with a secure lifestyle. At 27 years old, an engineer probably has a respectable, stable job that gives him high income to own a car, invest, have a comfortable life, and get married and buy a house too. Law graduates are still working as a lowly apprentice in law firm, most management graduates have just failed on their first business plan, the arts graduate is still

looking for a job, and the medical school graduate is still living in a hospital.

2. Unmatchable industriousness

An engineer boyfriend will dedicate an unimaginable amount of his time and effort to understand you. Engineers strain really really hard to understand their work. You can believe that they will try really really hard to understand women too, just like how they understand their work, once they believe that you are the one. So even if they don’t understand you initially, they will keep on trying. Even if they still do not understand, they will figure out the correct method to keep you happy (e.g. buy diamond ring = 1 week’s worth of happiness.) And once they find out the secret formula, they will just keep on repeating it so that the desired results appear. Unlike the Lawyer who will argue with you, the Management graduate who will try to control your spending, the Arts graduate who will ‘change major’, and the

medical school graduate who will operate on you. And you know what, it’s really so easy to make engineers believe that you are the ‘one’. Say that you like one of their projects and they will be hooked to you forever.

3. An engineer boyfriend will never betray your trust.

Let me first tell you what is wrong with the rest of the others – the lawyers will lie about everything, management graduates will cheat your money, the arts graduate will flirt, and you probably just look like another cadaver to the medical school graduate. Your engineer boyfriend is either too busy to have an affair, and even if he does, he is too dumb to lie to you about that. Hence, an engineer is the most secure boyfriend that you will ever find – rich enough, will keep on trying to understand and please you, has no time for affairs, and too dumb to lie to you.

Conclusion: Engineerz rule !

Performance Counters in .NET

Everything about Win32 performance counters were a pain for the Win32 developer. The good news is that .NET provides managed classes that make reading and providing data for performance counters straightforward and easy. In this article, I will outline the basic architecture of performance counters and describe how .NET provides its implementation.

A performance counter is any statistical measure, such as a running count, a rate of change over time, or some other rate that you determine. The process generating the performance counters provides the raw data (instantaneous values, or if it is a custom rate, the value and the divisor), and this data is read by the performance monitor, which displays the appropriate data. The .NET process that generates the data and the performance monitor (housed in MMC) that displays it are two different processes, so this means that there must be some interprocess communication between them. In fact, it goes one step further because if you have an administrator account for another machine, you can get performance counters from that machine. In this case, the WinLogon process gathers the performance counters and communicates this to the performance monitor on your machine via RPC.

COM would have been an ideal way to implement the interprocess and data gathering mechanisms, but performance counters predate COM by several years. Instead, the Windows designers simply gave up and pushed the responsibility of the IPC to the developer. Performance counter collection works like this: A process indicates that it can generate counters by adding a value in the system registry and part of this registration includes the name of a DLL. This DLL must export functions that are used to start and stop the performance counting, and a function that is called to collect the data. The names of these functions are registered so that the performance monitor knows what function to call. A process provides one or more counters and each of these will have a unique ID, so during registration, the process must reserve the IDs that it will use.

When a user indicates to a performance monitor that they want to gather performance counters from a process, the DLL that the process registered will be loaded into the performance monitor (or WinLogon.exe, in the remote case) and the Open function will be called to initialize the DLL. Then the performance monitor will call your DLL’s Collect to get the value of one, or more, counters by passing a string containing the IDs of those counters. Thus, the DLL’s Collect function will use the chosen IPC to get the values of the counters and package the values in the (rather arcane) format required by the performance monitor. (In actual fact, performance data is read by reading a special registry key called HKEY_PERFORMANCE_DATA, but lets ignore that detail here.)

.NET allows you to provide performance data through two unmanaged DLLs and several managed classes. Lets keep the managed API details for some other time. Concentrating on the performance, when you create a .NET performance counter through the managed API, the class will add a registry entry in the following key:

HKLMSystemCurrentControlSetServices

The .NET process does not have to be an NT service; however, the performance counter API mandates that the entry is in this key. The managed API requires that each counter is a member of a “category” and it is the name of this category that is used for the name of the key under the Services key. This key registers the netfxperf.dll DLL for the library for all .NET performance counter categories. This DLL is unmanaged and is one of the few .NET DLLs that is located in the %systemroot%System32 folder. This is a shim DLL that locates and loads another unmanaged library called perfcounter.dll, which is in the .NET framework folder. (The shim ensures that the right version of this library is loaded in the situation when you have multiple side-by-side versions of the framework.)

The source of this file is not available (its one of the files omitted from the Shared Source CLI); however, looking through the System.Diagnostics namespace with ILDASM shows a class called PerformanceCounterManager, which implements an interface called ICollectData. This class (and an associated class called SharedPerformanceCounter) creates a file-mapped object called netfxcustomperfcounters.1.0. The ICollectData.CollectData method obtains performance data through this memory-mapped file using SharedPerformanceCounter. The SharedPerformanceCounter class is also used by the PerformanceCounter managed class that user code uses to write performance data to a counter. This class provides the “client” and “server” code to share data between two processes.

Clearly, PerformanceCounterManager is used to read performance counters from managed code and since it used the memory mapped file object—an interprocess communications mechanisms—this class looks like the sort of code that a performance monitor library would use. However, the perfcounter.dll library is unmanaged, which raises the question of how it gets access to PerformanceCounterManager. My guess is that perfcounter.dll calls ICollectData.CollectData through a .NET COM callable wrapper. This guess is further backed up by the fact that the only public member of this class is the constructor, but the class has a GUID and implements a COM interface with a GUID that, when coupled together, will provide access to the interface methods through COM.