Native windows что это

Обновлено: 06.07.2024

Что такое файловый буфер? Что такое режим (модификатор) доступа, при работе с файлами?
Что такое файловый буфер? Что такое режим (модификатор) доступа, при работе с файлами?

Что такое IIS и что такое PWS? Почему одно без другого не работает?
вот уже второй день пытаюсь немного разобраться в АСП. накидал небольшую тестовую страничку. но с.

Что такое напряжение и что такое сила тока с позиции заряженных частиц
Объясните пожалуйста, что такое напряжение и что такое сила тока с позиции заряженных частиц.

The Native Image Generator (Ngen.exe) is a tool that improves the performance of managed applications. Ngen.exe creates native images, which are files containing compiled processor-specific machine code, and installs them into the native image cache on the local computer. The runtime can use native images from the cache instead of using the just-in-time (JIT) compiler to compile the original assembly. А чем они настолько выдаюшиеся, что привязываются к конкретному компу? Ведь если это некий native в классическом смысле, то идёт привязка разве что к версии винды + разрядности? Т.е. теоретически, "native" сделанный из NET должен бы запускаться на идентичной машине в плане версии фреймворка, разрядности, и версии операционки? Tulosba, это тоже ясно.
Тогда такой вопрос:
Код - чисто NET без дополнительных библиотек, без всяких winapi и прочей аддонщины.
1 машина - NET 3,5__W7x64
2 машина - NET 3,5__W7x64
Сгенерировали на первой машине "native" с помощью ngen
Скопировали на вторую машину - код работает.
Утверждение верно? да нее))) просто хочу выяснить что из себя представляет "платформозависимость" после ngen. Чем она обусловлена. skilllab, я по факту с ngen дел не имел. Но судя по описанию, на Ваш вопрос: Тогда такой вопрос:
Код - чисто NET без дополнительных библиотек, без всяких winapi и прочей аддонщины.
1 машина - NET 3,5__W7x64
2 машина - NET 3,5__W7x64
Сгенерировали на первой машине "native" с помощью ngen
Скопировали на вторую машину - код работает.
Утверждение верно?

Нет.
Нативный образ привязывается к конкретной системе, потому прекомпилированный образ распространять не получится.

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

Чем? Что в нём такого особенного, что зависит от конкретной системы? И тем более вопрос: зачем нативному. (по заявлению microsoft) коду какая-то привязка?

skilllab, К процессору , ОС-е например.

зачем нативному. (по заявлению microsoft) коду какая-то привязка?

Это позволяет коду выполнятся быстрее и в некоторых случаях выполняться вообще.

Native - родной код полученный на определенной ОС с определенным хардом)

Чем? Что в нём такого особенного, что зависит от конкретной системы? зачем нативному. (по заявлению microsoft) коду какая-то привязка? Нативный — это значит содержащий машинные инструкции, которые может выполнять ЦП под управлением текущей ОС без какого-либо посредника.
Что никак не отменяет возможность зависимости этих инструкций от внешних модулей (см. динамические библиотеки под нативный C/C++). images from the cache instead of using the just-in-time (JIT)

Что исключает использование промежуточной компиляции.

Под словом native я подразумевал НЕуправляемый код. Тоже самое подразумевают тысячи программистов))) Судя логике микрософта: из NET в IL в mashine = native. Native - родной для процессора. Если же этот нетовский native зависит даже не от процессора а от каких то там групповых политик винды - это не native.

Неуправляемый код компилируется для конкретного процессора и при вызове просто исполняется.
В управляемой среде компиляция производится в 2 этапа:

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

Могли бы Вы привести пример? Не очень понятно, что должно произойти: код не запустится вообще, или отвалится при попытке сделать что-то запрещенное?

Вообще, вот вырезка из той же страницы от MS:

The following changes to a computer's settings and environment cause native images to become invalid:

The version of the operating system, if the change is from the Windows 9x family to the Windows NT family.

For example, if the version of the operating system running on a computer changes from Windows 98 to Windows XP, all native images stored in the native image cache become invalid. However, if the operating system changes from Windows 2000 to Windows XP, the images are not invalidated.

The exact identity of the assembly.

If you recompile an assembly, the assembly's corresponding native image becomes invalid.

