W dniu niedziela, 19 listopada 2017 14:02:54 UTC+1 użytkownik fir napisał:
> W dniu środa, 15 listopada 2017 15:11:20 UTC+1 użytkownik Maciej Sobczak napisał:
> > > W wielu "dużych", "profesjonalnych" i "popularnych" programach obserwuję
zjawisko wyłączania z exe całego kodu aplikacji.
> > > Moje pytanie brzmi: Dlaczego wyłącza się dll z exe?
> >
> > Zamieszam trochę: od dłuższego czasu jestem zwolennikiem linkowania statycznego
wszystkiego co nie jest base-systemem. Życie mi się uprościło.
> >
> > Dopuszczam DLL-ki tam, gdzie elementy programu mogą być pozyskiwane niezależnie
od głównego programu i ten ficzer jest istotną częścią filozofii używania danego
programu (np. pluginy).
> >
>
> ja odwrotnie, kompilowanie ststyczne to dla mnie za duzo roboty
>
> bo o ile pamietam (nie jestem pewien czy dobrze pamietam ale chyba tak) aby
statyczny linker dzialal 'wybiórczo' nie wystarczy zlinkowac duzego pojedynczego
pliku.o (powiedzmy 5 MB) - jesli uzywamy tylko jednej prostej funkcji z tego obiektu
i tak statyczny linker zlinkuje 5 MB -
> aby dzialal wybiórczo tworca tej
> liby musialby kompilowac ja do wielu skladowych .o i potem pakowac ja w jedną
zbiorczą libe .lib
> (tak mi sie przynajmniej wydaje bo co ciekawe nigdy o tym wiecej nie czytalem i
nigdy jakos specjalnie tego nie uzywalem itd) tak ze to jest ok (dodatkowo np pozwala
kompilowac rozne podkawalki z roznymi opcjami kompilacji) ale wymaga zauwazalnej
ilosci dodatkowej roboty a dla mnie dodatkowa robota jest zwykle denerwujaca (ta
robota moglaby byc
> byc moze mniejsza gdyby toole robily troche wiecej z automatu itp, tak naprawde
mozna tez zauwazyc ze dynamiczne linkowanie
> tez mogloby byc zrobione tak by dzialac wybiórczo acz to by co nieco skomplikowalo
sprawy)
>
> dla mnie linkowanie dllek jest ok
> tyle ze nalezy moze jedynie pamietac by te dllki mialy rozsądne
> rozmiary (rozsądna jak na dzis to dla mnie chyba do 10 MB na jedną)
> oraz by dependencje miedzy nimi byly jak najmniejsze (tj by nie bylo ich duzo i jak
juz sa by mialy w swoim secie jak najmniej dependencji (te dependencje miedzy dllkami
mozna zliczajac zliczajac kreseczki importow na grafie miedzy dllkami, (mowie o
importach calej dllki nie pszczegolnych symboli)
> np jak ktos mialby 10 dllek z ktorych kazda importowalaby kazda inną to w sumie
zdaje sie tych dependencji byloby 90 - za duzo,
> u mnie w moich projektach mam na
> przyklad zaleznosc/import do green.fire.dll ktora z kolei ma importy do 7
systemowych dllek (kernel32.dll gdi32.dll msvcrt.dll psapi.dll user32.dll winmm.dll
ws2_32.dll) sam exe moze tez siegac do niektorych bezposrednio (akurat moj klient
irca siega bezposrednio do kernel32 (i do msvcrt.dll choc to jest zrozumiela) na 12
funkcji (dotyczacych critcal section, tls, exit process, get masage adress itp, i
tego ciagle do konca troche nie lapie szczerze mowiac, czy to gcc wkompilowuje te 12
funkci jako normalne calle w startupie mojego kodu czy tez moze tworzy sobie takie
importy tak troszke jakby na wyrost?) (wiem przynajmniej jedno, jak sam zasembluje
sobie swoim asemblerem swoj plik exe to moge miec eleganckie zero importow mimo ze
program dziala (i pisze na konsole przez msvcrt.printf - hmm - w takim razie to tez
jest dziwne, moze moj exe oszukuje plugin do total commandera bo importy dzialają ale
sie nie pokazują)

wiem tez z doswiadczenia (z moim wlasnym asemblerem ) ze odnoscnika do kernel32.dll
program tak naprawde nie potrzebuje: niektorzy wywolują exit process na koniec
programu ale zwykle ret (aloi nawet program zlozony wylacznie z ret (0xc3)) tez
dziala (i to komicznie bo taki program przy uruchomieniu tylko blinka czy tez ew
wywoluje jakby 'no reaction' ;c tak jak zreszta chyba powinno byc)