🚀 go-pugleaf

Dnia 07.07.2006, Johnny <johnny_bez_spamu_@klub.chip.pl> napisał(a):
> Przerabiam sobie książkę o asm no i wszystkie programy działają w
> środowisku DOS. Mam trochę głupie pytanie ale jak się ma asm do
> wywołania np. api windowsowego?
>
google: win32asm
Polecam tutoriale iczeliona, są chyba nawet przetłumaczone na polski

-- 
Pozdrawiam

Tutaj masz przetłumaczone na polski:

http://www.i-lo.tarnow.pl/edu/inf/prg/win32asm/

-- 
Remek

Johnny napisal(a):
> Przerabiam sobie ksiazke o asm no i wszystkie programy dzialaja w
> srodowisku DOS. Mam troche glupie pytanie ale jak sie ma asm do
> wywolania np. api windowsowego?
>
> --
> Pozdrawiam
> Johnny

Jesli natomiast chodzi o ksiazki to np.

"Asembler: Podrecznik programisty", Vlad Pirogov, wyd. Helion

Od podstaw - jak tworzyc "w" konsoli, okienka, kontrolki, okna,
programy (API), konczac na uslugcha i sterownikach - TASM, MASM
(wymagane juz sa podstawy co prawda autor cos wspomina o podstawch,
ale szybko przechodzi do konkretów)

link -> http://helion.pl/ksiazki/asempp.htm

Pozdrawiam!

Johnny napisał(a):
> Przerabiam sobie książkę o asm no i wszystkie programy działają w
> środowisku DOS. Mam trochę głupie pytanie ale jak się ma asm do
> wywołania np. api windowsowego?

 Odpowiednia funkcja WinAPI jest wywoływana komendą CALL, np.

	push	dword 0
	call	ExitProcess

To, co to CALL właściwie robi, jest bardziej zagmatwane. Program
pisany pod Windows (z wyjątkiem programów pisanych FASMem) jest
linkowany z tzw. biblioteką importową, np. kernel32.lib, która z
grubsza mówiąc zawiera odwołania do odpowiednich funkcji w dynamicznie
ładowanej bibliotece (tu: kernel32.dll). Bezpośrednio instrukcją CALL
wywoływany jest właśnie ów "łącznik" zawarty w pliku .lib, skok do
odpowiedniego kodu jest "potem". Tak przynajmniej ja to rozumiem.

 Pisząc FASMem jest łatwiej, bo nie ma linkowania z jakimiś plikami
.lib, nie ma dyrektyw includelib w źródle itp. Program działa "od
razu" na DLL, od razu (po 1 kliknięciu) dostajesz binarkę .exe (nawet
można chyba ją od razu uruchomić spod FASMw).

 Także polecam tutoriale Iczeliona.

-- 
Pozdrawiam, Bogdan                                  (Linux i FreeDOS)
Kurs assemblera x86 (DOS i Linuks): http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
Prawdziwy, bezpieczny komunikator:                   www.JabberPL.org

Johnny napisał(a):
> Przerabiam sobie książkę o asm no i wszystkie programy działają w
> środowisku DOS. Mam trochę głupie pytanie ale jak się ma asm do
> wywołania np. api windowsowego?
> 
Dziękuję wszystkim za odpowiedzi.

-- 
Pozdrawiam
Johnny

> push dword 0
> call ExitProcess
>
> To, co to CALL właściwie robi, jest bardziej zagmatwane. Program
> pisany pod Windows (z wyjątkiem programów pisanych FASMem) jest
> linkowany z tzw. biblioteką importową, np. kernel32.lib, która z
> grubsza mówiąc zawiera odwołania do odpowiednich funkcji w dynamicznie
> ładowanej bibliotece (tu: kernel32.dll). Bezpośrednio instrukcją CALL
> wywoływany jest właśnie ów "łącznik" zawarty w pliku .lib, skok do
> odpowiedniego kodu jest "potem". Tak przynajmniej ja to rozumiem.

Chyba nie tak. Parametrem call-a jest wskaźnik na komórkę z adresem funkcji 
bibliotecznej. Nie ma więc "skoku potem", wywołanie funkcji dzieje się już 
na tym callu, tylko w kodzie programu nie ma adresu funkcji, a adres komórki 
zawierającej adres funkcji.

dlatego NASM wymaga

call [ExitProcess]

gdzie [] oznacza, że ExitProcess jest wskaźnikiem, a nie etykietą.



-- 
Azarien
ejwi sizaa! moritiuri tej sejliutent!

To z Bogdana:

> Bezpośrednio instrukcją CALL
> wywoływany jest właśnie ów "łącznik" zawarty w pliku .lib, skok do
> odpowiedniego kodu jest "potem". Tak przynajmniej ja to rozumiem.

Wydaje mi się, że z informacji zawartej w pliku .lib korzysta
linker, umieszczając w execu adres funkcji. Po drodze jeszcze
jest jmp do właściwej procedury. Tak to przynajmniej widać w
debuggerze.
I chyba w większości programów tak jest, chyba że są jakieś
odstępstwa.

-- 
Remek

>> Bezpośrednio instrukcją CALL
>> wywoływany jest właśnie ów "łącznik" zawarty w pliku .lib, skok do
>> odpowiedniego kodu jest "potem". Tak przynajmniej ja to rozumiem.
>
> Wydaje mi się, że z informacji zawartej w pliku .lib korzysta
> linker, umieszczając w execu adres funkcji.

