16
EXE-Társkompresszor megírásához ötletek
-
olivaoil #16 Itt megtudod : http://www.sg.hu/listazas.php3?id=1323444532 -
kjhun #15 És ez a 7kB-os progi pontosan mire való, mire használható?? -
olivaoil #14 Itt a program, amivel "teszteltem": ZIP
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. -
#13
Már csak azt az egyet magyarázd meg nekem, hogy ENNEK mi köze az 1 bitre tömörítőhöz?!? :D -
kjhun #12 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. -
kjhun #11 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.
Tömörítő program készítése
Fájlok tömörítése (Egy kis tömörítő-teszt #31-es hsz-nél, olvasd el)
Maximumcompression Tesztek, tömörítők, egyéb.. -
#10
"Ö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. -
olivaoil #9 Ö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ó) 
-
olivaoil #8 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. -
steeldriver #7 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? -
#6
Nem ő, de a tudományos főcsoportban van néhány ilyen témát kedvelő társaság. -
#5
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 -
#4
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!" -
#3
Ez majdnem akkor ötlet, mint az egy bitre tömörítő!
"működőképes-e, vagy sérült, anélkül, hogy valójában megnyitnám és futtatnám"
Ennyi erővel az örökmozgót is kereshetnéd, az előbb vezetne sikerhez... -
#2
Jó az ötlet, biztos lenne valami haszna is ennek a tömörítésnek, de nem lenne jobb hétfő este inkább 1-2 sört meginni? -
olivaoil #1 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.