Windows research kernel это

Обновлено: 04.07.2024

Современные приложения и игры отличаются большим размером и детальной прорисовкой графики. Соответственно, работа с ними требует от ПК особой мощности. Часто пользователи сталкиваются, что во время работы и игрового процесса возникает Windows ошибка kernel – критический сбой в процессе работы. Некоторые компьютеры показывают BlueScreen – синий экран смерти, в некоторых случаях устройство перестает откликаться на любое действие.

Ошибка kernel. Общие сведения о неполадке

Ошибка Kernel-Power имеет кодировку 43. Возникновение такой проблемы означает, что у компьютера выявлено нарушение мощности ядра системы. Она относится к 63й категории, что означает невозможность Windows обрабатывать одновременно большое количество запросов и выполнять сложные операции. Именно это объясняет процесс торможения и подвисания современных компьютерных аркад.
На самом деле, выяснить точные проблемы возникновения Kernel-Power достаточно сложно, даже официальный сайт Майкрософт не предоставляет конкретных данных.

Существует ли лечение?

В случае, когда ПК зависает, отказываясь реагировать на любую команду мыши или клавиатуры, помогает только режим перезагрузки, попасть в который можно только с помощью длительного нажатия и удерживания кнопки питания. Но это не гарантирует дальнейшую бесперебойную работу. Вероятнее всего, что первые несколько минут/часов система проработает без нареканий, а затем повторно появится проблема.
Опытным путем стало понятно, что полная переустановка системы тоже не помогает. Отсюда напрашивается вывод, что проблема находится на уровне взаимодействия системы, ПО, ОЗУ, ПЗУ и жесткого диска. Действительно, прочитав рекомендуемые требования на упаковке диска с игрой, можно обнаружить что требования, предъявляемые к «железу», для того чтобы игра установилась, запустилась и шла ровно и плавно достаточно высокие. Кроме этого, рекомендуется проверить все ли шлейфы подключены к разъемам нет ли заломов, а также стабильность работы блока питания.

Windows ошибка kernel. Настройка Биоса

Одной из причин, вызывающих Kernel-Power является критический перегрев процессора. Это может случиться по двум причинам:

  • Его слишком сильно разогнали
  • Он не предназначен для сильных нагрузок
  • Высохла термопаста
  • Плохая система отвода тепла

Первое действие, которое нужно выполнить в таком случае, это проверить исходные данные ЦП и снизить все завышенные показатели, непосредственно связанные с разгоном. Так как для большинства обычных пользователей такие манипуляции выполнить достаточно трудно, в этом случае рекомендуется просто сделать откат до базовых заводских настроек.
Если вы используете не ноутбук, а простой компьютер, то можно достать материнскую плату и на некоторое непродолжительное время вынуть батарейку. Можно попробовать перевести Clear CMOS из положения «1-2» в положение «2-3» меньше чем на минуту, а затем вернуть его в исходное положение. Это тоже приведет к полному сбросу. Правда, этот способ тоже не гарантирует решения проблемы.

Тестирование центрального процессора

При повторном обнаружении Kernel-Power стоит провести тестирование центрального процессора ПК. Для этого скачивается и распаковывается специальная программа Everest. С ее помощью можно выяснить какие компоненты дали сбой. Правда, сделать восстановление через утилиту невозможно. Оптимально провести тестирование при помощи Prime95. Выбираете Just Stress Testing в опциях раздела Torture Test.

Сбой работы Kernel-Power может быть связан с ошибками в работе оперативной памяти. Проверить память можно несколькими способами. Первый – при помощи стандартной системной программы, введя в командную строку «mdsched»,и запустив перезагрузку системы с ее тестированием. Выполнить это можно только при условии, что вы зашли через учетную запись Администратора.
В случае, если проверка не выявила никаких неполадок можно прибегнуть к физическому способу – поочередно извлекать из своих слотов планки оперативной памяти каждый раз выполняя перезагрузку ПК. Если после определенного извлечения компьютер работает нестабильно, значит проблема кроется в ней, и стоить заменить ее на идентичную.

Проблема с жестким диском

