How to develop your own Boot Loader

Leave a comment


Table of content

1. Who may be interested
2. What is Boot Loader
3. Be ready to go deeper
3.1. So what language you should know to develop Boot Loader
3.2. What compiler you need
3.3. How system boots
4. Let’s code
4.1 Program architecture
4.2 Development environment
4.3 BIOS interrupts and screen clearing
4.4 «Mixed code»
4.5 CString implementation
4.6 CDisplay implementation
4.7 Types.h implementation
4.8 BootMain.cpp implementation
4.9 StartPoint.asm implementation
5. Let’s assemble everything
5.1 Creation of COM file
5.2 Assembly automation
6. Testing and Demonstration
6.1 How to test boot loader.
6.2 Testing with the virtual machine VmWare
6.2.1 Creation of the virtual machine
6.2.2 Working with Disk Explorer for NTFS
6.3 Testing on the real hardware
6.4 Debug
7. Information Sources
8. Conclusion

Who may be interested

Most of all I’ve written this article for those who have been always interested in the way the different things work. It is for those developers who usually create their applications in high-level languages such as C, C++ or Java, but faced with the necessity to develop something at low-level. We will consider low-level programming on the example of working at system loading.

We will describe what is going after you turn on a computer; how the system is loading. As the practical example we will consider how you can develop your own boot loader which is actually the first point of the system booting process.

What is Boot Loader

Boot loader is a program situated at the first sector of the hard drive; and it is the sector where the boot starts from. BIOS automatically reads all content of the first sector to the memory just after the power is turned on, and jump to it. The first sector is also called Master Boot Record. Actually it is not obligatory for the first sector of the hard drive to boot something. This name has been formed historically because developers used to boot their operating systems with such mechanism.

Be ready to go deeper

In this section I will tell about knowledge and tools you need to develop your own boot loader and also remind some useful information about system boot.

So what language you should know to develop Boot Loader

On the first stage on the computer work the control of hardware is performed mainly by means of BIOS functions known as interrupts. The implementation of interrupts is given only in Assembler – so it is great if you know it at least a little bit. But it’s not the necessary condition. Why? We will use the technology of “mixed code” where it is possible to combine high-level constructions with low-level commands. It makes our task a little simpler.

In this article the main development languages is C++. But if you have brilliant knowledge of C then it will be easy to learn required C++ elements. In general even the C knowledge will be enough but then you will have to modify the source code of the examples that I will descried here.

If you know Java or C# well unfortunately it won’t help for our task. The matter is that the code of Java and C# languages that is produced after compilation is intermediate. The special virtual machine is used to process it (Java Machine for Java, and .NET for C#) which transform intermediate code into processor instructions. After that transformation it can be executed. Such architecture makes it impossible to use mixed code technology – and we are going to use it to make our life easier, so Java and C# don’t work here.

So to develop the simple boot loader you need to know C or C++ and also it would be good if you know something about Assembler – language into which all high-level code is transformed it the end.

What compiler you need

To use mixed code technology you need at least two compilers: for Assembler and C/C++, and also the linker to join object files (.obj) into the one executable.

Now let’s talk about some special moments. There are two modes of processor functioning: real mode and protected mode. Real mode is 16-bit and has some limitations. Protected mode is 32-bit and is fully used in OS work. When it starts processor works in 16-bit mode. So to build the program and obtain executable file you will need the compiler and linker of Assembler for 16-bit mode. For C/C++ you will need only the compiler that can create object files for 16-bit mode.

The modern compilers are made for 32-bit applications only so we won’t able to use them.

I tried a number of free and commercial compilers for 16-bit mode and choose Microsoft product. Compiler along with the linker for Assembler, C, C++ are included into the Microsoft Visual Studio 1.52 package and also can be downloaded from the official site of the company. Some details about compilers we need are given below.

ML 6.15 – Assembler compiler by Microsoft for 16-bit mode;

LINK 5.16 – the linker that can create .com files for 16-bit mode;

CL – С, С++ compiler for 16-bit mode.

You can also use some alternative variants:

DMC – free compile for Assembler, C, C++ for 16 and 32-bit mode by Digital Mars;

LINK – free linker for DMC compiler;

There are also some products by Borland:

BCC 3.5 – С, С++ compiler that can create files for 16-bit mode;

TASM – Assembler compiler for 16-bit mode;

TLINK – linker that can create .com files for 16-bit mode.

All code examples in this article were built with the Microsoft tools.

How system boots

