Microsoft раскрыла исторические аспекты разработки Windows. Виндовс 10 архитектура


Архитектура Windows

Лабораторная работа № 2

Цель работы: изучение архитектуры операционной системы Windows

Приложение Windows - это совокупность исполняемых программ и вспомогательных файлов. Например, Microsoft Word представляет собой одно из популярных приложений Windows. Процессом называется исполняемый экземпляр приложения. В большинстве случаев пользователь может запускать несколько экземпляров (копий) одного и того же приложения одновременно. Каждый исполняемый экземпляр - это отдельный процесс со своей собственной областью памяти.

Более точно, процессом называется исполняемый экземпляр приложения и комплект ресурсов, выделенных данному исполняемому приложению.

Поток (thread) - это внутренняя составляющая процесса, которой операционная система выделяет процессорное время для выполнения кода. Именно потоки исполняют программный код, а не процессы. Каждый процесс должен иметь как минимум один поток. Основное назначение потоков - дать процессу возможность поддерживать несколько ветвей управления, то есть выполнять больше действий одновременно. В многопроцессорной конфигурации (компьютер с несколькими процессорами) Windows NT (но не Windows 9x) может распределять потоки по процессорам, реально обеспечивая параллельную обработку. В однопроцессорной конфигурации процессор выделяет кванты времени каждому исполняемому в данный момент потоку.

На рис. 1 представлена в обобщенном виде архитектура Windows NT.

Режим ядра и пользовательский режим

Микропроцессор Pentium имеет четыре уровня привилегий, известных также как кольца защиты, которые управляют, например, доступом к памяти, возможностью использовать некоторые критичные команды процессора (такие как команды, связанные с защитой) и т.д. Каждый поток выполняется на одном из этих уровней привилегий. Кольцо 0 - наиболее привилегированный уровень, с полным доступом ко всей памяти и ко всем командам процессора. Кольцо 3 - наименее привилегированный уровень.

Для обеспечения совместимости с системами на базе процессоров, отличных от тех, что выпускает компания Intel, Windows поддерживает только два уровня привилегий - кольца 0 и 3. Если поток работает в кольце 0, говорят, что он выполняется в режиме ядра. Если поток выполняется в кольце 3, говорят, что он работает в пользовательском режиме.

Рис. 1

Низкоуровневый код операционной системы действует в режиме ядра, тогда как пользовательские приложения выполняются в основном в пользовательском режиме.

Прикладной поток может переключаться из пользовательского режима в режим ядра при вызове некоторых API-функций, которые требуют более высокого уровня привилегий, например, связанных с доступом к файлам или с выполнением функций, ориентированных на графические операции. В действительности некоторые пользовательские потоки могут работать в режиме ядра даже больше времени, чем в пользовательском режиме.

Но как только завершается выполнение той части кода, которая относится к режиму ядра, пользовательский поток автоматически переключается обратно в пользовательский режим. Такой подход лишает возможности писать код, предназначенный для работы в режиме ядра, программист может только вызывать системные функции, выполняющиеся в режиме ядра. При работе с Windows NT можно определить, когда поток выполняется в пользователъском режиме, а когда - в режиме ядра. Для этого используется утилита Performance Monitor (Системный монитор) из пункта Administrative Tools (Администрирование) меню Start. (Пуск).

Драйверы устройств работают в режиме ядра. Это обстоятельство имеет два следствия. Во-первых, в отличие от неправильно выполняющегося приложения, неправильно работающий драйвер устройства может нарушить работу всей системы, так как он имеет доступ и ко всему системному коду и ко всей памяти. Во-вторых, прикладной программист может получить доступ к защищенным ресурсам, написав драйвер псевдоустройства, хотя это и нелегкая задача.

studfiles.net

Разрядность Windows 10

Любые современные операционные системы делятся на 2 вида: 32-битные и 64-битные. В этой статье мы расскажем, почему такое разделение необходимо, сравним 32-битную и 64-битную Windows 10 по ряду факторов, а также посоветуем, как правильно выбрать разрядность системы для вашего устройства.

Что такое разрядность Windows

Люди, прежде не знакомые с компьютерными технологиями, не всегда понимают, что такое разрядность Windows, откуда и зачем это явление возникло. Вернёмся немного в прошлое.

Ещё 10-15 лет назад компьютеры были довольно слабыми по сравнению с сегодняшними. Объёмы оперативной памяти (RAM, ОЗУ - всё это обозначает одно и то же) редко превышали 1-2 ГБ, а мощности процессоров хватало лишь для самых простых задач. В то время почти везде использовались 32-битные (или 32-разрядные, эти понятия аналогичны) системы. Но уже тогда стало понятно, что обыкновенные на тот момент объёмы оперативной памяти становятся слишком маленькими для всё возрастающих задач. Компьютеры учились делать больше и больше, соответственно, и требования к железу возрастали.

32-разрядные системы создавалась много лет назад, когда Билл Гейтс утверждал, что 640 КБ оперативной памяти хватит всем. Тогда казалось, что максимальный теоретический объём памяти, с которой может работать такой механизм (около 4 ГБ) просто недостижим. Но прогресс не остановишь, и этот предел был преодолён. Возникла необходимость в компьютерах нового вида, способных воспринимать 4 ГБ и больше RAM. Так появились 64-битные системы, способные работать с сотнями ГБ ОЗУ (а теоретически - с тысячами терабайт).

С тех пор Windows, как и другие операционные системы, делится на 2 вида:

  • 32-разрядная (x86). Иногда встречаются обозначения 32bit,  IA-32 или x32.
  • 64-разрядная (x86_64 или просто x64). Иногда встречается обозначения 64bit или amd64.

Главное их отличие - поддержка различных объёмов оперативной памяти.

Почему именно x86, x86-64, IA-32 и amd64

Неискушённому пользователю эти термины должны казаться довольно странными. Мы приведём некоторую справку и разберёмся в технических деталях.

Разрядность системы очень тесно связана с понятием архитектуры и разрядности процессора. Процессоры, как и системы, могут делиться на 32- и 64-разрядные. Поясним, что все это значит.

Что такое x86

x86 - это название архитектуры процессоров. Все современные чипы для ПК, ноутбуков, планшетов основаны на этой архитектуре. Её название образовано от конечных цифр первых процессоров Intel, использующих её: i386, i486.

Все эти первые процессоры были 32-битными, поэтому название архитектуры стало заодно и названием соответствующей разрядности (таким оно и остаётся до сих пор). Впрочем, официальное название технологии - IA-32 (она была создана компанией Intel). Правда, на сегодняшний день оно почти не используется.

Что такое x86-64

x86-64 - это название улучшенных программных механизмов для процессоров с архитектурой x86. Эти улучшения позволяют выполнять ПО в 64-разрядном режиме (то есть используя гораздо больше оперативной памяти).

Аналогично ситуации с x86, постепенно термин x86_64 стал применяться и для обозначения разрядности систем. Сокращённое наименование - просто x64. Иногда встречается название amd64, так как эти технологии были созданы компанией AMD.

Обобщая, любые процессоры для ПК построены на архитектуре x86, но некоторые поддерживают лишь 32-битные инструкции (и обозначаются просто x86), а некоторые - ещё и 64-битные (и тогда они обозначаются x86-64 или просто x64). При этом любые 64-битные процессоры работают и с 32-битным ПО, и с 64-битным, а 32-разрядные чипы могут запускать лишь 32-разрядное ПО.

