В Windows существует несколько типов приложений с разными точками входа в зависимости от того, к какому типу они относятся.Опцией link.exe:
/SUBSYSTEM:CONSOLE
- требуется main
и связь с msvcrXX.dll
.Эти приложения работают в консольных окнах;если вы не запускаете экземпляр cmd.exe, он будет открыт. /SUBSYSTEM:WINDOWS
- WinMain
- отправная точка.Смотрите здесь .Обычно в C эти #include <windows.h>
и связаны непосредственно с kernel32.dll
.Эти графические приложения почти наверняка связаны с user32.dll
и, возможно, advapi32.dll
. /SUBSYSTEM:NATIVE
- здесь есть два типа приложений;драйверы и приложения.Родные приложения NT запускаются во время запуска Windows и требуют NtProcessSStartup
в качестве точки входа.В родных приложениях нет libc.Драйверы снова различаются.
Полный список поддерживаемых оконных подсистем по link.exe
доступен здесь .
_start
- это символ окна на самом делезапустите ваш код на.Обычно libc
или что-то подобное обрабатывает _start
и выполняет некоторые начальные настройки, так что ваша программа на самом деле не совсем начинается с _main
.Если вы хотите связать с libc
, у вас будут проблемы, так как у вас будут конфликтующие символы с библиотекой libc.Однако, если вы никогда не намереваетесь вызывать какие-либо функции, являющиеся частью стандартных библиотек C или C ++, вы можете использовать _start
.
Edit yikes Я только что заметил это:
; how to compile: nasm -f elf test.asm
; how to link: ld -o test.exe test.o
Полагаю, вы не используете -f elf
.ELF (исполняемый и линкованный формат) - это формат linux для исполняемых файлов;Для Windows требуются образы Portable Executable (PE).Опция nasm: -f win32
, или для dos nasm -f coff
.
Edit 2 , просто чтобы проверить, я собрал код и снова разобрал его.Я также использовал Mingw.В любом случае, я получил:
SECTION .text align=16 execute ; section number 1, code
Entry_point:; Function begin
; Note: Length-changing prefix causes delay on Intel processors
mov ax, 4 ; 00401000 _ 66: B8, 0004
?_001: jmp ?_001 ; 00401004 _ EB, FE
; Entry_point End of function
; Note: Length-changing prefix causes delay on Intel processors
mov ax, 4 ; 00401006 _ 66: B8, 0004
?_002: jmp ?_002 ; 0040100A _ EB, FE
Остальная часть заголовка выглядит как допустимый исполняемый файл формата PE без спецификации точки входа.Поэтому я полагаю, что код просто «проваливается» на первый кусок кода сборки для запуска.Я бы не советовал такое поведение, особенно при связывании нескольких объектов, так как понятия не имею, что произойдет.Используй -entry
.
Разбирая объектный файл elf, я получаю это:
SECTION .data align=4 noexecute ; section number 1, data
SECTION .text align=16 execute ; section number 2, code
_start_here:; Local function
; Note: Length-changing prefix causes delay on Intel processors
mov ax, 4 ; 0000 _ 66: B8, 0004
?_001: jmp ?_001 ; 0004 _ EB, FE
_another_symbol:; Local function
; Note: Length-changing prefix causes delay on Intel processors
mov ax, 4 ; 0006 _ 66: B8, 0004
?_002: jmp ?_002
Другими словами, в нем нет никаких конкретных заголовков в формате ELF.Я верю, что тебе повезло в этом;начните импортировать или пытаться связать с другими модулями кода, и все станет сложнее.
Для Windows / mingw вы хотите:
nasm -f win32 file.asm
для каждого файла, который вы хотите собрать.Замените win32
на win64
при необходимости.ld
отлично подойдет для связывания.
Просто мысль - я никогда не объяснял часть @16
.Функции в Windows выровнены на 16 байтов, тогда как, как вы можете видеть, данные выровнены только на четыре байта.См. это объяснение , почему.