Еще одна распространенная проблема заключается в том, что многие жесткие диски плохо стыкуются в 64-х битной операционной системой. Чаще всего этим страдают винчестеры бренда Seagate, установленные в большинстве современных бюджетных ноутбуков.
Для проверки необходимо скачать и установить HDD Life или HDD Health, запустить соответствующую проверку. В редких случаях может потребоваться обновление прошивки жесткого диска до последней версии. Если неполадки заключаются в винчестере, решения может быть два – замена жесткого диска или ремонт в соответствующих сервисных центрах. Правда, он не дает гарантий, что через некоторое время вам не потребуется приобретать новый жесткий диск.
Можно попробовать самостоятельно восстановить битые кластеры жесткого диска при помощи пакета утилит HDD Regenerator, но и она не гарантирует восстановление жесткого диска в его первоначальное состояние.

Проблема звуковых и видеокарт

Такая проблема зачастую возникает в случае, если на ПК были установлены две звуковые или видеокарты. Установленные программы пытаются работать с обеими, что приводит к сильнейшим сбоям на программном уровне. Для решения данной проблемы следует удалить один из чипов или правильно настроить параллельную работу двух карт.

Драйвера сетевой карты

Появление ошибки Kernel-Power может быть спровоцировано не обновлёнными вовремя драйверами сетевой карты или неправильная их распаковка и установка. В этом случае можно попробовать сделать следующее:

Зайти на официальный сайт разработчика и скачать последнюю версию, после чего провести установку,
Если версия относится к последним, полностью удалить драйвера, после чего переустановить их и перезапустить ПК.

Обновление системы

Для того, чтобы постараться избежать появления многих системных ошибок, рекомендуется разрешить Windows обновлять элементы самостоятельно в автоматическом режиме. Проблемы, связанные с «железом», это не решит, а вот системных избежать удастся.
Зайдите в Центр обновления Windows, поставьте галочку напротив нужного режима. В этом случае, предпочтение стоит отдать полной автоматизации, чтобы избежать ручных действий.

Kernel-Power представляет собой серьезную и непростую ошибку, конкретные причины которой установить пока не удалось. Если ни один из вышеперечисленных методов не дал положительного результата, или проблема пропала на короткий промежуток времени, а затем появилась снова, рекомендуется обратиться в сервисную службу.

В 2006 году корпорация Microsoft в рамках академической программы Windows ( Windows Academic Program) сделала доступной для академических организаций исходный код исследовательского ядра Windows ( Windows Research Kernel , WRK) [15]. WRK основано на коде операционных систем Windows Server 2003 SP1 и Windows XP x64 [13; 11].

Кроме WRK в академическую программу Microsoft входят следующие компоненты [15]:

  • учебные материалы по курсу операционных систем на основе Windows XP – Windows Internals Curriculum Resource Kit (CRK). Составлены в соответствии с рекомендациями ACM/IEEE по преподаванию курса "Операционные системы" (Operating systems, OS) [4]. Материалы включают презентации лекций, указания к лабораторным работам (в том числе лабораторные работы для Windows 7), задания, тесты, а также материалы для преподавателей (Instructor Supplement);
  • среда ProjectOZ для экспериментального исследования ядра Windows;
  • описание опыта университетов (Faculty Experiences) по преподаванию в рамках академической программы Microsoft.

Все компоненты Windows Academic Program, кроме WRK и материалов для преподавателей ( Instructor Supplement), доступны любому желающему. WRK и Instructor Supplement можно получить, подтвердив свой статус преподавателя или по подписке Microsoft Developer Network Academic Alliance ( MSDN AA).

Microsoft, предоставляя академическому сообществу исходные коды ядра Windows , преследовало следующие цели [11]:

  • облегчить студентам и преподавателям сравнение Windows с другими операционными системами;
  • предоставить студентам возможность для изучения исходных кодов ядра и создания собственных проектов на их основе;
  • поддержать исследования и публикации по внутреннему устройству Windows;
  • содействовать разработке учебников по операционным системам на основе ядра Windows;
  • упростить лицензирование.

Исследовательское ядро Windows включает более 800 000 строк исходного кода, в основном на языке программирования C, но есть файлы и на ассемблере. В процессе подготовки к опубликованию исходный код в некоторых местах был упрощен, а комментарии улучшены [11].

На рис.5.1 представлена схема, отражающая покрытие исходным кодом WRK компонентов ядра [13].

Покрытие исходным кодом WRK компонентов ядра (выделено серым цветом)


Рис. 5.1. Покрытие исходным кодом WRK компонентов ядра (выделено серым цветом)

Как видно из рисунка, исходные коды практически всех компонентов исполнительной системы (кроме диспетчера Plug-and-Play и диспетчера электропитания) и ядра представлены в WRK.

