Właściwie, jeśli kod nie robi nic, to jest nawet w porządku, że kompilator nadal tworzy plik wykonywalny? ;-)
Cóż, w systemie Windows dowolny plik wykonywalny nadal będzie miał rozmiar, chociaż może być rozsądnie mały. W starym systemie MS-DOS kompletna aplikacja "nic nie robiąc" to po prostu kilka bajtów. (Wydaje mi się, że cztery bajty używają przerwania 21-godzinnego do zamknięcia programu.) Potem znowu te aplikacje zostały załadowane prosto do pamięci. Gdy format EXE stał się bardziej popularny, sytuacja nieco się zmieniła. Teraz pliki wykonywalne zawierały dodatkowe informacje o samym procesie, takie jak przeniesienie kodu i segmentów danych oraz niektóre sumy kontrolne i informacje o wersji. Wprowadzenie systemu Windows dodało kolejny nagłówek do formatu, aby powiedzieć systemowi MS-DOS, że nie mógł wykonać pliku wykonywalnego, ponieważ musiał on działać w systemie Windows. A Windows rozpoznałby go bez problemów. Oczywiście, format pliku wykonywalnego został również rozszerzony o informacje o zasobach, takie jak bitmapy, ikony i formularze dialogowe i wiele, wiele więcej.
Plik wykonywalny typu "do-nothing" miałby obecnie rozmiar od 4 do 8 kilobajtów, w zależności od kompilatora i każdej metody użytej do zmniejszenia jego rozmiaru. Byłby on w rozmiarze, w którym UPX faktycznie doprowadziłby do większych plików wykonywalnych! Dodatkowe bajty w pliku wykonywalnym mogą zostać dodane, ponieważ dodałeś pewne biblioteki do kodu. Zwłaszcza biblioteki z zainicjalizowanymi danymi lub zasobami dodadzą znaczną ilość bajtów. Dodanie informacji debugowania zwiększa również rozmiar pliku wykonywalnego.
Ale mimo, że wszystko to sprawia przyjemne ćwiczenie przy zmniejszaniu rozmiaru, można się zastanawiać, czy praktyczne jest po prostu ciągłe martwienie się nadmiariem aplikacji. Nowoczesne dyski twarde będą dzieliły pliki w segmentach i na naprawdę duże dyski, różnica byłaby bardzo mała. Jednak ilość kłopotów, które wymagałoby, aby rozmiar był jak najmniejszy, spowolni tempo rozwoju, chyba że jesteś ekspertem od programowania, który jest przyzwyczajony do tych optymalizacji. Tego rodzaju optymalizacje nie mają tendencji do poprawy wydajności i biorąc pod uwagę średnią przestrzeń dyskową większości systemów, nie widzę powodu, dla którego byłoby to praktyczne. (Wciąż jednak optymalizuję własny kod w podobny sposób, ale znowu mam doświadczenie z tymi optymalizacjami.)
Interesuje Cię
EXE header? Zaczyna się od liter MZ dla "Mark Żbikowski".Pierwsza część to staromodny nagłówek MS-DOS dla plików wykonywalnych i służy jako skrót do MS-DOS, mówiąc, że program jest
, a nie jako plik wykonywalny MS-DOS. (W binarnym, możesz znaleźć tekst "Ten program nie może być uruchomiony w trybie DOS.", Który jest w zasadzie wszystkim, co robi: wyświetlanie tego komunikatu.Następnym jest nagłówek PE, który system Windows rozpozna i użyje zamiast MS-DOS Zaczyna się od liter
PE for Portable Executable. Po tym drugim nagłówku będzie sam plik wykonywalny, podzielony na kilka bloków kodu i danych.W nagłówku znajdują się specjalne tabele realokacji, które informują OS, gdzie załadować konkretny blok. zachować to do limitu, ostateczna wykonywalny może być mniejsza niż 4 KB, ale 90% byłoby wtedy nagłówek informacji i nie funkcjonalność.
Jedna z sugestii: Czy uzyskujesz takie same wyniki przy użyciu wersji minGW GCC? Nie jestem pewien, czy ten rozmiar jest niezwykły, czy nie, ponieważ nie jestem zbytnio przyzwyczajony do C++. – Macha
UPX? http://upx.sourceforge.net/ – bobince
Tak, znam UPX, ale problem tutaj jest następujący: kompilator nie powinien generować ~ 23KB śmieci dla pustego programu. – George