Witam
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?

Moje domniemania:
1. Żeby używać w innych aplikacjach. Tylko tu pojawia się takie pytanie: Czemu cały
exe jest przerzucany do dll?
2. Żeby używać w innych aplikacjach jako obiektu COM.
3. Żeby łatwiej testować (pisać programy exe testujące dll-kę zamiast mieszać kod
roboczy z testowym).

A może są inne powody? Proszę potwierdzić moje domniemania lub je zweryfikować.

z góry dzięki
Szyk Cech

--
http://szyk.jcom.pl/
http://szyk.free.of.pl/
http://szykcech.cba.pl/
http://szyk.000webhostapp.com/
http://www.geocities.ws/szyk/
http://szyk.wex.pl/

do góry

W dniu 2017-11-15 o 06:10, s...@g...com pisze:
> Witam
> 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?
>
> Moje domniemania:
> 1. Żeby używać w innych aplikacjach. Tylko tu pojawia się takie pytanie: Czemu cały
exe jest przerzucany do dll?
> 2. Żeby używać w innych aplikacjach jako obiektu COM.
> 3. Żeby łatwiej testować (pisać programy exe testujące dll-kę zamiast mieszać kod
roboczy z testowym).
>
> A może są inne powody? Proszę potwierdzić moje domniemania lub je zweryfikować.

jedynie punkt 1 jest sensowny
dodam 4, czasami pewne funkcjonalności mogą być wariantowo dodawane do
programu.

Dodatkowo nie zauważyłem takiego zjawiska...

Pozdrawiam
--
http://kaczus.ppa.pl
http://zrzeda.pl

do góry

> Dodatkowo nie zauważyłem takiego zjawiska...

Acrobat Reader
Mozilla FireFox
Dia
Google Chrome
Internet Explorer
Libre Office
VLC
7-zip

To tak na szybko po przeglądnięciu katalogów Program Files i PF (x86)...

Po za tym prosiłbym o wypowiedź osób które znają to zjawisko...

do góry

W dniu 2017-11-15 o 09:21, s...@g...com pisze:
>> Dodatkowo nie zauważyłem takiego zjawiska...
>
> Acrobat Reader
> Mozilla FireFox
> Dia
> Google Chrome
> Internet Explorer
> Libre Office
> VLC
> 7-zip
>
> To tak na szybko po przeglądnięciu katalogów Program Files i PF (x86)...
>
> Po za tym prosiłbym o wypowiedź osób które znają to zjawisko...
>

wymieniłeś rzeczy, które właśnie są bardzo zależne od wariantowych
bibliotek, program główny jest w zasadzie oknem, które steruje resztą...

Część z nich można kompilować tez tak, że będziesz miał część bibliotek
zewnętrznych wkompilowanych, ale jest to bezsensowne. Podobnie masz np z
jądrem linuksa, możesz część rzeczy mieć wkompilowanych w jądro, albo
jako zewnętrzne moduły. Nie ma to nic wspólnego z testowaniem...

--
http://zrzeda.pl
http://kaczus.republika.pl

do góry

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

--
Maciej Sobczak * http://www.inspirel.com

do góry

On 11/15/2017 6:10 AM, s...@g...com wrote:
> Moje pytanie brzmi: Dlaczego wyłącza się dll z exe?

Aby nie ładować wszystkiego na raz do pamięci. Przeciętna poważna
aplikacja może mieć sumę zajmowanego kodu w dll w granicach kilku GB.

do góry

> Aby nie ładować wszystkiego na raz do pamięci. Przeciętna poważna
> aplikacja może mieć sumę zajmowanego kodu w dll w granicach kilku GB.

A ile ta przeciętna poważna aplikacja zajmowałaby gdyby była zlinkowana statycznie?

Przykład obrazkowy (nierealny, ale łatwy): jest biblioteka funkcji, nich będzie, że
matematycznych. Jest tam 1000 funkcji i biblioteka w postaci DLL ma 1000MB, czyli
średnio 1MB/funkcję. Program korzysta tylko z jednej funkcji i powiedzmy, że jest ona
niezależna od innych. Taki program wciąga 1GB DLL dynamicznie (i korzysta tylko z 1
promila tego) albo jest tylko o 1MB grubszy statycznie.

To nie jest taki całkiem nierealny przykład, zwłaszcza jeśli mówimy o bibliotekach
masowego rażenia, np. GUI albo innych 3rd-party. Przeciętny program używa tylko
ułamka takich bibliotek i jeśli jest linkowany statycznie, to jego ciężar może być
znacznie mniejszy, niż suma wszystkich bezpośrednio i pośrednio wciąganych DLLek.
Czas startu takiego programu też będzie mniejszy, nie tylko z powodu mniejszego
rozmiaru (czyli mniejszej ilości danych do wczytania), ale też z powodu braku
konieczności patchowania symboli z dynamicznie wczytanych bibliotek (jeśli taki
mechanizm w danym systemie występuje).

Ponawiam pytanie: ile przeciętna poważna aplikacja (taka na kilka GB) zajmuje po
statycznym linkowaniu? I jak to wpływa na jej czas uruchamiania?

--
Maciej Sobczak * http://www.inspirel.com

do góry

> Aby nie ładować wszystkiego na raz do pamięci. Przeciętna poważna
> aplikacja może mieć sumę zajmowanego kodu w dll w granicach kilku GB.