Структура Windows Research Kernel

В состав WRK, кроме собственно исходных кодов ядра Windows , входят руководство по ядру Windows NT (NT OS/2 Design Workbook ) и решение (solution) Visual Studio 2008 (WRK.sln) (которое можно преобразовать для более новых версий Visual Studio).

Руководство по ядру Windows NT было составлено в конце 1980 х – начале 1990 х гг., когда в Microsoft велась разработка новой операционной системы Windows NT с рабочим названием "NT OS/2 " сначала совместно с IBM , затем самостоятельно. Руководство содержит ценную информацию по структуре и функциям ядра Windows , а также раскрывает соображения, которые привели разработчиков к тем или иным архитектурным решениям.

Главные компоненты WRK находятся в папке WRK-v1.2\base\ntos и включают, в основном описания и определения функций и структур данных. В ядре Windows при именовании функций используются определенные соглашения [5; 2]. Название функции обычно строится по следующей схеме:

где < Префикс > обозначает модуль , которому принадлежит функция , <Операция> – действие, совершаемое над <Объектом>.

Например, рассмотрим функцию KeStartThread:

  • Ke (префикс) – функция входит в состав ядра;
  • Start (операция) – функция начинает выполнение объекта;
  • Thread (объект) – объектом является поток.

В таблице 5.1 приведены основные компоненты WRK (см. соответствие с компонентами на рис.5.1) с указанием префиксов входящих в их состав функций.

Кроме перечисленных в таблице, в WRK есть ещё два важных компонента:

  • inc – общедоступные заголовочные файлы;
  • init – функции инициализации системы.

Приведем ещё один префикс часто встречающихся в WRK функций – Nt. Функции ядра с этим префиксом входят в Native API , они экспортируются Ntdll.dll, их можно вызывать из пользовательского режима. Часто функции с префиксом Nt соответствует WinAPI функция , и, например, при вызове WinAPI функции CreateProcess происходит вызов функции NtCreateProcess.

HTML документация по WRK

HTML документация по WRK включает 4 раздела: функции (functions), типы данных (types), синонимы (typedefs) и макросы (macros) (рис.5.2).

HTML документация по Windows Research Kernel


Рис. 5.2. HTML документация по Windows Research Kernel

По информации, предоставляемой HTML документацией, WRK содержит 4167 функций и 1957 типов данных.

Резюме

В данной лекции представлен обзор исследовательского ядра Windows ( Windows Research Kernel , WRK). Перечислены компоненты WRK. Предложено использование HTML документации по WRK.

В следующей лекции будут рассмотрены основные объекты, отвечающие за работу приложений – процессы и потоки.

Цели уникального проекта по предоставлению академическому сообществу исходных кодов ядра Windows состоят в следующем:

  • Облегчить преподавателям и учащимся сравнение и нахождение различий в отношении Windows и других операционных систем;
  • Предоставить учащимся возможность изучать исходный код, вносить изменения и создавать проекты;
  • Обеспечить действенную поддержку исследованиям и публикациям по ОС;
  • Способствовать изданию большего числа учебников по ОС и предназначенных для университетов книг по внутренней организации ядра Windows;
  • Упростить лицензирование, чтобы разрешить использование исходных кодов Windows на классных занятиях и в лабораторных работах.

Использование WRK.Комплекс WRK может быть использован прежде всего для лабораторных работ по программированию – например, для внесения изменений или создание проектов в целях преподавания и проведения экспериментов. Пример возможного проекта: планирование в ОС на основе round-robin (справедливого раздела).

WRK может быть использован также для детального изучения исходного кода, что особенно удобно, если для обучения используется пакет CRK.

WRK может быть использован для студенческих проектов для выпускного курса (дипломов, магистерских диссертаций).

WRK также является хорошей основой для перспективных исследований в рамках кандидатских диссертаций.

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

В области лабораторных работ по программированию ОС UNIX на сегодняшний день представлена лишь в виде игрушечной ОС (Minix) или симуляторов Nachos и XINU.

ProjectOZ достаточно прост, но, тем не менее, обеспечивает реальные функциональные возможности ОС и простую среду разработки с инструментами для сборки, отладки и разработки инструментария.

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

Уровень SPACE проекта ProjectOZ поддерживает более сложные абстракции оборудования. Базовый уровень проекта, BasicOZ, предоставляет основные примитивы функций операционной системы. Поэтому времени на обучение требуется совсем немного, и учащиеся смогут очень быстро перейти к созданию собственных проектов, расширяя BasicOZ.