Соответственно, 32-битное ПО (в том числе Windows 32bit) создано для 32-разрядных x86-процессоров, но может запускаться и на 64-битных x86-процессорах. А 64-битное ПО (и Windows 64bit в том числе) создано и работает только на 64-разрядных x86-процессорах.

Разница между 32- и 64-разрядными процессорами - разный объем поддерживаемой оперативной памяти, что выливается в разный размер поддерживаемой ОЗУ в 32- и 64-разрядной Windows.

Какие существуют другие архитектуры процессоров

В мобильных устройствах на данный момент в основном используются процессоры с архитектурой ARM. Именно для таких чипов создана, например, Windows 10 Mobile. ARM-процессоры тоже делятся на 32- и 64-битные, но их ни в коем случае нельзя назвать x86 или x86-64: понятие x86 относится именно к десктопным процессорам. В случае с ARM-чипами мы можем говорить о разрядности ARM (32-битная) и ARM64 (64-битная).

Каков максимум оперативной памяти в 32/64-разрядной Windows

32-битная Windows

Из-за ограничений 32-разрядных процессоров максимальный теоретический объём ОЗУ в 32-битных системах составляет 4 ГБ. На деле чаще всего пользователю будет доступно 3-3,5 ГБ. Эти значения одинаковы для любых современных Windows - как Windows 7 и 8.1, так и для Windows 10. Исключением является лишь Windows 7 Starter, в которой лимит искусственно снижен до 2 ГБ.

64-битная Windows

Максимально возможный объем RAM на данный момент просто недостижим, так как составляет более 16 миллионов терабайт (1 ТБ = 1024 ГБ). Соответственно, присутствуют лишь ограничения Windows.

Windows 7
  • Home Basic: 8 ГБ.
  • Home Premium: 16 ГБ.
  • Professional, Enterprise, Ultimate: 192 ГБ.
Windows 8
  • Home: 128 ГБ.
  • Professional, Enterprise: 512 ГБ.
Windows 10
  • Home: 128 ГБ.
  • Pro, Enterprise: 2 ТБ.

В принципе, в случае с Windows 8 или 10, вы можете не задумываться о редакции: доступные обычным пользователям компьютеры вряд ли достигнут указанных лимитов в ближайшие несколько лет.

Какая разница между 32- и 64-битной Windows

Самым главным, но не единственным различием, является поддержка разных объёмов RAM. Помимо этого можно отметить разницу в поддержке программ, о чем мы уже говорили выше. Напомним:

  • 32-разрядные системы поддерживают только 32-битные программы.
  • 64-битные системы полноценно работают и с 64-битными программами, и с 32-битными (правда, последние не смогут использовать все доступные мощности ПК).

Других заметных обычному пользователю различий нет.

Поддерживает ли компьютер 64-разрядную Windows

x86-процессор любого устройства по умолчанию поддерживает 32-битную Windows, но для работы 64-битной системы необходим чип с поддержкой x86-64. Кроме того, чтобы запустить систему той или иной разрядности, вам нужны соответствующие драйвера.

Чтобы узнать, какой у вас процессор, достаточно зайти в окно системной информации.

  1. Нажмите Win + R, чтобы вызвать окно команд.
  2. Введите команду control и нажмите Enter.
  3. Пройдите в категорию Система и безопасность, затем в раздел Система.
  4. Обратите внимание на строку Тип системы. В ней будет указано, какую архитектуру поддерживает процессор, и система какой разрядности у вас установлена.

Если ваше устройство обладает x86-процессором, то на нём заработает только 32-битная Windows. В ином случае (процессор x64) теоретически вы будете способны запустить и 32-разрядную, и 64-разрядную систему. Но случается, что производители компьютеров намеренно ограничивают работу устройства с x64 (даже при наличии такого процессора), что часто происходит с планшетами. Кроме того, поставщик ПК может не предоставить драйвера для конкретной разрядности, из-за чего система фактически не будет нормально работать. Именно по этой причине лучше сразу смотреть не на процессор, а на драйвера.

Как узнать, есть ли драйвера для 32/64-битной Windows

На данный момент всё более распространённой становится ситуация, когда производитель устройства выпускает драйвера только для конкретной разрядности. Почти всегда это оправдано: устанавливать 64-битную систему на планшет с 2 ГБ оперативной памяти довольно бессмысленно, как и устанавливать 32-битную систему на компьютер с 8 ГБ ОЗУ. Так как драйвера являются важнейшей частью системы, без которой ничего не заработает, мы можем отметить следующее: устройство поддерживает систему той или иной разрядности тогда и только тогда, когда производитель выпустил соответствующие драйвера.

Проверить наличие драйверов можно на официальном сайте производителя.

Какую систему выбрать, 32- или 64-разрядную

В принципе, ответ на этот вопрос является обобщением всего, о чём мы писали выше.

Производитель предоставляет драйвера для систем обеих разрядностей

В таком случае ваше решение зависит от объёма оперативной памяти.

  • Установлено менее 4 ГБ.В таком случае установка 64-битной системы бессмысленна. 32-разрядная Windows будет работать у вас куда лучше.
  • Установлено 4 ГБ.Несмотря на то, что именно 4 ГБ является теоретическим предельным объёмом ОЗУ в 32-битных системах, фактически лимитом является цифра в 3,5 ГБ. Если вы установите 32-битную систему, то примерно 0,5 ГБ ОЗУ использоваться ей не будут. Впрочем, это не является веской причиной установки 64-разрядной Windows. Дело в том, что последняя использует заметно больше памяти при выполнении тех же задач, так что даже с учётом лишних 0,5 ГБ вы, скорее всего, только потеряете в производительности.32-битная Windows будет для вас лучшим выбором.
  • Установлено более 4 ГБ.Если вы воспользуйтесь 32-битной системой, она просто не увидит всю вашу оперативную память и не сможет использовать ресурсы компьютера по-максимуму. Даже не задумывайтесь и устанавливайте 64-разрядную Windows.

Производитель предоставляет драйвера только для конкретной разрядности

В таком случае выбора у вас нет, так как без драйверов компьютер нормально не заработает. Устанавливайте систему, рекомендованную производителем.

Отметим, что критерии производителя могут немного отличаться от тех, что мы привели выше. Например, владельцы ноутбуков HP могут заметить, что Hewlett-Packard при предустановленных 4 ГБ оперативной памяти часто предоставляет драйвера только для 64-битной системы (а мы в таком случае рекомендуем установку 32-битной). Подобные ситуации довольно распространены. Таким образом производитель намекает вам на то, что у вас в компьютере есть свободные слоты для RAM, и что их можно использовать для увеличения объёма ОЗУ.

Как обновиться с 32-битной системы до 64-битной

Фактически "обновиться" до системы другой разрядности невозможно. Фундаментальные различия в механизмах 32- и 64-разрядной Windows не позволяют выполнить коррректный переход с одной версии на другую с сохранением всех ваших программ и файлов. Вам придётся выполнить чистую установку системы.

wp-seven.ru

Microsoft раскрыла исторические аспекты разработки Windows

Несколько дней назад Microsoft опубликовала очень любопытную информацию, мимо которой мы не могли пройти мимо. Опубликованная статья называлась The engineer’s engineer: Computer industry luminaries salute Dave Cutler’s five-decade-long quest for quality и посвящена заслуженному инженеру Microsoft и первому архитектору Windows NT Дэйву Катлеру, который заложил основу всех версий Windows начиная с 1993 года.