The exact identity of any assemblies the assembly references.

If you update a managed assembly, all native images that directly or indirectly depend on that assembly become invalid and need to be regenerated. This includes both ordinary references and hard-bound dependencies. Whenever a software update is applied, the installation program should execute an Ngen Update command to ensure that all dependent native images are regenerated.

Security factors.

Changing machine security policy to restrict permissions previously granted to an assembly can cause a previously compiled native image for that assembly to become invalid.

С версиями фреймворка и ОС понятно. А вот как проверяется идентичность? Т.е. есть, скажем, исходный .exe (c IL внутри), и для него сгенерирован native .exe, который помещается, как я понял, в некий native image cache. Что должен сделать пользователь, чтобы запустился (или не запустился) native .exe?

Различия настроек компиляции в отладке и релизе

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



Все три архитектуры выбраны по умолчанию

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



Пакет .appxupload отправляется в магазин; папка Test содержит пакет appx для локальной устровки
Два следствия из этого: первое, вы как разработчик более не имеете доступа к номеру ревизии вашего приложения (четвертое число). Магазин резервирует это число как способ версионирования пакета приложения, если по какой-либо причине потребуется перекомпиляция в облаке. Не беспокойтесь, вы по-прежнему можете управлять тремя другими числами.



Выберите “Yes” для загрузки в магазин

Когда вы используете помощника для создания пакетов приложения, вам нужно выбрать “Yes” в ответ на вопрос Visual Studio, хотите ли вы создать пакет для загрузки в магазин. Я также рекомендую выбрать “Always” для опции “Generate app bundle”, что приведет к созданию единого файла .appxupload, готового для загрузки. Полная инструкция по созданию пакетов для магазина доступна в статье «Пакетирование универсальных приложений Windows для Windows 10».

  • Регулярно тестируйте ваше приложение в режиме релиза
  • Убедитесь, что вы оставляете номер ревизии пакета как 0. Visual Studio не даст вам его изменить, но также не стоит это делать в других редакторах.
  • Загружайте в магазин только .appxupload, собранные в процессе создания пакета для магазина, если вы загрузите .appx для UWP-приложения, вы получите ошибку в магазине.

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

Обеспечивает низкоуровневую инкапсуляцию дескриптора окна и процедуры окна.

Примеры

Комментарии

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

Окно не подходит для сборки мусора, если оно связано с обработчиком окна. Для обеспечения правильной сборки мусора дескрипторы должны либо быть уничтожены вручную с помощью DestroyHandle , либо освобождены с помощью ReleaseHandle .

NativeWindowКласс предоставляет следующие свойства и методы для управления дескрипторами: Handle , CreateHandle , AssignHandle , DestroyHandle и ReleaseHandle .

Конструкторы

Инициализирует экземпляр класса NativeWindow.

Свойства

Получает дескриптор данного окна.

Методы

Назначает дескриптор данному окну.

Создает окно и его дескриптор, используя указанные параметры создания.

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

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

Уничтожает окно и его дескриптор.

Определяет, равен ли указанный объект текущему объекту.

Освобождает ресурсы, связанные с данным окном.

Извлекает окно, связанное с указанным дескриптором.

Служит хэш-функцией по умолчанию.

Извлекает объект обслуживания во время существования, который управляет политикой времени существования данного экземпляра.

Возвращает объект Type для текущего экземпляра.

Получает объект службы времени существования для управления политикой времени существования для этого экземпляра.

Создает неполную копию текущего объекта Object.

Создает неполную копию текущего объекта MarshalByRefObject.

Задает метод уведомления, вызываемый при изменении дескриптора окна.

Будучи переопределен в производном классе, управляет необработанным исключением потока.

Native приложения — это программы, предназначенные для выполнения на операционных системах Windows семейства NT (NT/2000/XP/2003/Vista/7), способные запускаться на раннем этапе загрузки Windows, до окна входа в систему и даже до запуска каких-либо подсистем Windows. Синий экран при загрузке Windows XP, в котором, например, происходит проверка диска и есть тот самый режим. Native приложения используют только Native API, они могут использовать только функции, экспортируемые из библиотеки ntdll.dll. Для них недоступны функции WinAPI.

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