Статьи к прочтению:

Windows kernel: краткий курс молодого бойца (Артем Шишкин)


Похожие статьи:

Сегодня мы продолжим разговор о том, как помочь тебе выжить в суровых условиях ядра Windows, на территории, со всех сторон простреливаемой аверами и проактивными защитами. И не просто выжить, а сделать это красиво, элегантно и с наименьшими потерями.

Разработчики малвари постоянно жалуются, что их боты мрут, как мухи, аверы все сильнее закручивают гайки, и выживать в системе становится все сложнее и сложнее. Но не стоит отчаиваться – есть еще порох в пороховницах и ягоды в ягодицах. В подтверждение этому можно привести тот факт, что на широких просторах «тырнета» с определенной периодичностью отлавливаются все новые и новые зверушки типа Rustock'a или TDSS, которые формально уже должны были быть побеждены. А если поразмыслить о том, сколько еще тайных ботов будет выявлено, то можно с уверенностью утверждать, что в среднесрочной перспективе разработчики аверов и проактивных защит без работы точно не останутся.

Введение

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

Рассмотрим ситуацию: тебе всеми правдами и неправдами удалось установить драйвер в систему, и ты уже радостно потираешь свои руки, поскольку, как тебе говорили, проникновение в ядро делает тебя его повелителем. И плевать ты хотел на то, что какой-то авер что-то там контролирует.

Но не тут-то было! Проникновение в ядро, будь то установка своего драйвера или инфект уже установленного, при наличии в системе очень популярной антивирусной шушеры, не даст тебе ровным счетом ничего. Даже если ты наивно полагаешь, что исполнение твоего мегакода в ядре сделает тебя его полновластным Черным Властелином.

Такая ситуация могла быть абсолютно реальной еще несколько лет назад, когда kernel-based руткиты только-только стали появляться на публике, и аверам пришлось приспосабливаться к тому, что вирусы уже начали осваивать неизведанную ранее территорию – ядро операционной системы.

Почти каждый руткит, который можно найти в паблике, или который так или иначе попадал в мои руки, прямо или косвенно использовал системные сервисы – а куда без них? И ведь верно, уж такова архитектура ОС марки Windows, что и вирусы/руткиты, и аверы в ядре, кто для выживания, а кто – для охоты, используют один и тот же набор системных сервисов, куда входят те, которые можно найти в таблицах KeServiceDescriptorTable/KeServiceDescriptorTableShadow, экспорте ядра и важнейших драйверов.

KeServiceDescriptorTable – ключ ко всей системе

Ну, или почти ко всей системе. Первое, что сделает порядочный антивирус и файрвол, чтобы надавать по рукам мегакулхацкерам – установит свои перехватчики на KeServiceDescriptorTable – в ней содержатся адреса системных сервисов, таких как, например NtCreateFile, NtCreateProcess, NtCreateThread и т.д. Для чего это делается, я думаю, понятно – чтобы иметь возможность отслеживать вызовы потенциально опасных для стабильности ОС системных сервисов (работы с виртуальной памятью, реестром, привилегиями и тому подобными штуками). Как правило, такие функции перехватываются всеми аверами подряд, поэтому можно не сомневаться – если на машине стоит хоть что-нибудь антивирусное, будь уверен – в KeServiceDescriptorTable найдется пара-тройка, если не десяток перехватов системных сервисов. Их количество варьируется от одного (F-Secure, например, перехватывает только NtLoadDriver) до «до хрена и больше» (в случае с COMODO Internet Security или Outpost). Все это, естественно, не радует глаз начинающего системного прогера. К примеру, Kaspersky AV вообще грузит (грузил?) свою SSDT, благодаря чему все системные вызовы так или иначе проходят через его адресное пространство.

Не сильно от KeServiceDescriptorTable отличается теневая таблица KeServiceDescriptorTableShadow. Ее второй элемент содержит таблицу win32k.sys, драйвера, на котором в свою очередь держится вся графическая подсистема Windows. Win32k.sys содержит два типа сервисов: сервисы NtUser* и NtGdi*, первые отвечают за оконную подсистему, вторые за графику. Несмотря на неприглядное название и недокументированность, использование сервисов Win32k довольно популярно в андеграундной хакерской среде: посмотри на те сервисы, которые перехватывают аверы в KeServiceDescriptorTableShadow - NtUserFindWindowEx, NtUserQueryWindow, NtUserGetForegroundWindow – все они отвечают за работу с windows-окнами.