Известно, что Windows NT разрабатывалась как серверная операционная система и она прошла достаточно долгий путь эволюции перед тем как предстать во всей своей красе перед домашними пользователями в виде Windows 2000 и Windows XP. Не многие знают, что, на самом деле, все семейство ОС Windows NT, начиная от самых первых ее версий и заканчивая Windows 10 основано на одной из первых полностью 32-битных ОС фирмы Digital Equipment Corporation под названием VAX VMS, которая основана на UNIX.

Мы приведем наиболее значительные отрывки из вышеуказанной статьи с нашими комментариями

В 1976 г. компания Digital Equipment Corporation (DEC) [или просто Digital] была на волне успеха и считалась преуспевающей компьютерной фирмой. [Digital не только специализировалась на разработке своей ОС, но и железа для нее] Совместно с другими такими компаниями как Data General, Prime Computer и прочими IT-компаниями, которые располагались вдоль т. н. шоссе 128 (Massachusetts Route 128), DEC формировала компьютерный ландшафт того времени [выпуская миникомпьютеры].

В то же время уже известный на тот момент инженер Гордон Белл (Gordon Bell), который работал в Digital на высокой должности, был обеспокоен падением динамики продаж флагманского 16-битного миникомпьютера компании, известного как PDP-11 [работавшего на ОС RSX-11]. Другое беспокойство менеджеров DEC вызывал факт разработки IBM первого [микро-]компьютера.

Белл решил использовать свое видение будущего, поставив на создание нового 32-битного миникомпьютера под названием VAX с новой ОС [VMS], которая будет обеспечивать обратную совместимость с приложениями для миникомпьютера PDP-11. Тогда Белл обратился к Дэвиду Катлеру, которому, на тот момент, было 33 года. Он считался перспективным инженером Digital, к тому же, имевшим опыт разработки RSX-11. Бэлл попросил Катлера возглавить проект разработки VAX [Virtual Address Extension].

Два года спустя, первые экземпляры миникомпьютеров VAX увидели свет на производстве Digital. При этом VAX сразу же закрепил свою позицию лидера на этом рынке. Тогда Белл назвал Катлера лучшим «лучшим разработчиком операционных систем в мире».

Рис. Дэйв Катлер.В 1982 г. Катлер встретился с Беллом и анонсировал свой уход из DEC, что стало для него полной неожиданностью. В свою очередь, руководство DEC не собиралось просто так расставаться со своим самым талантливым инженером, хотя, подозревало, что его недовольство относится к растущей бюрократии в руководстве Digital. Катлеру сделали встречное предложение от которого он не смог отказаться. Так была создана дочерняя компания DECWest.

Офис новой компании расположился на расстоянии 3 тыс. миль от штаб-квартиры Digital: в Бельвью, штат Вашингтон, т. е. недалеко от Сиэтла и Microsoft. Молодой инженер Len Kawell стал одним из первых талантливых специалистов этой фирмы. Специалисты собрались разработать ОС реального времени (real-time) для VAX, но в результате был создан и новый компьютер MicroVAX, а также real-time ОС для него под названием VAXeln. Катлер взял на себя функции разработки нового железа, а Len Kawell отвечал за создание ПО.

Kawell говорил, что у Катлера есть уникальное видение функций железа (hardware), что отличало его от других инженеров того времени. Он мыслил на уровне машинных инструкций и операций с регистрами микропроцессора. Тем не менее, в 1988 г. Катлер покинул Digital, а новый компьютер MicroVAX и ОС для него так и не увидели свет. После этого Катлер ушел в Microsoft, познакомившись с Биллом Гейтсом еще за пять лет до этого. Для него уже был готов проект новой ОС, которой суждено было произвести настоящий переворот в области микрокомпьютеров.

Рис. Катлер с Соломоном и Руссиновичем, авторами известной книги Windows Internals.После переговоров с Биллом Гейтсом в 1988 г., Катлер принял решение о переходе в Microsoft для создания настоящей 32-битной ОС для микрокомпьютеров. К нему также присоединилась команда инженеров из предыдущего проекта: пять специалистов по разработке ОС и шесть специалистов в hardware.

Команда Катлера приступила к разработке новой ОС для Microsoft в апреле 1989-го, работа велась более десяти часов в сутки, иногда, без выходных. Основной задачей при разработке Windows NT стала портируемость будущей ОС, т. е. возможность ее работы не только на микропроцессорах Intel архитектуры x86, но также и на RISC-архитектурах, которые были популярны в тов время и обеспечивали большую производительность по сравнению с x86. Одновременно с этим, специалисты Microsoft уже сотрудничали с компанией IBM в новом проекте по разработке ОС под названием OS/2. Но у OS/2 были явные недостатки, во-первых она была 16-битной, а во вторых не была портируемой и могла работать только на микропроцессорах фирмы Intel.

Цели разработки Windows NT были сложными и амбициозными. Команда Катлера должна была обеспечить выполнение следующих требований:

  • Поддержка различных микропроцессорных архитектур [на уровне исходных текстов], включая, MIPS, Alpha, PowerPC, и x64.
  • Поддержка запуска приложений других ОС [модель подсистем], включая, UNIX POSIX, OS/2 и Win32.
  • ОС должна быть безопасной и соответствовать стандарту безопасности C2 (trusted computer certification).
  • Поддержка нескольких одновременно работающих микропроцессоров (мультипроцессорная архитектура) и подлинная многозадачность. Обе эти функции считались уникальными на тот момент для сегмента ПК.
Рис. Логотип Windows NT.Одной из самых сложных задач, которую предстояло решить разработчикам, была задача тестирования разрабатываемой ОС. На раннем этапе команда не обладала всеми необходимыми ресурсами для разработки нужного набора тестов. Вместо этого, они сделали выбор в пользу динамической системы проверки стрессоустойчивости, что создало высокую нагрузку на систему в целом. Каждую ночь разработчики запускали стресс-тесты новой ОС на сотнях машин. Утром авторы Windows приезжали в офис и производили сортировку ошибок для последующего их анализа.

Интересно отметить, что первоначально в качестве основной подсистемы Windows рассматривалась не Win32, а OS/2, но позже Microsoft отказалась от этой затеи.[Как и от разработки самой OS/2 как таковой] Отчасти это было связано и с быстро набравшей популярность Windows 3.1, продажи которой составили 16 миллионов копий за полгода. В результате 16-битное Windows API было взято за основу и расширено до 32-х бит. Для новой ОС также была написана своя 32-разрядная графическая подсистема. Позже разработчики были вынуждены адаптировать Windows NT на RISC микропроцессор MIPS R3000 вместо заявленного изначально Intel i860 XR. Еще одной проблемой, которую необходимо решить, была совместимость новой ОС с устаревшими приложениями MS-DOS и 16-битной Windows.

Рис. Архитектура Digital VMS.

Рис. Архитектура Windows NT.

Windows NT 3.1 увидела свет 27 июля 1993 г. В 1996 Катлер оставил руководство всем проектом Windows NT и сконцентрировался на руководстве команды разработки ядра до 2006 г. В марте 2005 года Катлер закончил часть работы по портированию Windows NT на платформу AMD64, когда были выпущены первые 64-битные версии для рабочих станций и серверов. См. также Windows NT and VMS: The Rest of the Story windowsitpro.com/windows-client/windows-nt-and-vms-rest-story

habrahabr.ru

Architecture of Windows 10 - dbj( org );

Windows 10 architecture is not a needle in this haystack.

