Galin Iliev's blog

Software Architecture & Development

Microsoft Office file formats' specifications

You've probably heard about Office Open XML File formats. It is zipped folder which includes content in XML format as well as the code and included files. This means you can take a look inside them by simply changing the extension:


This is not new and there are plenty of article about this on the web.

The news here is that Microsoft published Microsoft Office Binary (.doc, .xls, .ppt) file formats specifications. It could be very interesting... But it could be boring too :) because according Joel Spolsky:

A normal programmer would conclude that Office’s binary file formats:

  • are deliberately obfuscated
  • are the product of a demented Borg mind
  • were created by insanely bad programmers
  • and are impossible to read or create correctly.

There is a good article from Joel Spolsky who is former PM @ Microsoft Excel team that analyze the specification.

Read it to find out how complex data are handled in limited CPU power and memory back in 80386 at 20 MHz

TechEd Video - Framework Engineering: Architecting, Designing, and Developing Reusable Libraries

As we know it is very important to write reusable code as this lower the cost of the product and decrease development time. Here is recorded nice presentation of Krzysztof Cwalina on TechEd "Framework Engineering: Architecting, Designing, and Developing Reusable Libraries".

Krzysztof is kind enough to publish slides in XPS format (1.25 MB).

Download video in WMV format (01:07:23 and 371 MB)

image image

Framework Engineering: Architecting, Designing, and Developing Reusable Libraries

This session covers the main aspects of reusable library design: API design, architecture, and general framework engineering processes. Well-designed APIs are critical to the success of reusable libraries, but there are other aspects of framework development that are equally important, yet not widely covered in literature. Organizations creating reusable libraries often struggle with the process of managing dependencies, compatibility, and other design processes so critical to the success of modern frameworks. Come to this session and learn about how Microsoft creates its frameworks. The session is based on experiences from the development of the .NET Framework and Silverlight, and will cover processes Microsoft uses in the development of managed frameworks

Meet Microsoft Live Labs Volta

Here is another codename project from Microsoft that aims at Web UI experience - meet Microsoft Live Labs Volta:

The Volta technology preview is a developer toolset that enables you to build multi-tier web applications by applying familiar techniques and patterns. First, design and build your application as a .NET client application, then assign the portions of the application to run on the server and the client tiers late in the development process. The compiler creates cross-browser JavaScript for the client tier, web services for the server tier, and communication, serialization, synchronization, security, and other boilerplate code to tie the tiers together.

Developers can target either web browsers or the CLR as clients and Volta handles the complexities of tier-splitting for you.  Volta comprises tools such as end-to-end profiling to make architectural refactoring and optimization simple and quick. In effect, Volta offers a best-effort experience in multiple environments without any changes to the application.

Programming model:

In essence Volta is a recompiler. Volta works on MSIL rather than on a textual source language. Volta rewrites MSIL into any number of target languages, including, today JavaScript and MSIL itself. Rewriting, as a general technology, lets us delay permanent decisions about architecture, execution platform and browser until after our code is basically working. Furthermore, it frees us from having to express all these irreversible decisions in your source code. The result is a programming model that enables us to easily reshape a working application, and finally realizes the promise of one application running anywhere.

Volta effects recompilation through 3 general capabilities: refactoring, retargeting, and remodulating. Refactoring converts single-tier code into distributed, concurrent code as directed by user-supplied annotations. Retargeting converts MSIL code into code for other virtual machines. Remodulating tailors a single piece of code for multiple browsers. The next 3 sections explain in more detail.

See detailed architectural and fundamental description here.


VS 2008 and .NET Feature Specifications

Feature specifications are posted on MSDN so everyone who is interested how to write specifications or how looks like specifications inside Microsoft can take a look at Feature Specifications for Visual Studio 2008 and .NET Framework 3.5 in MSDN. All documents are in XPS format.

Technology Area

Feature Specification

Developer Tools Plaform

Command Bar Improvements

MSO File Dialog Removal

File Tab Channel Improvements

IDE Navigator

MSBuild Multi-Targeting

Object Browser Support for New Language Features

Segoe UI Font Support

Tool Window Docking Targets

Tool Window Frames and Tabs

VS Color Service and VS Gradient Service: Vista Palette Addition

Windows Framework Support in Object Browser and Find Symbol

Menu Improvements

Splash Screen Improvements

Pseudo Multi-targetting