In order to solve our task we should recall how the system is booting.

Let’s consider briefly how the system components are interacting when the system is booting (see Fig.1).


Fig.1 – “How it boots”
After the control has been passed to the address 0000:7C00, Master Boot Record (MBR) starts its work and triggers the Operating System boot. You can learn more about MBR structure for example here.

Let’s code

In the next sections we will be directly occupied with the low-level programming – we will develop our own boot loader.

Program architecture

Boot loader that we are developing is for the training only. Its tasks are just the following:

  1. Correct loading to the memory by 0000:7C00 address.
  2. Calling the BootMain function that is developed in the high-level language.
  3. Show “”Hello, world…”, from low-level” message on the display.

Program architecture is described on the Fig.2 that is followed by the text description.


Fig.2. – Program architecture description
The first entity is StartPoint that is developed purely in Assembler as far as high-level languages don’t have the necessary instructions. It tells compiler what memory model should be used, and what address the loading to the RAM should be performed by after the reading from the disk. It also corrects processor registers and passes control to the BootMain that is written in high-level language.

Next entity– BootMain – is an analogue of main that is in its turn the main function where all program functioning is concentrated.

CDisplay and CString classes take care of functional part of the program and show message on the screen. As you can see from the Fig.2 CDisplay class uses CStringclass in its work.

Development environment

Here I use the standard development environment Microsoft Visual Studio 2005 or 2008. You can use any other tools but I made sure that these two with some settings made the compiling and work easy and handy.

First we should create the project of Makefile Project type where the main work will be performed (see Fig.3).

File->New\Project->General\Makefile Project


Fig.3 – Create the project of Makefile type

BIOS interrupts and screen clearing

To show our message on the screen we should clear it first. We will use special BIOS interrupt for this purpose.

BIOS proposes a number of interrupts for the work with computer hardware such as video adapter, keyboard, disk system. Each interrupt has the following structure:

int [number_of_interrupt];

where number_of_interrupt is the number of interrupt

Each interrupt has the certain number of parameters that should be set before calling it. The ah processor register is always responsible for the number of function for the current interrupt, and the other registers are usually used for the other parameters of the current operation. Let’s see how the work of int 10h interrupt is performed in Assembler. We will use the 00 function that changes the video mode and clears screen:

mov al, 02h ; setting  the graphical mode 80x25(text)
mov ah, 00h ; code  of function of changing video mode
int 10h   ; call  interruption

We will consider only those interrupts and functions that will be used in our application. We will need:

int 10h, function 00h – performs changing of video mode and clears  screen;
int 10h, function 01hsets the cursor type;
int 10h, function 13h – shows the string on the screen;

«Mixed code»

Compiler for C++ supports the inbuilt Assembler i.e. when writing code in igh-level language you can use also low level language. Assembler Instructions that are used in the high level code are also called asm insertions. They consist of the key word __asm and the block of the Assembler instructions in braces:

__asm ;  key word that shows the beginning of the asm insertion
  { ;  block beginning
; some asm code
  } ;  end of the block

To demonstrate mixed code let’s use the previously mentioned Assembler code that performed the screen clearing and combine it with C++ code.

void ClearScreen()
 mov al, 02h ; setting the graphical mode 80x25(text)
mov ah, 00h ; code  of function of changing video mode
int 10h   ; call interrupt

CString implementation

CString class is designed to work with strings. It includes Strlen() method that obtains pointer to the string as the parameter and returns the number of symbols in that string.

// CString.h 

#ifndef __CSTRING__
#define __CSTRING__

#include "Types.h"

class CString 
    static byte Strlen(
        const char far* inStrSource 

#endif // __CSTRING__

// CString.cpp

#include "CString.h"

byte CString::Strlen(
        const char far* inStrSource 
        byte lenghtOfString = 0;
        while(*inStrSource++ != '\0')
        return lenghtOfString;

CDisplay implementation

CDisplay class is designed for the work with the screen. It includes several methods:

1) TextOut() – it prints the string on the screen.
2) ShowCursor() – it manages the cursor representation on the screen: show, hide.
3) ClearScreen() – it changes the video mode and thus clears screen.

  // CDisplay.h

#ifndef __CDISPLAY__
#define __CDISPLAY__

// colors for TextOut func