One of the reasons why so many developers do not understand how the Windows Runtime works (other than looking into its rather sparse documentation) is not just because the tooling and language “projections” do really obscure the underlying platform. No. The real reason is: there is no clear and detailed Windows 10 blueprints. In other words: There is no officially supported, published and reviewed, Windows 10, detailed architecture available.

Why the Architecture?

So who cares about this Architecture “thing” anyway? Simple answer: you, the software developer, should care. Architecture is imposed on you. You do suffer (for many years) or possibly enjoy Windows Architects decisions.

2015 Win10 example: it turns out that for some reason inheritance has been chosen (by Architects) over aggregation in WIN  RT API and especially so in it’s implementation patterns. And then, in the same time, while learning WIN RT API, one is faced with effectively not having interface inheritance in new IDL?  What?! Why?

Well, some Windows 10 Architect (I hope) knows why. But who she is? Where are they? Who do you call for real fundamental and necessary details, if you want to really understand Windows 10 API?

Architecture tells us WHY has something been done or not. Not HOW and not WHEN and not WHO …

“How” might be answered by technical or application Architect. But that is way bellow top level Windows 10 System Architecture we are talking here. Technical/Application Architect is more of an organizational tag for an important role of a senior developer.

Channel 9?

“Channel 9” is full of Architecture. Will it help perhaps, to follow all those Architects over there? Perhaps it will. But none of them clever MSFT Architects, never ever really answers that proverbial “Why” question. Although, as a matter of fact, nobody is asking them. Especially not on Channel 9. And that is funny.

MSDN?

OK then, who else can help and is now over there on the surface of the MSDN ocean? There are indeed guys (possibly called Application Architects) who can show you how actually WIN RT API works. In a great detail, too. How COM is back into the lime light, and HOW C# now understands WIN RT components written in modern C++. As an good example, Kenny Kerr is rather insightful and talented guy. But Kenny just delivers the HOW. Kenny never asks or answers WHY.

Why is Architecture important?

Because (among few other reasons) Architectural decisions are impossible to change after implementation milestone has been reached. Which makes them very important. And in case of mistakes, very (very) expensive.

Paradoxically non existence of Architectural decision is one fact impossible to change. And neither of the two (decisions) is good information to publish. Especially not good for shareholders and the company income.

Existence of Architecture is important, but non existence of Architecture is even more important

How so?  Here is one example. Windows “zero” was quickly built as an MS DOS add-on. Built. Not Architect-ed, designed, built, tested and then again to cycle 2 and the next cycle and so on. The fact that WIN 0.x was never Architect-ed is one fact almost impossible to deny. During last 30+ years, I do not remember anyone has ever tried to deny this. So After 30+ years I will call it a fact.

Thus it is very hard to defend against the claim that Windows 1.0 has generated one enormous technical debt.  Therefore. Publishing Windows 10 (or whichever) blueprints right now might actually break Microsoft. How?

Remember this is not a source code we are talking about here. We are talking about Windows 10 System Architecture. Detailed OS Architecture is a blue print, not a source code. Skyscraper is built by producing (very) detailed blue prints, finished before actual building is built 1.

Existence of Windows detailed architecture published will allow experts to quickly reveal the weak points. Wit the dates. The nightmare details. Inherited all the way back from Windows 0.x.

The speculations from last 30+ years (if that release happens) will quickly transform into facts. People will be able to see there was no Architecture BEFORE Windows 1.0 was ever built. In a way, Windows is one huge multi decade long struggle for hundreds (thousands ?) of good developers. And many  (many) more architects and developers know that. But. There is no detailed published Architecture available and all is just (carefully kept as) one big speculation. We all know they (MSFT developers) are working hard and they are working for years, on each new Windows release. But nobody is telling us, what exactly seems to be the problem, and most importantly why. It is impossible to argue, without Architectural blueprints. No blueprints no discussion.

Why COM (again) ?

Based on this swampy, erratic, shifting grounds is “tower of” COM. Beside WIN NT, COM is one huge achievement in long history of Windows struggle. Let me put it into perspective for you: COM is like deep sea oil rig that has never been broken. Something that is virtually unheard of. And crucially:  each deep sea oil rig improvement always starts by revisiting its architecture. One luxury that (I assume) COM architects have not had.

COM is one Windows subsystem we know a lot of about, and into which we implicitly trust, because Microsoft obviously trusts into COM. We know a lot about COM, but (again) we do not know: WHY. There are no COM blueprints published. No detailed COM System Architecture.

COM “material” is thus an good example of how very carefully Windows Architecture bits and pieces are sanitized and then  released into the “wild”.

Summary

Perhaps some of my older audience remembers Tanenbaum and his “MINIX” OS. Mid last century, people realized computers might become personal. Academia got interested in the challenge, and has produced  OS-es to utilize those little personal computers. People discussed them, re-architect-ed them OS-es, and so on. That has greatly influenced one young Linus Torvalds who has afterwards developed LINUX.  This is how software systems and especially the most complex ones called “operating systems” are and should be developed. Architecture driven, developers built.

And  what about Windows? There is no Academic proof of quality or correctness of WIN Architecture because there is no WIN Architecture to see. It was never published. We know a lot of high level details about Windows. But almost nothing bellow that. Going further will be reverse engineering. The ultimate (and punishable) NO NO.

But (beside LINUX variants) there are few more OS-es, on the market today. Do we know more about them? We do not. Make no mistake:

No modern, commercial OS will have it’s detailed Architecture published.

And here I mean OS System Architecture. Not marketing leaflets block diagrams called “architecture”. It is just too dangerous to publish such a thing called Detailed OS Architecture. Thus, around commercial modern OS-es there is a lot of deliberate speculation, and FUD. Things are happening out of the blue. Or not happening. And we can just speculate WHY. No blueprints no discussion.

Windows 10 Architecture?

I have seen WIN10 and I am using it right now. WIN10 “feels” to me as an  OS well architect-ed. I can “feel” it is quicker then its predecessors working inside the same VM with the same amount or RAM and same sized HD, and same underlying host hardware.  But, I am an Architect and I should be able to objectively quantify this subjective opinion of mine. And, I will. Here it is.

OS Architecture is the biggest crown jewel in every software company’s crown. But there is much more to it. Architecture is not to be sold and it is not ever to be seen. Ever. OS Architecture is the gem stone of great magical power. Power that is lost as soon as the stone is seen.

A rather quantum situation: we know it is there and we know it is fundamental. But we can not directly observe it.

That is the real technical explanation for you, on what is OS Architecture today. Windows 10 including.

1:  Software is not built from brick and mortar, and is thus much easier to bend this simple rule: First Architect, then design and then build. It is even feasible to break this rule and establish software development cycling. But, never without skipping any of these three phases. Never. Which (we can only speculate) was exactly the case with Windows 0.x in those primordial days of software industry.

DBJ.Systems :: Architecture can not be glanced over.

Related

dbj.org

Создание WIM-файла для нескольких типов архитектуры с помощью DISM

При разработке сценариев развертывания необходимо учесть способ развертывания и обслуживания образов для различных типов архитектуры. Существует несколько способов управления образами Windows (R) для различных типов архитектуры. Так как из 32-разрядной среды предварительной установки возможно развертывание 32- и 64-разрядных образов Windows, 32- и 64-разрядные образы Windows можно хранить в одном и том же WIM-файле или в разных WIM-файлах.

