Системные вызовы в windows & Native API?

Question

Недавно я использовал много языков ассемблера в операционных системах * NIX. Мне было интересно о домене Windows.

---

соглашение о вызовах в Linux:

mov $SYS_Call_NUM, %eax 
mov $param1 , %ebx 
mov $param2 , %ecx 
int $0x80 

Вот он. Вот как мы должны сделать системный вызов в Linux.

Отнесение всех системных вызовов в Linux:

, в отношении которых $ SYS_Call_NUM &, какие параметры мы можем использовать эту ссылку: http://docs.cs.up.ac.za/programming/asm/derick_tut/syscalls.html

ОФИЦИАЛЬНЫЙ Ссылка: http://kernel.org/doc/man-pages/online/dir_section_2.html

---

соглашение о вызовах в Windows:

???

Отнесение всех системных вызовов Windows:

???

Неофициальный: http://www.metasploit.com/users/opcode/syscalls.html, но как использовать их в сборке, если я не знаю соглашение о вызове.

ОФИЦИАЛЬНО: ???

• Если вы скажете, они не задокументировали это. Тогда как можно писать libc для Windows, не зная системных вызовов? Как собираются программировать Windows Assembly? По крайней мере, в программировании драйвера нужно знать это. правильно?

---

Теперь, Что с так называемой Native API? Is Native API & System calls for windows оба - разные термины, относящиеся к одной и той же вещи? Для того, чтобы подтвердить, я сравнил их с двух НЕОФИЦИАЛЬНЫМ Источники

Системные вызовы: http://www.metasploit.com/users/opcode/syscalls.html

Native API: http://undocumented.ntinternals.net/aindex.html

Мои наблюдения:

1. Все системные вызовы, начинающиеся с букв Nt где, как Native API состоит из множества функций, которые не начинаются с букв Nt.
2. System Call of windows Подмножество Native API. Системные вызовы являются частью Native API.

Может ли кто-нибудь подтвердить это и объяснить.

EDIT:

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

Answer 1

Если вы программируете сборку под Windows, вы не выполняете системные вызовы вручную. Для этого вы используете NTDLL и Native API.

Native API - это просто обертка вокруг стороны kernelmode. Все, что он делает, это выполнить syscall для правильного API.

Вам НИКОГДА не потребуется вручную использовать системный вызов, чтобы весь ваш вопрос был лишним.

Код syscall для Linux не изменяется, Windows делает это, поэтому вам нужно работать с дополнительным уровнем абстракции (иначе NTDLL).

EDIT:

Кроме того, даже если вы работаете на уровне сборки, вы по-прежнему иметь полный доступ к API Win32, нет никаких причин, чтобы с помощью NT API для начала! Импорт, экспорт и т. Д. Все работает отлично в программах сборки.

EDIT2:

Если вы действительно хотите сделать вручную системные вызовы, вы будете нуждаться в обратном Ntdll для каждой соответствующей версии Windows, добавьте определение версии (через ПЭБ), а также выполнять поиск системных вызовов для каждого вызов.

Однако, это было бы глупо. NTDLL существует не просто так.

Answer 2

Системные вызовы системы Windows выполняются путем вызова в системные DLL, такие как kernel32.dll или gdi32.dll, что осуществляется с помощью обычных вызовов подпрограмм. Механизмы захвата в привилегированный уровень ОС недокументированы, но это нормально, потому что DLL, например kernel32.dll, делают это за вас.

И системные вызовы, я имею в виду документированные точки входа Windows API, такие как CreateProcess() или GetWindowText(). Драйверы устройств обычно используют другой API из Windows DDK.

Answer 3

ОФИЦИАЛЬНЫЙ соглашение о вызовах в Windows: http://msdn.microsoft.com/en-us/library/7kcdt6fy.aspx

(надеюсь, что эта связь сохраняется в будущем, если это не так, просто для поиска «x64 Software конвенций» на MSDN).

Функция вызова соглашения отличается в Linux & Windows x86_64. В обоих ABI параметры предпочтительно передаются через регистры, но используемые регистры различаются. Более подробно о Linux ABI можно узнать по адресу http://www.x86-64.org/documentation/abi.pdf

Answer 4

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

Даже механизм, используемый для выполнения системных вызовов (который int или sysenter) не исправлен в камне и не изменился в прошлом, и я думаю, что когда-то одна и та же версия Windows использовала разные библиотеки DLL, которые использовали разные записи механизмов в зависимости от процессора в машине.