To raczej można między bajki włożyć... Nie wiem jak pod Windows, ale taki Linux
ładuje do pamięci tylko to co aktualnie jest potrzebne. Dlatego monitory
uruchomionych aplikacji podają 2 wartości zajętości pamięci (zadeklarowany i
rzeczywisty). Tak więc Linux nie ładuje do pamięci całych exe ani so. Nie widzę też
przeszkód by Windows nie zachowywał się podobnie...

do góry

On 11/17/2017 10:29 AM, Maciej Sobczak wrote:
> A ile ta przeciętna poważna aplikacja zajmowałaby gdyby była zlinkowana statycznie?

Nie jesteś w stanie przeprowadzić doświadczenia, jest zbyt kosztowne.
Możesz liczyć jednak że exe będzie miał powiedzmy 2GB rozmiaru jesli
suma dllek jest rzedu 2.5GB. Wyssałem to z palca, ale palec wcześniej
miał kontakt z takimi rozmiarami i takim kodem.

> Przykład obrazkowy (nierealny, ale łatwy): jest biblioteka funkcji, nich będzie, że
matematycznych. Jest tam 1000 funkcji i biblioteka w postaci DLL ma 1000MB, czyli
średnio 1MB/funkcję. Program korzysta tylko z jednej funkcji i powiedzmy, że jest ona
niezależna od innych. Taki program wciąga 1GB DLL dynamicznie (i korzysta tylko z 1
promila tego) albo jest tylko o 1MB grubszy statycznie.

Opisujesz inny przypadek. Ja opisuje przypadek kiedy *cały* kod w
dllkach jest unikatowy, używay, ale niekoniecznie ładowany od razu bo
nie ma takiej potrzeby.

> Ponawiam pytanie: ile przeciętna poważna aplikacja (taka na kilka GB) zajmuje po
statycznym linkowaniu? I jak to wpływa na jej czas uruchamiania?

Nie przypuszczam abyś dal radę przeprowadzić to doświadczenie. Ale
pozwole sobie na podstawie własnych doświadczeń zasugerować że:
a) mniej więcej tyle samo co suma dll minus specjalizacje templates i
meta szum dll
b) ilośc zmiennych statycznych które musisz zainicjować od razu jest
większa niż gdy aplikacja ladowana jest po kawałku, co spowolni proces
startu.
c) ilośc danych do relokacji od razu jest znacząco większa

Jeśli chcesz zobaczyć *naprawdę* duże aplikacje to zerknij na rynek EDA.
Np. sciągnij instalator Vivado, który wcale nie jest jakoś specjalnie
duży jak na ta branżę a na przeciętnym klikaczu robi wrażenie. Ten
projekt, gdyby go statycznie zlinkowac, miał by całkiem sporo problemów
związanych z czasami ladowania, zajętością pamięci, współdzieleniem kodu
i co najwazniejsze był by kilka razy większy.

Dla ilustracji: zakładając że masz 100MB kodu w dll i musisz szerować to
między dwa exe (bo taką masz architekturę). W przypadku dynamicznych
biblitek te 100MB można szerować między dwa procesy. Po statycznym
linkowaniu nie bo to różne exe. Oczywiście trzeba wziąć poprawkę na
gówniany x86 ale na szczęscie to badziewie już znika z rynku. Aplikacji
ktore dostarczają wiele exe w jednej instalacji dzieląc kod jest
pierdyliard.

Dla ilustracji2: wyobraź sobie że masz aplikację edytora która tylko
wtedy kiedy trzeba laduje parser gramatyki Perla. Jeśli nie otwierasz
plików perla to po ch... ma to siedzieć w pamięci? Jeszcze kilka lat
temu było to problemem z uwagi na 4GB przestrzeni adresowej więc
ładowanie wszystkiego bylo mało sensowne bo zabierałes przestrzeń na
projekt użytkownika.

do góry

On 11/17/2017 3:23 PM, s...@g...com wrote:
>> Aby nie ładować wszystkiego na raz do pamięci. Przeciętna poważna
>> aplikacja może mieć sumę zajmowanego kodu w dll w granicach kilku GB.
> To raczej można między bajki włożyć... Nie wiem jak pod Windows, ale taki Linux
ładuje do pamięci tylko to co aktualnie jest potrzebne. Dlatego monitory
uruchomionych aplikacji podają 2 wartości zajętości pamięci (zadeklarowany i
rzeczywisty). Tak więc Linux nie ładuje do pamięci całych exe ani so. Nie widzę też
przeszkód by Windows nie zachowywał się podobnie...

To co opisujesz nie ma żadnego związku z linkowaniem statycznym, te same
efekty uzyskuje się na ładowaniu dynamicznym.

Pozwole sobie zacytować prosto z "Modern C programming" [1]:

"Dynamic linking is now the default on computers running System V
release 4 UNIX, and it should always be used. Static linking is now
functionally obsolete, and should be allowed to rest in peace"

Niestety ludzie piszacy pojedncze pliki exe i nie mający kontaktu z
duzym software czesto zapominają że duże aplikacje zachowują sie
podobnie jak systemy operacyjne. I te stare słowa te sa nie tylko ważne
w OS ale i w app.

[1] Polecam przeczytać jako humorystyczna pozycje, wiele się można
dowiedzieć o tym dlaczego współczesne programowanie i OSy wygladają jak
wyglądają.

do góry