Так как в одном WIM-файле можно хранить несколько образов Windows, можно создать отдельные WIM-файлы для разных архитектур или один WIM-файл, содержащий образы для нескольких типов архитектуры.

  • Только 32-разрядные образы

    Можно создать WIM-файл, содержащий образы Windows для одного типа архитектуры. В этом случае создается WIM-файл, содержащий один или несколько образов Windows только для 32-разрядных систем. Для различных типов архитектуры можно создать отдельные WIM-файлы.

  • Только 64-разрядные образы

    Можно создать WIM-файл, содержащий один или несколько развертываемых 64-разрядных образов Windows.

  • 32-разрядный и 64-разрядный образы

    Можно создать WIM-файл, содержащий несколько версий Windows для различных типов архитектуры. Например, можно создать образ Windows, содержащий две версии этой операционной системы: одну для 32-разрядных архитектур, а другую – для 64-разрядных.

Создание образа Windows для нескольких типов архитектуры

Можно создать один WIM-файл, включающий 32- и 64-разрядные образы Windows. У вас должен быть дистрибутив 32-разрядной Windows и 64-разрядный файл Install.wim (дистрибутив Windows – это набор файлов на установочном носителе Windows, включающий не только файл Install.wim, но и дополнительные файлы и каталоги, необходимые для установки). Кроссплатформенные развертывания поддерживаются только из программы установки 32-разрядной версии Windows.

  1. Скопируйте весь дистрибутив 32-разрядной Windows во временный каталог локального компьютера.

  2. Скопируйте 64-разрядный файл Install.wim в отдельный каталог локального компьютера.

  3. В командной строке используйте команду Dism для экспорта 64-разрядных образов Windows в файл Install.wim в дистрибутиве Windows.

  4. Повторите команду Dism /Export-Image для каждого 64-разрядного образа Windows, который нужно добавить в дистрибутив Windows.

Например, если дистрибутив скопирован в папку C:\WindowsDistribution, а 64-разрядный файл Install.wim скопирован в C:\Windows64-bit, выполните следующую команду.

Dism /Export-Image /SourceImageFile:c:\windows64-bit\install.wim /SourceIndex:1 /DestinationImageFile:c:\windowsdistribution\sources\install.wim /DestinationName:"Fabrikam 64-bit Image" Примечание  

Важно добавить имя образа Windows, чтобы указать, что он предназначен только для 64-разрядных компьютеров.

 

Во время экспорта 64-разрядный образ Windows и все необходимые метаданные копируются в файл Install.wim с новым индексом. После добавления всех образов Windows в файл Install.wim этот дистрибутив Windows готов к использованию в вашей рабочей среде.

Во время автоматической установки пользователю предлагается выбрать образ Windows определенной архитектуры для установки (образы x86 или x64).

Если в ходе автоматической установки несколько версий Windows для различных типов архитектуры хранятся в одном WIM-файле, во время установки явным образом указывайте нужный образ с помощью параметра MetaData.

Связанные разделы

Параметры командной строки для управления образами DISM Платформы, поддерживаемые программой установки Windows, и кроссплатформенное развертывание

 

 

msdn.microsoft.com

Smart Card Architecture (Windows 10)

  • 04/19/2017
  • 19 minutes to read
  • Contributors

In this article

Applies To: Windows 10, Windows Server 2016

This topic for the IT professional describes the system architecture that supports smart cards in the Windows operating system, including credential provider architecture and the smart card subsystem architecture.

Authentication is a process for verifying the identity of an object or person. When you authenticate an object, such as a smart card, the goal is to verify that the object is genuine. When you authenticate a person, the goal is to verify that you are not dealing with an imposter.

In a networking context, authentication is the act of proving identity to a network application or resource. Typically, identity is proven by a cryptographic operation that uses a key only the user knows (such as with public key cryptography), or a shared key. The server side of the authentication exchange compares the signed data with a known cryptographic key to validate the authentication attempt. Storing the cryptographic keys in a secure central location makes the authentication process scalable and maintainable.

For smart cards, Windows supports a provider architecture that meets the secure authentication requirements and is extensible so that you can include custom credential providers. This topic includes information about:

Credential provider architecture

The following table lists the components that are included in the interactive sign-in architecture of the Windows Server and Windows operating systems.

Component Description
Winlogon Provides an interactive sign-in infrastructure.
Logon UI Provides interactive UI rendering.
Credential providers (password and smart card) Describes credential information and serializing credentials.
Local Security Authority (LSA) Processes sign-in credentials.
Authentication packages Includes NTLM and the Kerberos protocol. Communicates with server authentication packages to authenticate users.

Interactive sign-in in Windows begins when the user presses CTRL+ALT+DEL. The CTRL+ALT+DEL key combination is called a secure attention sequence (SAS). To keep other programs and processes from using it, Winlogon registers this sequence during the boot process.

After receiving the SAS, the UI then generates the sign-in tile from the information received from the registered credential providers. The following graphic shows the architecture for credential providers in the Windows operating system.

Figure 1  Credential provider architecture

Typically, a user who signs in to a computer by using a local account or a domain account must enter a user name and password. These credentials are used to verify the user's identity. For smart card sign-in, a user's credentials are contained on the smart card's security chip. A smart card reader lets the computer interact with the security chip on the smart card. When users sign in with a smart card, they enter a personal identification number (PIN) instead of a user name and password.

Credential providers are in-process COM objects that run on the local system and are used to collect credentials. The Logon UI provides interactive UI rendering, Winlogon provides interactive sign-in infrastructure, and credential providers work with both of these components to help gather and process credentials.

Winlogon instructs the Logon UI to display credential provider tiles after it receives an SAS event. The Logon UI queries each credential provider for the number of credentials it wants to enumerate. Credential providers have the option of specifying one of these tiles as the default. After all providers have enumerated their tiles, the Logon UI displays them to the user. The user interacts with a tile to supply the proper credentials. The Logon UI submits these credentials for authentication.

Combined with supporting hardware, credential providers can extend the Windows operating system to enable users to sign in by using biometrics (for example, fingerprint, retinal, or voice recognition), password, PIN, smart card certificate, or any custom authentication package. Enterprises and IT professionals can develop and deploy custom authentication mechanisms for all domain users, and they may explicitly require users to use this custom sign-in mechanism.

Note  Credential providers are not enforcement mechanisms. They are used to gather and serialize credentials. The LSA and authentication packages enforce security.

Credential providers can be designed to support single sign-in (SSO). In this process, they authenticate users to a secure network access point (by using RADIUS and other technologies) for signing in to the computer. Credential providers are also designed to support application-specific credential gathering, and they can be used for authentication to network resources, joining computers to a domain, or to provide administrator consent for User Account Control (UAC).

Multiple credential providers can coexist on a computer.

Credential providers must be registered on a computer running Windows, and they are responsible for:

  • Describing the credential information that is required for authentication.

  • Handling communication and logic with external authentication authorities.

  • Packaging credentials for interactive and network sign-in.

Note  The Credential Provider API does not render the UI. It describes what needs to be rendered. Only the password credential provider is available in safe mode.The smart card credential provider is available in safe mode during networking.

Smart card subsystem architecture

Vendors provide smart cards and smart card readers, and in many cases the vendors are different for the smart card and the smart card reader. Drivers for smart card readers are written to the Personal Computer/Smart Card (PC/SC) standard. Each smart card must have a Credential Service Provider (CSP) that uses the CryptoAPI interfaces to enable cryptographic operations, and the WinSCard APIs to enable communications with smart card hardware.

