Do tej pory było tak, aby kod modyfikować w aplikacji kod musi być najpierw skompilowany. Przez co musi być nowa wersja pliku exe. Ciekawi mnie ten temat. Proszę o podpowiedzi.
0
1
Rozumiem chcesz kompilować, ale nie kompilować? Bo inaczej nie rozumiem pytania
Żeby była nowa wersja EXE, ale jej nie było?
5
Żeby była nowa wersja pliku wykonywalnego to trzeba go podmienić — inaczej się nie da.
Jeśli chcesz zmienić działanie aplikacji bez podmiany pliku wykonywalnego, to w takim przypadku używa się silnika skryptów — czyli przenosi się część logiki właśnie do skryptów i te ładuje się w programie i wykonuje (tym zajmuje się interpreter). Dzięki temu aby zmienić zachowanie programu, wystarczy podmienić sam skrypt (czyli plik tekstowy), a exeka ruszać nie trzeba.
Tak działają np. emulatory starych konsol — one same z siebie potrafią odtwarzać gry, ale dzięki skryptom Lua można wpływać na proces emulacji, renderować dodatkowe rzeczy na ekranie, uzyskiwać dostęp i wykorzystywać dane przechowywane w pamięci emulatora. I dzięki temu każdy może sobie takie skrypty pisać, a twórcy nie muszą rekompilować niczego.
1
W dawnych czasach istniały interpretery języków. Np. interpreter Basica i mocno biedne pliki .BAT.
Współcześnie masz skrypty powłoki, np. PowerShell. Chyba, że zdążyli już coś nowego wymyślić.
1
Mariusz Bruniewski napisał(a):
Do tej pory było tak, aby kod modyfikować w aplikacji kod musi być najpierw skompilowany.
U Mariusza B., być może.
Przez co musi być nowa wersja pliku exe. Ciekawi mnie ten temat. Proszę o podpowiedzi.
Tak jak sam sobie odpowiedziałeś; AutoHotKey to skrypt, a nie exe.
A że on tam potrafi tworzyć exe, które ma w sobie osadzony cały skrypt, który potem wykonuje nie oznacza, że to de-facto standardowa skompilowana aplikacja. Nie.
Użyj osadzonego języka skryptowego, w którym będziesz pisał logikę - część lub całość, jak tam chcesz.
Masz do wyboru całą masę (JS/Pascal/Python/PHP itd.).
0
Nie wprowadzajcie kolegi w błąd. Da się modyfikować istniejący plik
.exe bez kompilacji. Da się go zmodyfikować i zmienić jego działanie. Przecież to nie jest niemożliwe. Da się zmienić teoretycznie wszystko.
0
Ghost_ napisał(a):
Nie wprowadzajcie kolegi w błąd. Da się modyfikować istniejący plik
.exe bez kompilacji. Da się go zmodyfikować i zmienić jego działanie. Przecież to nie jest niemożliwe. Da się zmienić teoretycznie wszystko.
Powiem więcej, da się nawet zmodyfikować działanie exe bez gmerania w exe.
Tylko co z tego, że się da?
To jest orka na ugorze, podatna na masę błędów i problemów i takie działanie to zdecydowanie nie jest dobra droga do uczynienia apki elastyczną.
Poza tym, to tylko pudrowanie problemu a nie rozwiązanie.
Bo co, w razie zmiany logiki będziesz pisał cracka do własnej aplikacji?
Jasne, da się.
Ja jednak wolałbym zmienić/dodać kawałek skryptu i cześć.
1
Ja to wszystko wiem, ale czy powinniśmy zabraniać koledze orki na ugorze? Ma do tego prawo. To wolny kraj.
2
@Ghost_: nie trzeba nikomu zabrać, bo każdy niech robi to co chce, ale forum jest po to, aby wybrać jak najlepsze rozwiązanie, które będzie spełniać wymagania pytającego i nie będzie wymagać gigantycznych nakładów pracy. Jeśli jest możliwość zrobienia czegoś łatwo i szybko, to takie rozwiązanie ma priorytet i wolność nie ma tutaj nic do rzeczy.
Można sobie modyfikować plik wykonywalny w dowolny sposób, ale to nie ma żadnego sensu — jest to bardzo trudne, czasochłonne i skomplikowane. Im więcej pracy wymaga tym gorzej, im bardziej skomplikowane zadanie tym większa możliwość popełnienia błędów. Po cholerę się z tym użerać, skoro wystarczy skompilować nową wersję pliku wykonywalnego i ją podmienić?
Nieważne co się wybierze, plik wykonywalny i tak musi dostać nową zawartość — musi mieć zaaplikowaną nową funkcjonalność/zasoby/whatever, więc i tak proces musi zostać zakończony przed jakimikolwiek modyfikacjami. A skoro program najpierw należy zamknąć, aby móc przeprowadzić aktualizację, to najprostszym i najmniej czasochłonnym rozwiązaniem jest zwykła podmiana exeka na nowego, co robi 99.9% normalnych programów.
I od razu napomnę, że nie każda aktualizacja programu dotyczy samego pliku wykonywalnego, więc często do zaktualizowania nie potrzeba jego pełnego restartu. Często update dotyczy jego składników — bibliotek, styli, skryptów, assetów czy innych binarek — co proces programu potrafi ogarnąć. Tu przykładem może być aktualizacja bazy sygnatur programów antywirusowych.
Rozwiązanie dobiera się do potrzeb, a my nadal tych potrzeb nie znamy. Jeśli problemem jest normalna aktualizacja głównego pliku wykonywalnego programu, to rozwiązaniem jest normalna podmiana exeka z pełnym restartem. Jeśli update ma dotyczyć oddelegowanej logiki do zewnętrznych plików (bibliotek DLL, skryptów itp.) to można się szarpnąć na podmianę samych tych plików, bez restartu. Jednak w większości przypadków nie ma sensu komplikować logiki programu, bo użytkownikowi raczej w niczym nie przeszkodzi pełny restart programu — nie będzie z tego powodu płakał (chyba że update zeżre mu efekty pracy).
0
Pośrednio w temacie jest jeszcze takie rozwiązanie jak TMS scripter, pośrednio ponieważ nie jest przeznaczone na zatagowanego Lazarusa.
0
Bez uprzedzeń panowie. Każde Wasze uprzedzenie zdradza waszą niemoc. Kiedy skończy się w końcu przenoszenie uprzedzeń z wątku na wątek. Jeśli nie chcesz lub nie lubisz mnie nie odpowiadaj tutaj....
1
Tak czysto teorytycznie bo do praktyki nigdy nie doszedłem w delphi jesteś w stanie do exe dołączyć plik z resourcami. Jak się to tworzy i zarządza to już inna sprawa jednak w pliku opisującym resa (.rc) możesz dać ścieżkę do pliku *.pas, *.dfm, *.dpk i *.dpr czyli teorytycznie jesteś w stanie stworzyć exe z res'em zawierającym wszystkie niezbędne pliki do skompilowania exe. Ponadto możesz również do pliku .rc dodać scieżkę do dcc.exe (kompilator konsolowy delphi) i jego również dołączyć do swojego exe. Co za tym idzie (podkreślam czysto teorytycznie bo tego nie sprawdziłem) byłbyś w stanie przygotować sobie exe z plikiem res, który zawierałby źródła twojej aplikacji + kompilator. Mając taki zestaw jesteś w stanie napisać kod aplikacji w taki sposób aby wypakował z res'a niezbędne pliki, podmienił nazwę twojego exe (tego uruchomionego) na exe_old, uruchomił dcc wskazując w parametrach projekt, który ma przekompilować i urtworzyć nowy exe. W ten sposób miałbyś exe, który generowałby nowe exe. Na tym etapie (wypakowywania) w zależności od potrzeb (np sprawdzenie daty na kompie) możesz wypakowany plik *.pas podmienić tak aby uwzględnił datę pobraną z kompa i wkompilował ją w exe.
1
@woolfik:
Bez urazy, ale kopiesz w miejscu, totalny overkill, a programy antywirusowe będą aż skakać ze szczęścia
Za to zgodził bym się z ideą doklejania w resursach skryptu np. Lua
Niestety @Mariusz Bruniewski puszcza jakieś emocje, a ma niemoc jeśli chodzi o doprecyzowanie tematu
1
AnyKtokolwiek napisał(a):
Bez urazy, ale kopiesz w miejscu, totalny overkill, a programy antywirusowe będą aż skakać ze szczęścia
Za to zgodził bym się z ideą doklejania w resursach skryptu np. Lua
Jedyna różnica jest taka, że skrypt napisany np. w Lua jest wykonywany przez interpreter osadzony w programie, a pliki źródłowe kompilowane są przez kompilator. I ta różnica nie sprawia, że antywirusy zakochują się w tym drugim podejściu. Np. Lazarus potrafi się sam rekompilować i AV nie widzi w tym niczego podejrzanego — bo nie powinien.
Jednak dołączanie pełnych źródeł do programu, w postaci zasobów, brzmi dość dziwnie. Bo to wygląda, jakby program miał zamknięte źródła, ale z drugiej strony one cały czas były dostarczane, tyle że w sposób niejawny. Niby zamknięte oprogramowanie, a jednak otwarte. Może i jakieś zastosowania by się znalazły dla takiego podejścia — kto wie, ludzie są kreatywni. Dać się da zrobić wszystko, ale pytanie takie czy ów rozwiązanie ma w ogóle sens.