На коде какого ядра основан код ядра windows 8

Windows 8 – новейшая операционная система от корпорации Microsoft, предназначенная для использования на персональных компьютерах, в том числе с сенсорными дисплеями.

Разработка Windows 8 началась в 2009 году и впервые система была анонсирована в январе 2011 года, а в сентябре того же года представлена предварительная версия для разработчиков Windows 8 Developer Preview. В феврале 2012 года выпускается предварительная версия Windows 8 Consumer Preview, в мае – Windows 8 Release Preview. В августе 2012 становится доступной окончательная версия Windows 8 для подписчиков MSDN и TechNet. Официальная дата начала продаж назначена на 26 октября 2012 года.

Ядро Windows 8 имеет номер версии 6.2 и его код основан на коде ядра Windows 7 (имеющего номер версии 6.1) с небольшими изменениями.

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

Интерфейс

Самым заметным отличием новой системы от Windows 7 является, конечно, интерфейс Modern UI, который используется при старте системы вместо привычного рабочего стола (рис.3.1).

Впервые Modern UI появился в Windows Phone 7 в 2010 году. Принцип, используемый в этом интерфейсе, – на первом месте содержание, а не графическое оформление. Поэтому в Modern UI минимизировано использование элементов интерфейса – кнопок и меню; вместо иконок используются плитки (tiles), внутри которых текст выводится при помощи легко читаемых шрифтов, а для динамичного отображения информации широко используется анимация.

Традиционный рабочий стол также присутствует – его можно вызвать, щелкнув на плитку Desktop. Обратно к интерфейсу Modern UI можно вернуться, подведя указатель мыши в левый нижний угол экрана (один из четырех «активных углов») или нажав кнопку Windows на клавиатуре.

Другим изменением в интерфейсе стало использование Ribbon Interface (Ленточный интерфейс) в Проводнике Windows (рис.3.2).

Учетные записи

На компьютер под управлением Windows 8 можно войти, используя учетную запись Microsoft (Live ID). При этом становятся доступны все связанные с учетной записью сервисы – SkyDrive, Outlook.com, Microsoft Messenger, Facebook, LinkedIn, Twitter и др.

С помощью использования Live ID доступна функция семейной безопасности и родительского контроля (Microsoft Family Safety).

Безопасность

Программа Защитник Windows (Windows Defender), которая ранее обладала только антишпионскими функциями, теперь стала ещё и антивирусом.

Поддерживается механизм безопасной загрузки на системах с UEFI (Unified Extensible Firmware Interface – унифицированный расширенный интерфейс для встроенного программного обеспечения; стандарт, предназначенный для замены BIOS), путем проверки целостности загрузчика Windows. Таким образом, предотвращаются попытки вредоносных программ перехватить управление до загрузки системы.

Диспетчер задач

Диспетчер задач (Task Manager) существенно изменен по сравнению с предыдущими версиями: добавлены подробности по текущему использованию ресурсов, добавлена вкладка Автозапуск (Startup), добавлена вкладка истории использования приложениями различных ресурсов (App history) (рис.3.3).

История файлов

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

Восстановление системы

Добавлены две функции по восстановлению системы без использования носителей с дистрибутивом – Обновление (Refresh) и Сброс (Reset). При Обновлении система переустанавливается с сохранением пользовательских файлов и настроек; при Сбросе диск форматируется и система устанавливается с нуля.

Storage Spaces

Функция Storage Spaces позволяет объединять физические диски, построенные по разным технологиям (SATA, USB, SAS), в единый виртуальный диск с автоматическим резервированием информации.

Версии Windows 8

Планируется выпуск четырех версий Windows 8:

• Windows 8 – базовая версия для 32 разрядных (x86) и 64 разрядных (x64) платформ;
• Windows 8 Pro – версия для продвинутых и бизнес-пользователей. В неё будут добавлены поддержка доменов Windows, групповые политики, шифрование файлов, технологии виртуализации;
• Windows 8 Enterprise – версия для корпоративных пользователей. Присутствуют все возможности Windows 8 Pro и добавляются следующие технологии: Windows To Go (возможность загрузки с переносных устройств – внешних жестких дисков и флеш дисков), DirectAccess (простой и безопасный доступ к ресурсам корпоративной сети через Интернет), BranchCache (кэширование файлов корпоративной сети), AppLocker (гибкое управление разрешениями на запуск приложений);
• Windows RT – версия, которая будет поддерживать мобильные процессоры ARM. Будет доступна только как предварительно установленная операционная система на компьютерах с ARM процессорами. В состав системы будет входить пакет Microsoft Office Home & Student 2013 RT.

Минимальные системные требования для Windows 8 практически совпадают с требованиями для Windows 7:

• процессор не менее 1 ГГц;
• оперативная память не менее 1 ГБ для 32 разрядных систем, 2 ГБ для 64 разрядных;
• свободное пространство на жестком диске не менее 20 ГБ;
• видеокарта с поддержкой DirectX 9 и с WDDM драйвером.

Разработка приложений для Windows 8

Для Windows 8 стала возможной разработка нового типа Windows приложений – приложений в стиле Modern UI (см. раздел на MSDN [MSDN Apps]).

Особенности приложений в стиле Modern UI

У приложений в стиле Modern UI есть ряд особенностей, которые отличают их от традиционных Windows-приложений:

• наличие одного окна – приложение имеет одно окно, по умолчанию развернутое на весь экран, лишенное необязательных элементов интерфейса;
• поддержка сенсорного ввода – Windows 8 предоставляет приложениям средства для поддержки ввода с разных устройств – клавиатуры, мыши, пера, сенсорной панели;
• контракты приложений – приложения могут объявлять поддержку контрактов – соглашений по предоставлению определенных сервисов. В Windows 8 поддерживается несколько контрактов:
  • поиск (Search) – соглашение о возможности поиска по содержимому;
  • общий доступ (Sharing) – соглашение о предоставлении своего содержимого другим приложениям;
  • воспроизведение (Play To) – соглашение о передаче данных из приложения на устройство воспроизведения;
  • выбор между приложениями (App to App picking) – соглашение о возможности напрямую выбирать файлы;
  • параметры (Settings) – соглашение о доступности параметров приложения;
  • печать (Print) – соглашение о возможности печати на любом совместимом принтере;
• плитки вместо ярлыков – приложение представляется пользователю в виде плитки, в которой может быть текст или динамически изменяющееся содержимое, даже когда само приложение не работает;
• новые элементы интерфейса:
  • строка команд приложения (App bar) – располагается внизу экрана, вызывается как контекстное меню. В этой строке можно размещать основные команды приложения (рис.3.4);
  • панель Charms – располагается в правой части экрана и содержит кнопки для поиска, общего доступа, вызова начального экрана, работы с устройствами и работы с параметрами (рис.3.5).

Инструменты