Base CSP and smart card minidriver architecture

Figure 2 illustrates the relationship between the CryptoAPI, CSPs, the Smart Card Base Cryptographic Service Provider (Base CSP), and smart card minidrivers.

Figure 2  Base CSP and smart card minidriver architecture

Caching with Base CSP and smart card KSP

Smart card architecture uses caching mechanisms to assist in streamlining operations and to improve a user’s access to a PIN.

  • Data caching: The data cache provides for a single process to minimize smart card I/O operations.

  • PIN caching: The PIN cache helps the user from having to reenter a PIN each time the smart card is unauthenticated.

Data caching

Each CSP implements the current smart card data cache separately. The Base CSP implements a robust caching mechanism that allows a single process to minimize smart card I/O operations.

The existing global cache works as follows:

  1. The application requests a cryptographic operation. For example, a user certificate is to be read from the smart card.

  2. The CSP checks its cache for the item.

  3. If the item is not found in the cache, or if the item is cached but is not up-to-date, the item is read from the smart card.

  4. After any item has been read from the smart card, it is added to the cache. Any existing out-of-date copy of that item is replaced.

Three types of objects or data are cached by the CSP: pins (for more information, see PIN caching), certificates, and files. If any of the cached data changes, the corresponding object is read from the smart card in successive operations. For example, if a file is written to the smart card, the CSP cache becomes out-of-date for the files, and other processes read the smart card at least once to refresh their CSP cache.

The global data cache is hosted in the Smart Cards for Windows service. Windows includes two public smart card API calls, SCardWriteCache and SCardReadCache. These API calls make global data caching functionality available to applications. Every smart card that conforms to the smart card minidriver specification has a 16-byte card identifier. This value is used to uniquely identify cached data that pertains to a given smart card. The standard Windows GUID type is used. These APIs allow an application to add data to and read data from the global cache.

PIN caching

The PIN cache protects the user from entering a PIN every time the smart card is unauthenticated. After a smart card is authenticated, it will not differentiate among host-side applications—any application can access private data on the smart card.

To mitigate this, the smart card enters an exclusive state when an application authenticates to the smart card. However, this means that other applications cannot communicate with the smart card and will be blocked. Therefore, such exclusive connections are minimized. The issue is that a protocol (such as the Kerberos protocol) requires multiple signing operations. Therefore, the protocol requires exclusive access to the smart card over an extended period, or it require multiple authentication operations. This is where the PIN cache is used to minimize exclusive use of the smart card without forcing the user to enter a PIN multiple times.

The following example illustrates how this works. In this scenario, there are two applications: Outlook and Internet Explorer. The applications use smart cards for different purposes.

  1. The user starts Outlook and tries to send a signed e-mail. The private key is on the smart card.

  2. Outlook prompts the user for the smart card PIN. The user enters the correct PIN.

  3. E-mail data is sent to the smart card for the signature operation. The Outlook client formats the response and sends the e-mail.

  4. The user opens Internet Explorer and tries to access a protected site that requires Transport Layer Security (TLS) authentication for the client.

  5. Internet Explorer prompts the user for the smart card PIN. The user enters the correct PIN.

  6. The TLS-related private key operation occurs on the smart card, and the user is authenticated and signed in.

  7. The user returns to Outlook to send another signed e-mail. This time, the user is not prompted for a PIN because the PIN is cached from the previous operation. Similarly, if the user uses Internet Explorer again for another operation, Internet Explorer will not prompt the user for a PIN.

The Base CSP internally maintains a per-process cache of the PIN. The PIN is encrypted and stored in memory. The functions that are used to secure the PIN are RtlEncryptMemory, RtlDecryptMemory, and RtlSecureZeroMemory, which will empty buffers that contained the PIN.

Smart card selection

The following sections in this topic describe how Windows leverages the smart card architecture to select the correct smart card reader software, provider, and credentials for a successful smart card sign-in:

Container specification levels

In response to a CryptAcquireContext call in CryptoAPI, the Base CSP tries to match the container that the caller specifies to a specific smart card and reader. The caller can provide a container name with varying levels of specificity, as shown in the following table, and sorted from most-specific to least-specific requests.

Similarly, in response to a NCryptOpenKey call in CNG, the smart card KSP tries to match the container the same way, and it takes the same container format, as shown in the following table.

Note  Before opening a key by using the smart card KSP, a call to NCryptOpenStorageProvider (MS_SMART_CARD_KEY_STORAGE_PROVIDER) must be made.

Type Name Format
I Reader Name and Container Name \\.\<Reader Name>\<Container Name>
II Reader Name and Container Name (NULL) \\.\<Reader Name>
III Container Name Only <Container Name>
IV Default Container (NULL) Only NULL

The Base CSP and smart card KSP cache smart card handle information about the calling process and about the smart cards the process has accessed. When searching for a smart card container, the Base CSP or smart card KSP first checks its cache for the process. If the cached handle is invalid or no match is found, the SCardUIDlg API is called to get the card handle.

Container operations

The following three container operations can be requested by using CryptAcquireContext:

  1. Create a new container. (The CNG equivalent of CryptAcquireContext with dwFlags set to CRYPT_NEWKEYSET is NCryptCreatePersistedKey.)

  2. Open an existing container. (The CNG equivalent of CryptAcquireContext to open the container is NCryptOpenKey.)

  3. Delete a container. (The CNG equivalent of CryptAcquireContext with dwFlags set to CRYPT_DELETEKEYSET is NCryptDeleteKey.)

The heuristics that are used to associate a cryptographic handle with a particular smart card and reader are based on the container operation requested and the level of container specification used.

The following table shows the restrictions for the container creation operation.

Specification Restriction
No silent context Key container creation must always be able to show UI, such as the PIN prompt.
No overwriting existing containers If the specified container already exists on the chosen smart card, choose another smart card or cancel the operation.
Context flags

The following table shows the context flags used as restrictions for the container creation operation.

Flag Description
CRYPT_SILENT No UI can be displayed during this operation.
CRYPT_MACHINE_KEYSET No cached data should be used during this operation.
CRYPT_VERIFYCONTEXT Only public data can be accessed on the smart card.

In addition to container operations and container specifications, you must consider other user options, such as the CryptAcquireContext flags, during smart card selection.

Important  The CRYPT_SILENT flag cannot be used to create a new container.

Create a new container in silent context

Applications can call the Base CSP with CRYPT_DEFAULT_CONTAINER_OPTIONAL, set the PIN in silent context, and then create a new container in silent context. This operation occurs as follows:

  1. Call CryptAcquireContext by passing the smart card reader name in as a type II container specification level, and specifying the CRYPT_DEFAULT_CONTAINER_OPTIONAL flag.

  2. Call CryptSetProvParam by specifying PP_KEYEXCHANGE_PIN or PP_SIGNATURE_PIN and a null-terminated ASCII PIN.

  3. Release the context acquired in Step 1.

  4. Call CryptAcquireContext with CRYPT_NEWKEYSET, and specify the type I container specification level.

  5. Call CryptGenKey to create the key.

Smart card selection behavior

In some of the following scenarios, the user can be prompted to insert a smart card. If the user context is silent, this operation fails and no UI is displayed. Otherwise, in response to the UI, the user can insert a smart card or click Cancel. If the user cancels the operation, the operation fails. The flow chart in Figure 3 shows the selection steps performed by the Windows operating system.

Figure 3  Smart card selection behavior

