Windows

Da jeg har programmeret siden i det meste af mit liv synes jeg at det er sjovt at læse Raymond Chen’s fortælling om alt det der gjorde det vanskeligt at få gamle programmer til at køre under Windows 95. Det er selvfølgelig over 20 år siden men det er gode eksempler på hvad man ikke skal gøre. Hvis bare dem der lavede Go Basic havde haft samme indsigt..

Example 59
Program 24a from our friends at Publisher 3 allocates all the memory it can and locks it to
speed up its CD-ROM transfer rate. In Windows 95, the CD-ROM file system driver is itself
pageable, so locking everything forces the CD-ROM file system to be paged out, thus slowing
down the CD-ROM transfer rate.
Maxim 22: Bite the hand that feeds you.
— Raymond Chen, “The Old New Thing / How to Ensure That Your Program Does Not Run Under Windows 95

Chen har flere historier fra den tid der er værd at besøge, for eksempel om hvordan Windows 95 teamet blev forsinket af at en udvikler et andet sted i Microsoft havde slukket sin computer eller hvordan MS-DOS og Windows 95 arbejdede sammen.

Første gang jeg hørte om Chen var ved at læse Joel Spolsky’s “How Microsoft Lost the API War“. Artiklen er ret gammel nu og meget har forandret sig. Men den grundlæggende pointe gælder stadig. Microsoft var på tidspunktet for Windows 95 ekstremt fokuseret på at tidligere programmer fortsat skulle fungere. Det havde den afledte effekt at udviklere ikke havde løbende omkostninger ved at udvikle til Microsoft produkter; når først noget fungerede ville det fortsætte med at fungere. Spolsky begræder at den tid for længst er ovre og det at man ved at udvikle til Windows må indse at man løbende skal bruge tid på bare at få tingene til at fungere; at i stedet for at opgradere software gik Microsoft over til at udskifte software.

Jeg oplevede det selv da .NET 1.1 erstattede 1.0 og dele af min kode holdt op med at fungere. En pause i mit arbejde med .NET gjorde at jeg først fik den oplevelse igen, til gengæld var det igen dyrt. Det var da Microsoft kom med .NET 4.5 der var “highly compatible” med .NET 4.0, som den erstattede. Nu er kompatibilitet en binær ting så “highly compatible” betyder at den ikke er kompatibel. Der spildte vi igen meget tid, tid som Microsoft havde pålagt os at bruge.

Udviklere hader at implementere bagudkompatibilitet fordi det tager tid. Men alternativet er at alle brugerne i stedet skal bruge den samme tid, hver for sig.

Dette indlæg blev udgivet i Udvikling og tagget , , , , , . Bogmærk permalinket.

Skriv et svar

Udfyld dine oplysninger nedenfor eller klik på et ikon for at logge ind:

WordPress.com Logo

Du kommenterer med din WordPress.com konto. Log Out / Skift )

Twitter picture

Du kommenterer med din Twitter konto. Log Out / Skift )

Facebook photo

Du kommenterer med din Facebook konto. Log Out / Skift )

Google+ photo

Du kommenterer med din Google+ konto. Log Out / Skift )

Connecting to %s