Wielkość pliku wynikowego (ciekawostka)

0

kod z wątku Analiza kodu pobierającego pliki z sieci

Przekompilowany na Delphi 7 - 240 640 bajtów
Przekompilowany na Delphi XE5 - 1 072 400 bajtów (32 bit release), wersja debug 7 609 692 bajtów

Wielkość pliku wynikowego jest prawie 4,5 razy większa. A to na dobrą sprawę jakieś 20-30 linijek kodu...

0

Zobacz jeszcze jaka będzie różnica, jeśli w obu przypadkach wywali się symbole debugera, a całość potraktuje jakims pakerem, np. upxem z opcją -9; To i tak mało - Lazarus zrobiłby dwa razy większy plik, niż XE7 :]

0

nie ma to znaczenia znaczenia - rozmiar ten sam. Co do pakowania UPXem to dla mnie to proteza :)

0
abrakadaber napisał(a):

kod z wątku Analiza kodu pobierającego pliki z sieci

Przekompilowany na Delphi 7 - 240 640 bajtów
Przekompilowany na Delphi XE5 - 1 072 400 bajtów (32 bit release), wersja debug 7 609 692 bajtów

Wielkość pliku wynikowego jest prawie 4,5 razy większa. A to na dobrą sprawę jakieś 20-30 linijek kodu...

20 kB nie powinno to zajmować.
Kiedyś robiłem programy, tak wprost na windows, na surowo, no i takie to było...

No, ale teraz dzieci pracują... pity programują na c## net.scripcie... za 300 mln. ;)

0
Mały Krawiec napisał(a):

No, ale teraz dzieci pracują... pity programują na c## net.scripcie... za 300 mln. ;)

nie wiem co to c## net.script, ale akurat w C# by to nawet 20 kB nie zajęło...
w delphi z tego co pamiętam najprostsza aplikacja okienkowa w VCL to minimum 500 kB

0

No niestety w tak smutnym kierunku "tuczenia" exeków z gołą formatką albo prostym kodem poszły środowiska do pisania w obiektowym Pascalu. Szkoda, że nie mogli Lazarusa rozwinąć na bazie kodu Delphi 7 z poprawieniem błędów i unowocześnieniem. Ale bez tuczenia exeków pakując tam co się im podoba. Pod WinAPI osobiście piszę jeśli już to tylko w Delphi 7. Wiadomo z VCL bywa tam różnie, ale domyślny projekt to 365 568 bajtów. Wiadomo, dzisiejsze łącza i dyski to pomięszczą. Ale jak ktoś kiedyś jadł krakersky i jego dzieła pisane w masmie i WinAPI zajmowały niespakowane góra 20 kb i to po wstawieniu oraz obsłudze muzyczki w tle, to teraz się łapie za głowe :)

0
fafdas napisał(a):
Mały Krawiec napisał(a):

No, ale teraz dzieci pracują... pity programują na c## net.scripcie... za 300 mln. ;)

nie wiem co to c## net.script, ale akurat w C# by to nawet 20 kB nie zajęło...
w delphi z tego co pamiętam najprostsza aplikacja okienkowa w VCL to minimum 500 kB

Jak poznać subiektywną opinię? Niedomówienia. Np. że C# wymaga posiadania frameworka, którego rozmiar jest duuuużo większy. Aplikacja w VLC jest niezależna od tego co mamy zainstalowane w systemie.

0

Wymaga posiadania frameworka który jest preinstalowany z każdym wspieranym obecnie systemem

żeby nie być gołosłownym - program przetłumaczony na C#: http://ideone.com/QyTiau

po skompilowaniu: 8192 bajty

0

Ok, zgoda, wiem, że Microsoft sobie na takie rzeczy może pozwolić. Gdyby twórcy Delphi byli na takiej samej pozycji monopolisty, to myślisz, że nie wpakowaliby wymaganych bibliotek w system?

0
abrakadaber napisał(a)

Co do pakowania UPXem to dla mnie to proteza :)

Eee tam, UPX potrafi zdziałać cudza :]

Mały Krawiec napisał(a)

20 kB nie powinno to zajmować.
Kiedyś robiłem programy, tak wprost na windows, na surowo, no i takie to było...

Aha... Napisz więc taką aplikację w gołym WinAPI i zaprezentuj;

No, ale teraz dzieci pracują... pity programują na c## net.scripcie... za 300 mln. ;)

Sam jesteś jeszcze dzieckiem;

fafdas napisał(a)

w delphi z tego co pamiętam najprostsza aplikacja okienkowa w VCL to minimum 500 kB

Zależy w którym Delphi - wersja 7 generuje plik wykonywalny najprostszego programu okienkowego o wadze 359KiB.

0
fafdas napisał(a):

Wymaga posiadania frameworka który jest preinstalowany z każdym wspieranym obecnie systemem

żeby nie być gołosłownym - program przetłumaczony na C#: http://ideone.com/QyTiau

po skompilowaniu: 8192b

Przecież to jest zwyczajne źródło... czyli to co pisze programers.

No, ale jak te 8KB potem chodzi... szkoda słów.

furious programming napisał(a):

Aha... Napisz więc taką aplikację w gołym WinAPI i zaprezentuj;

Niby jaką znowuż aplikację - czyżby tę aż 20 liniową?

Czemu nie, chcesz to mogę ci sprzedać takie coś za... 1 marny mln. lol;

Na początek masz piękny obrazek w 1 linii:

