Tartalmazza az eredeti cpp-s EXE-exportot, annak a megnyírását, az eredetit UPX-el betömörítve, valamint a megnyírt verziót szintén UPX-el betömörítve.
Xtremecompression Ez is egy spéci tömörítõ (adatbázis-tömörítõ ???) lehet, jobb még a NanoZip-nél is, de viszont sebességre mint a ZIP, akár be, akár kitömörítéskor.
Ja van itt az sg-n egy-két fórumja. Amúgy, amit leírt az a rekurzív-tömörítés. Volt a neten egy Recursiveware néven egy weblap, ahol errõl is írtak, meg fejlesztettek állítólag már egy programot is egy egyetemen talán(??), de aztán eltûnt az oldal azóta. Meg amit a képek kapcsán leírt, lehet, hogy a HPK codec tömörítés lenne??? Ami BMP-ben 910kB, az HPK-ban meg 7kB!, Jpeg-ben rossz minõségû ugyanekkora méretben. Katt ide: HPK És nem csak kép, hanem videótömörítéssel (ISCT codec) is foglalkoznak, ami lehet, hogy egyszer majd leváltja az MPEG4-et, amivel akár sok helyet is megspórolhatnánk. Bár a Fraunhofer-ék nem örülnének ennek.
A legjobb tömörítõ program (#79-nél ajánlottam két tömörítõt, ha netán nem ismernéd õket, nagyon jók. A NanoZip-bõl már van 0.09-es verzió is.) A FEAD-et meg nem nagyon lehet leszedni sehonnan se.
"Örökmozgóról szólva inkább azt nem kutatnám" "Az erõ mindig arra törekszik, hogy elenyésszen és eltékozolja magát; ha legyõzte önmagát, minden testet legyõz. Nélküle semmi sem mozog..." "... ó ti, az örökmozgó feltalálói, hány semmit nem érõ tervet alkottatok! Menjetek az aranycsinálók közé!" Leonardo da Vinci
"Nekem elküldte levélben az elméletét, s az amivel próbálkozott lehet, hogy zseni-nehézségû szint volt, viszont nem hülyeség." Ahhoz, hogy egy ilyen "csodatömörítõ" elfogadható dologgá váljon, nagyon alaposan alá kell támasztani konzekvens matematikai elmélettel (pláne hogy ott a Shannon-limit, az entrópia), programozói gyakorlattal. Ha ez hiányzik, szép álom marad, de nem több. Hasonló a helyzet az örökmozgók, "szabadenergiás gépek" esetében is.
Örökmozgóról szólva inkább azt nem kutatnám, nehogy én is ujjat húzzak a "tisztelt" maffiával. (kisbetûsen írandó)
Mellesleg az álltömörítõ programot már kitalálták rég, BARF-nak hívják, itten letölthetõ : http://cs.fit.edu/~mmahoney/compression/barf.exe
Amúgy abban tényleg nem volt tisztességes f1ú, hogy hajtogatta, hogy ez 100%-ig menni fog, de belebukott; viszont azt joggal kikérhetné magának, ahogy szidjátok. Nekem elküldte levélben az elméletét, s az amivel próbálkozott lehet, hogy zseni-nehézségû szint volt, viszont nem hülyeség. Szerintem ha írtok neki, veletek is megosztja, csak akkor személyesen tõle kérjétek, mert úgy tisztességes.
Nem biztos hogy egy összetettebb program mindegy egyes funkciója mûködne (még ha le is fut)
Ráadásul ha a egy olyan input van aminél nem adott lehetõségek közül lehet választani hanem a felhasználó bármit beírhat akkor ott már lehetetlennek tûnik algoritmussal leellenõrizni
Esetleg egy olyanban amiben adatok elõre ismert kisméretû halmazából számol a program, viszont ennél meg már fordító szinten megoldható az optimalizálás (szerintem)
Egyébként milyen program volt amin letesztelted?
Nem õ, de a tudományos fõcsoportban van néhány ilyen témát kedvelõ társaság.
Mifelénk is van SG-n egy õrült, a frayer talán (?), annak is ez a mániája. Bírom, mikor (ál)tudományosan próbálja megmagyarázni az alapvetõ elméleti és fizikai képtelenségen is túlmutató faszságait és a sok hülye meg beszopja és asszisztál neki. :D
ajánlott olvasmány a témában, a nyitó hozzászólás: "Mit szólnátok ahhoz ha azt mondanám, hogy elméletben kitaláltam egy olyan tömöritési eljárást, amivel bármekkora fájlt betömöritek 2 bájtba? Akár 52 GB méretû fájlt is... A programot már elkezdtem fejleszteni, lassan kész az alap felhasználói interfész. Pár napon belül elkezdem fejleszteni a tömöritési eljárást. Mi történne ha ez a program kikerülne a piacra? Képzeljétek el hogy akár több ezer filmet el tudnátok tárolni egy 1.44 -es lemezen... Várom a véleményeteket!"
A kezdeti helyzet az, hogy Win32-ben szoktam programozgatni, és szeretem, ha egy alkalmazás a lehetõ legkisebb méretû (persze ha nem tartalmaz hosszú lefutású ciklusokat és a sebesség egyáltalán nem számottevõ). Múltkor nézegettem egy ilyen saját kis méretû (7 KB) kiexportált EXE-t, és látom a rengeteg 00-ás bájtot tratalmazó blokkokat itt-ott. Ez persze önmagában nem nagy újdonság, én is sejtem, hogy memóriacímkezelések meg ilyen assembly-s dolgok miatt van mindig ez így, igaz, nem nagyon értek, hozzá, de ez így van rendjén. Aztán viszont látom, hogy itt-ott a 0-ás bájtblokkok közepén árvátlankodik egy-egy bájt (nem 0-ás értékû), \"messze a társaitól\". Ekkor már valami el kezdett motoszkálni a fejemben, hogy hát ez még sincs igazán rendjén, ez így nem \"gazdaságos\" egy tömörítõ program számára. Erõs késztetést éreztem arra, hogy azokat a 0-ás bájtblokkokba belecsöppent nem 0-ás bájtokat lenullázzam és... Voilà! : Az alkalmazás még mindig remekül futott. Persze egyes lenullázások már nem vezettek jóra, de azért még is el kezdtem gondolkozni ezen, hogy: nocsak-nocsak, tán még sincs feltétlenül szükség minden egyes byte-ra?! Így jutottam el odáig, hogy pl.: szintén erõs késztetés hatására az \"MZ\" és egy távoli E0 kivételével felszántottam a fejlécet, meg egy számomra ismeretlen kb. 110 byte-os blokkot, az exe meg azóta is vígan mûködik. (Zárójelben: az exe kizárólag 32 bittes volt eredetileg is)
Látszólag ez mind haszontalanságnak tûnhet, ugyanis a méretet hex-editorral semmiképpen sem változtathatom meg, mert az exe akkor egybõl elromlik. Amire viszont ez a módszer szerintem használható lenne - bár még nem próbáltam ki - hogy UPX-el az eredetihez képest a nem kritikus pontokon lenullázott exe jobban betömöríthetõ lenne.
Így mondjuk talán lehetne írni egy EXE-Társtömörítõt, ami annyit csinálna, hogy sorra veszi az EXE-alkalmazás bájtjait egyenként (ha azok nem 00-ák), lenullázza, az így egyetlen bájtban különbözõ adathalmazt lementi másolatként, aztán pedig megnézi, hogy a másolat tud e futni, és ha nem tud, akkor ezt a módosítást nem alkalmazza és ugrik a következõ bájtra, ha viszont tud futni ezzel az egy bájtnyi lenullázással, akkor az eredeti EXE-t felülírja a módosított másolattal és úgy ugrik a következõ bájtra (...) és-így-tovább-és-így-tovább, amíg nem lesz vége a fájlnak, jelen esetben EXE-nek.
Ennél persze az marad a kérdés, hogy hogyan lehet megnézni egy alkalmazásról, hogy az mûködik-e rendesen, vagy \"sérült\". Egy olyan programnál, ami pl. bekér valamit a felhasználótól, s arra várakozik, vagy aminek mondjuk kicsit hosszabb (néhány másodperces a futási ideje) annál esetleg meg lehet nézni, hogy mondjuk futott 5 másodpercig, és akkor valószínû, hogy mûködik; viszont mi a helyzet pl. egy olyan automatikus programnál, ami csak felvillan, aztán egy pillanat alatt meg is csinálja amit kell, s már be is zárul?
Igazából ez lenne a kérdésem, hogy lehet-e valahogy egy EXE-alkalmazásról valamilyen algoritmussal megállapítani, hogy mûködõképes-e, vagy sérült, anélkül, hogy valójában megnyitnám és futtatnám?
A szóban forgó EXE-Társkompresszor többi pontját gondolom pofonegyszerû megírni, úgyhogy jelen esetben a fenti kérés a kritikus pont.