Для написания приложений в стиле Modern UI можно использовать среду разработки Visual Studio 2012, средство для создания пользовательского интерфейса Blend, шаблоны проектов Visual Studio (http://msdn.microsoft.com/ru-RU/windows/apps/br229516.aspx).

Поддерживаемые языки программирования – C#, С++, Visual Basic, JavaScript. Для разработки приложений, требующих эффективной работы с графикой, можно использовать Microsoft DirectX 11.

Для интеграции приложения с сервисами Hotmail, Windows Live Messenger, Microsoft SkyDrive и др. применяется Live SDK – набор специализированных API для доступа к информации пользователя этих сервисов.

Для более подробной информации см. [MSDN Apps; Лутай и др.; Techdays].

Резюме

Рассмотрены ключевые особенности и версии новейшей операционной системы Microsoft Windows 8. Приводится также информация о разработке приложений в стиле нового интерфейса Modern UI.

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

Контрольные вопросы

1. Расскажите об истории разработки Windows 8.
2. Перечислите основные особенности Windows 8.
3. Назовите версии Windows 8 и отличия между ними.
4. Каковы минимальные системные требования для установки Windows 8?
5. Что такое «контракты» при разработке приложений в стиле Modern UI?
6. Чем отличается Modern UI от традиционных интерфейсов?
7. Какие новые элементы интерфейса появились в Modern UI?

Windows Research Kernel (WRK) — исходный код ядра ОС Windows (Windows XP x64 и Windows Server 2003 SP1), распространяемый для некоммерческих, исследовательских целей в рамках «Windows Academic Program» под НЕ СВОБОДНОЙ лицензией (где пруфлинк?). Как следствие, этот код не может быть использован в процессе разработки ReactOS (т.е. разработчики никогда не смотрели этот код и не планируют этого делать, пока не изменятся условия лицензирования WRK)

(19:00:58) Fireball: лицензия ихняя, она кабальная
(19:01:11) Fireball: эти исходники использовать нельзя почти ни в каком виде.

WRK предназначен для факультетов и преподавателей, работающих в области операционных систем, для разработчиков курсов, авторов учебников и т.д., желающих включить информацию о ядре Windows, основанную на действующем исходном коде. WRK содержит среду для сборки/тестирования и бинарные файлы для исключённых компонентов исходного кода, которые могут быть использованы, чтобы собрать полнофункциональные NTOS ядра для последующей установки на Windows Server 2003 для x86/x64 и Windows XP x64.

Ниже информация из лекции «Исследовательское ядро Windows» курса «Введение во внутреннее устройство Windows» от Intuit.ru.

Windows Academic Program

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

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

• учебные материалы по курсу операционных систем на основе Windows XP – Windows Internals Curriculum Resource Kit (CRK). Составлены в соответствии с рекомендациями ACM/IEEE по преподаванию курса «Операционные системы» (Operating systems, OS). Материалы включают презентации лекций, указания к лабораторным работам (в том числе лабораторные работы для 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, преследовало следующие цели:

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

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

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

Рис.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.2basentos и включают, в основном описания и определения функций и структур данных. В ядре Windows при именовании функций используются определенные соглашения [5; 2]. Название функции обычно строится по следующей схеме:

<Префикс><Операция><Объект>

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

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

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

Компонент WRK	Префикс функций	Название компонента на англ. языке	Название компонента на русском языке
cache	Cc	Cache manager	диспетчер кэша
config	Cm	Configuration manager	диспетчер конфигурации
dbgk	Dbgk	Debugging Framework	подсистема отладки
ex	Ex	Executive support routines	функции поддержки исполнительной системы – синхронизация, таймеры, структуры данных исполнительной системы, системная информация
fsrtl	FsRtl	File system driver run-time library	библиотека функций поддержки файловой системы времени выполнения
io	Io	Input/Output manager	диспетчер ввода-вывода
ke	Ke	Kernel	ядро
lpc	Lpc	Local Procedure Call	механизм вызова локальных процедур
mm	Mm	Memory manager	диспетчер памяти
ob	Ob	Object manager	диспетчер объектов
perf	Perf	Performance	функции для сбора информации о производительности системы
ps	Ps	Process manager	диспетчер процессов
raw	Raw	Raw File System	функции для Raw File System
rtl	Rtl	Run-Time Library	библиотека функций времени выполнения
se	Se	Security manager	диспетчер безопасности
wmi	Wmi	Windows Management Instrumentation	поддержка WMI – инструментальные средства управления Windows

Компоненты WRK и префиксы функций

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

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

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

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

В Институте программной инженерии Хассо Платтнера Университета г. Потсдама (Hasso-Plattner-Institute for Software Engineering at University Potsdam) Александром Шмидтом (Alexander Schmidt) и Михаэлем Шёбелем (Michael Schobel) была создана HTML документация по WRK с использованием генератора документации Phoenix Cross Reference (PXR)2 . Данная документация доступна для преподавателей по следующей ссылке:

http://www.facultyresourcecenter.com/curriculum/pfv.aspx?ID=8668

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

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

Дополнительная информация

1. Презентация “Windows Research Kernel: Source overview & project” одного из архитекторов ядра Windows, 2006 год.Медиа:WindowsResearchKernel-1.pdf

Microsoft
Windows Research Kernel • WNT: правдивая история Windows NT • Remote Desktop Protocol • Xming • Windows Subsystem for Linux (WSL) • Запуск DE и графического ПО в WSL • Cygwin • PowerShell

Ever asked how Windows API retrieves the current time, the version of the OS, or whether an evaluation period has expired? This structure will answers some of these questions.

Recently, a colleague of mine, Martin von Löwis, found an article in Google about Windows timing and this article used an artifact of the KUSER_SHARED_DATA structure. Well, as we have the sources, let’s have a closer look to that structure (see publicsdkincntexapi.h). (As the WRK license agreement limits the number of lines of code that can be shown in one piece to 50 lines, I left out the comments.)

02229 typedef struct _KUSER_SHARED_DATA {
02237     ULONG TickCountLowDeprecated;
02238     ULONG TickCountMultiplier;
02244     volatile KSYSTEM_TIME InterruptTime;
02250     volatile KSYSTEM_TIME SystemTime;
02256     volatile KSYSTEM_TIME TimeZoneBias;
02264     USHORT ImageNumberLow;
02265     USHORT ImageNumberHigh;
02271     WCHAR NtSystemRoot[260];
02277     ULONG MaxStackTraceDepth;
02283     ULONG CryptoExponent;
02289     ULONG TimeZoneId;
02290     ULONG LargePageMinimum;
02291     ULONG Reserved2[7];
02297     NT_PRODUCT_TYPE NtProductType;
02298     BOOLEAN ProductTypeIsValid;
02309     ULONG NtMajorVersion;
02310     ULONG NtMinorVersion;
02316     BOOLEAN ProcessorFeatures[PROCESSOR_FEATURE_MAX];
02322     ULONG Reserved1;
02323     ULONG Reserved3;
02329     volatile ULONG TimeSlip;
02335     ALTERNATIVE_ARCHITECTURE_TYPE AlternativeArchitecture;
02344     LARGE_INTEGER SystemExpirationDate;
02350     ULONG SuiteMask;
02356     BOOLEAN KdDebuggerEnabled;
02362     UCHAR NXSupportPolicy;
02368     volatile ULONG ActiveConsoleId;
02376     volatile ULONG DismountCount;
02384     ULONG ComPlusPackage;
02392     ULONG LastSystemRITEventTickCount;
02399     ULONG NumberOfPhysicalPages;
02405     BOOLEAN SafeBootMode;
02413     ULONG TraceLogging;
02422     ULONGLONG TestRetInstruction;
02423     ULONG SystemCall;
02424     ULONG SystemCallReturn;
02425     ULONGLONG SystemCallPad[3];
02431     union {
02432         volatile KSYSTEM_TIME TickCount;
02433         volatile ULONG64 TickCountQuad;
02434     };
02440     ULONG Cookie;
02446     ULONG Wow64SharedInformation[MAX_WOW64_SHARED_ENTRIES];
02447
02448 } KUSER_SHARED_DATA, *PKUSER_SHARED_DATA;

While I cannot say the meaning and usage of all fields, I will concentrate on the most interesting ones.

Windows Times

Windows maintains three types of time: The interrupt time (line 2244), the system time (line 2250), and the system’s tick count (lines 2431 thru 2434). While the first ones represent a real time value in units of 100 ns, the latter is just a counter starting at zero when the machine boots. In tests using the KUSER_SHARED_DATA we figured out that the tick count is incremented each 15.625 ms.

The interrupt time is the only Windows clock that guarantees to be monotonous that is, its value only increases over timer. Its value represents the time in units of 100 ns since the system was booted. The interrupt time is the base clock for all timers in Windows (see my recent article A Bug in Windows Timer Management). It is updated every clock interrupt.
In contrast, the system time represents the time in units of 100 ns since January 1, 1601. It always represents your local time, not UTC (Universal Coordinated Time). The system time does not guarantee to be monotonous, which means it might “jump” backwards. (Just think of the Daylight Saving time adjustment or NTP.)

Now, let’s have a closer look at the data structure that is used to hold the interrupt time and the system time (see publicsdkincntkeapi.h):

00048 typedef struct _KSYSTEM_TIME {
00049     ULONG LowPart;
00050     LONG High1Time;
00051     LONG High2Time;
00052 } KSYSTEM_TIME, *PKSYSTEM_TIME;

As you can see, the time is stored as a 64-bit value: High1Time:LowPart. But why is there another HighPart (High2Time) field in the structure (line 51)? To be short, it is for synchronization purposes. The three time values are updated directly by the clock interrupt service routine (ISR). An ISR must not acquire any lock because it must complete as fast as possible and thus must not block. However, to ensure applications (Win32) to read a consistent time value, the order in which the members of KSYSTEM_TIME are updated has a very strict manner. The ISR first updates High2Time, then LowPart, and finally High1Time. A consuming application must read the structure the same strict but inverse order, that is, it first reads High1Time, then LowPart, and finally High2Time. If High1Time and High2Time are equal, the High1Time:LowPart is a consistent value. Otherwise the application was interrupted by the clock interrupt and needs to read the structure again.

Access the Structure in Your Application

The most important thing I need to tell you about the KUSER_SHARED_DATA structure is that it is exported to user address space. See files basentosinci386.h or basentosincamd64.h, respectively, depending on your target architecture. Refer to the definition of KI_USER_SHARED_DATA. This constant holds the virtual address, where the single instance of KUSER_SHARE_DATA is mapped to. For example, on an x86 architecture, it is mapped to 0xFFDF0000. But be careful with using this structure! It is subject to change and it might have a completely different structure on Windows XP or Windows Vista. Although I think this is pretty improbable because of its strong usage inside the kernel, you must be aware of that fact.

If you already have experiences with KUSER_SHARED_DATA, don’t hesitate to comment and share your knowledge among the community.

This entry was posted on Thursday, August 9th, 2007 at 10:40 am and is filed under Data structures. You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.

Windows-Research-Kernel-WRK-

Windows Research Kernel Source Code

Copyright (c) Microsoft Corporation. All rights reserved.

You may only use this code if you agree to the terms of
the Windows Research Kernel Source Code License agreement
(see License.txt). If you do not agree to the terms, do not use the code.

---

WRK v1.2

The Windows Research Kernel v1.2 contains the sources for the core of
the Windows (NTOS) kernel and a build environment for a kernel that will run on
x86 (Windows Server 2003 Service Pack 1) and
amd64 (Windows XP x64 Professional)
A future version may also support booting WRK kernels on Windows XP x86 systems,
but the current kernels will fail to boot due to differences in some shared
structures.

The NTOS kernel implements the basic OS functions
for processes, threads, virtual memory and cache managers, I/O management,
the registry, executive functions such as the kernel heap and synchronization,
the object manager, the local procedure call mechanism, the security reference
monitor, low-level CPU management (thread scheduling, Asynchronous and Deferred
Procedure calls, interrupt/trap handling, exceptions), etc.

The NT Hardware Abstraction Layer, file systems, network stacks, and device
drivers are implemented separately from NTOS and loaded into kernel mode
as dynamic libraries. Sources for these dynamic components are not included
in the WRK, but some are available in various development kits published
by Microsoft, such as the Installable File System (IFS) Kit and the
Windows Driver Development Kit (DDK).

WRK v1.2 includes most of the NTOS kernel sources from the latest released
version of Windows, which supports the AMD64 architecture on the Desktop.
The kernel sources excluded from the kit are primarily in the areas of
plug-and-play, power management, the device verifier, kernel debugger
interface, and virtual dos machine. The primary modifications to WRK
from the released kernel are related to cleanup and removal of server
support, such as code related to the Intel IA64.

---

Organization of the WRK sources

The file License.txt contains the license covering use of the WRK.

The public directory contains a number of include files shared among system
components. basentos contains the NTOS sources.

The primary NTOS source components included in the WRK are organized as follows:

cache  - cache manager
config - registry implementation
dbgk   - user-mode debugger support
ex     - executive functions (kernel heap, synchronization, time)
fsrtl  - file system run-time support
io     - I/O manager
ke     - scheduler, CPU management, low-level synchronization
lpc    - local procedure call implementation
mm     - virtual memory manager
ob     - kernel object manager
ps     - process/thread support
se     - security functions
wmi    - Windows Management Instrumentation

inc    - NTOS-only include files
rtl    - kernel run-time support
init   - kernel startup

---

Copying and building the WRK

WRK can be built on Windows Server 2003 or later, or on Windows XP or later.

To copy WRK to your machine:

• open a console window;
• switch to DVD;
• switch to ResourcesWindows_Research_KernelGet_WRK;
• run WRKCopy.bat /w <destination_directory>
  (if you run WRKCopy.bat without parameters, WRK will be copied to C:WRK-v1.2);
  ALTERNATIVELY
• open Windows Explorer (MyComputer);
• create the destination directory on your hard drive;
• switch to DVD;
• navigate to ResourcesWindows_Research_KernelGet_WRKWRK-v1.2;
• select all files and subdirectories, drag and drop them to the destination
  directory.

To adjust the WRK environment setting batch file:

• open console window;
• switch to the directory WRK was copied to;
• run Notepad WRKEnv.bat;
• make sure the «set path=…» statement contains the directory WinDbg was
  installed to; (unchanged WRKEnv.bat refers to default directory
  C:Program FilesDebugging Tools for Windows);
• save the file and exit Notepad.

To build WRK from command line:

• open console window;
• switch to the directory WRK was copied to;
• run Build (or Rebuild or Clean ), see note about
  below;
  ALTERNATIVELY
• open console window;
• switch to the directory WRK was copied to;
• run WRKEnv , see note about below;
• switch to basentos;
• run nmake %wrkarch%=

To build WRK in Visual Studio 2008 environment:

• start VS2008;
• open solution <WRK_DIR>WRK.sln, where <WRK_DIR> is the directory WRK was
  copied to;
• make sure the configuration is amd64/Win32 or x86/Win32, as is appropriate;
• select Build/Build Solution (or Rebuild Solution, or Clean Solution).

To start Windows Debugger from command line:

• open console window;
• switch to the directory WRK was copied to;
• run WRKDebug , see note about below;
  ALTERNATIVELY
• open console window;
• switch to the directory WRK was copied to;
• run WRKEnv , see note about below;
• run WinDbg %windbgargs%

---

NOTE ABOUT

Batch files Build.bat, Rebuild.bat, Clean.bat, WRKEnv.bat and WRKDebug.bat
take one parameter – target architecture, which is x86 or amd64.

For the first use of either of these batch files, default target architecture
is x86.

Once the target architecture was defined (explicitly or by default), it
cannot be changed for current console window, and parameter of the
batch files is ignored.

The title of the window where the WRK environment has been set to some target
architecture changes to “WRK x86” or “WRK amd64”.

To work with different target architecture, open another console window.

---

Copyright (c) Microsoft Corporation. All rights reserved.

You may only use this code if you agree to the terms of
the Windows Research Kernel Source Code License agreement
(see License.txt). If you do not agree to the terms, do not use the code.

---

WRK v1.2

The Windows Research Kernel v1.2 contains the sources for the core of
the Windows (NTOS) kernel and a build environment for a kernel that will run on
x86 (Windows Server 2003 Service Pack 1) and
amd64 (Windows XP x64 Professional)
A future version may also support booting WRK kernels on Windows XP x86 systems,
but the current kernels will fail to boot due to differences in some shared
structures.

The NTOS kernel implements the basic OS functions
for processes, threads, virtual memory and cache managers, I/O management,
the registry, executive functions such as the kernel heap and synchronization,
the object manager, the local procedure call mechanism, the security reference
monitor, low-level CPU management (thread scheduling, Asynchronous and Deferred
Procedure calls, interrupt/trap handling, exceptions), etc.

The NT Hardware Abstraction Layer, file systems, network stacks, and device
drivers are implemented separately from NTOS and loaded into kernel mode
as dynamic libraries. Sources for these dynamic components are not included
in the WRK, but some are available in various development kits published
by Microsoft, such as the Installable File System (IFS) Kit and the
Windows Driver Development Kit (DDK).

WRK v1.2 includes most of the NTOS kernel sources from the latest released
version of Windows, which supports the AMD64 architecture on the Desktop.
The kernel sources excluded from the kit are primarily in the areas of
plug-and-play, power management, the device verifier, kernel debugger
interface, and virtual dos machine. The primary modifications to WRK
from the released kernel are related to cleanup and removal of server
support, such as code related to the Intel IA64.

---

Organization of the WRK sources

The file License.txt contains the license covering use of the WRK.

The public directory contains a number of include files shared among system
components. basentos contains the NTOS sources.

The primary NTOS source components included in the WRK are organized as follows:

cache  - cache manager
config - registry implementation
dbgk   - user-mode debugger support
ex     - executive functions (kernel heap, synchronization, time)
fsrtl  - file system run-time support
io     - I/O manager
ke     - scheduler, CPU management, low-level synchronization
lpc    - local procedure call implementation
mm     - virtual memory manager
ob     - kernel object manager
ps     - process/thread support
se     - security functions
wmi    - Windows Management Instrumentation

inc    - NTOS-only include files
rtl    - kernel run-time support
init   - kernel startup

---

Copying and building the WRK

WRK can be built on Windows Server 2003 or later, or on Windows XP or later.

To copy WRK to your machine:

• open a console window;
• switch to DVD;
• switch to ResourcesWindows_Research_KernelGet_WRK;
• run WRKCopy.bat /w <destination_directory>
  (if you run WRKCopy.bat without parameters, WRK will be copied to C:WRK-v1.2);
  ALTERNATIVELY
• open Windows Explorer (MyComputer);
• create the destination directory on your hard drive;
• switch to DVD;
• navigate to ResourcesWindows_Research_KernelGet_WRKWRK-v1.2;
• select all files and subdirectories, drag and drop them to the destination
  directory.

To adjust the WRK environment setting batch file:

• open console window;
• switch to the directory WRK was copied to;
• run Notepad WRKEnv.bat;
• make sure the «set path=…» statement contains the directory WinDbg was
  installed to; (unchanged WRKEnv.bat refers to default directory
  C:Program FilesDebugging Tools for Windows);
• save the file and exit Notepad.

To build WRK from command line:

• open console window;
• switch to the directory WRK was copied to;
• run Build (or Rebuild or Clean ), see note about
  below;
  ALTERNATIVELY
• open console window;
• switch to the directory WRK was copied to;
• run WRKEnv , see note about below;
• switch to basentos;
• run nmake %wrkarch%=

To build WRK in Visual Studio 2008 environment:

• start VS2008;
• open solution <WRK_DIR>WRK.sln, where <WRK_DIR> is the directory WRK was
  copied to;
• make sure the configuration is amd64/Win32 or x86/Win32, as is appropriate;
• select Build/Build Solution (or Rebuild Solution, or Clean Solution).

To start Windows Debugger from command line:

• open console window;
• switch to the directory WRK was copied to;
• run WRKDebug , see note about below;
  ALTERNATIVELY
• open console window;
• switch to the directory WRK was copied to;
• run WRKEnv , see note about below;
• run WinDbg %windbgargs%

---

NOTE ABOUT

Batch files Build.bat, Rebuild.bat, Clean.bat, WRKEnv.bat and WRKDebug.bat
take one parameter – target architecture, which is x86 or amd64.

For the first use of either of these batch files, default target architecture
is x86.

Once the target architecture was defined (explicitly or by default), it
cannot be changed for current console window, and parameter of the
batch files is ignored.

The title of the window where the WRK environment has been set to some target
architecture changes to “WRK x86” or “WRK amd64”.

To work with different target architecture, open another console window.

---

Windows не является операционной системой с открытым исходным кодом, но, как уже упоминалось в предыдущей главе, Microsoft открыла исходный код ядра на основе Windows XP X64 и Windows Server 2003 SP1. Он может компилировать и проходить, как обучение исследовательских учреждений. И исследовательская платформа использует, называется WRK (Windows Research Kerrel, Kernel Windows Research).

Важная цель WRK — это вспомогательное обучение, позволяющее компьютерным специалистам понимать и освоить основные концепции и различные механизмы в современной операционной системе через исходный код Windows Kernel.

1, WRK содержит следующие

WRK ядра исходный код, связанный процесс, нить, управление поток памяти, руководитель, руководитель объектов, диспетчер объектов, Cache Manager, локальный вызов процесса (LPC), реестр, I / O Manager, Manager, контрольный монитор безопасности и планирование потоков, APC (асинхронный процесс) / DPC (задержка обрабатываний процесса), прерывание и обработка исключений и т. Д. В качестве исходного кода есть ответ на компиляционный инструмент, поэтому нет дополнительного компилятора для компиляции WRK на исполняемое ядро ​​Windows Server 2003 SP1.

NT Docket Documentation. Это набор ранних документов, однако, прочитав эти документы, вы можете четко понять оригинальные идеи дизайна за Windows NT, а с другой стороны, видно, как Windows развивается и развивается в течение более десяти лет. Эти документы охватывают все аспекты операционной системы Windows, даже в том числе наброски дизайна файловой системы и структуру модуляции ядра.

Программное обеспечение Virtual PC 2007 и виртуальные изображения Windows Server 2003 SP1, эта система виртуальной машины настроила ядро ​​WRK. С помощью этого виртуального изображения System PC 2007 и WRK вы можете легко отладки и отслеживать код в WRK.

Ресурсы курса CRK (комбинация ресурсов учебных программ), включая полный набор операционных систем Windows, в общей сложности 15 единиц. Каждый блок содержит некоторую тему, упражнения и восходящие работы. Это очень полезное обучение для курса с Windows в качестве платформ преподавания и эксперимента.

Исходный код проекта. Projectoz — это операционная система экспериментальной среды для механизмов CPU, MMU и Trap, установленные NTAPI из ядра Windows. Ядро представляет собой космическую абстракцию CPU, MMU и механизма ловушки. Поскольку следующее следующее — это настоящая операционная система Windows в обработке и манипулирующей оборудовании, учащиеся имеют больше возможностей для изучения и почувствовать сложность алгоритмов операционной системы и структур данных.

Однако Microsoft в настоящее время не открыта для всех, но преподавание и научных исследований как открытая цель, ограничена факультетом университета. Видеть:

2, Описание исходного кода WRK

Файл модуля ядра Windows является NTOSKRNL.EXE, который расположен в каталоге Windows System32, который содержит раздел «Исполнительного и ядра» (Micronucleen) в архитектуре Windows. Исходный код, предоставленный WRK, может компилировать этот файл модуля ядра, и созданный по умолчанию файл drkx86.exe называется wrkx86.exe в среде компиляции WRK. Опция / ядро ​​загрузки Windows может указать файл основного модуля, отличный от ntoskrnl.exe. Таблица 2.2 Перечисляет структуру каталогов исходного кода WRK и его соответствующих компонентов ядра.

WRK содержит большую часть кода, необходимого для компиляции модулей ядра NTOSKRNL.EXE, и код, который не раскрыт, в основном реализован путем управления подключаемым устройством, управлением питанием, детектором драйвера устройств и реализацией виртуальной продукции VOS. Для того, чтобы составить исходный код WRK и получить фактический запуск модуля ядра, отсутствующая деталь включена в WRK в виде бинарного целевого кода, расположенного в базе NTOS Build Prebuilt i386 (или база ntos build Prebuilt amd64) каталог. Этот каталог также содержит некоторые другие целевые файлы, которые требуют статических ссылок. Поэтому, как только WRK все еще является отличным ресурсом для изучения и понимания рабочего механизма Windows.

Код WRK извлекается в последнем коде продукта Windows, который может быть скомпилирован и запущен в Windows Server 2003 SP1 (процессор для процессоров X86) и Vindos XP SP2 (версию AMD64), его версия ядра составляет 5,2. Код WRK практически соответствует коду продукта. Основное изменение состоит в том, чтобы удалить поддержку сервера, такого как код, связанный с Intel IA 64.

Консистенция исходного кода Windows лучше, очень легко читать. Логика самого кода и различные идентификаторы в основном, пожелание, и важные заголовки функций имеют подробные инструкции по применению, а важные фрагменты кода также имеют специальные ноты. В целом, организация кода более четко, как показано в таблице 2.2. Каждый компонент внутри модуля ядра предоставляет некоторые функции интерфейса для других компонентных вызовов, а некоторые функции используются внутри компонента. Таблица 2.3 перечислены некоторые часто используемые префиксы идентификации. Есть некоторые компонентные внутренние функции. Есть также закономерности: префикс является первой буквой, сопровождающейся одним I, или следует по одному P в префиксе, здесь я представляет внутреннюю, то есть внутренний; P-код частного, то есть частные.

Даже если нет кода, также можно понять основной принцип Windows через эту книгу, гораздо более интуитивно понятную и эффективную, чем код.

This is the first part of the WRK series. For your convenience you can find other parts using the links below (or by guessing the address):
Part 1 – Compiling and debugging
Part 2 – Monitoring and function invocation
Part 3 — Syscall
Part 4 — New module

Nowadays Microsoft is very happy to share code of its tools with the open source community. But it wasn’t always the same — .NET Framework code wasn’t freely available, however, there was the project Rotor (or Shared Source CLI 2.0) which was a .NET implementation for research purposes. You could download the code, compile it on your own and experiment with the internals of the platform. It wasn’t exactly the same though, but it was good enough to see the code and play with it.

Similarly, there was a project with Windows OS source code, namely Windows Research Kernel. In this series we are going to compile the code, change some of its internals and see it in action.

WRK

Windows Research Kernel (WRK) is a source code of the kernel of Windows Server 2003 SP 1. It was released for research purposes so you couldn’t download it just like that, however, right now you might find it on Github pretty easily. The code is old, which means that getting it to work is a little hard, however, you should be able to follow the guide Getting started with WRK.doc to compile the project since it comes down to just running the bat file (assuming you have installed all of the dependencies). You can build the code for x86 and x64. There is also a solution (VS 2008!), you can just choose the configuration and build everything with your favorite IDE.

But the kernel is not enough, you need to have the rest of the Windows OS to actually test it. That’s why it was distributed with virtual machine based on Virtual PC 2007 (do you even remember this application?) which you could use to boot the kernel. The Windows Server 2003 installed in that VM was a little different than the normal one, i.e., it was showing the build number of the desktop so you could see which kernel you booted. Also, it had SP 1 installed and disabled updates because SP 2 was not compatible with the WRK.

Let’s start with enabling debugging for the VM. I assume you downloaded the WRK and the VM image and you can run it correctly. I will be using VMWare Player. By the way, did you know that you can use the same hard drive file for VMWare, Virtual Box and Hyper-V? This way you can configure your VM to be able to boot it with any hypervisor you like, and also support boot to VHD to use it natively on your machine. Pretty cool.

First, you need to configure serial port for the machine and expose it as a named pipe for the host. You can see the configuration below:

The OS should have debugging enabled by default. If it is not, then you need to add the following to the boot.ini:

default=multi(0)disk(0)rdisk(0)partition(2)WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(2)WINDOWS=«Windows Server 2003, Standard» multi(0)disk(0)rdisk(0)partition(2)WINDOWS=«Windows Server 2003, WRK» /kernel=wrkx86.exe /hal=< your HAL > /debug /debugport=com1 multi(0)disk(0)rdisk(0)partition(2)WINDOWS=«Windows Server 2003, WRK — No Debugger» /kernel=wrkx86.exe /hal=< your HAL >

Remember to set correct HAL.

Finally, you need to configure WinDBG. Just use the following settings:

Also, configure your symbols to the correct directory. You can automate this by using the following script to run the debugger:

@echo off set wrksymbols=%wrkpath%basentosBUILDEXE set dbgpipe=.pipedebugPipe set dbgargs=-k com:pipe,port=%dbgpipe%,resets=0,reconnect —y %wrksymbols% windbg %dbgargs%

Done. You should now be able to debug the kernel and play with it.

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

Windows 8 – новейшая операционная система от корпорации Microsoft, предназначенная для использования на персональных компьютерах, в том числе с сенсорными дисплеями.

Ядро Windows 8 имеет номер версии 6.2 и его код основан на коде ядра Windows 7 (имеющего номер версии 6.1) с небольшими изменениями.

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

Интерфейс

Самым заметным отличием новой системы от Windows 7 является, конечно, интерфейс Modern UI, который используется при старте системы вместо привычного рабочего стола (рис.3.1).

Впервые Modern UI появился в Windows Phone 7 в 2010 году. Принцип, используемый в этом интерфейсе, – на первом месте содержание, а не графическое оформление. Поэтому в Modern UI минимизировано использование элементов интерфейса – кнопок и меню; вместо иконок используются плитки (tiles), внутри которых текст выводится при помощи легко читаемых шрифтов, а для динамичного отображения информации широко используется анимация.

Традиционный рабочий стол также присутствует – его можно вызвать, щелкнув на плитку Desktop. Обратно к интерфейсу Modern UI можно вернуться, подведя указатель мыши в левый нижний угол экрана (один из четырех «активных углов») или нажав кнопку Windows на клавиатуре.

Другим изменением в интерфейсе стало использование Ribbon Interface (Ленточный интерфейс) в Проводнике Windows (рис.3.2).

Учетные записи

На компьютер под управлением Windows 8 можно войти, используя учетную запись Microsoft (Live ID). При этом становятся доступны все связанные с учетной записью сервисы – SkyDrive, Outlook.com, Microsoft Messenger, Facebook, LinkedIn, Twitter и др.

С помощью использования Live ID доступна функция семейной безопасности и родительского контроля (Microsoft Family Safety).

Безопасность

Программа Защитник Windows (Windows Defender), которая ранее обладала только антишпионскими функциями, теперь стала ещё и антивирусом.

Поддерживается механизм безопасной загрузки на системах с UEFI (Unified Extensible Firmware Interface – унифицированный расширенный интерфейс для встроенного программного обеспечения; стандарт, предназначенный для замены BIOS), путем проверки целостности загрузчика Windows. Таким образом, предотвращаются попытки вредоносных программ перехватить управление до загрузки системы.

Диспетчер задач

Диспетчер задач (Task Manager) существенно изменен по сравнению с предыдущими версиями: добавлены подробности по текущему использованию ресурсов, добавлена вкладка Автозапуск (Startup), добавлена вкладка истории использования приложениями различных ресурсов (App history) (рис.3.3).

История файлов

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

Восстановление системы

Добавлены две функции по восстановлению системы без использования носителей с дистрибутивом – Обновление (Refresh) и Сброс (Reset). При Обновлении система переустанавливается с сохранением пользовательских файлов и настроек; при Сбросе диск форматируется и система устанавливается с нуля.

Storage Spaces

Функция Storage Spaces позволяет объединять физические диски, построенные по разным технологиям (SATA, USB, SAS), в единый виртуальный диск с автоматическим резервированием информации.

Версии Windows 8

Планируется выпуск четырех версий Windows 8:

Минимальные системные требования для Windows 8 практически совпадают с требованиями для Windows 7:

Разработка приложений для Windows 8

Для Windows 8 стала возможной разработка нового типа Windows приложений – приложений в стиле Modern UI (см. раздел на MSDN [MSDN Apps]).

Особенности приложений в стиле Modern UI

У приложений в стиле Modern UI есть ряд особенностей, которые отличают их от традиционных Windows-приложений:

Инструменты

Для написания приложений в стиле Modern UI можно использовать среду разработки Visual Studio 2012, средство для создания пользовательского интерфейса Blend, шаблоны проектов Visual Studio (http://msdn.microsoft.com/ru-RU/windows/apps/br229516.aspx).

Поддерживаемые языки программирования – C#, С++, Visual Basic, JavaScript. Для разработки приложений, требующих эффективной работы с графикой, можно использовать Microsoft DirectX 11.

Для интеграции приложения с сервисами Hotmail, Windows Live Messenger, Microsoft SkyDrive и др. применяется Live SDK – набор специализированных API для доступа к информации пользователя этих сервисов.

Для более подробной информации см. [MSDN Apps; Лутай и др.; Techdays].

Резюме

Рассмотрены ключевые особенности и версии новейшей операционной системы Microsoft Windows 8. Приводится также информация о разработке приложений в стиле нового интерфейса Modern UI.

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

Источник

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

Windows Academic Program

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

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

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

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

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

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

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

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

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

Компонент WRK	Префикс функций	Название компонента на англ. языке	Название компонента на русском языке
cache	Cc	Cache manager	диспетчер кэша
config	Cm	Configuration manager	диспетчер конфигурации
dbgk	Dbgk	Debugging Framework	подсистема отладки
ex	Ex	Executive support routines	функции поддержки исполнительной системы – синхронизация, таймеры, структуры данных исполнительной системы, системная информация
fsrtl	FsRtl	File system driver run-time library	библиотека функций поддержки файловой системы времени выполнения
io	Io	Input/Output manager	диспетчер ввода-вывода
ke	Ke	Kernel	ядро
lpc	Lpc	Local Procedure Call	механизм вызова локальных процедур
mm	Mm	Memory manager	диспетчер памяти
ob	Ob	Object manager	диспетчер объектов
perf	Perf	Performance	функции для сбора информации о производительности системы
ps	Ps	Process manager	диспетчер процессов
raw	Raw	Raw File System	функции для Raw File System 1 Raw File System («сырая» файловая система) – если Windows не может распознать файловую систему диска, для него назначается Raw File System (драйвер которой реализован в ядре) и все запросы чтения/записи файлов к такому диску отклоняются.
rtl	Rtl	Run-Time Library	библиотека функций времени выполнения
se	Se	Security manager	диспетчер безопасности
wmi	Wmi	Windows Management Instrumentation	поддержка WMI – инструментальные средства управления Windows

Таблица 5.1. Компоненты WRK и префиксы функций

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

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

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

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

Резюме

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

Источник

Архитектура ОС Windows и Linux

Добрый день Пикабушники!

Сегодня я решил показать Вам различия между ядрами операционных систем Windows и Linux.

Начнем с относительно простого ядра Linux.

Теперь перейдем к Windows:

Как видим структура ядра намного более сложная. Преимущество это или недостаток? Каждый решает для себя сам. Программа под Windows обращается через документированный Windows API к «своей» библиотеке (например Kernel32.dll, Advapi32.dll, User32.dll, Gdi32.dll), эти библиотеки по внутреннему протоколу (документация для разработчиков не из Microsoft не доступна) обращается по протоколу Native API к Ntdll.dll и далее передается через диспетчер системных сервисов ядру (все это внутри Ntoskrnl.exe).

Не менее важным является включение графической подсистемы в ядро (в современных серверных ОС данная система отключена или отсутствует), что во-первых не дает сменить графическую оболочку «на ходу», а во-вторых уже не способствует быстродействию.

Источник

Практическое изучение Windows Research Kernel

Аппаратура и программные инструменты, необходимые для лабораторной работы

Настольный или портативный компьютер с одной из версий операционной системы Microsoft Windows

Продолжительность лабораторной работы

2 академических часа

Обзор Windows Research Kernel

Пакет WRK включает исходный код ядраWindows XP x64 и Windows Server 2003 SP1 с окружением для сборки и тестирования экспериментальных версий ядра Windows для использования в целях изучения и преподавания.

WRK включает исходные коды для следующих компонент:

Пакет Windows Research Kernel содержит исходные коды ядра Windows (NTOS).

NTOS реализует основные функции ОС для:

Скачивание и установка WRK

Структура директорий WRK

Войдите в базовую директорию WindowsResearchKernel-WRK.

Вы увидите в Windows Explorer структуру директорий пакета WRK ( рис. 39.1):

Файл README содержит краткое описание структуры пакета.

Файл LICENSE содержит подробное описание лицензии, на основе которой доступен WRK.

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

Откройте файлы README и LICENSE и ознакомьтесь с их содержимым.

Весь материал для изучения в пакете WRK представлен на английском языке.

Ознакомьтесь с содержимым базовых директорий пакета WRK:

Ознакомление со структурой исходных кодов ядра Windows

Войдите в директорию WRK-v1.2.

Директория tools содержит инструменты для сборки из исходных кодов, например, утилиту nmake. Ознакомьтесь с содержимым данной директории.

Источник

Заглянуть в ядро: насколько сильна Windows

Чтобы выяснить, насколько хороша Windows на самом деле, нужно изучить ее ядро и понять, как оно устроено и что оно может. В данной статье мы сравниваем Windows с Linux и Mac OS X и выявляем сильные и слабые стороны этой операционной системы, имеющей так много пользователей и так мало поклонников.

Чтобы выяснить, насколько хороша Windows на самом деле, нужно изучить ее ядро и понять, как оно устроено и что оно может. В данной статье мы сравниваем Windows с Linux и Mac OS X и выявляем сильные и слабые стороны этой операционной системы, имеющей так много пользователей и так мало поклонников.

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

Windows Debugger анализирует образ памяти и показывает причины сбоев — в нашем случае виноват драйвер режима ядра Файл NTOS — сердце ядра Windows, логически подразделяется на два слоя. Особенность состоит в том, что из соображений повышения производительности драйверы могут обращаться к оборудованию напрямую Ядро Linux отвечает за управление командами ввода-вывода, памятью и процессами. На самом низком уровне ядра находятся функции, управляющие прерыванием процессов Доступ к ядру Linux открыт каждому. На рисунке — фрагмент конфигурации ядра версии 2.6.19 Ядро системы Apple основано на двух источниках: в нем используются функции основанной на Unix подсистемы BSD наряду с частями микроядра Mach Со словом «Windows» связано много предубеждений и мифов. Например, бытует мнение, что работать в Windows крайне опасно, так как миллионы вирусов, гуляющих по Интернету, атакуют исключительно эту ОС. К тому же многие уверены, что детище Microsoft не отличается высокой производительностью: чем дольше вы пользуетесь этой системой, тем медленнее она работает. Что касается стабильности, то всем хорошо знаком пресловутый «синий экран». Это и неудивительно: Vista состоит из семидесяти миллионов строк кода — как тут не запутаться! Чтобы выяснить, справедливы ли все эти обвинения, необходимо заглянуть в самое ядро операционной системы и проверить, насколько оно отвечает трем критериям: безопасность, производительность и стабильность. А для сравнения возьмем ядра двух других систем — Linux и Mac OS X. Кроме того, мы подробно расскажем, какие методы используют Windows и ее конкуренты.

Контроль над системой

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

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

Обзор типов ядер

Монолитное.

Одно большое ядро для всех задач — в этом заключается идея монолита. Такое ядро отвечает за управление памятью и процессами, за коммуникацию между процессами, а также предлагает функции для поддержки драйверов и оборудования. Именно к этой категории относятся Windows, Linux и Mac OS X.

Микро. Ошибка в ядре может вывести из строя всю операционную систему. Поэтому микроядро отличается предельно малыми размерами — чтобы свести ошибки и сбои к минимуму. Но поскольку ядро должно поддерживать широкий набор функций, оно подразделяется на несколько модулей, из которых только один работает в режиме ядра. Классическим примером является Mach — компонент Mac OS X. Так или иначе, до сих пор ни одна операционная система с микроядром не завоевала популярности среди домашних пользователей.

Гибрид.

Гибридное ядро представляет собой нечто среднее между монолитным и микроядром. Само ядро делается облегченным, а для дополнительных задач существуют динамические модули. В Linux и OS X тоже можно подгружать части ядра, но не в таких масштабах, чтобы отнести их ядра к гибридным.

Windows : работает на любом оборудовании

Начиная с NT, в архитектуре Windows выделяется два режима: пользовательский и привилегированный, или режим ядра. Это относится и к Vista.

В режиме пользователя работает практически все, что видит пользователь, то есть приложения вроде Word или Photoshop. В этом режиме программы не имеют прямого доступа к оборудованию или оперативной памяти. Таким образом, пользовательский режим надежно изолирован, а все обращения к глубинам системы направляются через специальные интерфейсы, такие как Win32 API с системными библиотеками DLL (Dynamic Link Libraries).

Такой режим ядра — фоновый и практически незаметен для пользователя. Все хорошо до тех пор, пока не возникнет какая-либо проблема — например, драйвер режима ядра (см. схему ядра Windows) не обрушит всю систему, и взору пользователя предстанет синий экран.

Центральное значение здесь имеет файл ntoskrnl.exe.

По аналогии с режимом ядра и пользовательским режимом его задачи также делятся на две группы — слой ядра и исполнительная система. Главная задача слоя ядра — планировать загрузку центрального процессора, то есть распределять процессорное время между отдельными программами. Исполнительная система отвечает за виртуальную память, процессы ввода-вывода и другие задачи.

Глубже всего в системе располагается уровень аппаратных абстракций (Hardware Abstraction Layer, HAL). Он предоставляет другим слоям ОС службы для работы со встроенным оборудованием. Так, слой ядра может распределять процессорное время между программами независимо от того, какой процессор используется в компьютере — двуядерный AMD или четырехъядерный Intel. Если бы не HAL, Microsoft пришлось бы разрабатывать отдельную Windows для каждого компьютера.

Средства для отладки Windows WINDBG Чтобы проанализировать состояние памяти при выдаче «синего экрана», вам понадобится программа-отладчик, такая как WinDbg. На странице загрузок Microsoft вы найдете также соответствующий файл символов. www.microsoft.com/whdc/DevTools/Debugging NotMyFault тестирует систему на прочность: эта программа провоцирует ошибки в Windows и пытается ее обрушить. Экспериментируйте осторожно! Process Explorer. Управление процессами — одна из главных задач операционных систем. Process Explorer показывает все текущие процессы, соответствующие дескрипторы и связи между процессами. http://download.sysinternals.com

Linux : подгружает модули при необходимости

Хотя ядро Linux (см. схему) основано на Unix, но сходства с Windows у него больше, чем можно подумать. Оно также располагается непосредственно над оборудованием и играет роль своеобразной прослойки между оборудованием и работающими программами. Стандартные задачи тоже сходны: как и в Windows, ядро сотрудничает с устройствами ввода-вывода и берет на себя управление памятью. Оно также управляет процессами, то есть решает, какая задача в данный момент имеет приоритет, и получает доступ к процессорному времени. Для этого на самых нижних уровнях ядра располагаются функции управления прерываниями (interrupts).

Запрос на прерывание посылает, к примеру, клавиатура, когда пользователь нажимает на любую клавишу. Этот запрос обрабатывается специальным системным механизмом — диспетчером. Он решает, насколько высока приоритетность прерывания и включает его в очередь текущих процессов. Как только появляется возможность выполнить прерывание, диспетчер приостанавливает протекающий процесс и сохраняет его статус. Только после этого прерывание, то есть введенная с клавиатуры команда, может быть реализовано.

Архитектура Linux, как и Windows, имеет монолитное строение. Тем не менее, ядро может динамически догружать различные модули. В основном они дополняют имеющиеся компоненты или даже полностью заменяют их.

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

Mac OS X : сила двух ядер

Ядро Mac OS X сокращенно обозначается как XNU — X is Not Unix.

Эта аббревиатура соответствует действительности, потому что ядро операционной системы Apple скомбинировано из двух источников, и лишь его часть имеет отношение к Unix (см. рис.). Остальное компания взяла из проекта Mach — классического примера микроядра (см. рис.). При этом Mach используется только для передачи сообщений (message passing), то есть эффективной коммуникации между отдельными частями ядра. Помимо Mach XNU содержит код проекта FreeBSD, который основан на Unix. Эта часть отвечает за взаимодействие с пользователем, обработку сигналов и совместимость со стандартами POSIX.

Последнее гарантирует, что большинство программ для Unix будут функционировать и в Mac OS X.

Важным компонентом Mach является система ввода-вывода (I/O Kit).

Именно здесь заключается существенное отличие от Windows и Linux: I/O Kit представляет собой дополнительный слой абстракций между оборудованием и остальной системой.

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

Помимо служб ядра Mac OS X позволяет также использовать расширения ядра. Система загружает их динамически по мере необходимости. Часто в таких случаях говорят о гибридном ядре, однако эксперты относят ядро Mac OS X скорее к монолитным из-за особенностей его строения.

Процессы: цифровая подпись как средство защиты

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

Под этим подразумевается не только расстановка приоритетов, но и обеспечение безопасности. В классическом варианте в Windows процессы запускаются и управляются через интерфейс Win32 API.

В ядре этим занимается исполнительная система NTOS.

Доступ к объектам ядра, относящимся к про цессу обеспечивают так называемые дескрипторы (handles). Процессы в Windows могут запускать новые процессы. Так, Word (процесс 1) может открыть новый документ (процесс 2). В классической модели Windows Word имеет право также стереть или изменить новый документ. Иными словами, по общему правилу процесс может распоряжаться порожденными собою же процессами.

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

В связи с этим Vista пересмотрела процессную модель специально для мультимедийных файлов и ввела новый тип процессов — защищенные. Возможности манипулирования ими существенно ограничены: хоть ядро и предоставляет диагностическую информацию о таких процессах, но непосредственный доступ закрыт даже для администраторов.

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

Защищенные процессы — показательный пример того, как Microsoft приспосабливает устаревшую архитектуру Windows к современным проблемам.

В Linux и Mac OS X процессная модель сходна с моделью Windows: процессы-«родители» контролируют порожденных ими «детей». Однако защищенных процессов, таких как в Vista, нет. Это неудивительно: Microsoft использует эту технологию в первую очередь для цифрового управления правами (Digital Rights Management).

Таким образом, при наличии администраторских (root) прав в Linux и Mac OS X можно делать все, даже анализировать процессы и манипулировать ими.

ASLR : «неуловимые» адреса

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

Например, NX-бит препятствует исполнению данных DEP (Data Execution Prevention).

При попытке выполнить код, который находится в участке памяти, помеченном «не для исполнения», возникает внутренняя ошибка. В Windows отключить DEP для 64-битных программ и драйверов нельзя, зато для 32-битных (все еще весьма распространенных) — без проблем. Это позволяет злоумышленникам вызвать переполнение буфера. В результате они могут инфицировать такие процессы, как Internet Explorer, и проникнуть внутрь системы. После того как вредитель закрепился в Windows, он может использовать Windows-API в своих интересах — например, для того, чтобы считать нужные ему данные или изменить конфигурацию системы.

Поэтому Microsoft ввела новую функцию защиты ядра — Address Space Load Randomization (ASLR, «рандомизация адресного пространства»). Частично она была реализована уже в SP2 для ХР, но полностью — только в Vista. Ее суть заключается в следующем. В Windows входными воротами для злоумышленников обычно являются библиотеки DLL, которые в предшествовавших версиях системы всегда загружались в одни и те же участки памяти. С ASLR системные DLL и исполняемые файлы при каждой загрузке системы попадают в разные участки оперативной памяти, чтобы вредоносное ПО больше не могло атаковать системные операции по стандартным адресам. Для этого менеджер памяти имеет в своем распоряжении 256 различных адресов и при загрузке DLL выбирает один из них случайным образом. Такая «плавающая» стратегия ASLR имеет дополнительное преимущество: адресное пространство упаковано плотнее, чем в более ранних версиях Windows, так что непрерывных свободных участков в памяти остается больше.

В специальных дистрибутивах Linux, таких как Hardened Gentoo, ASLR уже полностью реализована. В стандартном же ядре содержится лишь неполный вариант. В современном OS X Build ASLR используется для нескольких библиотек, но их полноценная реализация, к сожалению, отсутствует.

Проверка подлинности: надежный код

В качестве противоядия Microsoft использует в Vista подпись кода в режиме ядра (KMCS), которая разрешает загружать лишь те драйверы устройств, которые снабжены цифровой подписью. Большинство драйверов получают подписи через лабораторию WHQl (Windows Hardware Quality Lab), однако разработчики могут подписывать свой код сами — правда, для этого им нужен действительный сертификат. Windows проверяет также, имеет ли выданный сертификат отношение к одному из центров сертификации, данные о которых содержатся в загрузчике Windows и ядре ОС. Надо сказать, что 32-битные системы Vista хотя и проверяют цифровые подписи драйверов, все-таки позволяют загрузить неподписанные драйверы.

В 64-битных Windows такой номер не пройдет.

Все модули ядра в Mac OS X и Linux, в принципе, могут иметь цифровую подпись. Хотя теоретически это относится и к драйверам, никаких механизмов проверки в этих операционных системах не встроено.

MMCSS : приоритет видео

Планировщик Windows жонглирует несколькими процессами, открытыми одновременно. Каждое приложение на определенное время получает доступ к вычислительным мощностям центрального процессора, затем уступает место другим и ждет снова своей очереди.

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

В Vista приоритет фильмов и музыки обеспечивается службой планирования мультимедийных классов — MMCSS. Для этого мультимедийное приложение, такое как Media Player, сначала должно зарегистрироваться в этой службе. Данная служба, реализованная в файле %SystemRoot%System32Mmcss.dll, включает в себя поток для управления приоритетами. Windows предусматривает ступени приоритетности от 0 до 31, при этом MMCSS имеет очень высокую приоритетность — 27. Соответственно, приоритетность всех зарегистрированных мультимедийных потоков поднимается до 27. С 16-й ступени начинается режим реального времени, то есть потоку с приоритетом 16 остальные помешать уже не могут.

Linux предлагает еще более высокую градацию шкалы приоритетности — от 0 до 99. Для мультимедийных задач, например, на медиасерверах, такая разбивка подходит лучше. В Mac OS X планировщик является одним из используемых компонентов Mach.

Шкала приоритетности здесь еще мельче — от 0 до 127, и это не единственное подтверждение того, что Mach намного современнее, чем Linux и Windows. В OS X мультимедийное приложение может даже присвоить себе фиксированную долю вычислительного времени. При достаточной мощности это практически исключает риск образования узких мест.

Ввод-вывод: приоритетность задач

Высокая приоритетность при просмотре фильмов может негативно отразится на многозадачности. Так, до ХР в Windows существовали серьезные проблемы с фоновыми службами, например, автоматической дефрагментацией.

Конечно, это помогало поддерживать жесткий диск в порядке, но кому же понравится, когда, к примеру, Outlook выпадает из обоймы на два часа? Однако благодаря приоритетности ввода-вывода ждать больше не придется. Так, в Vista процессы «переднего плана» (не фоновые) всегда пользуются преимуществом, и дефрагментация приостановится до тех пор, пока пользователь не сделает в своей работе очередную паузу. Система ввода-вывода в Vista предполагает пять ступеней приоритетности — от «очень низкая» до «критически важная»; стандартный уровень — «нормальная». Фоновым задачам Windows автоматически присваивает низкую приоритетность, однако менеджер памяти всегда считается критически важным: действительно, когда оперативной памяти начинает не хватать, он должен незамедлительно сбросить данные на жесткий диск.

Команды ввода-вывода, посылаемые от драйверов устройств (такие как движение мыши), поступают в очередь со средней приоритетностью.

Еще одна ценная возможность заключается в том, что Vista может резервировать для операций ввода-вывода фиксированные диапазоны. Так, например, Media Player может потребовать от системы ввода-вывода гарантию, что фильм будет считываться с DVD в определенном темпе.

Тогда как в Vista приоритетность ввода-вывода — нововведение, в Mac OS X и Linux данный прием используется давно. В Mac OS X это заложено в архитектуре, так как для передачи сообщений используется Mach. В системах семейства Linux, начиная с ядра 2.6, тоже встроена эффективная схема приоритетов.

Адресное пространство: динамическое управление

32-битные процессоры накладывают на Windows и инсталлированные программы серьезные ограничения в отношении адресного пространства. Так, ядро Windows не может занимать больше 2 Гбайт. Когда нужно выделить место для драйверов, кеша файловой системы и стека, это может привести к определенным трудностям. Поэтому в Vista адресное пространство ядра динамическое. Оно занимается раздачей и разблокированием участков в зависимости от рабочих потребностей.

Операционные системы Linux и Mac OS X не имеют строгих ограничений. И в этих операционных системах общие размеры ядра имеют свой предел. В целом формат отдельных компонентов никак не ограничен. Действительно, в отличие от Windows в этих системах нет четкого разграничения между пространством ядра и пространством драйверов.

КТМ: предотвращение программных сбоев

Если приложение намерено предпринять ряд взаимосвязанных изменений, оно может создать либо дескриптор КТм («диспетчера транзакций ядра») и транзакцию DTC (Distributed Transaction Coordinator, «координатора распределенных транзакций»), либо просто дескриптор КТМ, и выполнять изменения файлов и ключей реестра в рамках этой транзакции. Если все прошло успешно, транзакция подтверждается — изменения приняты. До этого программа может в любой момент отменить весь процесс. Дополнительное преимущество заключается в том, что другие приложения видят эти изменения только после того, как транзакция принята.

Ядра Mac OS X и Linux тоже работают с транзакциями.

Пользователь, как правило, этого совсем не замечает, если не считать сбоев при установке обновлений. Впрочем, в обеих ОС это никак не подрывает стабильность системы, просто транзакции не будут исполнены.

Windows 7, 8, 9…

Не секрет, что Microsoft работает над новой архитектурой Windows. Прототипом операционной системы будущего (после Win7) должны стать два проекта.

Singularity обещает нам Windows без «синих экранов» и зависаний. Проект основан на трех ключевых функциях: программно-изолированные процессы (SIP), микроядро и каналы (channels).

Микроядро обеспечивает лишь неотъемлемые «ядерные» функции, такие как управление памятью, процессами и каналами, планировка процессорного времени и управление вводом-выводом. Все другие функции перекладываются на модули и реализуются изолированно друг от друга через SIP-процессы.

Проект Midori рассчитан на отдаленную перспективу. Его ядро будет иметь модульную структуру.

Преимущество заключается в том, что Windows будет лучше работать на различных платформах, таких как нетбуки, КПК или мобильные телефоны.

Вывод

Прошлые версии Windows на фоне Linux и Mac OS X смотрятся совсем неплохо. Хотя конкуренты несколько моложе, они во многом основаны на старых принципах Unix. Vista доказывает, что устаревшую архитектуру Windows можно компенсировать современными технологиями безопасности, такими как защищенные процессы или цифровые подписи кода для модулей ядра. Но, к сожалению, эти функции часто работают только в 64-битном мире, а в ХР они и вовсе отсутствуют. К тому же Linux и OS X не нуждаются в уловках вроде ASLR, поскольку они не так сильно подвержены атакам хакеров. Да и получить права администратора в Linux и Mac OS X сложнее, чем в Windows.

В Windows много застарелых проблем: например, даже в Vista дефектный драйвер все еще может обрушить всю систему. OS X выглядит несколько более современно: высокая производительность обеспечивается главным образом за счет использования компонентов Mach для коммуникаций внутри ядра, а также системы ввода-вывода I/O Kit.

В этом смысле Windows отстает, и компенсировать разрыв сумела только Vista. В пользу Linux говорит ее открытость: каждый может сконфигурировать ядро по своему усмотрению.

Источник

Windows Research Kernel

Содержание

Что такое Windows Research Kernel?

Windows Research Kernel (WRK) — исходный код ядра ОС Windows (Windows XP x64 и Windows Server 2003 SP1), распространяемый для некоммерческих, исследовательских целей в рамках «Windows Academic Program» под НЕ СВОБОДНОЙ лицензией (где пруфлинк?). Как следствие, этот код не может быть использован в процессе разработки ReactOS (т.е. разработчики никогда не смотрели этот код и не планируют этого делать, пока не изменятся условия лицензирования WRK)

WRK предназначен для факультетов и преподавателей, работающих в области операционных систем, для разработчиков курсов, авторов учебников и т.д., желающих включить информацию о ядре Windows, основанную на действующем исходном коде. WRK содержит среду для сборки/тестирования и бинарные файлы для исключённых компонентов исходного кода, которые могут быть использованы, чтобы собрать полнофункциональные NTOS ядра для последующей установки на Windows Server 2003 для x86/x64 и Windows XP x64.

Ниже информация из лекции «Исследовательское ядро Windows» курса «Введение во внутреннее устройство Windows» от Intuit.ru.

Windows Academic Program

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

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

• учебные материалы по курсу операционных систем на основе Windows XP – Windows Internals Curriculum Resource Kit (CRK). Составлены в соответствии с рекомендациями ACM/IEEE по преподаванию курса «Операционные системы» (Operating systems, OS). Материалы включают презентации лекций, указания к лабораторным работам (в том числе лабораторные работы для 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, преследовало следующие цели:

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

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

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

Рис.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.2basentos и включают, в основном описания и определения функций и структур данных. В ядре Windows при именовании функций используются определенные соглашения [5; 2]. Название функции обычно строится по следующей схеме:

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

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

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

Компонент WRK	Префикс функций	Название компонента на англ. языке	Название компонента на русском языке
cache	Cc	Cache manager	диспетчер кэша
config	Cm	Configuration manager	диспетчер конфигурации
dbgk	Dbgk	Debugging Framework	подсистема отладки
ex	Ex	Executive support routines	функции поддержки исполнительной системы – синхронизация, таймеры, структуры данных исполнительной системы, системная информация
fsrtl	FsRtl	File system driver run-time library	библиотека функций поддержки файловой системы времени выполнения
io	Io	Input/Output manager	диспетчер ввода-вывода
ke	Ke	Kernel	ядро
lpc	Lpc	Local Procedure Call	механизм вызова локальных процедур
mm	Mm	Memory manager	диспетчер памяти
ob	Ob	Object manager	диспетчер объектов
perf	Perf	Performance	функции для сбора информации о производительности системы
ps	Ps	Process manager	диспетчер процессов
raw	Raw	Raw File System	функции для Raw File System
rtl	Rtl	Run-Time Library	библиотека функций времени выполнения
se	Se	Security manager	диспетчер безопасности
wmi	Wmi	Windows Management Instrumentation	поддержка WMI – инструментальные средства управления Windows

Компоненты WRK и префиксы функций

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

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

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

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

В Институте программной инженерии Хассо Платтнера Университета г. Потсдама (Hasso-Plattner-Institute for Software Engineering at University Potsdam) Александром Шмидтом (Alexander Schmidt) и Михаэлем Шёбелем (Michael Schobel) была создана HTML документация по WRK с использованием генератора документации Phoenix Cross Reference (PXR)2 . Данная документация доступна для преподавателей по следующей ссылке:

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

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

Html документация по windows research kernel

Windows Research Kernel Source Code

Copyright (c) Microsoft Corporation. All rights reserved.

You may only use this code if you agree to the terms of the Windows Research Kernel Source Code License agreement (see License.txt). If you do not agree to the terms, do not use the code.

The Windows Research Kernel v1.2 contains the sources for the core of the Windows (NTOS) kernel and a build environment for a kernel that will run on x86 (Windows Server 2003 Service Pack 1) and amd64 (Windows XP x64 Professional) A future version may also support booting WRK kernels on Windows XP x86 systems, but the current kernels will fail to boot due to differences in some shared structures.

The NTOS kernel implements the basic OS functions for processes, threads, virtual memory and cache managers, I/O management, the registry, executive functions such as the kernel heap and synchronization, the object manager, the local procedure call mechanism, the security reference monitor, low-level CPU management (thread scheduling, Asynchronous and Deferred Procedure calls, interrupt/trap handling, exceptions), etc.

The NT Hardware Abstraction Layer, file systems, network stacks, and device drivers are implemented separately from NTOS and loaded into kernel mode as dynamic libraries. Sources for these dynamic components are not included in the WRK, but some are available in various development kits published by Microsoft, such as the Installable File System (IFS) Kit and the Windows Driver Development Kit (DDK).

WRK v1.2 includes most of the NTOS kernel sources from the latest released version of Windows, which supports the AMD64 architecture on the Desktop. The kernel sources excluded from the kit are primarily in the areas of plug-and-play, power management, the device verifier, kernel debugger interface, and virtual dos machine. The primary modifications to WRK from the released kernel are related to cleanup and removal of server support, such as code related to the Intel IA64.

Organization of the WRK sources

The file License.txt contains the license covering use of the WRK.

The public directory contains a number of include files shared among system components. basentos contains the NTOS sources.

The primary NTOS source components included in the WRK are organized as follows:

Copying and building the WRK

WRK can be built on Windows Server 2003 or later, or on Windows XP or later.

To copy WRK to your machine:

• open a console window;
• switch to DVD;
• switch to ResourcesWindows_Research_KernelGet_WRK;
• run WRKCopy.bat /w (if you run WRKCopy.bat without parameters, WRK will be copied to C:WRK-v1.2); ALTERNATIVELY
• open Windows Explorer (MyComputer);
• create the destination directory on your hard drive;
• switch to DVD;
• navigate to ResourcesWindows_Research_KernelGet_WRKWRK-v1.2;
• select all files and subdirectories, drag and drop them to the destination directory.

To adjust the WRK environment setting batch file:

• open console window;
• switch to the directory WRK was copied to;
• run Notepad WRKEnv.bat;
• make sure the «set path=. » statement contains the directory WinDbg was installed to; (unchanged WRKEnv.bat refers to default directory C:Program FilesDebugging Tools for Windows);
• save the file and exit Notepad.

To build WRK from command line:

• open console window;
• switch to the directory WRK was copied to;
• run Build (or Rebuild or Clean ), see note about below; ALTERNATIVELY
• open console window;
• switch to the directory WRK was copied to;
• run WRKEnv , see note about below;
• switch to basentos;
• run nmake %wrkarch%=

To build WRK in Visual Studio 2008 environment:

• start VS2008;
• open solution WRK.sln, where is the directory WRK was copied to;
• make sure the configuration is amd64/Win32 or x86/Win32, as is appropriate;
• select Build/Build Solution (or Rebuild Solution, or Clean Solution).

To start Windows Debugger from command line:

• open console window;
• switch to the directory WRK was copied to;
• run WRKDebug , see note about below; ALTERNATIVELY
• open console window;
• switch to the directory WRK was copied to;
• run WRKEnv , see note about below;
• run WinDbg %windbgargs%

Batch files Build.bat, Rebuild.bat, Clean.bat, WRKEnv.bat and WRKDebug.bat take one parameter – target architecture, which is x86 or amd64.

For the first use of either of these batch files, default target architecture is x86.

Once the target architecture was defined (explicitly or by default), it cannot be changed for current console window, and parameter of the batch files is ignored.

The title of the window where the WRK environment has been set to some target architecture changes to “WRK x86” or “WRK amd64”.

To work with different target architecture, open another console window.

Copyright (c) Microsoft Corporation. All rights reserved.

You may only use this code if you agree to the terms of the Windows Research Kernel Source Code License agreement (see License.txt). If you do not agree to the terms, do not use the code.

The Windows Research Kernel v1.2 contains the sources for the core of the Windows (NTOS) kernel and a build environment for a kernel that will run on x86 (Windows Server 2003 Service Pack 1) and amd64 (Windows XP x64 Professional) A future version may also support booting WRK kernels on Windows XP x86 systems, but the current kernels will fail to boot due to differences in some shared structures.

The NTOS kernel implements the basic OS functions for processes, threads, virtual memory and cache managers, I/O management, the registry, executive functions such as the kernel heap and synchronization, the object manager, the local procedure call mechanism, the security reference monitor, low-level CPU management (thread scheduling, Asynchronous and Deferred Procedure calls, interrupt/trap handling, exceptions), etc.

The NT Hardware Abstraction Layer, file systems, network stacks, and device drivers are implemented separately from NTOS and loaded into kernel mode as dynamic libraries. Sources for these dynamic components are not included in the WRK, but some are available in various development kits published by Microsoft, such as the Installable File System (IFS) Kit and the Windows Driver Development Kit (DDK).

WRK v1.2 includes most of the NTOS kernel sources from the latest released version of Windows, which supports the AMD64 architecture on the Desktop. The kernel sources excluded from the kit are primarily in the areas of plug-and-play, power management, the device verifier, kernel debugger interface, and virtual dos machine. The primary modifications to WRK from the released kernel are related to cleanup and removal of server support, such as code related to the Intel IA64.

Organization of the WRK sources

The file License.txt contains the license covering use of the WRK.

The public directory contains a number of include files shared among system components. basentos contains the NTOS sources.

The primary NTOS source components included in the WRK are organized as follows:

Copying and building the WRK

WRK can be built on Windows Server 2003 or later, or on Windows XP or later.

To copy WRK to your machine:

• open a console window;
• switch to DVD;
• switch to ResourcesWindows_Research_KernelGet_WRK;
• run WRKCopy.bat /w (if you run WRKCopy.bat without parameters, WRK will be copied to C:WRK-v1.2); ALTERNATIVELY
• open Windows Explorer (MyComputer);
• create the destination directory on your hard drive;
• switch to DVD;
• navigate to ResourcesWindows_Research_KernelGet_WRKWRK-v1.2;
• select all files and subdirectories, drag and drop them to the destination directory.

To adjust the WRK environment setting batch file:

• open console window;
• switch to the directory WRK was copied to;
• run Notepad WRKEnv.bat;
• make sure the «set path=. » statement contains the directory WinDbg was installed to; (unchanged WRKEnv.bat refers to default directory C:Program FilesDebugging Tools for Windows);
• save the file and exit Notepad.

To build WRK from command line:

• open console window;
• switch to the directory WRK was copied to;
• run Build (or Rebuild or Clean ), see note about below; ALTERNATIVELY
• open console window;
• switch to the directory WRK was copied to;
• run WRKEnv , see note about below;
• switch to basentos;
• run nmake %wrkarch%=

To build WRK in Visual Studio 2008 environment:

• start VS2008;
• open solution WRK.sln, where is the directory WRK was copied to;
• make sure the configuration is amd64/Win32 or x86/Win32, as is appropriate;
• select Build/Build Solution (or Rebuild Solution, or Clean Solution).

To start Windows Debugger from command line:

• open console window;
• switch to the directory WRK was copied to;
• run WRKDebug , see note about below; ALTERNATIVELY
• open console window;
• switch to the directory WRK was copied to;
• run WRKEnv , see note about below;
• run WinDbg %windbgargs%

Batch files Build.bat, Rebuild.bat, Clean.bat, WRKEnv.bat and WRKDebug.bat take one parameter – target architecture, which is x86 or amd64.

For the first use of either of these batch files, default target architecture is x86.

Once the target architecture was defined (explicitly or by default), it cannot be changed for current console window, and parameter of the batch files is ignored.

The title of the window where the WRK environment has been set to some target architecture changes to “WRK x86” or “WRK amd64”.

To work with different target architecture, open another console window.

PC-PORTAL

МЕНЮ