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ą)