Begin WinExec('rakieta.jpg'); end.

0

Niby jaką znowuż aplikację - czyżby tę aż 20 liniową?

Jeżeli nie wiesz o jaką aplikację chodzi, to lepiej skończ postować;

Wypowiadasz się w tym i innym wątku, choć nawet nie wiesz o czym jest dyskusja; Z innej strony - ciekawe ile linijek kodu będziesz musiał klepnąć, skoro aż tak bardzo przeszkadza Ci opasłość VCL i biblioteki standardowej.

0

Ależ ja zawsze chętnie się zakładam - o symboliczne 100 mln,
że szybciej klepnę w surowym windows, niż wy wyklikacie to samo w delfinie. :)

Trzaskam:
OpenKey... Queryvalue... i koniec.

Co ty chcesz tu więcej tworzyć... sobie trykasz i finalizujesz - no i co z tego masz? lol)

1
Mały Krawiec napisał(a):

Ależ ja zawsze chętnie się zakładam - o symboliczne 100 mln,
że szybciej klepnę w surowym windows, niż wy wyklikacie to samo w delfinie. :)

Trzaskam:
OpenKey... Queryvalue... i koniec.

Co ty chcesz tu więcej tworzyć... sobie trykasz i finalizujesz - no i co z tego masz? lol)

A ja się zakładam o 100 mln (tych starych od Wałęsy) że w Windows w ogóle nie klepniesz bo to system operacyjny... Zakładając że chodziło o WinApi to jestem pewien że klepnę to 10x szybciej niż Ty sprawdzisz w dokumentacji parametry wywołań wszystkich tych funkcji RegOpenKeyEx, RegQueryValueEx, RegCloseKeyExwięc nie podniecaj się... a try finally masz to że to jest programowanie OBIEKTOWE wiec jak tworzysz obiekt to musisz (a właściwie tylko powinieneś) go zwolnić wspomniany blok zapewnia to że zwolnisz nawet jeżeli wystąpi błąd. O zaletach programowania obiektowego to pewnie nigdy nie słyszałeś a może jesteś z tych upartych co słyszeli o kole ale i tak i wolą nosić niż wozić, bo przecież wózek miejsce zajmuje.

0
kAzek napisał(a):

A ja się zakładam o 100 mln (tych starych od Wałęsy) że w Windows w ogóle nie klepniesz bo to system operacyjny... Zakładając że chodziło o WinApi to jestem pewien że klepnę to 10x szybciej niż Ty sprawdzisz w dokumentacji parametry wywołań wszystkich tych funkcji RegOpenKeyEx, RegQueryValueEx, RegCloseKeyExwięc nie podniecaj się... a try finally masz to że to jest programowanie OBIEKTOWE wiec jak tworzysz obiekt to musisz (a właściwie tylko powinieneś) go zwolnić wspomniany blok zapewnia to że zwolnisz nawet jeżeli wystąpi błąd. O zaletach programowania obiektowego to pewnie nigdy nie słyszałeś a może jesteś z tych upartych co słyszeli o kole ale i tak i wolą nosić niż wozić, bo przecież wózek miejsce zajmuje.

Nie martw się o to,
miałem czasu sporo na czytanie... bo tak od 1990r licząc z grubsza, czyli w zasadzie od zarania windowsa.

Tak że z 5000 parametrów funkcji mam w neuronach,
no a resztę sobie łatwo przypomnę, albo nawet wydedukuję - z sufitu, bo tam jest konkretna logika,
tego nie robili jacyś tam wizualni delfiniarze... na szczęście.

A odnośnie obiektowego programowania, powiem krótko: [CIACH!] wiesz na ten temat... zresztą to żaden temat - każdy program jest finalnie falt.

0

Trolu szkoda na ciebie czasu jak ci nie pasuje RTL i VCL z Delphi to dla mnie możesz sobie tworzyć nawet od razu w HexEdytorze (nie będzie ci nawet potrzebny kompilator). Niektórzy nigdy niczego się nie nauczą i nie zrozumieją że jak dla kilku kilobajtów coś się robi godzinę a nie minutę to jest to wysoce nieopłacalne. Nie wmawiaj mi że bezpośrednio w WinApi pisze się wygodniej i szybciej, bo to oznaczałoby że wszystko co powstało później to po to aby utrudnić ludziom życie. Co do WinApi mogę się założyć że sam znam nie gorzej od ciebie a jednak używam sporadycznie. Po postu niektóre rzeczy warto znać ale trzeba wiedzieć kiedy opłaca się ich użyć. Dla mnie EOT bo jak wspomniałem szkoda czasu którego ty masz chyba nadmiar skoro możesz sobie pozwolić na klepanie nawet dużych aplikacji w WinApi.

0

Wracajac do upx jest to tez fajny patent chociazby ze wzgledu na prace exe na terminalach blad C0000006 (exe + dll lub exe + bpl).

0

Na srodowiskach terminalowych gdzie exe + dll lub exe+ bpl jest odpalany z zasobow sieciowych windows nie laduje calosci do pamieci.
Czesto wystepuja bledy external access. Spakowanie upx wymusza na windows zaladowanie calosci do pamieci w celu rozkompresowania.

3

Jak ktoś chce mieć exeki wielkości kilku kilo (~10kb) to może użyć KOL: http://kolmck.net/

Zawsze to lepsze od pisania w WinAPI...

1 użytkowników online, w tym zalogowanych: 0, gości: 1