Для начала получим указатель на KeServiceDescriptorTable. Чтобы это сделать, просто добавь в свой код такую строку: extern PVOID KeServiceDescriptorTable. Получить адрес KeServiceDescriptorTableShadow немного сложнее, она не экспортируется, код для ее получения ты можешь найти на диске.

Итак, что же делать? Как убрать установленные хуки? Самый дешевый и сердитый способ – просто восстановить SSDT и выполнить свой код, а там – хоть трава не расти. Сделать это, несмотря на сложное название, довольно просто. Сначала мы через вызовы ZwOpenFile/ZwCreateSection/ZwMapViewOfSection найдем и промаппим в свою виртуальную память образ ядра ntoskernl.exe (ntkrnlpa.exe для многоядерных систем). Далее находим в полученной проекции ядра указатель на KeServiceDescriptorTable, после чего в цикле восстанавливаем адреса оригинальных обработчиков.

Находим адрес KiServiceTable

ULONG FindKiServiceTable( ULONG SdtPtr, ULONG Handle )
ULONG bFirst = 1, RvaPtr, i;
pointer = (char *)Handle;
pointer += 0x3c;
pointer = (char *)(*(ULONG *)pointer) + Handle + 0xA0;
reloc = (PIMAGE_BASE_RELOCATION)((char *)
(*(ULONG *)pointer) + Handle);
while ((bFirst) || (reloc->VirtualAddress))
bFirst = 0;
fixup = (PIMAGE_FIXUP_ENTRY)((ULONG)reloc + 8);
for (i = 0; i < ( reloc->SizeOfBlock - 8) >>
1; i++, fixup++)
if ( fixup->type == 3)
RvaPtr = reloc->VirtualAddress +
fixup->offset;
if (*(PULONG)( Handle + RvaPtr) –
0x400000 == SdtPtr)
if (*(PUSHORT)( Handle + RvaPtr - 2)
== 0x05c7)
return (*(PULONG)
( Handle + RvaPtr + 4) - 0x400000 + Handle);
>
>
*(PULONG)&reloc += reloc->SizeOfBlock;
>
return 0;
>

Минусы такого способа, я думаю, очевидны – практически все аверы и проактивки следят за состоянием своих хуков, установленных в SSDT и, обнаружив их отсутствие, тут же их восстановят. К тому же нельзя игнорировать тот факт, что все порядочные аверы перехватывают NtCreateSection и NtMapViewOfSection, без которых при проецировании ядра не обойтись. Что делать в этом случае, ты узнаешь ближе к концу статьи.

Код, реализующий восстановление SSDT и ShadowSSDT, ты можешь найти на диске.

Position number two

Как ни крути, выжить в условиях тотального контроля за системой очень и очень сложно.

При вызове системного сервиса ядро находит указатели на KeServiceDescriptorTable и KeServiceDescriptorTableShadow, которые хранятся в структуре KTHREAD. Мы дружно маппим ядро, находим в нем указатель на старую, неизмененную KeServiceDescriptorTable. Далее подменяем в «живой» KeServiceDescriptorTable указатели на системные сервисы своими, а в KTHREAD.ServiceDescriptorTable сохраняем указатель на найденную ранее неизмененную KeServiceDescriptorTable.

Вуаля! Этим незатейливым способом можно поставить в тупик не один продвинутый авер. Как это сделать в ядре? Чтобы получить указатель на структуру ETHREAD, частью которой является структура KTHREAD (не веришь – сам посмотри), можно вызвать функцию PsLookupThreadByThreadId (как вариант – PsLookupProcessThreadByCid), в которые нужно передать хендл потока, либо выполнить такой несложный код:

__asm push esi;
__asm mov esi, fs:[0x124].

После этого в регистре esi будет находиться искомый указатель на ETHREAD. Что делать дальше, я думаю, ты поймешь.

Position number три

