Native приложения. Первые шаги
Native приложения — это программы, предназначенные для выполнения на операционных системах Windows семейства NT (NT/2000/XP/2003/Vista/7), способные запускаться на раннем этапе загрузки Windows, до окна входа в систему и даже до запуска каких-либо подсистем Windows. Синий экран при загрузке Windows XP, в котором, например, происходит проверка диска и есть тот самый режим. Native приложения используют только Native API, они могут использовать только функции, экспортируемые из библиотеки ntdll.dll. Для них недоступны функции WinAPI.
Native приложения запускаются на экране, который возникает до появления окна входа в систему. Примером native приложения является приложение chkdsk, которое запускается перед входом в Windows, если предварительно была запущена проверка системного раздела на ошибки и отложена до перезагрузки. Приложение работает, выводя сообщения экран, а затем происходит обычный запуск Windows.
Преимущества использования этого режима: большая часть компонентов Windows ещё не запущена, отсутствуют многие ограничения. Этот режим, например, используется в приложениях, которые хотят что-то сделать с системным разделом Windows, но не могут, пока запущена операционная система: дефрагментаторы, конверторы файловой системы, и тому подобные утилиты.
Моя программа Native shell запускается до экрана входа в систему и предоставляет интерфейс командной строки с возможностью перемещаться по файловой системе Windows, копировать и удалять файлы, просматривать некоторую информацию об операционной системе и запускать другие процессы, способные выполняться в native-режиме, такие как autochk.exe и autoconv.exe. Доступны исходные коды программы на языке Си.
Загрузочные экраны native режима разных версий Windows:
 — Синий экран Windows XP. |  Серый экран Windows Server 2003 |
 Чёрный экран Windows Vista |  Чёрный экран Windows 7 |
