Hopp til navigasjon Hopp til innhold
Microsofts hunger etter å støtte absolutt all programvare i alle OS betyr at snodige regler fra fire tiår tilbake fremdeles følger oss. (Ill.: Mike Swanson. MS-DOS © 1994 Microsoft)

Du nektes å bruke disse Windows-filnavnene grunnet valg gjort for 40 år siden

Dette er historien om Microsofts trang til bakoverkompabilitet.

Selv i moderne versjoner av Windows, som nyeste stabile versjon av Windows 10, nektes du å bruke en rekke filnavn og filtype-kombinasjoner. Årsaken er et valg Microsoft gjorde helt tilbake i den personlige datamaskinens startfase.

Dette er listen

Følgende navn under kan ikke brukes i noen form for filnavn.

Det spiller ingen rolle om du døper om f.eks. «CON» eller «PRN» til .mp3 eller hva som helst annet – Microsoft vil nekte deg dette med meldingen «det spesifiserte enhetsnavnet er ugyldig».

  • CON
  • PRN
  • AUX
  • NUL
  • COM1
  • COM2
  • COM3
  • COM4
  • COM5
  • COM6
  • COM7
  • COM8
  • COM9
  • LPT1
  • LPT2
  • LPT3
  • LPT4
  • LPT5
  • LPT6
  • LPT7
  • LPT8
  • LPT9

Men hvorfor?

Årsaken går langt tilbake i tid og har sin begynnelse i operativsystemet Unix der prinsippet er at alt behandles som en fil – selv maskinvare ble tildelt unike plasseringer som /dev/lp0 for den første printeren i systemet eller /dev/tty for terminalen.

Samme år ble dette konseptet videreført til CP/M («Control Program/Monitor» – senere døpt «Control Program for Microcomputers») OS-et. Problemet er at dette OS-et ble laget for maskiner med veldig lite RAM og ingen harddisker.

Systemet brukte sågar en rekke disker, men ingen mapper, så disse spesialfilene representerte enhetene i hele systemet, på hver disk, mener HowToGeek (andre er ikke enige, mer om dette under).

Sendte rett til printeren grunnet mangel på harddisk

Og her kommer poenget: da man lagret en tekst fil, forklarte man rett og slett at tekstredigereren skulle lagre filen til printeren, som deretter sendte filen til printeren for å skrive den ut.

Med andre ord: om man prøvde å lagre en fil med etternavnet .txt, så regnet CP/M med at det var printeren man ønsket å kommunisere med, og altså ignorerte fil-etternavnet.

Heldigvis la PC-DOS 2.0 til mapper i 1983, men siden Microsoft og bakoverkompabilitet er hellig, bestemte selskapet at disse enhetsfilene skulle være å finne i alle mapper for kompatibilitet med eksisterende DOS-programvare.

Etter Windows 9x kom NT, som jo ikke var basert på DOS, men siden Microsoft ønsket bakoverkompabilitet igjen mot Windows 95 (som jo er basert på DOS), så måtte disse filnavnene fremdeles beskyttes, og slik er det den dag i dag, 44 år senere.

Men stemmer dette helt?

Selv er jeg for ung til å huske dette selv med praktisk erfaring (jeg er født i 1983), så mener Joe Wein som kommenterte under HowToGeek sin artikkel, at det ikke stemmer det var CM/M som har skyld i dette:

«CM/M 1.4 behandlet ikke filnavn spesielt i det hele tatt, men kopiprogrammet PIP («Peripheral Interchange Program») støttet en spesial-syntaks som PRN: eller AUX: som mål for filkopiering til printeren».

Ifølge Wein var dette knyttet til applikasjonen og ikke bygget inn OS-et. Derfor var det visstnok heller ikke slik at apper som kjørte i OS-et bundet til å behandle disse filtypene på en spesiell måte.

«MS-DOS, i kontrast til CP/M, sendte faktisk dataene til printeren, uansett hva programmet sendte til OS-et. Derfor går dette tilbake til rundt 1980, og ikke 1974 og Gary Kildall/Digital Research Inc.»

 

Kilde:

Stikkord: Microsoft, windows