Есть еще один вариант: оставить не слишком расторопный авер с носом (или что там у них между ног, я не помню :)). Вспомним тезисы, изложенные мной в одной из прошлых статей, посвященных организации виртуальной памяти в Windows. В частности, там шла речь о подмене PTE для нужных виртуальных адресов, в результате чего появляется интересная возможность изменения данных в АП целевого процесса без вызова контролируемых аверами системных функций типа NtWriteVirtualMemory. Вспомнил? Так вот, что мешает нам сделать то же самое здесь? Проецируем ядро уже известными шагами, находим KeServiceDescriptorTable и адрес интересующей нас функции и вызываем ее, но только не через виртуальный адрес, а с адреса, считанного с PTE. Экстремалам и мазохистам можно предложить и такой способ: считывать нужный нам адрес напрямую из физической памяти. Он легко находится вот таким простым способом:

ULONG_PTR GetPhysicalAddress(IN ULONG_PTR VirtualAddress)
<
return (VirtualAddress & 0x1FFFFFFF);
>

Еще одно ядро?

А почему нет? Можно пойти двумя путями. Первый – пропатчить ядро Windows на диске. Делается это элементарно – CreateFile/ReadFile/WriteFile. После любой модификации системных файлов необходимо пересчитать их контрольную сумму, иначе Windows просто откажется их загружать.

Экстремалам я могу предложить такой способ: собираем свое ядро из сорцов WRK (Windows Research Kernel), правим его при этом, как хотим, а затем – заменяем им ядро операционной системы и начинаем властвовать. Предвижу бурю недовольства и шквал вопросов, дескать, что это невозможно, что существует и SFC, и ядро весит несколько мегабайт… Да, не спорю, способ трудоемок, но вполне реализуем. И главное – может принести массу дивидендов. Каких? Если у тебя в руках будет свое полностью контролируемое ядро, то дивиденды ты будешь придумывать сам.

Да и потом, простые эксперименты с ядром Windows в стиле «а-ля Linux» будут очень полезны для начинающего системного кодера, пусть даже эти эксперименты не будут направлены на обеспечение безопасности системы. Если ты из числа этих самых экстремалов – сорцы WRK ты сможешь найти на диске. Для начала собери их у себя на машине, а затем тщательно протести на виртуалке, перед тем, как рисковать установкой этого ядра на рабочую машину.

Pro & cons

Ну что ж, пора подводить итоги. Выжить в ядре, даже будучи в условиях тотального контроля со стороны бдительных аверов, можно. Самое главное, чего нельзя делать – это недооценивать разработчиков антивирусов, файрволов и прочих защитных системы – они грамотные люди и зря свой хлеб не едят. Однако лазейки для выживания найти всегда можно, если хорошенько покопаться. И не стоит, наверное, серьезно относиться к вышеописанному :). Просто взгляни на смысл послания как на демонстрацию «proof of concept».
Удачного компилирования, и да пребудет с тобой Сила!

На диске ты найдешь WRK – Windows Research Kernel, альтернативные сорцы для сборки ядра Windows. Крайне полезный подгон для изучения внутренностей Windows :).

В лекции рассмотрены следующие вопросы: академическая программа Windows (WAP); исследовательское ядро Windows с открытыми исходными кодами (WRK); комплект учебных материалов по Windows фирмы Microsoft (CRK); проект Oz по созданию исследовательских ОС на базе WRK.

Академическая программа Microsoft Shared Source Initiative

Академическая программа Microsoft Windows Academic Program

Компоненты академической программы Windows

Пакет учебных ресурсов CRK

Исследовательское ядро Windows Research Kernel

Контактная информация и ссылки

Набор для практики

Темы для курсовых работ, рефератов, эссе

При подготовке данной и предыдущей лекций были использованы презентации докладов коллег из Microsoft Redmond Дейва Проберта и Аркадия Ретика на семинаре по операционным системам в Политехническом университете, Санкт-Петербург, октябрь 2007 г. Автор благодарен коллегам за любезно предоставленные материалы. Содержание данной лекции – академические программы Microsoft по операционным системам, открытым исходным кодам и их использование в преподавании и обучении.

Академическая программа Microsoft Shared Source Initiative

Программа Shared Source Initiative (SSI) — это организационная структура, целью которой является предоставление доступа к исходным кодам продуктов Microsoft для преподавания и исследований. Программа SSI включает в себя технологии и лицензии для частных лиц и организаций.

Программа Microsoft Shared Source Initiative решает несколько важных задач:

Поддержка заказчиков путем предоставления им возможности упростить разработку собственных приложений, повысить самостоятельность в решении задач и усовершенствовать тестирование систем безопасности;

Создание новых возможностей для партнеров Майкрософт по разработке привлекательных решений и услуг, при одновременном уменьшении затрат и обеспечении ускоренного выхода на рынок;