In general, smart card selection behavior is handled by the SCardUIDlgSelectCard API. The Base CSP interacts with this API by calling it directly. The Base CSP also sends callback functions that have the purpose of filtering and matching candidate smart cards. Callers of CryptAcquireContext provide smart card matching information. Internally, the Base CSP uses a combination of smart card serial numbers, reader names, and container names to find specific smart cards.

Each call to SCardUI * may result in additional information read from a candidate smart card. The Base CSP smart card selection callbacks cache this information.

Make a smart card reader match

For type I and type II container specification levels, the smart card selection process is less complex because only the smart card in the named reader can be considered a match. The process for matching a smart card with a smart card reader is:

  1. Find the requested smart card reader. If it cannot be found, the process fails. (This requires a cache search by reader name.)

  2. If no smart card is in the reader, the user is prompted to insert a smart card. (This is only in non-silent mode; if the call is made in silent mode, it will fail.)

  3. For container specification level II only, the name of the default container on the chosen smart card is determined.

  4. To open an existing container or delete an existing container, find the specified container. If the specified container cannot be found on this smart card, the user is prompted to insert a smart card.

  5. If the system attempts to create a new container, if the specified container already exists on this smart card, the process fails.

Make a smart card match

For container specification levels III and IV, a broader method is used to match an appropriate smart card with a user context, because multiple cached smart cards might meet the criteria provided.

Open an existing default container (no reader specified)

Note  This operation requires that you use the smart card with the Base CSP.

  1. For each smart card that has been accessed by the Base CSP and the handle and container information are cached, the Base CSP looks for a valid default container. An operation is attempted on the cached SCARDHANDLE to verify its validity. If the smart card handle is not valid, the Base CSP continues to search for a new smart card.

  2. If a matching smart card is not found in the Base CSP cache, the Base CSP calls to the smart card subsystem. SCardUIDlgSelectCard() is used with an appropriate callback filter to find a matching smart card with a valid default container.

Open an existing GUID-named container (no reader specified)

Note  This operation requires that you use the smart card with the Base CSP.

  1. For each smart card that is already registered with the Base CSP, search for the requested container. Attempt an operation on the cached SCARDHANDLE to verify its validity. If the smart card handle is not valid, the smart card's serial number is passed to the SCardUI * API to continue searching for this specific smart card (rather than only a general match for the container name).

  2. If a matching smart card is not found in the Base CSP cache, a call is made to the smart card subsystem. SCardUIDlgSelectCard() is used with an appropriate callback filter to find a matching smart card with the requested container. Or, if a smart card serial number resulted from the search in Step 1, the callback filter attempts to match the serial number, not the container name.

Create a new container (no reader specified)

Note  This operation requires that you use the smart card with the Base CSP.

If the PIN is not cached, no CRYPT_SILENT is allowed for the container creation because the user must be prompted for a PIN, at a minimum.

For other operations, the caller may be able to acquire a "verify" context against the default container (CRYPT_DEFAULT_CONTAINER_OPTIONAL) and then make a call with CryptSetProvParam to cache the user PIN for subsequent operations.

  1. For each smart card already known by the CSP, refresh the stored SCARDHANDLE and make the following checks:

    1. If the smart card has been removed, continue the search.

    2. If the smart card is present, but it already has the named container, continue the search.

    3. If the smart card is available, but a call to CardQueryFreeSpace indicates that the smart card has insufficient storage for an additional key container, continue the search.

    4. Otherwise, use the first available smart card that meets the above criteria for the container creation.

  2. If a matching smart card is not found in the CSP cache, make a call to the smart card subsystem. The callback that is used to filter enumerated smart cards verifies that a candidate smart card does not already have the named container, and that CardQueryFreeSpace indicates the smart card has sufficient space for an additional container. If no suitable smart card is found, the user is prompted to insert a smart card.

Delete a container
  1. If the specified container name is NULL, the default container is deleted. Deleting the default container causes a new default container to be selected arbitrarily. For this reason, this operation is not recommended.

  2. For each smart card already known by the CSP, refresh the stored SCARDHANDLE and make the following checks:

    1. If the smart card does not have the named container, continue the search.

    2. If the smart card has the named container, but the smart card handle is no longer valid, store the serial number of the matching smart card and pass it to SCardUI *.

  3. If a matching smart card is not found in the CSP cache, make a call to the smart card subsystem. The callback that is used to filter enumerated smart cards should verify that a candidate smart card has the named container. If a serial number was provided as a result of the previous cache search, the callback should filter enumerated smart cards on serial number rather than on container matches. If the context is non-silent and no suitable smart card is found, display UI that prompts the user to insert a smart card.

Base CSP and KSP-based architecture in Windows

Figure 4 shows the Cryptography architecture that is used by the Windows operating system.

Figure 4  Cryptography architecture

Base CSP and smart card KSP properties in Windows

The following properties are supported in versions of Windows designated in the Applies To list at the beginning of this topic.

Note  The API definitions are located in WinCrypt.h and WinSCard.h.

Property Description
PP_USER_CERTSTORE - Used to return an HCERTSTORE that contains all user certificates on the smart card- Read-only (used only by CryptGetProvParam)- Caller responsible for closing the certificate store- Certificate encoded using PKCS_7_ASN_ENCODING or X509_ASN_ENCODING- CSP should set KEY_PROV_INFO on certificates- Certificate store should be assumed to be an in-memory store- Certificates should have a valid CRYPT_KEY_PROV_INFO as a property
PP_ROOT_CERTSTORE - Read and Write (used by CryptGetProvParam and CryptSetProvParam)- Used to write a collection of root certificates to the smart card or return HCERTSTORE, which contains root certificates from the smart card- Used primarily for joining a domain by using a smart card- Caller responsible for closing the certificate store
PP_SMARTCARD_READER - Read-only (used only by CryptGetProvParam)- Returns the smart card reader name as an ANSI string that is used to construct a fully qualified container name (that is, a smart card reader plus a container)
PP_SMARTCARD_GUID - Return smart card GUID (also known as a serial number), which should be unique for each smart card- Used by the certificate propagation service to track the source of a root certificate
PP_UI_PROMPT - Used to set the search string for the SCardUIDlgSelectCard card insertion dialog box- Persistent for the entire process when it is set- Write-only (used only by CryptSetProvParam)

Implications for CSPs in Windows

Credential Service Providers (CSPs), including custom smart card CSPs, continue to be supported but this approach is not recommended. Using the existing Base CSP and smart card KSP with the smart card minidriver model for smart cards provides significant benefits in terms of performance, and PIN and data caching. One minidriver can be configured to work under CryptoAPI and CNG layers. This provides benefits from enhanced cryptographic support, including elliptic curve cryptography and AES.

If a smart card is registered by a CSP and a smart card minidriver, the one that was installed most recently will be used to communicate with the smart card.

Write a smart card minidriver, CSP, or KSP

CSPs and KSPs are meant to be written only if specific functionality is not available in the current smart card minidriver architecture. For example, the smart card minidriver architecture supports hardware security modules, so a minidriver could be written for a hardware security module, and a CSP or KSP may not be required unless it is needed to support algorithms that are not implemented in the Base CSP or smart card KSP.

For more information about how to write a smart card minidriver, CSP, or KSP, see Smart Card Minidrivers.

docs.microsoft.com

Windows 10 на ARM » MSReview – Новости из мира Windows