Что нужно знать:
Native приложения используют Native API. Оно частично документировано в MSDN для использования при написании драйверов. Но документированы не все функции. Информацию по остальным нужно брать из неофициальных источников. Например, на сайте http://undocumented.ntinternals.net/
Для программирования нужны прототипы функций Native API, но в заголовочных файлах WDK присутствуют не все определения. Нужно использовать альтернативные заголовочные файлы, содержащие в том числе и определения недокументированных функций и типов данных. Например, можно воспользоваться заголовочными файлами Native Development Kit (NDK), которые доступны здесь.
При необходимости, native-приложение можно запустить и не перезагружая компьютер. Для этого следует воспользоваться утилитой nrun.exe. Но загрузочный экран от этого не появится, и вам следует придумать, как ещё взаимодействовать с вашим приложением, если нужна интерактивность. В исходном коде nrun можно посмотреть, как реализован запуск native-процессов с использованием недокументированных функций Native API.
У native приложений точка входа не main и не wmain, а NtProcessStartup. В PE-заголовке EXE-файла есть специальное поле, означающее подсистему, в которой выполняется приложение. У native приложений в это поле установлено специальное значение, означающее, что EXE не требует подсистемы. У обычных приложений ставится значение, соответствующее подсистемам «Windows GUI» или «Windows console». Native приложения не запускаются в обычном режиме работы Windows. При попытке запустить программу Windows выдаёт сообщение «Приложение нельзя запустить в режиме Win32».
Вывод кириллицы на экран по-умолчанию в этом режиме не поддерживается. Есть способ обойти это ограничение, впрочем, способ сложный и пока работает только на Windows XP.
Заготовка проекта Native приложения
Возможно также разрабатывать и собирать Native-приложения прямо в Visual Studio, без использования компилятора WDK. О том, как это сделать, написано в статье Сборка Native API-приложения в Visual Studio 2010.
Windows native что это
Этот этап позволяет продолжить установку или запустить Recovery Console, но только если на HDD уже есть установленная WinXP.
Очевидно что diskpart Windows XP Native Mode в вариантах установки и консоли практически не различаются.
Portable Windows XP SP3 Recovery Console
Portable Windows XP SP3 Recovery Console запускается c HDD или USB Flash
С помощью загрузочной флешки Portable Recovery Console легко подготовить жесткий диск, разбить на разделы, отформатировать или проверить на ошибки.
Microsoft Windows XP native
C одержание файла boot.ini для запуска автономной ОС Microsoft Windows XP native
BT Опция /cmdcons записывает в память строку cmdcons также как и Grub для DOS см. menu.lst. В варианте установки файл txtsetup.sif должен быть в корне активного раздела.
Также как и n ative.exe defrag_native.exe поддерживает команду exit
и главная команда udefrag
Возможности :
OsLoadOptions = «/fastdetect /noguiboot /nodebug» ==>> OsLoadOptions = «/fastdetect /nodebug»
OS Windows XP native standalone build 2
N ative.img boot from Grub for DOS with A> command prompt (driver WVBlk32.sys)
Bug remove type only cd c: cd a : начало работы
VHD Native Boot снаружи и внутри
Цель настоящей статьи — рассказать о моем опыте работы с весьма полезной и не слишком хорошо известной функцией Windows, которая называется VHD Native Boot, то есть способности загружаться с виртуального жесткого диска формата VHD/VHDx.
Начиная с 7-й версии, в Windows появилась возможность создавать виртуальные диски VHD/VHDx (далее просто VHD), а также подсоединять и отсоединять их через графический интерфейс «Управление дисками» и утилиту командной строки diskpart. Кроме этого, Windows научилась с таких дисков загружаться, и все бы ничего, но этот самый Native Boot был доступен только обладателям старших версий, то есть от Pro и выше. Очевидно, что это было лишь маркетинговое ограничение, потому что с появлением Windows 10, а я проверял Anniversary Update (1607) и Creators Update (1703), никаких ограничений больше нет. Это работает и в Windows 10 Home, причем она может выступать как в роли хоста, так и в роли гостя. О том, как это выглядит и как это можно использовать, вы узнаете ниже.
С давних пор меня интересовала идея использования виртуализации применительно к рабочему компьютеру, внутренней виртуализации, если так можно выразиться. Как полезны и удобны виртуальные машины для разработчиков-программистов, специалистов по безопасности, тестированию. А вот до уровня домашнего/рабочего компьютера и его операционной системы это дело все никак не доходило. Ну, очевидно же, что если операционная система — такой сложный и чувствительный компонент, нельзя огульно доверять ее пользователю, он ее так и норовит чем-нибудь заразить или повредить. Да, есть резервное копирование и восстановление из точек восстановления (то есть из теневой копии), и это отличные вещи. Но это весьма чувствительные к ошибкам компоненты, и могут не спасти, кроме того, многие зловреды умеют удалять теневые копии, не оставляя пользователю шанса. Хотелось бы что-то простое и банальное на уровне copy-paste, чтобы «упавшую» или «испортившуюся» систему вернуть в рабочее состояние в течение нескольких минут. Конечно, идеально было бы, чтобы решение было в самой системе, просто заложено в ней. Hyper-V все же не совсем то, хотя может быть его и допилят до требуемого уровня. Ведь хочется, чтобы все возможности машины, все ее железо, вся мощь были доступны, с минимальными жертвами.
Использование виртуального жесткого диска вместо реального кажется вполне допустимой жертвой с учетом того, что вся система умещается в один файл, и достаточно этот файл время от времени копировать куда-то «в сторонку», и всё будет хорошо. Ведь копировать один файл, пусть и большой, явно проще, чем десятки тысяч. Кроме того, такой файл можно легко использовать для развертывания Windows в организации.
Когда есть несколько (немного) типов компьютеров, достаточно установить систему и все требуемое ПО на VHD, а потом просто скопировать этот файл на все аналогичные компьютеры, сведя работы на местах к минимуму. Неплохо было бы иметь некую оболочку, без загрузки Windows, что-то типа «консоли гипервизора», позволяющую попадать в нее и работать с VHD на уровне файлов, копировать, заменять, обновлять и т.д. Тем более, что сама Windows такую оболочку в своем составе имеет, и называется она Windows Recovery Environment, далее WinRE. Давайте посмотрим, как все это выглядит на практике.
1. Установка Windows на VHD с нуля
Эта тема широко освещена в Сети, существуют десятки толковых руководств (см. ссылки в конце статьи), поэтому я остановлюсь лишь вскользь, попутно рассматривая возможные варианты.
В целом все сводится к нажатию волшебной комбинации Shift-F10 в момент, когда компьютер загрузился с установочного диска. Параллельно открывается окошко командной строки, где следует, используя diskpart, отформатировать и разметить реальный жесткий диск (если компьютер/диск новый) и создать VHD требуемого объема. Для простоты я буду рассматривать установку 64-разрядной версии и жесткие диски с MBR.
Итак, жесткий диск разбит, папка VHDs на соответствующем томе создана, теперь в diskpart надо создать виртуальный жесткий диск в этой папке, дав ему понятное имя, и выполнить присоединение, тогда тому виртуального диска будет присвоена очередная буква. Теперь можно вернуться в окно установки Windows и выбрать именно эту букву для установки. Всё, дальше программа установки все сделает сама. В том числе и добавит нужную запись в файл BCD.
Сразу скажу, что использовать bcdedit мне показалось уж слишком жестоким самоистязанием, поэтому я позволил себе использование одного стороннего инструмента для манипуляций, это утилита Bootice соответствующей разрядности. Предположим, он у вас есть на том же установочном диске. Если нет, в дальнейшем я покажу, как его можно «закинуть» в нашу оболочку «гипервизора».
Итак, для демонстрации пусть у меня есть один жесткий диск 25 Gb (я воспользуюсь любимым Virtualbox для показа), в нем один раздел, там папка VHDs, где я создал виртуальный диск, а на него установил Windows 10.
Вот так будет выглядеть меню загрузки системы в Bootice (раздел BCD, Easy Mode)
Здесь 25 Gb C: это тот «физический» диск, на котором я создал виртуальный размером 20 Gb и куда установил Windows 10. Все прекрасно, но дальше нам нужно создать оболочку для управления. Как известно, WinRE всегда устанавливается вместе с Windows и приходит на помощь тогда, когда обнаруживаются проблемы с загрузкой. Нам же она нужна для другой цели, я хочу попадать туда для работы с VHD-файлами. Добавим пункт WinRE в меню загрузки. Для этого в Bootice воспользуемся Professional Mode, последний объект в списке слева это как раз Windows Recovery, справа видно его расположение на VHD:
Этот объект, вернее, ссылку на него, надо добавить в список меню загрузки, выберем вверху слева ветвь Windows Boot Manager, в правой панели выберем пункт Display Order и добавим пункт про WinRE из выпадающего списка:
Теперь пункт Windows Recovery Environment будет показываться в загрузочном меню системы, в чем мы можем убедиться, вернувшись в Easy Mode:
Осталось перезагрузиться и выбрать второй пункт, начнется загрузка WinRE, а там нас интересует только пункт Поиск и устранение неисправностей, Дополнительные параметры, Командная строка. Все это напоминает и программу установки Windows, и прародителя WinRE, широко известную Windows Preinstallation Environment. Отсюда, собственно, и начинается работа с оболочкой, и не так важно, какую именно вы выберете, поскольку там все приблизительно одно и то же.
Наш основной жесткий диск оказывается в ней диском C:, в его папке VHDs обнаруживается наш master.vhd, и мы можем спокойно его куда-нибудь скопировать. В WinRE волшебной командой мы подключаем сеть:
автоматически выбирается и запускается драйвер сетевого адаптера, получается ip-адрес от сервера DHCP, и мы можем работать с сетью. В Virtualbox я могу подключить сетевую папку такой командой:
и оттуда уже скопировать необходимые инструменты для работы в оболочке. Так как выбрана версия x64, то и программы, запускаемые в WinRE, должны быть x64, никакие суррогаты не запустятся.
Помимо Bootice легко добавляются Far Manager, 7-zip, а с ними уже как-то повеселее. Мне удалось найти даже работающий веб-браузер Palemoon Portable, а уж с ним загрузить из Сети необходимые компоненты совсем легко. Прекрасно установился cygwin64, что открывает путь для ssh/rsync в смешанных средах. Дальше понятно, у нас есть возможность спокойно архивировать и копировать файлы vhd. Если что-то не так в master.vhd, мы загружаемся в WinRE и забираем его резервную копию из сетевого хранилища, затем выходим из WinRE и получаем нашу систему обратно.
Прямо из оболочки WinRE при помощи diskpart или Bootice можно создать новый VHD диск, запустить программу установки Windows, если хочется добавить какую-то иную версию и установить эту новую Windows на новый VHD, нужный пункт в меню загрузки ОС добавится сам.
Осталось только подстраховаться на тот случай, если с master.vhd все настолько плохо, что и в оболочку WinRE не загрузишься, ведь она часть этого диска. Конечно, это не смертельно, всегда можно загрузиться с установочного диска Windows и нажать Shift-F10, но приложив определенные усилия, можно сделать так, чтобы WinRE находилась на нашем хост-диске, и грузиться в нее оттуда. Загрузочное меню будет выглядеть так:
2. Установка Windows на VHD на работающем компьютере
Не представляет никакой проблемы добавить на имеющемся компьютере дополнительную операционную систему, создав новый VHD и присоединив его, а затем запустив программу установки и выбрав букву, назначенную для присоединенного диска. Намного более сложной задачей будет перенос текущей конфигурации, уже установленной на физическом диске системы на диск виртуальный. Здесь приходит на ум несколько вариантов. Первый, о котором я вспомнил, это использовать Windows Backup, ведь он как раз создает файл VHD (vhdx) в режиме создания образа системы. Казалось бы, всё, что требуется — это добавить ссылку на такой VHD в меню загрузки и посмотреть, что выйдет. Так я и сделал, при первой загрузке Windows выдала ошибку, а при всех последующих старательно что-то загружалось, очень долго, и даже промелькивало окошко с картинкой экрана блокировки первоначальной системы, но так и исчезало опять. Не знаю почему, но с VHD-диска, полученного из backup’а, Windows загрузить не удается. Пришлось идти иным путем, воспользоваться Disk2vhd из комплекта Sysinternals.
Все довольно просто, выбираешь раздел физического диска, или весь диск, и Disk2vhd делает из него VHD-файл:
3. Использование дифференциальных VHD
В особо ненадежных средах, на публичных компьютерах или при проведении каких-то опасных экспериментов, может пригодиться возможность использования дифференциальных VHD-дисков, на которых записывается только разница, изменившаяся информация, а оригинальный VHD остается без изменений. Ясно, что для начала надо уже иметь работающую систему на VHD-диске, а потом добавить вариант с дифференциальным диском. Создать такой диск можно в diskpart или все в том же Bootice. Пусть master.vhd наш основной диск, создадим для него дифференциальный child.vhd, нажав кнопку Create:
Теперь нужно добавить/исправить в BCD пункт, отвечающий за загрузку с VHD, указав вместо master.vhd дифференциальный child.vhd.
Для этого воспользуемся Professional Mode в Bootice, сделаем копию имеющегося пункта Windows 10 (правая кнопка мыши, Duplicate this entry) и переименуем новый в Windows 10 Child VHD. Теперь в этом пункте исправим ApplicationDevice и OsDevice, изменив имя vhd-файла:
Всё, теперь нужный пункт добавлен в загрузочное меню. Если выбрать Windows 10 Child VHD, Windows запустится и с этого момента будет все изменения записывать в child.vhd. Следует учесть, что под child.vhd в момент загрузки будет зарезервировано столько же места, сколько указано в master.vhd, то есть в нашем случае 20 Gb, пусть его реальный размер в сотни раз меньше. Время от времени имеет смысл выполнять процедуру слияния (merge), то есть отправлять накопленную разницу из child в master, чтобы ничего не потерять. Дело в том, что стоит вам загрузиться не в child, а в master или даже WinRE на основе master.vhd, то связь между master и child будет нарушена, придется чинить child, но Bootice и это умеет:
4. Рекомендуемая конфигурация физического диска при работе с загрузочными VHD
Я бы предложил разметить физический диск следующим образом.
Один раздел, достаточно большой, оставить под хранение файлов VHD, тут все зависит от того, сколько разных VHD вам понадобится. Минимально для установки Windows x64 требуется 20 Гб, можно создавать динамические диски, то есть увеличивающие свой реальный размер только по мере их внутреннего наполнения. Но еще раз подчеркну, в момент загрузки динамического VHD Windows резервирует под него место в соответствии с указанным максимальным размером.
Microsoft советует использовать VHD фиксированного размера в производственной среде, а динамические — только для тестов, но я особой потери производительности у динамических VHD не ощутил.
Второй раздел я бы предпочел создать для данных пользователя и набора портативных приложений, если требуется, например, загружаться с разных VHD, а работать с одними и теми же файлами и программами. Такое деление может быть полезным еще и для того, чтобы раздел с VHD вообще скрыть, во избежание неразумных действий конечного пользователя.
А скрыть раздел можно при помощи вот такого нехитрого сценария для diskpart, с учетом выбранного диска и раздела для хранения VHD.
Теперь раздел скрыт, буква ему не присвоена, однако Windows все равно будет грузиться с VHD, хранящегося в этом разделе. Единственный нюанс — выбор места на физическом диске для файла подкачки. Если он выбирается системой, и это как раз тот раздел, который будет скрыт, каждый раз при старте Windows будет спрашивать, где же создавать файл подкачки.
А чтобы вернуть ларчик назад, достаточно в diskpart выполнить команду
Для приложений обеспечивается производительность на уровне машинного кода. Как правило, производительность будет значительно выше, чем если бы код сначала компилировался в промежуточный язык, а затем в машинный код JIT-компилятором.
Можно продолжить программировать в C# или Visual Basic.
ускоренное выполнение для большинства приложений и сценариев;
ускоренная загрузка для большинства приложений и сценариев;
низкая стоимость развертывания и обновления;
оптимизированное использование памяти приложением.
.NET Native использует ту же серверную часть, что и компилятор C++, который оптимизирован для статических сценариев предварительной компиляции.
.NET Native может обеспечить производительность на уровне C++ для разработчиков управляемого кода, так как эта технология использует те же или аналогичные средства, что и C++, как показано в этой таблице.
| Компонент | .NET Native | C++ |
|---|---|---|
| Библиотеки | .NET Framework и среда выполнения Windows | Win32 + среда выполнения Windows |
| Компилятор | Оптимизирующий компилятор UTC | Оптимизирующий компилятор UTC |
| Развернут | Готов к запуску двоичных файлов | Готов к запуску двоичных файлов (ASM) |
| Параметры выполнения | MRT.dll (минимальной среды CLR) | CRT.dll (среда выполнения C) |
Windows Native Applications и сервис Acronis Active Restore
Сегодня продолжаем рассказ о том, как мы вместе с ребятами из Университета Иннополис разрабатываем технологию Active Restore, чтобы позволить пользователю как можно раньше начать работу на своей машине после сбоя. Речь пойдет о нативных приложениях Windows, включая особенности их создания и запуска. Под катом – немного о нашем проекте, а также практическое руководство как писать нативные приложения.
В прошлых постах мы уже рассказывали о том, что такое Active Restore, и как студенты из Иннополиса разрабатывают сервис. Сегодня я хочу остановиться на нативных приложениях, до уровня которых мы хотим “закопать” наш сервис активного восстановления. Если все получится, то мы сможем:
Что вообще такое нативное приложение?
Чтобы ответить на этот вопрос, давайте взглянем на последовательность вызовов, которые совершает система, например, если программист в своем приложении пытается создать файл.
Pavel Yosifovich — Windows Kernel Programming (2019)
Основное преимущество нативных приложений заключается в том, что ntdll загружается в систему значительно раньше kernel32. Это логично, ведь kernel32 требует наличия ntdll для работы. Как следствие, приложения, использующие нативные функции, могут начать работу значительно раньше.
Таким образом, Windows Native Applications – это программы, способные запускаться на раннем этапе загрузки Windows. Они используют ТОЛЬКО функции из ntdll. Пример такого приложения: autochk который исполняет chkdisk utility для проверки диска на ошибки еще до запуска основных сервисов. Именно на таком уровне мы и хотим видеть наш Active Restore.
Что нам понадобится?
Что же в коде?
Давайте немного потренируемся и для примера напишем небольшое приложение которое:
Начнем с вывода сообщения на экран. Для этого у нас есть нативная функция NtDisplayString, которая в качестве аргумента принимает указатель на объект структуры UNICODE_STRING. Инициализировать его нам поможет RtlInitUnicodeString. В результате, для вывода текста на экран мы можем написать вот такую небольшую функцию:
Так как нам доступны только функции из ntdll, и других библиотек в памяти просто еще нет, у нас обязательно возникнут проблемы с тем как аллоцировать память. Оператора new ещё не существует (потому что он родом из слишком высокоуровнего мира C++), также нет функции malloc (для нее нужны библиотеки runtime C). Можно конечно пользоваться лишь стэком. Но если нам нужно динамически аллоцировать память, делать это придется в куче (т.е. heap). Поэтому давайте создадим для себя кучу и будем брать из нее память когда нам потребуется.
Для этой задачи подойдет функция RtlCreateHeap. Далее, используя RtlAllocateHeap и RtlFreeHeap, мы будем занимать и освобождать память когда нам это будет нужно.
Перейдем к ожиданию ввода с клавиатуры.
Все что нам нужно – это использовать NtReadFile на открытом устройстве, и ждать, пока клавиатура не вернет нам какое либо нажатие. В случае, если нажата клавиша ESC, мы продолжим работу. Чтобы открыть устройство, нам потребуется вызвать функцию NtCreateFile (открыть нужно будет \Device\KeyboardClass0). Также мы вызовем NtCreateEvent, чтобы инициализировать объект для ожидания. Мы самостоятельно объявим структуру KEYBOARD_INPUT_DATA, которая представляет данные клавиатуры. Это облегчит нам работу.
Работа нативного приложения завершается вызовом функции NtTerminateProcess, потому что мы просто убиваем свой собственный процесс.
Весь код нашего небольшого приложения:
PS: Мы можем запросто использовать в коде функцию DbgBreakPoint() для остановки в дебаггере. Правда нужно будет подключить WinDbg к виртуальной машине для кернельной отладки. Инструкцию как это сделать можно найти тут или просто использовать VirtualKD.
Компиляция и сборка
Самый простой способ собрать нативное приложение – это использовать DDK (Driver Development Kit). Нам нужна именно древняя седьмая версия, так как более поздние версии имеют несколько иной подход и тесно работают с Visual Studio. Если же использовать DDK, то нашему проекту нужны всего лишь Makefile и sources.
Данный файл не получится так просто запустить, система ругается и отправляет нас думать о своем поведении со следующей ошибкой:
Как запустить нативное приложение?
В момент старта autochk последовательность запуска программ определяется значением ключа реестра:
Менеджер сессии поочередно исполняет программы из этого списка. Сами же исполняемые файлы менеджер сессии ищет в директории system32. Формат значения ключа реестра следующий:
Значение должно быть в шестнадцатеричном формате, а не в привычном ASCII, следовательно ключ, представленный выше, будет иметь формат:
Чтобы конвертировать название, можно использовать онлайн-сервис, например, этот.
Получается, чтобы запустить нативное приложение, нам необходимо:
После установки и перезагрузки еще до появления экрана выбора пользователей мы получим следующую картину:
На примере вот такого маленького приложения мы убедились, что запустить приложение на уровне Windows Native вполне возможно. Дальше мы с ребятами из Университета Иннополис продолжим строить сервис, который будет инициировать процесс взаимодействия с драйвером намного раньше, чем в предыдущей версии нашего проекта. А с появлением оболочки win32 логично будет передать управление полноценному сервису, который уже был разработан (об этом подробнее здесь).
В очередной статье мы коснемся еще одного компонента сервиса Active Restore, а именно UEFI драйвера. Подписывайтесь на наш блог, чтобы не пропустить следующий пост.