Witam.
Po zainstalowaniu Delphi 7 pod Windows 7 przy tworzeniu nowej aplikacji wywala błąd jak w załączniku - oczywiście nowej formy - aplikacji nie tworzy.
Proszę o pomoc w rozwiązaniu tego problemu.
0
1
Kiedy pisano Delphi 7 to Windows 7 nawet nie było jeszcze w planach, więc Delphi 7 nie radzi sobie (w sposób standardowy) z zabronionym zapisem gdzie tylko się da.
Ja to rozwiązałem przez dołożenie do pliku exe manifesta aby się odpalał z prawami administratora - zawsze i automagicznie.
0
Dzięki
1
Zawsze zamiast zamiast korzystać z 10+letniego środowiska można także zastanowić się nad bardziej rozbudowaną darmową alternatywą: Lazarusem.
0
Lub wyłączyć UAC, lub zainstalować Delphi 7, nie w PROGRAM FILES. Powinno się dać. Zadanie bardziej ekstremalne, zrobić sobie loader z manifestem wymuszającym koniecznie prawa Administratora, który uruchomi z takimi prawami jeśli się na to zgodzimy Delphi 7. Ale oczywiście również polecam Lazarusa jeśli chcemy najmniej kombinować. Jedyna wada to inny układ GUI IDE na który trzeba się przestawić i pomimo kombinacji w opcjach 64 bitowy Lazarus generuje u mnie ponad 2 MB exek z czystą formatką. A użyty strip wcale nie pomaga i nic nie zmienia. Ale na to pewnie poprzednik coś Ci zaradzi i podpowie, bo lepiej na pewno zna temat ode mnie.
0
Co wy z tymi manifestami…
0
A ja nie wiem, wole manifest, jeśli trzeba, bo jak kiedyś tak ustawiłem dla skrótu do exeka, to i tak nie uruchamiało na tych prawach. Ale każdy tobi jak woli, może i ja coś pokręciłem.
0
Co wy z tymi manifestami…
Już się domyślam dlaczego wszyscy użytkownicy Delphi7 mają wyłączone UAC.
pomimo kombinacji w opcjach 64 bitowy Lazarus generuje u mnie ponad 2 MB exek z czystą formatką
http://wiki.freepascal.org/Size_Matters
Ja bym zakładał opcję "have an unrealistic expectancy of the binary size".
Kod x64 będzie większy nawet jeżeli staniesz na głowie, prawa RISC i większego adresowania.
Raz jeszcze polecę assembler jeżeli @olesio chcesz mieć możliwie małe pliki wynikowe. Z całą pewnością będzie lepszy niż twoje ukochane Delphi7... Również w prędkości i zgodności z nowymi OS... Ale po prostu niektórzy nie rozumieją że 2Mb w dzisiejszym świecie to okruszek na dyskach 200Gb+ i nie ma sensu przejmować się rozmiarem. Ja mam binarkę Lazarusa z debugiem która waży 100Mb+ i nie płaczę... (tak tak, tak to jest jak się buduje Lazarusa bez smartlinkowania, bodaj dodali jakiś czas temu ostrzeżenie...)
1
Wystarczy zainstalować poza Program Files.
1
Ja bym zakładał opcję "have an unrealistic expectancy of the binary size".
Nie zgodzę się. Duże exeki wynikają głównie z jednej rzeczy: wlinkowywania mnóstwa śmieci, całych wielkich frameworków, mimo że 1% z tego jest faktycznie potrzebne.
Jest oczywiste, że exek z symbolami dla debuga będzie większy (czasami kilka razy większy) oraz linkowany statycznie będzie dużo większy, ale jeśli widzę releasowego exeka na poziomie hello worlda, który zajmuje powyżej tych 2 MB, to coś jest bardzo nie tak.
0
Nie zgodzę się. Duże exeki wynikają głównie z jednej rzeczy: wlinkowywania mnóstwa śmieci, całych wielkich frameworków, mimo że 1% z tego jest faktycznie potrzebne.
FPC smartlinkuje tylko te rzeczy które są używane. Natomiast linkowane jest dużo rzeczy które są używane, ale które można rozpracować lepiej: np. parser XML jest wbudowany w każdy program LCL gdyż parsuje to zasoby form.
Więc nie jest linkowane mnóstwo śmieci, wszystko jest w teorii używane.
I niestety nie wiem o jakie wielkie frameworki ci chodzi, ale chętnie dowiem się czegoś nowego.
ale jeśli widzę releasowego exeka na poziomie hello worlda, który zajmuje powyżej tych 2 MB, to coś jest bardzo nie tak.
Polecam popatrzeć co się zacznie dziać jeżeli będziesz wlinkowywać wszystko co potrzebne przy współczesnych RTL/LCL. C++ już dawno ucieka się tym że wszystko ma w oddzielnych DLLkach.
Gdzieś był wykres który pokazywał że o ile rozmiar był większe przy malutkich programach w Lazarusie z LCL, to przy dużych programach rozmiar dużo wolniej rosło niż u innych.
I nie, 2Mb to nie jest dużo. Zwracając uwagę na to że kompilujesz to pod x64 to to jest mało. Jeżeli skompilujesz to pod x86 to wyjdzie ci po włączeniu opcji wywalenia niepotrzebnych rzeczy ~1Mb, które ja sobie pakuję fajnym packerem do 500Kb. Natomiast jeżeli napiszesz coś bardziej skompilowanego niż helloworld, to np. mój bot do warcab miał po kompresji w sumie miał 700Kb (Większość z dodatkowej przestrzeni to grafika pionków). Dużo? Moim zdaniem nie.
Problem twojego porównania jest bardzo banalny: Porównujesz miejsce w którym Lazarus spisuje się najgorzej, nie w którym spisuje się najlepiej. Żadnego porównania wielu wypadków, żadnych wielu testów, po prostu zakładasz przypadek negatywny dla Lazarusa i nic nie odkrywasz. Nie zgadzam się że coś jest bardzo nie tak, po prostu wy zakładacie przypadek najbardziej negatywny i wyciągacie z niego wnioski dla wszystkiego. Nigdzie nie widziałem rzetelnego porównania przy kodzie który coś znaczy. Każdy jeden ogranicza się do hello worlda i wyciąga bezsensowne wnioski.
Więc jeżeli chcesz polemizować, to rzetelnie podejdź do tej kwestii, Lazarus to nie jest narzędzie do pisania zabawek tylko poważnych programów które i tak zawsze stabilnie skompilujesz do 600Kb w przypadku użycia UPXa i x86. Natomiast jeżeli używacie x64 i helloworlda to macie wielkie pretensje mimo ze powszechnie wiadomo że to jest przypadek w którym Lazarus spisuje się najgorzej. Jeżeli chcecie mieć jeszcze gorsze wyniki (co jest oczywistym waszym celem), to kompilujcie pod Linuxa, tam jest większy rozmiar plików.
0
olesio napisał(a):
Jedyna wada to inny układ GUI IDE na który trzeba się przestawić i pomimo kombinacji w opcjach 64 bitowy Lazarus generuje u mnie ponad 2 MB exek z czystą formatką. A użyty strip wcale nie pomaga i nic nie zmienia. Ale na to pewnie poprzednik coś Ci zaradzi i podpowie, bo lepiej na pewno zna temat ode mnie.
2 MB to nie jest dużo. Owszem, pusty EXE w Delphi ma 370kB, ale mam wrażenie, że żyjesz jeszcze w epoce dyskietek 1.44 MB - wtedy to był problem.
No ale nadal powstają aplikacje pokroju SysInternals (exeki już od 87 kB), więc rozumiem, że można chcieć móc zrobić sobie takiego toolika.
Wtedy można wykorzystać KOL-a:
http://kolmck.net/
- puste demo to 12 kB
2
Żadnego porównania wielu wypadków, żadnych wielu testów, po prostu zakładasz przypadek negatywny dla Lazarusa i nic nie odkrywasz.
Mój stosunek do Lazarusa jest negatywny z kilku powodów łącznie, ale to nie znaczy że jestem uprzedzony.
Lazarus generuje względnie duże exeki, o czym wszyscy trąbią, natomiast twórcy nie bardzo chcą sobie tego wziąć do serca, twierdząc że tak ma być.
Zwracając uwagę na to że kompilujesz to pod x64 to to jest mało
Kod maszynowy x64 jest większy, ale bez przesady. Jest to jakieś 20% więcej (dla równoważnego kodu), nie kilka razy więcej.
Lazarus to nie jest narzędzie do pisania zabawek tylko poważnych programów
Nie wiem co na to odpowiedzieć.
Każdy jeden ogranicza się do hello worlda i wyciąga bezsensowne wnioski.
Wnioski nie są bezsensowne.
Z pewnością dałoby się zmniejszyć narzut LCL-a, ale najwyraźniej nie jest to priorytetem u twórców, skoro zbywają tekstami typu “unrealistic expectancy”, albo wciskając UPX-a, na którego antywiry potem często wrzeszczą…
0
Lazarus generuje względnie duże exeki, o czym wszyscy trąbią, natomiast twórcy nie bardzo chcą sobie tego wziąć do serca, twierdząc że tak ma być.
Powiedz mi, jak twoim zdaniem powinny być one redukowane? Zapewne wiesz lepiej od twórców co zrobić? Nie wydaje mi się.
Kod maszynowy x64 jest większy, ale bez przesady. Jest to jakieś 20% więcej (dla równoważnego kodu), nie kilka razy więcej.
Po jakich kalkulacjach wyszło ci kilka razy więcej skoro pusta aplikacja LCL x86 Win32 waży 1Mb z (większym) kawałkiem. Mi wychodzi poniżej 2x.
Widać wiesz jak Lazarus powinien działać lepiej niż sam Lazarus.
wciskając UPX-a, na którego antywiry potem często wrzeszczą…
Problem z twoim antywirusem nie jest problemem z moją aplikacją. I niestety, pudło, bo UPX raczej na żadnych antywirusach nie generuje false-positivów (a jeżeli to robi to natychmiast zmień antywirus). Ja sobie korzystam z bardziej wydajnych packerów i większość porządnych antywirusów radzi sobie z rozpakowaniem tego (nawet darmowy Avast)... Natomiast wydaje mi się, że ty żyjesz 10 lat temu, kiedy packery generowały masę falsepositivów, a typowy dysk miał ~10Gb. O czasie pobierania pliku 2Mb przez internet nie mówiąc. Nic dziwnego że w takim wypadku Lazarus ci nie pasuje.
Czas pobierania 2Mb przez internet w moim przypadku to poniżej 1sec, mogę sobie przechować 375 tysięcy kopii mojego programu oraz mogę go spakować żeby hejterzy rozmiaru się nie czepiali, chociaż nie, wtedy odezwą się hejterzy false-positivów. Więc nie ważne co zrobię, to jest nieistotne czy je spakuję czy nie, i tak to będzie i za duże i będzie generować false-positivy!
Od jutra zaczynam przepisywać swoje programy na assembler. Chociaż to też źle, bo jakiś false positive może być! To na kod maszynowy SScript (bo tego antywirusy nie wykrywają jeszcze, packerów też nie ma. @Patryk27, udostępnij jakiś assembler tego). Wynika z tego, że jedyne rozwiązanie to napisanie portu FPC na SScript, wtedy nie będzie false-positivów oraz nie będzie porównania rozmiarów między różnymi środowiskami (Patryka przekupimy żeby jego kompilator generował 100x większy output). Aha!
Co do twoich false-positivów, ostatnio sobie budowałem FPC z debugiem, rozmiar ok. 18Mb, nie spakowany niczym. Avast wykrył to jako podejrzany plik i na tym kończę temat związku falsepositivów z powszechnymi packerami, bo takowy po prostu nie istnieje, a używanie mniej znanych zapewne spowoduje że przy downloadzie aplikacji umieścisz informację że plik nie jest zainfekowany a spakowany i żeby osoby z głupimi antywirusami się odwaliły.
Z pewnością dałoby się zmniejszyć narzut LCL-a, ale najwyraźniej nie jest to priorytetem u twórców, skoro zbywają tekstami typu “unrealistic expectancy”
Skoro jesteś o tym przekonany to może pokażesz to na przykładach? Tylko wiesz, to że potrafisz wywalić 1Kb to nie jest osiągnięcie, my mówimy o zysku z rzędu ćwiartki megabajta żeby to miało sens stosowania.
Jestem przekonany że jeżeli zaimplementujesz porządne rozwiązanie redukujące rozmiar plików wykonywalnych to twórcy nim nie pogardzą. Problem leży w tym, że każdy potrafi jedynie narzekać, mało kto ma realną wiedzę jak to zrobić. Być może w niedługiej przyszłości popracuję nad poprawką do FPC która zwiększy przydatność trybu "Compile for size rather than for speed" i usunie wyrównanie procedur i może jeszcze parę innych rzeczy... Ale zapewne ty potrafisz napisać coś co zamiast poprawić rozmiar o parę Kb zmieni to o 1Mb?
I widać tak, nie jest to priorytetem, bo nawet ja wolę żeby było więcej opcji i lepsza optymalizacja niż zmniejszanie rozmiaru plików wynikowych które mi nie przeszkadzają, bo skutecznie unikam plików większych niż 800Kb... Więc po co dopieszczam opcję generowania mniejszych plików wykonywalnych? Bo znam się nieco na formacie EXE i chcę coś napisać, uznałem że to będzie coś co ma sens.
No ale nadal powstają aplikacje pokroju SysInternals (exeki już od 87 kB), więc rozumiem, że można chcieć móc zrobić sobie takiego toolika.
W FPC można generować 30Kb pliki, jak się potrafi użyć packera to można zejść poniżej 20Kb...
Natomiast LCL generalnie jest spory, tylko problem jest taki że nikomu to realnie nie przeszkadza, bo gdyby przeszkadzało to ktoś by się za to zabrał. A tak to tylko skrytohejterzy którzy są genialnymi teoretykami i słabymi praktykami się czepiają...
Jeżeli już mówimy o małych plikach wykonywalnych, to assembler potrafi wypluć 268 bajtowy plik EXE który działa (najmniejszy jaki da się wygenerować). Więc jeżeli szukamy najmniejszych rozmiarów, to assembler zawsze wygra, po prostu. Tylko pytanie czy używając narzędzi stylu Delphi/Lazarus nam nie zależy na wygodzie a na rozmiarze? Widać niektórzy są tak dziwni że mijają się z celem istnienia pewnych narzędzi. Pewno na forum assemblera hejtują brak wygody użytkowania...
Nie wiem co na to odpowiedzieć.
No to nie odpowiadaj nic. Mowa jest srebrem, milczenie złotem. Serio, skoro dla ciebie Lazarus to narzędzie do pisania zabawek no to niestety, nasze spojrzenia na te środowisko różnią się.
0
znalezione dzisiaj na scianie dworca w Pruszkowie:
"Stay positive"
pozdro