10 мая началась ежегодная конференция разработчиков Microsoft Build. Среди прочего компания рассказала на ней о процессе создания системы Windows 10 на ARM. Были показаны интересные демонстрационные ролики, которые помогут разработчикам универсальных приложений подготовиться к появлению Windows 10 на ARM. Также было рассказано о том, как работает технология эмуляции приложений x86.

В ближайшие четыре года больше миллиарда человек подключатся к интернету в первый раз. Поможет им в этом сотовая связь. Её скорость постоянно увеличивается, доступ становится дешевле. Уже сейчас Microsoft предлагает множество устройств с поддержкой стандартов связи Wi-Fi и LTE. Пользователи ожидают наличия связи в любом месте, будь то общественный транспорт, собственная квартира, ресторан или школа.

При наличии такого спроса перед платформой Windows открываются новые возможности. На ней необходимо выпускать устройства с поддержкой сотовой связи и с хорошей продолжительностью автономной работы. Именно для этого создаётся Windows 10 на ARM. Устройства на этой операционной системе будут работать на процессорах Qualcomm Snapdragon, в которые встроен модем и которые расходуют минимум энергии, что повышает продолжительность работы.

Windows 10 на ARM предложит привычный пользователям рабочий стол. Здесь будут браузер Edge, цифровой ассистент Cortana, функция авторизации Windows Hello и Windows Ink. Здесь же будут все привычные программы, универсальные приложения из магазина Windows Store, в том числе и на архитектуре Win32.

Последнее нужно отметить особо: Windows 10 на ARM будет поддерживать все существующие приложения на архитектуре x86. Произойдёт это благодаря эмуляции. Для примера была показана работа программы PowerPoint на Windows 10 на ARM. Использовалась инженерная версия устройства производства компании Qualcomm. Именно такие устройства Microsoft применяет для разработки системы Windows на архитектуре х64. Естественно, в продажу такие устройства не поступают. Пользователи получат традиционные ноутбуки, устройства два в одном и другие форматы до конца нынешнего года.

Также была продемонстрирована работа пакета приложений Office в Windows 10 на ARM. Использовался Office 2016 и программа PowerPoint. Открыв системные настройки, можно увидеть её свойства. Там указана 64-разрядная система Windows 10 Pro на архитектуре ARM, устройство работает на процессоре Snapdragon 835, объём оперативной памяти 4 Гб. Поскольку это полноценная версия системы Pro, устройство можно подключить к домену.

Если открыть диспетчер задач в разделе Производительность, здесь будут отображаться восемь вычислительных ядер процессора Snapdragon 835, четыре больших, четыре поменьше. Следом был запущен браузер Edge, он работает быстро и плавно.

При работе на Windows 10 взаимодействие с системой не ограничивается одним только рабочим столом. Ещё есть приложения и устройства. Windows 10 на ARM обеспечит обширную поддержку периферийных устройств через USB, все необходимые драйверы будут предустановлены в системе. Чтобы продемонстрировать это, была подключена USB-камера. После подключения она сразу же начинает работать без необходимости настраивать её. Остаётся только запустить приложение камеры и снимать видео и фотографии.

Всё вышеописанное было нативной работой системы. Рассмотрим теперь эмуляцию приложений. Например, вам присылают несколько файлов. Они находятся в архиве, который создан при помощи программы вроде 7-zip. Чтобы распаковать файлы, нужно найти в интернете эту программу, скачать и установить на компьютер. Всё то же самое нужно делать и на Windows 10 на ARM. Процесс установки ничем не отличается от существующего сейчас на обычных версиях Windows. Используется обычный установочный файл без всяких изменений, скаченный из интернета.

Ниже поговорим о том, как именно работает эмулятор приложений x86. Было показано несколько диаграмм, используется нативный процесс х64. Windows, браузер Edge, оболочка, все они являются примерами нативных процессов. В библиотеках операционной системы содержатся файлы .dll, также есть нечто под названием NTDLL, посредством которого приложения общаются с ядром операционной системы. Ещё следует упомянуть настоящее ядро Windows и драйверы. Они общаются с устройствами, такими как графический чип, сетевые устройства и другие, на их собственных скоростях. Нативные процессы используют все возможности ARM64.

При эмуляции процесс работает поверх уровня Windows на Windows (WOW). Похожая инфраструктура имеется на компьютерах на архитектуре х64 для запуска приложений x86. В этих приложениях есть код x86, исполняемые файлы и файлы системы. Доступна версия файлов x86 и вторая часть процесса, где используется нативный код. Используется эмулятор центрального процессора, который в обычном 64-разрядном компьютере исполняет 32-разрядный код. Вместо этого здесь используется Dynamic Binary Translator, который смотрит на куски кода и в среде исполнения преобразует их в блоки кода x64. Они сохраняется в памяти или на диске для дальнейшего использования. Системные вызовы производятся через нативную систему NTDLL, все они общаются с ядром. Взаимодействие с ядром и устройствами происходит на привычных для устройств скоростях.

Отдельно стоит поговорить об уровне абстракции WOW и о том, почему система x86 запускается с эмуляцией DOL. На это есть пара причин. Приложение общается с двоичным кодом при помощи 32-разрядных типов данных и 32-разрядных стандартов оформления кода. Если преобразовывать нативные файлы DLL, придётся менять все интерфейсы программирования, постоянно менять типы данных между 32- и 64-разрядными и выполнять сериализацию стандартов вызовов.

Сериализацию стандартов вызовов можно осуществлять автоматически, но сериализация типов данных является сложной задачей. В результате в Microsoft решили выполнять сериализацию типов данных только на этом уровне.

Это выгодный компромисс, благодаря которому аппаратное обеспечение работает на нативных скоростях. Архитектура х86 в данном случае не играет роли. Когда речь идёт о динамической двоичной трансляции, происходит перерасход ресурсов при обработке всего этого кода. По этой причине совместно с группой разработчиков компилятора велась работа на технологией под названием CHPE (скомпилированные гибридные портативные исполняемые файлы).

Они генерируются из того же кода, который есть в системе, поэтому используются стандарты вызовов ARM64, работа ведётся с 32-разрядными типами данных. Была выполнена автоматизация стандартов вызовов, это позволяет работать с 32-разрядными типами данных. Таким образом, преобразование типов данных происходит только на этом уровне. Чаще всего работа ведётся на нативных скоростях. Перед нами идеально установленный двоичный код, который можно использовать в процессе. В зависимости от времени, потраченного между кодом приложений, системным кодом и ядром, можно получить близкую к нативной производительность.

После этого краткого анализа уровня эмуляции x86 посмотрим на универсальные приложения. Приложения магазина открываются почти мгновенно. Был выполнен поиск популярного приложения iHeartRadio, оно было установлено и запущено. Программа работает быстро, страницы прокручиваются плавно. Перед нами образец работы универсального приложения на архитектуре ARM. Повторим, что приложения x86 эмулируются, но универсальные приложения запускаются нативно. Чтобы увидеть это, достаточно открыть диспетчер задач. Там показывается, что приложение iHeartRadio 32-разрядное на ARM. В программу не нужно вносить никаких изменений, она работает в своём нынешнем состоянии.

Точно также нативно работает сам магазин приложений, что тоже можно увидеть в диспетчере задач в разделе свойств. Как видим, универсальные приложения оправдывают своё название. Для их работы на разных архитектурах не нужно вносить в код никаких изменений. В будущем появится стандарт Windows Standart ARM, разработчикам приложений достаточно будет выставить его в магазин.

msreview.net


Смотрите также