Użytkownik "Borneq" <b...@a...hidden.pl> napisał:

> Pliki Exe i Dll właściwie się nie różnią, oba mogą importować i eksportować
funkcje, mają sekcje
> zasobów, debuggera itp.
> A jak jest z plikami lib i obj? Jaka jest różnica między nimi a plikami
wykonywalnymi? W takim obj
> i lib nie ma ustalonych adresów.

Lib to nic wiecej niz pop rostu biblioteka obj-tow.
Obj (mowie o intelu x86/x64) to taki magazyn relokowalnych paczek
kody maszynowego i danych odpowiadajacych z grubsza strukturze
programu w pamieci x86/64 (segmenty (e)cs:kod = CODExx
(e)ds:DATA,_DATA bss:BSS,_BSS itp) + rozne mappingi symboli
(nazw z j.programowania) na adresy wzgledne w tychze, fuxupy itp.

Linker po prostu scala te czesci z roznych objtow i produkuje
exe (dwa pierwsze bajty to 'MZ') ktory jest zlozony z wielu segmentow,
(ale juz wewnetrznie spojnych) + tablica relokacji (offsety tychze).
"Drzewiej"produkowac mozna bylo tez .com ktory tym sie rozni
od execa, ze loader traktuje go jako jeden 'BLOB" (nie ma zadnych relokacji)
wczytuje go i skacze zwyklym jumpem na jego poczatek
(a dokladnie chyba na adres 0x400 - nie pamietam).
.Com z oczywistych wzgledow moze miec maksymalny rozmiar jednego
segmentu procesora intel.
Dla 16 bitowego adresowania bylo to wiec ~65000b - dosc malo:)
Taki com byl niekiedy bardzo wygodny przy pisaniu driverow/pluginow
itp (rozszerzenia byly czesto inne; .bin, .sys, .bgi itp itd).
Aby uzyskac pluginowa/driverowa dynamike uruchomienia drivera
po prostu czytalo sie taki twor ''in runtime" jakims (f)read i oddawalo
sie mu sterowanie zwyklym jmp seg:0x400.
(Ok ok :) wiem ze sa spawny i exec. Nie zawsze byly idealne.)

A wiec zadnej tajemnej i skomplikowanej wiedzy e tym nie ma.
Ba! Dzis ta "wiedza" jest jzu kompletnie zbedna (i baardzo dobrze),
co pod powazna rozwage Ci polecam (sa przyjemniejsze/potrezbniejsze
rzeczy w prog. niz grzebanei w takich bebechach)

AK