Updated Branding

Visual Studio Proxy Service

Visual Studio Settings Migration

Visual Studio for Devices

eVC: VS2005 Migration

Visual C++

Friend Templates


.NET Framework Multitargeting in Visual C++

Versioning of Visual C++ Libraries


Dialog Templates

File Dialogs

Marshaling Library

MFC Support for Common Controls

Scope Reduction in VC Libraries

UAC for VC

Vista Common Controls

Network Class Libraries

Internationalized Resource Identifier Functional Specification


VSTO & VSTA Project Upgrade


Dynamic Programming Model

Office Workflow Tools


Uninstall Wizard UI

UI Frameworks


Partial Page Rendering

Visual C#

Mapping Format


.NET Compact Framework

Microsoft.WindowsCE.Forms.SystemSettings Extensions

Team Architect

Support for Web Application Projects

Architectural Roles

Enterprise Developer

ASP.NET AJAX: Debugging Breakpoint Mapping

ASP.NET AJAX: Script Explorer in Solution Explorer

Project Astoria

I am on codenamed projects wave today and I would like to share with you another one - project Astoria (reposted from official blog):

Project Astoria Overview

The goal of the Astoria project is to enable applications to expose data as a data service that can be consumed by web clients within corporate networks and across the internet. Such data services are reachable over regular HTTP requests using standard HTTP verbs such as GET, POST, PUT and DELETE to represent the operations against the service.   The payload format for the data exchanged with the service can be controlled by the client and all options are simple, open formats such as plan XML and JSON. The use of web-friendly technologies make it ideal as a data back-end for AJAX-style applications, Rich Interactive Applications and other applications that need to operate against data that is across the web. 

                Further reading: Astoria Overview, Using Astoria        

By Mike Flasko

For those who are interested in architecture & design & process the team made another post Transparency in the design process which describes how the things happens inside MS (described for this particular project)

Architect or developer?

I recently came across good article The role of the Software Architect by Fabrice Marguerie and I have some comments I would like to share. There was an paragraph that says ( about comparing architects with developers ):
Michael Platt wrote: "Architects are a lot slower in getting a solution, especially if the problem is simple!". Probably we could add that "Architects are much likely to come up with complex and costly solutions, especially if the problem is simple!".

I am not quite sure this is true. Building software solution is not much different than building construction (or building a car) - the main principles are same:
  1. understand business needs
  2. create it durable (and usable)
  3. give time and price estimations (for implementation and use)
  4. try to understand future changes and integrations (or easy repairable)
I wont discuss how this is done but let's say it is quite difficult to let this out from the stakeholders (point 1 and 4).

Getting above things done is much different in software for number of reasons but mainly (according my opinion)
because software industry is much younger and technologies are changing ( and constantly lowering development cost and time).

But let's back to paragraph above: Why Architects should create much complex solutions!? Based on their experience they would try to guess future needs and cover them. This is the only explanation I have... But ( in opinion again ) I think customer/stakeholders should known main decisions taken regarding solution built for them. In this case they will be told all main assumptions and constraints. Knowing these ( as well as how important it is represented by time and money :) ) they will closely involved in defining goals and scope.

I agree that architects, based on their experience, would notice much more details and would have much more questions to stakeholders. But this doesn't make solution more complex or expensive. This makes goals much clearer and allows setting good solution architecture as well as avoids changes in later stages.

Indeed, an architect can have to write lines of code (at least to create prototypes or mock-ups), but also has to get his hands dirty with code to validate the quality of what is produced or resolve a particularly technically difficult situation.

About this paragraph I absolutely agree :) Definitely the architects should be able understand and influence what 's done by developers and even could be able to participate in first stages of development.  But  not too close because  pure developers won't have the chance to take design decisions on certain levels of solution and would be obstacle to for them in gaining valuable experience.

Thus make me think about my career :) Since very first days I was having to deal with clients, to get their needs and build appropriate solutions. According my knowledge in Bulgaria most of senior devs fulfill these activities. I am calling them senior devs because we are involved closely in development, team lead, solution design and, of course, matching clients' needs (and managing their expectations)

So what are we - Architects or Developers?! By being the person who gets the project, and make it happens, are we developers because we are highly involved in implementation/code phase or we are architects because we do much more things beside implementation?

What is your opinion on this?

I highly recommend reading the article - The role of the Software Architect by Fabrice Marguerie