Краткая история пути к 64-м битам

Попалась такая вот статья в Communications of ACM - The long Road To 64 Bits. Что мне больше всего понравилось - это коллекция событий ведущих к нынешнему 64-битному компьютингу. Позволю себе содрать сей календарь для вашего удовольствия...

Оригинал на персональном блоге...

1964 IBM S/360 (ага, "старушка" ОС ЕС) 32 бита с 24-х битным адресным пространством (16 Мб) реальной памяти.

1967 Алгол 68 - один из моих любимых, хотя и экзотических языков, который включал тип .long .long.

1970 DEC PDP-11/20 - 16 бит с 16-битным адресным пространством (всего 64 Кб) -- зато поменьше размером чем IBM 360 и ближе к нынешним PC.
А также IBM S/370 с виртуальной памятью, которая давала всю ту же 24-х битную память, но КАЖДОМУ процессу.

1971 IBM 30/145 Переход памяти с магнитных сердечников (core) на DRAM с плотностью (держитесь за стул) 1 Кбит на чип.

1973 "Урожайный год". DEC PDP-11/45 с отдельной памятью для инструкций и данных (64 Кб на каждую), и до 248 Кб реальной памяти.
Unix на PDP 11/45, ОС переписанная на С.
C первый относительно переносимый язык

1975 Unix: 6-ая версия, 24-битная адресация (до 16 Мб адресуемой памяти). Юниксоиды и PDP наконец-то почти достигли уровня IBM 360.

1976 DEC PDP-11/70. По прежнему всего 64К на данные и 64К на программы, но вся память теперь может достигать "огромных" 4 Мб
C Нововведение в языке C - типы short и long. Причем long введено для переноса на XDS Sigma, на которой long был уже 64 бита.

1977 Unix перенесен на 32-х битную систему Interdata 8/32.
C: Куча новых нововведений - unsigned, typedef, union, 32-битный long использован вместо 16-битного int в файловых операциях seek и tell на 16-ти битных PDP-11. Также перенесено на VAX.
DEC VAX-11/780 32 бит с 32-битной адресацией, до 4 Гб всего, 2 Гб на процесс.

1978 Unix: 32-битная версия для VAX-11/780
C: Издана классическая книга The C Programming Language by Brian Kernigan & Dennis Ritchie издательством Prentice-Hall.
Intel 8086 16 бит, но с сегментацией видимой для программы. Ну, и, конечно, славное начало на котором расцвел нынешний компьютинг.

1979 Motorola MC68000 с 32-битной шиной, хотя и 24-битной адресацией как на S/360.

1982 C на MC68000 в Bell Labs Blit терминал.
Intel 80286 теоретически позволяет до 16 Мб реальной памяти, хотя большинство систем по-прежнему ограничено 1 Мб (помните, PC AT и драверы расширения памяти? Да еще отдельно технологии extension и expansion, которые не следовало путать?)

1983 IBM 370/XA добавило 31-битную адресацию (с поддержкой старой 24-х битной).

1984 Motorola: MC 68020 с 32-битной адресацией и размером слова.
C: Появлися тип lon long на UTS (32-bit S/370), в основном для длинных адресов в больших файлах.
C: Convex (64-битный векторый мини суперкомпьютер) использует long long для 64-битных целых.

1986 Intel выпустил 80386 - 32-битный процессор с поддержкой старого 8086 режима.

1987 Apple Mac II на MC68020 с 32 битной адресацией (что вызвало проблемы для более старого софта для MC68000).

1988 IBM ESA/370 31-битные адресные пространства для каждого процесса (с поддержкой старого 24-битного процесса).

1989 ANSI C (C89) принят как стандарт ANSI X3J11. Разработка стандарта была начата в 1983.

1992 SGI выпустила первый 64-битный микропроцессор MIPS R4000 (с поддержкой более старого 32-битного режима).
C: Неформальная Рабочая Группа по 64-битному С (впрочем, работавшая без особого успеха).
DEC выпустил 64-битную систему Альфа с 64-битной ОС LP64.

1994 SGI выпустила IRIX - смешаную 64/32-битную систему на машине Power Challenge.

1995 Sun: UltraSPARC - Смешаная 64/32-битная система с 32-битной операционной системой.
Встреча по большим файлам кодифицирует 64-битный интерфейс к файлам более 2 Гб, в том числе и на 32-битных системах.

1996 Hewlett-Packard объявил о выпуске 64-битного PA-RISC 2.0.

1997 Hewlett-Packard UP/UX 11.0 - 64/32-битная ОС.
IBM RS64 PowerPC с AIX 4.3.

1998 Sun: Выпущен 64/32-бит Соларис 7.

1999 С: ISO/IEC C (WG14 "С99") включает 64-битный (не менее) long long.

2001 IBM: 64-битная zSeries (наследница S/360, с поддержкой для совместимости старой 24-х битной адресации).
Intel: 64-битный Итаниум.

2002 Microsoft: Windows 64-bit для Итаниум.

2003 AMD: 64-битный X86 - AMD64.

2004 Intel: 64-битный X86 - EMT64, совместимый с AMD.

2005 Microsoft: Windows Professional x64 (AMD64/EMT64).

Ну, и 64-битные Виста и Сервер 2008 - это уже не новость.

---

[1] The Long Road To 64 Bit by John Mashey - Communications of the ACM, January 2009, Vol.52, No. 1, p. 45-53

Honey, where are my keys???

Cross-post from my main blog: --------------- No, really? Suppose, you’ve got a certificate from some certificate authority, installed it in the localmachine store, and then your application cannot see it!!! What happened? Is it a bug? Is it a virus? Did somebody stole you precious key??? Not quite… Let’s see what’s happening when you install the certificate. The certificate itself is stored in the registry, and it includes the public key. However, the private key is stored separately in a special folder. That’s “%system drive%\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys”, or whatever it is in a localized version. This folder is quite special. First of all, a normal consumer Windows does not have much to keep there. Sometimes, it’s just empty. Unfortunately, this is important to our story. Read on! So, you install the certificate, and the file with the private key is created in this folder. Where does it gets its permissions? Right, from the folder. That’s quite logical, isn’t it? Step 2, and that a smart thing, maybe a too smart thing, happens. Crypto layer, which created this file, removes the permissions for Everyone (WD) identity on this file. Which is also quite logical, you cannot have a private key that everybody can read, can you? Now, what does it mean if Everyone was the only one having access to this folder? Right, nobody can get your key. Not even Admin or SYSTEM – semi-divine identity in Windows used to run system processes. That’s not fun, but wait, here is more! If for some reason at some moment in the history of the machine this folder gets empty, it may – I repeat, it may – be deleted by the same code that created file for private key and maintained it so far. Then, some other application starts and tried to import a private key. Guess, what happens? The folder is magically recreated. Sounds good? Wait a bit for a small detail. It’s recreated under the current user. Ouch, ouch, ouch! What does it mean for you? It means that on any well used Windows system you don’t have a predictable state of this folder and your private keys. And if you install certificates under one user, it may not work under another user. So, the generic word of wisdom is: take care of ACLs on your private keys, if you install them, or it may be the last time you’ve seen them!