Ale adres funkcji znany jest dopiero w momencie załadowania programu - 
wypełnia go system w trakcie ładowania exeka.


-- 
Azarien
ejwi sizaa! moritiuri tej sejliutent!

Witam!

Przepraszam, że piszę z opóźnieniem, ale mam drobne
problemy z łączem.

> adres funkcji znany jest dopiero w momencie załadowania programu -
wypełnia go system w trakcie ładowania exeka.

Wszystko sie zgadza. Jednak pewne informacje muszą być wcześniej
umieszczone zarówno w DLL'u, jak i execu. Jak są one wykorzystywane
bardzo dobrze widać jeśli ładujemy DLL'a "ręcznie", tzn przez
LoadLibrary i GetProcAddress. Natomiast nie wiem jak to robi
"automatycznie" sam system. Byłbym Ci wdzięczny za jakiś link
do opisu tego procesu (oczywiście jeśli znasz i zechcesz podać).

-- 
Remek

Dnia 7/17/2006 6:06 PM, Remek wrote:
> 
>> adres funkcji znany jest dopiero w momencie załadowania programu -
> wypełnia go system w trakcie ładowania exeka.
> 
> Wszystko sie zgadza. Jednak pewne informacje muszą być wcześniej
> umieszczone zarówno w DLL'u, jak i execu. Jak są one wykorzystywane
> bardzo dobrze widać jeśli ładujemy DLL'a "ręcznie", tzn przez
> LoadLibrary i GetProcAddress. Natomiast nie wiem jak to robi
> "automatycznie" sam system. Byłbym Ci wdzięczny za jakiś link
> do opisu tego procesu (oczywiście jeśli znasz i zechcesz podać).
> 

W uproszczeniu: plik wykonywalny zawiera sekcję importów. Składa się ona 
z kilku części zawierających:

a) część określającą nazwę biblioteki

b) część zapełnioną numerami lub nazwami funkcji importowanych (zależy 
od ostatniego bitu - jeśli zapalony to import przez numer, jeśli 
zgaszony - to przez nazwę)

c) część przeznaczoną na adresy zaimportowanych funkcji (IAT - Import 
Address Table)

Loader odczytuje nazwę biblioteki - jeśli jest już w pamięci, to mapuje 
ją do procesu, jeśli nie ma - ładuje i mapuje do procesu (po drodze 
sprawdza sekcję importów tej biblioteki i jeśli ona ma swoje biblioteki 
importowe to sprawdza, czy są w pamięci itd.). Jeśli biblioteka ma być 
przerelokowana, to loader to robi (jest do tego specjalna sekcja). Po 
drodze pewnie buduje tablicę eksportów biblioteki.

Jak już bibliotek jest załadowana i zamapowana, loader odczytuje numer 
lub nazwę funkcji, którą ma zaimportować. Jeśli jest numer, to po prostu 
w tabeli eksportów biblioteki znajduje adres funkcji o podanym numerze i 
wstawia go do IAT. Jeśli import odbywa się przez nazwę, to:

1. loader sprawdza, czy przy nazwie znajduje się tzw. hint, czyli jakby 
numer funkcji o podanej nazwie

a) jeśli tak, to sprawdza, czy pod podanym numerem w tabeli eksportów 
rzeczywiście znajduje się ta funkcja i jeśli tak, to jej adres wstawia 
do IAT

b) jeśli nie, to po prostu wyszukuje funkcję po nazwie

2. jeśli nie ma hinta, to wyszukuje w tabeli eksportów funkcję o podanej 
nazwie

Jeśli funkcja została znaleziona (z użyciem hinta czy bez), to do IAT 
wędruje jej adres. Skoki do importowanych funkcji odbywają się (zwykle) 
właśnie przez IAT.


To tyle w uproszczeniu. Funkcje mogą być jeszcze forwardowane (czyli 
mogą wskazywać na funkcje z innych bibliotek), mogą być ładowane z 
opóźnieniem (delayload).

Jeśli Ci to nie wystarcza, to musisz sam poszukać w sieci odpowiednich 
materiałów - powyższy opis to moje wnioski z gdzieś-tam-kiedyś 
wyczytanych informacji oraz z lektury specyfikacji PE/COFF 
(http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx)

Pozdrawiam,
Morris

> Jeśli Ci to nie wystarcza, to musisz sam poszukać

Dzięki za wyczerpujący opis. Jasne jest dla mnie, że
tu nie miejsce na naukę i zamieszczanie całej wiedzy o
asemblerze.

-- 
Remek

Użytkownik "Remek" <wiasmed@neostrada.pl> napisał w wiadomości 
news:e9gcb2$pie$1@inews.gazeta.pl...
> Witam!
>
> Przepraszam, że piszę z opóźnieniem, ale mam drobne
> problemy z łączem.
>
>> adres funkcji znany jest dopiero w momencie załadowania programu -
> wypełnia go system w trakcie ładowania exeka.
>
> Wszystko sie zgadza. Jednak pewne informacje muszą być wcześniej
> umieszczone zarówno w DLL'u, jak i execu. Jak są one wykorzystywane
> bardzo dobrze widać jeśli ładujemy DLL'a "ręcznie", tzn przez
> LoadLibrary i GetProcAddress. Natomiast nie wiem jak to robi
> "automatycznie" sam system. Byłbym Ci wdzięczny za jakiś link
> do opisu tego procesu (oczywiście jeśli znasz i zechcesz podać).
>
> -- 
> Remek
>
http://codediver.kaist.ac.kr/vbulletin/showthread.php?t=550
Pozdrawiam