Моя программа Native shell запускается до экрана входа в систему и предоставляет интерфейс командной строки с возможностью перемещаться по файловой системе Windows, копировать и удалять файлы, просматривать некоторую информацию об операционной системе и запускать другие процессы, способные выполняться в native-режиме, такие как autochk.exe и autoconv.exe. Доступны исходные коды программы на языке Си.

— Синий экран Windows XP. Серый экран Windows Server 2003
Чёрный экран Windows Vista Чёрный экран Windows 7

Native приложения компилируются с помощью WDK - Windows Driver Kit (также известный, как DDK). Есть возможность делать их и в какой-то другой среде разработки, но в WDK проще всего.

Функции в ntdll.dll имеют префиксы Zw и Nt, а также некоторые другие. Видно, что у Zw и Nt функции дублируются названия. На самом деле это одни и те же функции. Если искать в сети пример использования какой-либо функции, стоит поискать сначала с одним префиксом, потом с другим, иначе можно что-то упустить. Почему у них разные префиксы - отдельная история, для программирования native приложений существенной роли не играет.

Для программирования нужны прототипы функций Native API, но в заголовочных файлах WDK присутствуют не все определения. Нужно использовать альтернативные заголовочные файлы, содержащие в том числе и определения недокументированных функций и типов данных. Например, можно воспользоваться заголовочными файлами Native Development Kit (NDK), которые доступны здесь.

Программировать на чистом Native API неудобно. Не обойтись без библиотеки, в которой уже реализованы некоторые рутинные действия. Существует библиотека с открытым кодом - ZenWINX, можно пользоваться ей. Ещё на страничке NDK анонсирована некая библиотека NDL, но на сайте её нет.

Чтобы native приложение запустилось при запуске Windows, надо положить его в каталог system32, а в ключ реестра HKLM\System\CurrentControlSet\Control\Session Manager\BootExecute прописать его имя файла, и аргументы, если они есть. Ключ имеет тип MULTI_SZ, может содержать несколько строк. Первой строкой там идёт Autocheck Autochk * . После неё можно прописывать свою программу. Программа, прописанная в этом ключе, имеет свойство запускаться даже в безопасном режиме Windows (safe mode), так что нужно быть осторожным. Ошибка в программе - и система не запустится. Но можно внутри приложения отслеживать факт запуска в safe mode и обрабатывать этот режим отдельно, например сделать завершение программы, если она обнаружила себя запущенной в safe mode. Кроме того, несмотря на то, что программа запускается и может выполнять какие-то действия, в этом режиме не работает вывод на консоль. Невозможно взаимодействие с пользователем. Это следует учитывать.

При необходимости, native-приложение можно запустить и не перезагружая компьютер. Для этого следует воспользоваться утилитой nrun.exe. Но загрузочный экран от этого не появится, и вам следует придумать, как ещё взаимодействовать с вашим приложением, если нужна интерактивность. В исходном коде nrun можно посмотреть, как реализован запуск native-процессов с использованием недокументированных функций Native API.

Вывод кириллицы на экран по-умолчанию в этом режиме не поддерживается. Есть способ обойти это ограничение, впрочем, способ сложный и пока работает только на Windows XP.

Я создал заготовку проекта Native приложения — набор файлов, который можно использовать в качестве базы для разработки собственного Native приложения. Заготовка содержит файл native.c , содержащий точку входа в приложение. Остальные файлы - это файлы библиотеки ZenWINX, которые модифицированы так, что используют определения функций из NDK, а не из своего файла с определениями. Это позволяет использовать как функции самой библиотеки, так и функции Native API, которые разработчики ZenWINX забыли включить в собственный заголовочный файл. Фактически, NDK - более полный каталог Native API функций, чем файл, поставляемый с ZenWINX. Компилировать заготовку нужно утилитой build из состава WinDDK (я использую версию WinDDK 1.1.6001.000). Следует подключать заголовочные файлы NDK, прописав пути к каталогу с ними.

Возможно также разрабатывать и собирать Native-приложения прямо в Visual Studio, без использования компилятора WDK. О том, как это сделать, написано в статье Сборка Native API-приложения в Visual Studio 2010.

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