#define BLACK			0x0
#define BLUE			0x1
#define GREEN			0x2
#define CYAN			0x3
#define RED				0x4
#define MAGENTA			0x5
#define BROWN			0x6
#define GREY			0x7
#define DARK_GREY			0x8
#define LIGHT_BLUE		0x9
#define LIGHT_GREEN		0xA
#define LIGHT_CYAN		0xB
#define LIGHT_RED		      0xC
#define LIGHT_MAGENTA   	0xD
#define LIGHT_BROWN		0xE
#define WHITE			0xF

#include "Types.h"
#include "CString.h"

class CDisplay
    static void ClearScreen();

    static void TextOut(
        const char far* inStrSource,
        byte            inX = 0,
        byte            inY = 0,
        byte            inBackgroundColor   = BLACK,
        byte            inTextColor         = WHITE,
        bool            inUpdateCursor      = false

    static void ShowCursor(
        bool inMode

#endif // __CDISPLAY__

// CDisplay.cpp

#include "CDisplay.h"

void CDisplay::TextOut( 
        const char far* inStrSource, 
        byte            inX, 
        byte            inY,  
        byte            inBackgroundColor, 
        byte            inTextColor,
        bool            inUpdateCursor
    byte textAttribute = ((inTextColor) | (inBackgroundColor << 4));
    byte lengthOfString = CString::Strlen(inStrSource);

        push	bp
        mov		al, inUpdateCursor
        xor		bh, bh	
        mov		bl, textAttribute
        xor		cx, cx
        mov		cl, lengthOfString
        mov		dh, inY
        mov		dl, inX  
        mov     es, word ptr[inStrSource + 2]
        mov     bp, word ptr[inStrSource]
        mov		ah,	13h
        int		10h
        pop		bp
void CDisplay::ClearScreen()
        mov     al, 02h
        mov     ah, 00h
        int     10h

void CDisplay::ShowCursor(
        bool inMode
    byte flag = inMode ? 0 : 0x32;

        mov     ch, flag
        mov     cl, 0Ah
        mov     ah, 01h
        int     10h

Types.h implementation

Types.h is the header file that includes definitions of the data types and macros.

 // Types.h

#ifndef __TYPES__
#define __TYPES__     

typedef unsigned char   byte;
typedef unsigned short  word;
typedef unsigned long   dword;
typedef char            bool;

#define true            0x1
#define false           0x0

#endif // __TYPES__

BootMain.cpp implementation

BootMain() is the main function of the program that is the first entry point (analogue of main()). Main work is performed here.

// BootMain.cpp

#include "CDisplay.h"

#define HELLO_STR               "\"Hello, world…\", from low-level..."

extern "C" void BootMain()



StartPoint.asm implementation

.286							   ; CPU type
.model TINY						   ; memory of model
;---------------------- EXTERNS -----------------------------
extrn				_BootMain:near	   ; prototype of C func
org				07c00h		   ; for BootSector
				jmp short start	   ; go to main
;----------------------- CODE SEGMENT -----------------------
        mov ax,cs               ; Setup segment registers
        mov ds,ax               ; Make DS correct
        mov es,ax               ; Make ES correct
        mov ss,ax               ; Make SS correct        
        mov bp,7c00h
        mov sp,7c00h            ; Setup a stack
                                ; start the program 
        call           _BootMain
        END main                ; End of program

Let’s assemble everything

Creation of COM file

Now when the code is developed we need to transform it to the file for the 16-bit OS. Such files are .com files. We can start each of compilers (for Assembler and C, C++) from the command line, transmit necessary parameters to them and obtain several object files as the result. Next we start linker to transform all .obj files to the one executable file with .com extension. It is working way but it’s not very easy.

Let’s automate the process. In order to do it we create .bat file and put commands with necessary parameters there. Fig.4 represents the full process of application assembling.

Fig.4 – Process of program compilation
Let’s put compilers and linker to the project directory. In the same directory we create .bat file and fill it accordingly to the example (you can use any directory name instead of VC152 where compilers and linker are situated):

.\VC152\CL.EXE /AT /G2 /Gs /Gx /c /Zl *.cpp
.\VC152\ML.EXE /AT /c *.asm

.\VC152\LINK.EXE /T /NOD StartPoint.obj bootmain.obj cdisplay.obj cstring.obj

del *.obj

Assembly automation

As the final stage in this section we will describe the way how to turn Microsoft Visual Studio 2005, 2008 into the development environment with any compiler support. Go to the Project Properties: Project->Properties->Configuration Properties\General->Configuration Type.

Configuration Properties tab includes three items: General, Debugging, NMake. Go to NMake and set the path to the build.bat in the Build Command Line and Rebuild Command Line fields – Fig.5.
Fig.5 –NMake project settings

If everything is correct then you can compile in the common way pressing F7 or Ctrl + F7. At that all attendant information will be shown in the Output window. The main advantage here is not only the assembly automation but also navigation thru the code errors if they happen.

Testing and Demonstration

This section will tell how to see the created boot loader in action, perform testing and debug.

How to test boot loader

You can test boot loader on the real hardware or using specially designed for such purposes virtual machine – VmWare. Testing on the real hardware gives you more confidence that it works while testing on the virtual machine makes you confident that it just can work. Surely we can say that VmWare is great method for testing and debug. We will consider both methods.

First of all we need a tool to write our boot loader to the virtual or physical disk. As far as I know there a number of free and commercial, console and GUI applications. I used Disk Explorer for NTFS 3.66 (version for FAT that is named Disk Explorer for FAT) for work in Windows and Norton Disk Editor 2002 for work in MS-DOS.

I will describe only Disk Explorer for NTFS 3.66 because it is the simplest method and suits our purposes the most.

Testing with the virtual machine VmWare

Creation of the virtual machine

We will need VmWare program version 5.0, 6.0 or higher. To test boot loader we will create the new virtual machine with minimal disk size for example 1 Gb. We format it for NTFS file system. Now we need to map the formatted hard drive to VmWare as the virtual drive. To do it:

File->Map or Disconnect Virtual Disks…

After that the window appears. There you should click Map button. In the next appeared window you should set the path to the disk. Now you can also chose the letter for the disk- see Fig.6.
Fig.6 – Parameters of virtual disk mapping

Don’t forget to uncheck the “Open file in read-only mode (recommended)” checkbox. When checked it indicates that the disk should be opened in read-only mode and prevent all recording attempts to avoid data corruption.

After that we can work with the disk of virtual machine as with the usual Windows logical disk. Now we should use Disk Explorer for NTFS 3.66 and record boot loader by the physical offset 0.

Working with Disk Explorer for NTFS

After program starts we go to our disk (File->Drive). In the window appeared we go to the Logical Drivessection and chose disk with the specified letter (in my case it is Z) – see Fig.7.
Fig.7 – choosing disk in Disk Explorer for NTFS

Now we use menu item View and As Hex command. It the appeared window we can see the information on the disk represented in the 16-bit view, divided by sectors and offsets. There are only 0s as soon as the disk is empty at the moment. You can see the first sector on the Fig.8.

Fig.8 – Sector 1 of the disk

Now we should write our boot loader program to this first sector. We set the marker to position 00 as it is shown on the Fig.8. To copy boot loader we use Edit menu item, Paste from file command. In the opened window we specify the path to the file and click Open. After that the content of the first sector should change and look like it’s shown on the Fig.9 – if you haven’t changed anything in the example code, of course.

You should also write signature 55AAh by the 1FE offset from the sector beginning. If you don’t do it BIOS will check the last two bytes, won’t find the mentioned signature and will consider this sector as not the boot one and won’t read it to the memory.

To switch to the edit mode press F2 and write the necessary numbers –55AAh signature. To leave edit mode press Esc.

Now we need to confirm data writing.

Fig.9 – Boot Sector appearance
To apply writing we go to Tools->Options. Window will appear; we go to the Mode item and chose the method of writing – Virtual Write and click Write button – Fig.10.

Fig.10 – Choosing writing method in Disk Explorer for NTFS
A great number of routine actions are finished at last and now you can see what we have been developing from the very beginning of this article. Let’s return to the VwWare to disconnect the virtual disk (File->Map or Disconnect Virtual Disks… and click Disconnect).

Let’s execute the virtual machine. We can see now how from the some depth, from the kingdom of machine codes and electrics the familiar string appears ““Hello, world…”, from low-level…” – see Fig.11.

Fig.11 – “Hello world…”

Testing on the real hardware

Testing on the real hardware is almost the same as on the virtual machine except the fact that if something doesn’t work you will need much more time to repair it than to create the new virtual machine. To test boot loader without the threat of existent data corruption (everything can happen), I propose to use flash drive, but first you should reboot your PC, enter BIOS and check if it supports boot from the flash drive. If it does than everything is ok. If it does not than you have to limit your testing to virtual machine test only.

The writing of boot loader to the flash disk in Disk Explorer for NTFS 3.66 is the same to the process for virtual machine. You just should choose the hard drive itself instead of its logical section to perform writing by the correct offset – see Fig.12.

Fig.12 – Choosing physical disk as the device


If something went wrong – and it usually happens – you need some tools to debug your boot loader. I should say at once that it is very complicated, tiring and time-eating process. You will have to grasp in the Assembler machine codes – so good knowledge of this language is required. Any way I give a list of tools for this purpose:

TD (Turbo Debugger) – great debugger for 16-bit real mode by Borland.

CodeView – good debugger for 16-bit mode by Microsoft.

D86 – good debugger for 16-bit real mode developed by Eric Isaacson – honored veteran of development for Intel processor in Assembler.

Bocsh – program-emulator of virtual machine that includes debugger of machine commands.

Information Sources

Assembly Language for Intel-Based Computers” by Kip R. Irvine is the great book that gives good knowledge of inner structure of the computer and development in Assembler. You ca also find information about installation, configuration and work with the MASM 6.15 compiler.

This link will guide you to the BIOS interrupt list:


In this article we have considered what is boot loader, how BIOS works, and how system components interact when system boots. Practical part gave the information about how to develop your own simple boot loader. We demonstrated the mixed code technology and process of automation of assembly with Microsoft Visual Studio 2005, 2008.

Of course it is just a small piece comparing with the huge theme of low-level programming, but if you get interested of this article – it’s great.

See more case studies and research results at Apriorit site.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

How do you know you’re writing good code?

Leave a comment

The biggest clue for me is:

When you have to go back and add/modify a feature, is it difficult? Do you constantly break existing functionality when making changes?

If the answer to the above is “yes” then you probably have a poor overall design.

It is (for me at least) a bit difficult to judge a design until it is required to respond to change (within reason of course; some code is just bad and you can tell right away, but even that comes with experience.)

You know you are writing good code when:

  • Things are clever, but not too clever
  • Algorithms are optimal, both in speed as well as in readability
  • Classes, variables and functions are well named and make sense without having to think too much
  • You come back to it after a weekend off, and you can jump straight in
  • Things that will be reused are reusable
  • Unit tests are easy to write

The code quality test: Have another programmer who has never seen the code read it an explain what each module does to you while you look over their shoulder. The stronger your urge to jump in and explain something the worse the code likely is. If you can calmly sit there with your mouth shut and they don’t need to ask a lot of questions, you are probably good.

For your benefit, here are some general guidelines for when you don’t have a peer handy. They are not absolutes, just “smells”.

Good signs

  • Methods tend to be very short that ideally perform a single task.
  • You have enough information to call methods WITHOUT looking at the body of them.
  • Unit tests are easy to write.

Bad signs

  • Long methods made up of 2-3 sub-tasks that are not broken out into other methods.
  • Methods share data through some means other than their interface.
  • If you change the implementation of one method (but not the interface) you need to change the implementation of other methods.
  • Lots of comments, especially long winded comments.
  • You have code that never runs in your application to provide “future flexibility”
  • Large try/catch blocks
  • You are having a hard time coming up with good method names or they contain the words “OR” and “AND” (e.g. GetInvoiceOrCustomer)
  • Identical or nearly identical blocks of code.

Here is a longer list of code smells that should also be helpful.

For me personally, I think it’s when I forget about the code. In other words:

  • Bugs rarely occur
  • When they do occur, other people resolve them without asking me anything
  • Even more important, no one ever asks me anything regarding my code
  • People don’t have a high rate of WTF/min when reading it
  • A lot of new classes in the system start to use my class (high fan-in, as Steve McConnell would call it)
  • The code is easy to modify and/or refactor when/if needed, without cursing me (even if it’s me – cursing myself!)
  • I also love it when I guess just the right amount of abstraction which seems to suit everyone on the team

I have three golden rules:

  1. If I feel compelled to copy/paste blocks of code I’m doing something wrong
  2. If I can’t take the whole code in my head I’m doing something wrong
  3. If someone jumps in and gets lost in my code I’m doing something wrong

Those rules has guided me to do some real architectural improvements, ending up with small, clean and maintainable classes/methods.

Now, how do you know when you’re writing good code?

  • When your classes each serve a single, very clearly defined purpose, separated from other classes with other clearly defined purposes.
  • When your methods are short – ideally under 50 lines and certainly under 100 – and their names clearly define what they do exactly. A method should not do anything but what it’s name implies. If you’re going over 100 lines, or tabbed in very far, you can probably pull something out into it’s own function.
  • When your code provides one way to do something – when it does not provide the option to zig or zag, but instead provides a single linear path for each possible course of action the user may send it down.
  • When you’ve done everything you reasonably can to reduce coupling between classes; so that if Class A depends on Class B, and Class B is removed and Class C is put in it’s place, little to no changes have to be made to Class A. Class A should be as blind as possible to what’s going on in the outside world.
  • When your class, method, and variable names can be read and immediately understood by anyone that comes across the code – there’s no need for ‘pktSize’ when ‘packetSize’ reads much more easliy.

As others have said, essentially, if you’re doing Object-Oriented Programming, and when the time comes to change something you find it like trying to untangle and rewind a ball of yarn, the code isn’t following good Object-Oriented principles.

I highly recommend the book “Clean Code”, if you’re interested in digging a little further into this. It’s a good read for novices and experts alike.

This has been my experience since shifting from the college world of programming to the industry over the last five months:

  • Ease of use is so important that we pay people just to design user Interfaces. Coders often suck at UI design.
  • You find that that getting it to work isn’t enough
  • Optimizations become more critical in real-world scenarios.
  • There are a thousand ways to approach a problem. However, often times the approach does not account for slightly less well-known factors that could adversely affect the performance of your approach such as database authentication, transactions, file I/O, reflection, just to name a random few.
  • Maintainability is a very important aspect of coding. Just because your code is super optimized and super dense … doesn’t mean that it is sexy. Sometimes it is simply labeled as “Hero coding”.
  • Design skills are learned, not inherent. I’m sure there are a few brain children out there, but generally speaking, solid design with respect to real-world problems, is wrought through time, investigation, and most importantly, the imparting of knowledge from your superiors =P
  • Documentation is not an convenience, it is a necessity.
  • The same thing goes for unit testing (this varies from company to company admittedly)

I would suggest that you take an opportunity with an open source project. You will get a chance to see how much you really know if you work along side other programmers bottom line. An open source project is probably the best way to find out based on your background.


‘d say my main points would be:

  • Readability (for you and anyone else who has look into your code)
  • Maintainability (easy to modify)
  • Simplicity (not complicating things when there’s no need for that)
  • Efficiency (of course your code should execute fast)
  • Clarity (if your code is self-explanatory, there’s no need for comments most of the time, name your methods/properties etc. sensibly, break the long code down, never copy & paste a block of code)

I’m not putting Design in this list as I believe a good code can be written without sticking to a design pattern as long as it’s consistent within your project.

Good MSDN article on this topic: What Makes Good Code Good?

Agile Principles, Patterns, and Practices in C# by Robert C. Martin

Leave a comment


| Index
With the award-winning book Agile Software Development: Principles, Patterns, and Practices,
Robert C. Martin helped bring Agile principles to tens of thousands of Java and C++ programmers.
Now .NET programmers have a definitive guide to agile methods with this completely updated
volume from Robert C. Martin and Micah Martin, Agile Principles, Patterns, and Practices in
This book presents a series of case studies illustrating the fundamentals of Agile development and
Agile design, and moves quickly from UML models to real C# code. The introductory chapters lay
out the basics of the agile movement, while the later chapters show proven techniques in action.
The book includes many source code examples that are also available for download from the
authors’ Web site.
Readers will come away from this book understanding
Agile principles, and the fourteen practices of Extreme Programming
Spiking, splitting, velocity, and planning iterations and releases
Test-driven development, test-first design, and acceptance testing
Refactoring with unit testing
Pair programming
Agile design and design smells
The five types of UML diagrams and how to use them effectively
Object-oriented package design and design patterns
How to put all of it together for a real-world project
Whether you are a C# programmer or a Visual Basic or Java programmer learning C#, a software
development manager, or a business analyst, Agile Principles, Patterns, and Practices in C# is
the first book you should read to understand agile software and how it applies to programming in
Agile Principles, Patterns, and Practices in C#
By Martin C. Robert, Martin Micah
Publisher: Prentice Hall
Pub Date: July 20, 2006
Print ISBN-10: 0-13-185725-8
Print ISBN-13: 978-0-13-185725-4
Pages: 768
Table of Contents | Index
With the award-winning book Agile Software Development: Principles, Patterns, and Practices,
Robert C. Martin helped bring Agile principles to tens of thousands of Java and C++ programmers.
Now .NET programmers have a definitive guide to agile methods with this completely updated
volume from Robert C. Martin and Micah Martin, Agile Principles, Patterns, and Practices in

This book presents a series of case studies illustrating the fundamentals of Agile development and
Agile design, and moves quickly from UML models to real C# code. The introductory chapters lay
out the basics of the agile movement, while the later chapters show proven techniques in action.
The book includes many source code examples that are also available for download from the
authors’ Web site.

Readers will come away from this book understanding
Agile principles, and the fourteen practices of Extreme Programming
Spiking, splitting, velocity, and planning iterations and releases
Test-driven development, test-first design, and acceptance testing
Refactoring with unit testing
Pair programming
Agile design and design smells
The five types of UML diagrams and how to use them effectively
Object-oriented package design and design patterns
How to put all of it together for a real-world project

Whether you are a C# programmer or a Visual Basic or Java programmer learning C#, a software
development manager, or a business analyst, Agile Principles, Patterns, and Practices in C# is
the first book you should read to understand agile software and how it applies to programming in
the .NET Framework.

Agile Principles, Patterns, and Practices in C#
By Martin C. Robert, Martin Micah
Publisher: Prentice Hall
Pub Date: July 20, 2006
Print ISBN-10: 0-13-185725-8
Print ISBN-13: 978-0-13-185725-4
Pages: 768
Table of Contents | Index
Robert C. Martin Series
About the Authors

Section I. Agile Development

Chapter 1. Agile Practices
The Agile Alliance

Chapter 2. Overview of Extreme Programming
The Practices of Extreme Programming

Chapter 3. Planning
Initial Exploration
Release Planning
Iteration Planning
Defining “Done”
Task Planning

Chapter 4. Testing
Test-Driven Development
Acceptance Tests
Serendipitous Architecture
Chapter 5. Refactoring
A Simple Example of Refactoring: Generating Primes

Chapter 6. A Programming Episode
The Bowling Game
Overview of the Rules of Bowling
Section II. Agile Design

Chapter 7. What Is Agile Design?
Design Smells
Why Software Rots
The Copy Program

Chapter 8. The Single-Responsibility Principle (SRP)
Defining a Responsibility
Separating Coupled Responsibilities

Chapter 9. The Open/Closed Principle (OCP)
Description of OCP
The Shape Application

Chapter 10. The Liskov Substitution Principle (LSP)
Violations of LSP
Factoring Instead of Deriving
Heuristics and Conventions

Chapter 11. The Dependency-Inversion Principle (DIP)
A Simple DIP Example
The Furnace Example

Chapter 12. The Interface Segregation Principle (ISP)
Interface Pollution
Separate Clients Mean Separate Interfaces
Class Interfaces versus Object Interfaces
The ATM User Interface Example

Chapter 13. Overview of UML for C# Programmers
Class Diagrams
Object Diagrams
Collaboration Diagrams
State Diagrams

Chapter 14. Working with Diagrams
Why Model?
Making Effective Use of UML
Iterative Refinement
When and How to Draw Diagrams

Chapter 15. State Diagrams
The Basics
Using FSM Diagrams
Chapter 16. Object Diagrams
A Snapshot in Time
Active Objects

Chapter 17. Use Cases
Writing Use Cases
Diagramming Use Cases

Chapter 18. Sequence Diagrams
The Basics
Advanced Concepts

Chapter 19. Class Diagrams
The Basics
An Example Class Diagram
The Details

Chapter 20. Heuristics and Coffee
The Mark IV Special Coffee Maker
Section III. The Payroll Case Study

Chapter 21. COMMAND and ACTIVE OBJECT: Versatility and Multitasking
Simple Commands
Undo Method
Active Object

Chapter 22. TEMPLATE METHOD and STRATEGY: Inheritance versus Delegation
Template Method

Chapter 23. Facade and Mediator
Chapter 24. Singleton and Monostate
Chapter 25. Null Object

Chapter 26. The Payroll Case Study: Iteration 1
Rudimentary Specification
Analysis by Use Cases
Reflection: Finding the Underlying Abstractions

Chapter 27. The Payroll Case Study: Implementation
Main Program
The Database
About This Chapter

Section IV. Packaging the Payroll System

Chapter 28. Principles of Package and Component Design
Packages and Components
Principles of Component Cohesion: Granularity
Principles of Component Coupling: Stability

Chapter 29. Factory
A Dependency Problem
Static versus Dynamic Typing
Substitutable Factories
Using Factories for Test Fixtures
Importance of Factories

Chapter 30. The Payroll Case Study: Package Analysis
Component Structure and Notation
Applying the Common Closure Principle (CCP)
Applying the Reuse/Release Equivalence Principle (REP)
Coupling and Encapsulation
Applying the Metrics to the Payroll Application
The Final Packaging Structure

Chapter 31. Composite
Composite Commands
Multiplicity or No Multiplicity

Chapter 32. Observer: Evolving into a Pattern
The Digital Clock
The OBSERVER Pattern
Chapter 33. Abstract Server, Adapter, and Bridge
Abstract Server

Chapter 34. PROXY and GATEWAY: Managing Third-Party APIs
Databases, Middleware, and Other Third-Party Interfaces
Table Data Gateway
Using Other Patterns with Databases

Chapter 35. Visitor
Acyclic Visitor
Extension Object

Chapter 36. State
Nested Switch/Case Statements
Transition Tables
The State Pattern
Classes of State Machine Application

Chapter 37. The Payroll Case Study: The Database
Building the Database
A Flaw in the Code Design
Adding an Employee
Loading an Employee
What Remains?

Chapter 38. The Payroll User Interface: MODEL VIEW PRESENTER
The Interface
Building a Window
The Payroll Window
The Unveiling

Appendix A. A Satire of Two Companies
Appendix B. What Is Software?
Manifesto for Agile Software Development
Principles behind the Agile Manifesto
Practices of Extreme Programming
The Principles of Object Oriented Design

Learn iOS design and Xcode. It’s a book about iOS design and prototyping using Sketch and Xcode. Build a news reader app from Sketch to the App Store. Book for $50.

Leave a comment


Chapter 1: iOS Design


Last year, Apple completely revamped their design language for the modern users. It is now much simpler, allowing designers to focus on animation and function rather than intricate visual details.

You’ll learn how to design for iOS 8. Because the new OS focuses on functional colors, beautiful typography and delightful animations, we’ll dive deep into all the techniques and tools that are available to us. You can also find a number of resources and UI templates to help on your journey.

Chapter 2: Learn the Tools


Design isn’t hard to learn. That’s because most of us are already building products and are familiar with what design means. What used to be complex and confusing is now simple and effective, thanks to an app that is entirely focused on user interface design. In Sketch, you don’t need to worry about photo editing and the thousands of other settings that are just noise to designing a simple application.

Sketch uses one unit, a few styles only relevant to UI design, a built-in iPhone previewing tool called Mirror and Artboards, the most efficient way to template multiple screens. Everything is already in vector, so you don’t have to worry about designing for multiple devices. And delivering assets is a breeze.

Chapter 3: Build a Swift App


When I wrote Chapter 3 last year, it was written in Objective-C, and for Xcode 5. Things improved dramatically since. Swift made code simpler and it quickly became one of the top languages used. Xcode 6 introduced a number of new features such as Playground, Vector Assets and Designable Views. Ultimately, it made Adaptive Layouts an essential skill because of the iPhone 6 and 6 Plus.

You’ll learn prototyping in Storyboard, Auto Layout, Designable Views, animation and Swift to design and build an iOS app from a designer’s perspective.

In Part II, you’ll learn how to work with real data using a Table View Controller. Things like API Connections, JSON parsing, Keyboard Interactions, Custom Transitions and pull to refresh will be covered in great detail. You’ll also learn how to release your app to the App Store.

This is the final app that you’ll build. It’s in the App Store.

Chapter 4: Design with Swift


Swift is much easier to follow, especially if you’ve never done iOS development before. This chapter is for designers and complete beginners. I will focus on executing simple user interfaces and powerful animations instead of the language itself, which can be read in theiBooks. You don’t need to have read the book before reading this chapter. I’ll include all the important information for designers.

The best way to learn is to create something that you’d want to use. Guidelines are most useful while you’re directly manipulating results. So while we’re building things, I’ll explain what you need to know during the process. At the end of this chapter, you’ll be able to create aDribbble app prototype.

Learning Paths VIDEO TRAINING Stop hacking your way through the underbrush. O’Reilly’s cleared the way: our Learning Paths will help you get where you want to go, whether it’s learning a programming language, developing new skills, or getting started with something entirely new.

Leave a comment


Architect and Build Big Data Applications: 30 hours of video training

Build Apps for Amazon Web Services: 17 hours of video training

Hadoop: 16 hours of video training

C#: 27 hours of video training

Python for Data: 19 hours of video training

Beginning UX Design: 10 hours of video training

Design for Mobile: 12 hours of video training

Android Basics: 15 hours of video training