Стимулирование новых разработок и разработчиков предоставлением инструментов, сервисных программ и базовых технологий, что позволит изучать и реализовывать новаторские идеи на базе технологий Майкрософт.

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

Отметим принципиальное отличие подхода Shared Source от Open Source: открытый исходный код в статусе Shared Source (в отличие от open source - продуктов, для которых подчас никто не отвечает ни за качество кода, ни за его развитие и изучение) имеет кураторов со стороны фирмы, которая предоставила открытый исходный код (в данном случае – Microsoft). Они отвечают на вопросы и дают консультации и рекомендации, что просто бесценно для академических разработчиков и преподавателей. По личному опыту автора, образец такой поддержки для программы SSCLI (Rotor) фирма Microsoft продемонстрировала с 2002 г., когда на сотни писем с вопросами в почтовой рассылке Rotor следовал незамедлительный, четкий и понятный ответ специалистов Microsoft.

Основные вехи истории программы Shared Source Initiative:

Апрель 2004 г. Выпущен набор открытых инсталляторов Windows Installer XML (WiX), - первый из трех проектов в рамках программы, ставших доступными на веб-узле SourceForge на условиях обычной публичной лицензии.

Октябрь 2005 г. Опубликованы образцы лицензий SSI (Microsoft Reference License, Microsoft Community License, Microsoft Permissive License). Текст лицензий ясен, изложен легким для понимания языком и невелик по объему (каждая лицензия - не более страницы), что облегчает понимание условий лицензирования.

Портал Codeplex

Сайт CodePlex является одним из расширений программы Microsoft Shared Source Initiative и предоставляет разработчикам портал сетевого сообщества для инновационной деятельности и активного участия в совместных проектах по разработке программного обеспечения.

Портал CodePlex создан на базе Visual Studio Team Foundation Server.

Каких-либо лицензионных ограничений не существует; разработчики в полной мере вольны выбирать тип лицензии, наилучшим образом отвечающий их потребностям.

Более 1000 проектов; приблизительно 10% являются проектами Майкрософт, остальные были предложены сообществом.

Приведем цитату по поводу CodePlex из википедии - свободной Web-энциклопедии:

"CodePlex — это веб-узел корпорации Майкрософт, размещающий проект открытого исходного кода. Он предназначен для совместной разработки программных проектов с открытым исходным кодом. Его функциональные возможности включают вики-страницы, управление источниками на базе Team Foundation Server, дискуссионные форумы, отслеживание проблем, разметку проектов, поддержку RSS, статистику и релизы".

Академическая программа Microsoft Windows Academic Program

Академическая программа Windows (WAP) – это уникальная программа, организованная фирмой Microsoft для изучения на основе открытых исходных кодов операционных систем семейства Windows, включая как новейшие ОС типа Windows NT / 2000 / 2003 / 2008 / Vista / 7, так и версии Windows для встроенных систем (Windows Embedded). Еще 10 лет назад трудно было даже представить, что Microsoft предпримет столь беспрецедентный шаг – откроет "святую святых" – исходный код ядра Windows. Ныне, в течение нескольких лет, это оказалось возможным. Поэтому у студентов, аспирантов, преподавателей и исследователей есть, без преувеличения, уникальный шанс изучить Windows "изнутри" и тем самым получить полное практическое представление об организации современной ОС.

Целm программы WAP, сформулированная фирмой Microsoft, - способствовать повышению интереса к исследованиям и преподаванию базовой операционной системы. Как отмечает Дейв Проберт, менеджер по разработке Windows, ныне Microsoft необходимы новые свежие идеи по разработке ОС. Очень важен также интерес к ОС студентов, так как именно в предмете операционных систем воплотилось сочетание изучения математических методов, методов информатики и практической программной инженерии – архитектуры и механизмов сложнейшего программного продукта – современной операционной системы.

В результате программы WAP корпорация Майкрософт получит лучше подготовленных пользователей, партнеров, а некоторые из них, возможно, станут сотрудниками Microsoft. Очень важны для Microsoft фундаментальные новаторские разработки ОС, а также возможность расширить использование Windows в образовании.

Мотивация студентов, аспирантов и преподавателей, особенно молодежи, для участия в программе WAP вполне понятна. Обсудим лишь некоторые ее аспекты:

Научная любознательность – приведены примеры типичных высказываний:

Читайте также: