The Old New Thing

Je viens de finir de lire The Old New Thing. L’auteur, Raymond Chen, a bosse dans l’equipe de developpement de Windows depuis 1995 (au moins) et il raconte les raisons de certaines decisions prises pendant le design de differentes versions de Windows, depuis 1985 jusqu’a Vista. Le livre est une compil’ des meilleurs articles de son blog.

Et franchement, c’est a ne pas y croire.

Windows Vista possede encore des APIs pour faire tourner des applications DOS 1.0, juste pour le plaisir de la compatibilite descendante ad infinitum. Les noms des methodes de Win32 sont absolument cryptiques, impossibles a retenir, mais le gars justifie toutes et chacune de ces aberrations par des raisons historiques diverses. La registry contient des infos pour changer le fonctionnement du memory manager juste pour que Lotus 1-2-3 version 2 pour Windows (1990) tourne sans probleme sous Vista.

Je me demande comment M$ a permis que ce livre soit publie! Il fait plutot envie de ne plus jamais, jamais, developper pour Windows, dans aucun langage de programmation qui soit. Je recommande vivement sa lecture, surtout si vous avez des connaissances techniques du kernel Linux! Les descriptions du fonctionnement interne de Windows sont impressionantes, avec un niveau de detail unique.

Hey Mr Policeman – this car is stolen!, by Dave Jewell

http://www.regdeveloper.co.uk/2007/08/28/hey_mr_policeman_wga/

Anyone with half a brain cell understands perfectly well that [Windows Genuine Advantage] is all to Microsoft’s “advantage” – and confers no benefit whatsoever on the customer; just tons of unnecessary hassle. For years, I’ve felt that Microsoft has lost the plot as far as Windows is concerned – now I’m convinced of it

8 choses à propos de moi

I’ve been tagged by Sandrine! :) Voici donc mes réponses:

  1. Le site que vous consultez en premier le matin (après votre blog): Google Reader
  2. Un service que vous venez de découvrir et qui vous amuse / séduit: Twitter et Wink
  3. Un blog dont vous appréciez beaucoup le design: Daring Fireball by John Gruber and Theocacao by Scott Stevenson
  4. Un widget qui vous serait utile mais qui n’existe pas encore: si je le savais je serais en train de le développer!
  5. Le livre 2.0 que vous avez le plus aimé: Founders at Work, by Jessica Livingston
  6. Un service qui selon vous va devenir indispensable: pizza à domicile
  7. Un service qui devrait exister parce qu’il est indispensable: empanadas à domicile
  8. Un blogueur / net-entrepreneur (proche ou pas) dont vous admirez le travail: Joel Spolsky

Je dois choisir 8 personnes pour passer le flambeau, alors les voici (pour le moment, il n’y a que quatre, mais ils comptent double :)

Holding a Program in One’s Head, by Paul Graham

Brilliant.

It’s striking how often programmers manage to hit all eight points by accident. Someone has an idea for a new project, but because it’s not officially sanctioned, he has to do it in off hours—which turn out to be more productive because there are no distractions. Driven by his enthusiasm for the new project he works on it for many hours at a stretch. Because it’s initially just an experiment, instead of a “production” language he uses a mere “scripting” language—which is in fact far more powerful. He completely rewrites the program several times; that wouldn’t be justifiable for an official project, but this is a labor of love and he wants it to be perfect. And since no one is going to see it except him, he omits any comments except the note-to-self variety. He works in a small group perforce, because he either hasn’t told anyone else about the idea yet, or it seems so unpromising that no one else is allowed to work on it. Even if there is a group, they couldn’t have multiple people editing the same code, because it changes too fast for that to be possible. And the project starts small because the idea is small at first; he just has some cool hack he wants to try out. Even more striking are the number of officially sanctioned projects that manage to do all eight things wrong. In fact, if you look at the way software gets written in most organizations, it’s almost as if they were deliberately trying to do things wrong. In a sense, they are. One of the defining qualities of organizations since there have been such a thing is to treat individuals as interchangeable parts. This works well for more parallelizable tasks, like fighting wars. For most of history a well-drilled army of professional soldiers could be counted on to beat an army of individual warriors, no matter how valorous. But having ideas is not very parallelizable. And that’s what programs are: ideas.

How to test software security?

Howard and LeBlanc give a very complete answer to this question in their classic “Writing Secure Code” book:

Most testing is about proving that some feature works as specified in the functional specifications. If the feature deviates from its specification, a bug is filed, the bug is usually fixed, and the updated feature is retested. Testing security is often about checking that some feature appears to fail. What I mean is this: security testing involves demonstrating that the tester cannot spoof another user’s identity, that the tester cannot tamper with data, that enough evidence is collected to help mitigate repudiation issues, that the tester cannot view data he should not have access to, that the tester cannot deny service to other users, and that the tester cannot gain more privileges through malicious use of the product. As you can see, most security testing is about proving that defensive mechanisms work correctly, rather than proving that feature functionality works. In fact, part of security testing is to make the application being tested perform more tasks than it was designed to do. Think about it: code has a security flaw when it fulfills the attacker’s request, and no application should carry out an attacker’s bidding.

(Howard & LeBlanc, 2003, page 568). Continue reading

Design by Contract

Introduction

Even if Design by Contract is a trademark (Eiffel Software, 2007) the idea behind it is the more general one of “defensive programming”. As software developers, we often concentrate our efforts in the main code of the application, which is the interesting part, and that provides the realization of the use cases identified during the early phases of the project.

My opinion is that defensive programming techniques lead to more secure, stable, and less bug-prone code, and that they require less documentation, since the resulting code is more “self-documenting”. Moreover, I will describe in this paper language-independent techniques, that can be used in different situations and systems, that are somehow similar to the Eiffel approach.

Contract Continue reading

Browsers’ Multiple Connection Settings

Introduction

I’m not such a “power user” when it comes to web browsing, and having good connectivity both at home and at work helps forgetting about tweaking the maximum number of TCP connections in my web browser. However, I can think of a two cases where the establishment of multiple connections might bring great value to the power user: first, multiple file downloads. Being able to download several files at once might be really helpful in some situations. Secondly, in the case of complex web pages. When web pages contain different elements, the required download time goes up (which is often the case: images, sound, video, Java applets, Flash animations, JavaScript files, stylesheets, etc., are ubiquitous nowadays).

In this article I will provide an overview of multiple connection availability in some Mac browsers, and also provide some tips for Internet Explorer for Windows, in the context of the HTTP RFC. Continue reading

About Mercury TestDirector for Quality Center

Mercury TestDirector for Quality Center is an enterprise-class solution, recognized as one of the most complete and integrated software suites geared towards the management of testing- and quality-related activities. Mercury Interactive, the company behind TestDirector, was bought by Hewlett Packard in 2006 for USD 4.5 billion (Wikipedia). TestDirector is used by several important organizations such as Nextel, the United States Navy, Nestlé, Qualcomm and Shell (Mercury Website, 2007a). Continue reading