Malo ti je los primer - "bcc32 main.c" nema veze sa kompajliranjem
asembler koda. bcc32 (C/C++ kompajler) radi zapravi isto sto bilo kakav
drugi kompajler. ovo sto si gore spomenuo je najlaksi moguci slucaj,
kada je sve u jednom (main.c) fajlu, pa su stvari mnogo jednostavne -
bcc32 zna da pozove linker i sve lepo procesira, asembira, kompajlira i
na kraju linka.
Predlazem da pre nego pocnes sa asemblerskim programiranjem prvo jos
jednom procitas sta u toj knjizi pise o samom procesu kompajliranja i
sta se radi dok se ne dodje do izvrsnog koda.
Ja nemam pojma o MASM-u, a i generalno sam asembler-neznalica, jer nemam
nekog prevelikog interesa da idem tako duboko - C mi i dalje radi sve
low-level stvari koje mi trebaju u zivotu. Ovako odokativno ml je kako
vidim kompajler, onaj /c "fleg" (IMHO veoma glupa M$ konvencija za
davanje parametara, cisto da bi se razlikovali od cistih i lepih UNIX
-flegova ) znaci da se dati fajl kompajlira (u prevodu da se generise
..obj fajl, masinski kod). /coff je parametar kome se MASM-u naredjuje da
pravi masinski kod u tzv. COFF formatu (koliko sam (ne)upucen
modifikovani ELF). /Cp ne znam cemu sluzi, probao bih bez tog flega.
msgbox.asm je tvoj asemblerski sors (fajl).
Sto se link-a tice tu su stvari malo, ali vrlo malo zakomplikovane - tu
zapravo nema nista nejasno - ko god zna sta linker radi i ko god zna
kako se pisu aplikacije na windows-u, znace sta ona linija znaci.
/SUBSYSTEM:WINDOWS "objasnjava" linkeru da je aplikacija koja treba da
se linka WINDOWS aplikacija, tako da linker zna da treba da upotrebi
odredjenu runtime biblioteku (zapravo je trik u tome da Windows moraju
imati WinMain() dok konzolne moraju imati main()). /LIBPATH je valjda
jasno sta je :) - tom direktivom se linker "upucuje" gde da trazi
biblioteke potrebne da bi se aplikacija uspesno linkala.
Na manje ili vise slican nacin rade maltene svi asembleri/kompajleri.
Dejan Lekic
software engineer, MySQL/PgSQL DBA, sysadmin
ne mogu da kompajliram!?
