Architecture
Inside Microsoft Windows Source Code – Windows Research Kernel
May 3rd
The Windows Research Kernel v1.2 contains the sources for the core of the Windows (NTOS) kernel and a build environment for a kernel that will run on
x86 (Windows Server 2003 Service Pack 1) and
AMD64 (Windows XP x64 Professional)
The NTOS kernel implements the basic OS functions for processes, threads, virtual memory and cache managers, I/O management, the registry, executive functions such as the kernel heap and synchronization, the object manager, the local procedure call mechanism, the security reference monitor, low-level CPU management (thread scheduling, Asynchronous and Deferred Procedure calls, interrupt/trap handling, exceptions), etc.
WRK v1.2 includes most of the NTOS kernel sources from the latest released version of Windows, which supports the AMD64 architecture on the Desktop. The kernel sources excluded from the kit are primarily in the areas of plug-and-play, power management, the device verifier, kernel debugger interface, and virtual dos machine. The primary modifications to WRK from the released kernel are related to cleanup and removal of server support, such as code related to the Intel IA64.
The public\ directory contains a number of include files shared among system components. base\ntos\ contains the NTOS sources.
The primary NTOS source components included in the WRK are organized as follows:
cache\ – cache manager
config\ – registry implementation
dbgk\ – user-mode debugger support
ex\ – executive functions (kernel heap, synchronization, time)
fsrtl\ – file system run-time support
io\ – I/O manager
ke\ – scheduler, CPU management, low-level synchronization
lpc\ – local procedure call implementation
mm\ – virtual memory manager
ob\ – kernel object manager
ps\ – process/thread support
se\ – security functions
wmi\ – Windows Management Instrumentation
inc\ – NTOS-only include files
rtl\ – kernel run-time support
init\ – kernel startup
MVP Nomination: One more year as MVP Visual C# !!!
Apr 2nd
I got an email yesterday from Microsoft containing the info that I am awarded Microsoft MVP Visual C# again for 2012. I am very happy and honored for being selected again and proud to call myself MVP for one additional year !!!
I want to take some time and thank my MVP Lead for having me nominated.
Also a big thank you to Microsoft for putting their trust in me. I will do my best and continue sharing my knowledge with the community. So be prepared for many new blog posts and articles in the technical press on Software Architecture & Design, Visual C# and Windows Azure, which are my main interests. I will also continue concentrating on speaking at conferences so I would be glad to see you at any Microsoft events (TechDays, MS Days, etc…).
Stay tuned and continue following me if you like this Blog !
Certifications: Now TOGAF9 certified !
Nov 3rd
Just to let you know that I passed the two TOGAF9 exams lately (Foundation & Certified) during the combined OG0-093 exam.
I am happy to announce that I am now TOGAF9 certified !
For more information concerning the TOGAF9 Framework please consult the official website of The Open Group : http://www.opengroup.org/togaf/.
Common Design Patterns in C# 4.0 Part8: Bridge Pattern
Jul 18th
Pattern Name:
Bridge Pattern
Short Description:
Separate implementation and object interfaces
Usage:
Sometimes used, useful to decouple an abstraction from its implementation and to be able to modify them independently.
Note that the Bridge pattern has nearly the same structure as the Adapter Pattern. But it is used when designing new systems instead of the Adapter pattern which is used in already existing systems.
Complexity:
1 / 5
UML Class Diagram:
Explanation:
- The abstract Repository class defines the interface that all inheriting refined Repository classes will use for object management purposes.
- Note that the operations within the Repository classes define high-level operations.
- The refined Repositories extend the basic functionalities and implement the execution code that uses the implementation classes. They should contain specializations which only apply to specific Repositories.
- The abstract DataObject class defines the interfaces of the implementation classes. Note that the abstract Repository and the abstract DataObject classes can have completely different interfaces.
- The concrete DataObject implementations contain the code that executes all the low-level operations.
- Note that the methods within the Repository class could also call multiple methods in the implementation classes (1 to * relationship).
- In the last step we add some code to test the software design and the Bridge implementation.
- When running the example you can see that everything is working as expected and that the correct classes are instantiated during runtime.
Source Code:
Common Design Patterns in C# 4.0 Part7: Adapter Pattern
Jul 1st
Pattern Name:
Adapter Pattern
Short Description:
Match interfaces of classes with different interfaces
Usage:
Often used and easy to implement, useful if classes need to work together that have incompatible existing interfaces.
Complexity:
1 / 5
UML Class Diagram:
Common Design Patterns in C# 4.0 Part5: Prototype Pattern
May 7th
Pattern Name:
Prototype Pattern
Short Description:
Clone or copy initialized instances
Usage:
Easy pattern, usage depends on the preferred software design, provides an alternative to the other creational patterns that are mainly based on external classes for creation
Complexity:
1 / 5
UML Class Diagram:
Explanation:
- The abstract prototype class defines the interface that contains a clone method for cloning itself.
- The inherited classes implement the clone function. Note that C# provides two different ways of cloning an object: by shallow copy (only top level objects) or by deep copy (all objects).
- You could also manually create a new object and set its values with the values of the original object but since C# already implements everything necessary I advise using that.
- The client class does not create new objects itself. Instead it asks the objects to clone themselves when needed. The cloned objects are perfect copies and contain all values of the original objects depending on the shallow or deep copy approach (see above).
- You may also use the ICloneable interface that already exists in C#
- In the last step we add some code to test the software design and the Prototype implementation.
- When running the example you can see that everything is working as expected and that the correct classes are instantiated during runtime.
Source Code:
http://csharpdesignpatterns.codeplex.com/
Common Design Patterns in C# 4.0 Part4: Factory Method Pattern
May 6th
Pattern Name:
Factory Method
Short Description:
Create instances of derived classes
Usage:
Frequently used, fairly easy to implement and useful for centralizing object lifetime management and avoiding object creation code duplication
Complexity:
1 / 5
UML Class Diagram:
Explanation:
- The abstract creator implements a factory method that returns an objects. It also contains a method for testing purposes that serves to validate the design.
- Each concrete creator overrides the abstract factory method and returns a specific object concerning on the context.
- In this example the factory method is used internally to set a property but it could also be used in an external context for creating objects when needed.
- The abstract class defines the interface and class structure for all objects that get build by the specific concrete creators via their factory methods.
- There is also the possibility to create a C# specific solution that uses generics which also results in a valid factory method.
- In the last step we add some code to test the software design and the Factory Method implementation in the language agnostic and in the C# specific versions.
- When running the example you can see that everything is working as expected and that the correct classes are instantiated during runtime.
Source Code:
http://csharpdesignpatterns.codeplex.com/
Common Design Patterns in C# 4.0 Part3: Builder Pattern
May 5th
Pattern Name:
Builder Pattern
Short Description:
Separate representation and object construction
Usage:
Rarely used, only useful if complex objects consisting of multiple parts need to be constructed (composite objects for example)
Complexity:
1 / 5
UML Class Diagram:
Explanation:
- The director (ComputerShop) implements a method that is responsible for the sequence of steps of an object creation process. It takes an abstract builder class as input parameter and delegates the real creation to it.
- The abstract builder class defines the interface that all inheriting concrete builders will use for object creation.
- The concrete builder implementations contain the parts that are assembled and that build the objects.
- The final object contains all different parts that get assembled by the concrete builder classes. Those may differ from each other depending on the implementations.
- A method was added that prints out the characteristics of the different parts to be able to validate the design.
- In the last step we add some code to test the software design and the Builder implementation.
- When running the example you can see that everything is working as expected and that the correct classes are instantiated during runtime.
Source Code:
http://csharpdesignpatterns.codeplex.com/
Common Design Patterns in C# 4.0 Part2: Abstract Factory Pattern
May 1st
Pattern Name:
Abstract Factory Pattern
Short Description:
Create instances of classes belonging to different families
Usage:
Very frequently used and very useful
Complexity:
1 / 5
UML Class Diagram:
Explanation:
- The abstract factory class defines the abstract methods that have to be implemented by concrete factory classes. It serves as interface and contract definition.
- The concrete factory classes contain the real implementation that define which classes are created during run-time.
- Note that the methods return values are also defined by abstract classes, this allows a high flexibility and independence, leading to methods that must only be implemented once.
- The returned classes are however specific to each concrete factory class (you will see their implementation below).
- Here you see the abstract classes that are used during the creation process (a method was added that serves to prove the validity of the design).
- Based on the abstract classes some real example implementation are created, those will be instantiated during run-time, depending on the concrete factory that creates them.
- When implementing the associations between the Driver class, the abstract factory class and the abstract classes you may either use the common language agnostic approach using only private members (which is the most memory efficient one).
- Or you may use the C# language specific approach where everything is wrapped using private properties. This allows adding logic when accessing or changing the private members but might be a little overkill (this is also what gets auto-generated when modeling using the class diagram).
- You may also use another C# language specific solution that uses generic classes to create objects and that is also a valid implementation for the abstract factory pattern.
- In the last step we add some code to test the software design and the Abstract Factory implementation.
![image_thumb[2]](http://www.dotnetrangers.net/wp-content/uploads/2011/05/image_thumb24.png "image_thumb[2]")
- When running the example you can see that everything is working as expected and that the correct classes are instantiated during runtime.
![image_thumb[4]](http://www.dotnetrangers.net/wp-content/uploads/2011/05/image_thumb41.png "image_thumb[4]")
Source Code:
http://csharpdesignpatterns.codeplex.com/
Common Design Patterns in C# 4.0 Part1: Introduction Gang of Four Design Patterns
Apr 28th
Design Patterns provide standardized and efficient solutions to software design and programming problems that are re-usable in your code. Software Architects and developers use them to build high quality robust applications.
However, you have to take care to select the right pattern for the right problem. If you need to modify the initial pattern too much, this may indicate that it is not adapted to your needs and may in the worst case lead to unmaintainable, complex and inefficient code. The opposite of what you intend when using Design Patterns !!
You may also create your own custom Design Patterns. Whenever you come up with a certain solution that is reusable in a vast majority of your projects, you may decide to abstract a design pattern out of it. Then you may create your own library of patterns and share them within your whole company, thus creating standards and ameliorating maintainability.
In this series of blog posts I am going to show you how to use the well known Gang of Four (GoF) Design Patterns in C# 4.0 code. Those patterns will work well in any project that uses C# but especially in WPF, WCF, WinForms, ASP.NET projects.
The GoF Design Patterns are divided into 3 categories : Creational Patterns, Structural Patterns and Behavioral Patterns. In my following blog posts I am going to explain each GoF Design Pattern in detail and will show you examples of how to write good C# 4.0 code that implement those patterns.
Creational Patterns
- Abstract Factory: Create instances of classes belonging to different families
- Builder: Separate representation and object construction
- Factory Method: Create instances of derived classes
- Prototype: Clone or copy initialized instances
- Singleton: Class with only one single possible instance
Structural Patterns
- Adapter: Match interfaces of classes with different interfaces
- Bridge: Separate implementation and object interfaces
- Composite: Simple and composite objects tree
- Decorator: Dynamically add responsibilities to objects
- Facade: Class that represents subclasses and subsystems
- Flyweight: Minimize memory usage by sharing as much data as possible with similar objects
- Proxy: Object that represents another object
Behavioral Patterns
- Chain of Responsibility: Pass requests between command and processing objects within a chain of objects
- Command: Encapsulate a method call as an object containing all necessary information
- Interpreter: Include language elements and evaluate sentences in a given language
- Iterator: Give sequential access to elements in a collection
- Mediator: Encapsulates and simplifies communication between objects
- Memento: Undo modifications and restore an object to its initial state
- Observer: Notify dependent objects of state changes
- State:Change object behavior depending on its state
- Strategy: Encapsulate algorithms within a class and make them interchangeable
- Template Method: Define an algorithm skeleton and delegate algorithm steps to subclasses so that they may be overridden
- Visitor: Add new operations to classes without modifying them
There are also many other types of pattern such as: Parallel Patterns, SOA Patterns, Enterprise Architecture Patterns, etc… So if you work in the respective area don’t hesitate to look up patterns that may help you to be more efficient and build better applications.