Vlákno názorů k článku Programovací jazyk BASIC na osmibitových mikropočítačích (3) od jarous - Vzpoměl jsem si na takovou zajímavost. Na ZX...
-
jarous (neregistrovaný)
Vzpoměl jsem si na takovou zajímavost. Na ZX Spectru se číselné konstanty v programu ukládaly dvakrát, jednou binárně a jednou jako String. Při psaní programu se po „zaentrování“ převedl řetězec na binární číslo, jež se ve výpisu nezobrazovalo. Program při běhu pak používal jen tato čísla. Šlo tedy program „zamaskovat“, tak, že se všechny stringy konstant „napoukovaly“ třeba na 0, což programu nevadilo, stejně je nepoužíval, ale z vypisu pak nikdo nepoznal, jak to funguje. Když jsem to poprvé viděl, tak jsem se docela lekl. Byl i prográmek, který to rekonstruoval zpátky.
-
Substance242 (neregistrovaný)
… ako sa vlastne volal ten program, ktorý načítal BASIC-ový loader hry a NESPUSTIL ho? Tie napokované programy ktoré sa nedali normálne ani vylistovať ani nahrať pomocou merge. Vlastne si spomínam, že som tiež do svojho loadera dal na napokovaný riadok číslo nula skok na AT 0,0 nejaký nápis a potom biele na bielom… jój, to boli srandičky. :-D
-
Peto_MiG (neregistrovaný)
To veru boli. Dosť som si obzeral niektoré loadery a bolo to územie nekončiaceho majstrovstva :-) Základným levelom boli fintičky, kedy sa vložením nejakého „zlého“ znaku (alebo aj viacerých znakov) do programového kódu BASICu docielilo, že pri pokuse o listing to blblo, dlho otravne pískalo pri každom kroku (či skôr vrčalo…), ale toto sa ešte dalo obísť, napríklad si napoukovať kratší chybový zvuk. Kombinovalo sa to s nastavením atribútov farieb na bielu na bielej, v niektorých prípadoch to bolo urobené tak šikovne, že sa mi to ani nepodarilo zrušiť :-) Videl som aj také loadery, kde chýbalo číslovanie riadkov, alebo bolo zdanlivo opačné, čo editor BASICu nerozchodil a vyhadzoval chyby.
Vrcholom umenia pre mňa boli loadery, kde sa vyskytovali úplne nezmyselné, v BASICu neexistujúce príkazy, ktoré však vyzerali úplne autenticky.
To už ani pravda nie je… -
Peto_MiG (neregistrovaný)
Ešte doplním pre mladšiu generáciu, o čo išlo.
Počítač bol po zapnutí v režime interpretera BASICu. Keď bolo treba nahrať nejaký program, zadal sa príkaz LOAD"" a pustila sa magnetofónová páska s príslušným programom. Príkaz zabezpečil nahratie a spustenie najbližšieho BASICovského programu z pásky. Hry boli programované samozrejme v assembleri (kvôli výkonu), ktorý si tento príkaz nevšímal, takže najprv musel byť na páske uložený krátky BASICovský program, ktorý zabezpečil nahratie nasledujúcej strojovej časti programu a jej spustenie (preto sa mu hovorilo loader – nahrávač).
Výrobcovia všemožne zabezpečovali BASICovský loader proti nahliadnutiu nepovolaným okom, pretože obsahoval adresu spustenia strojového programu. Prečo to robili? Kvôli ochrane proti kopírovaniu. Ak chcel niekto (zvyčajne nelegálne) skopírovať hru, musel to urobiť pomocou špeciálneho programu, ktorý dokázal načítať celú hru BEZ JEJ SPUSTENIA (čiže načítať z pásky v správnom poradí niekoľko sekvenčne nasledujúcich blokov kódu aj s ich zavádzačmi) z pásky do pamäte, a až keď bol program v pamäti, dal sa, opäť sekvenčne, uložiť na inú pásku. Existovalo niekoľko fínt, ako programátori ukladali hru na pásku tak, aby zmiatli kopírovací program a spôsobili, že sa kopírovanie nepodarilo (falošné zavádzače, prekročenie kapacity pamäte apod).
Samozrejme, bolo možné jednoducho skopírovať magnetofónovú pásku na dvojkazetovom magnetofóne, ale vtedy boli len veľmi vzácne (a šialene drahé) také prístroje, ktoré boli dosť kvalitné aby dokázali vytvoriť funkčnú kópiu. Zvyčajne bola funkčná aj tak len prvá, nanajvýš druhá generácia takýchto „audio“ kópií.
Takže ak sa podarilo zabezpečiť hru tak, aby sa nedala kopírovať bežnými kopírovacími programami, tak to domácich používateľov dostatočne odradilo od kopírovania.
Samozrejme, aj vtedy existovali hackerské spolky, ktoré sa pretekali v prelamovaní ochrán, a na prelomenie najlepších ochrán boli potrebné rôzne hi-tech úpravy počítača apod, takže to vyžadovalo značné vedomosti o konštrukcii počítača a znalosť assembleru. Akonáhle bola ochrana prelomená, hackeri dokázali vyrobiť takú kópiu programu, ktorá sa už dala ďalej kopírovať. Tak ako aj neskôr v dobe PC, hackerské skupiny boli rôzne schopné a tí menej šikovní nezriedka svojimi zásahmi poškodili zaujímavé efekty hry pri nahrávaní, obrázky, alebo poškodili samotný program, takže v nejakých častiach sa zasekával apod.
No a tu sa dostávame na začiatok – loader sa po nahratí z pásky rovno spustil a už neumožnil listing. Ale pre prípad, že by sa niekomu podarilo načítať ho do pamäte bez spustenia, autor programu čo najviac znepríjemnil prípadnému „nepovolanému oku“ nahliadnutie do loadera, najrôznejšími spôsobmi, zvyčajne zámerným „poškodením“ BASICovského programu tak, aby bol plne funkčný, ale aby zmiatol interpreter. Využívala sa na to „hardcore“ zmena rôznych pomocných kódov a hodnôt. -
Karel (neregistrovaný)
Tuším se místo „LOAD“ použil příkaz „MERGE“. Ten připojil nahraný program k tomu již existujícímu a nespouštěl ho. Tím jste obešel ochranu, kdy jako první příkaz byla nastavena „příkazová řádka“ mimo viditelnou obrazovku, čímž editor basicu vytuhl. Takový program normálně běžel až do chvíle, kdy jste ho zastavil. Basic se pokusil zobrazit „příkazovou řádku“ a umřel.
Ale i proti příkazu MERGE se dalo chránit – neporadil si, pokud v načítaném programu bylo více řádků se stejným číslem. Pak bylo nutné si pomocí nějakého programu načíst program jen jako data někam do paměti, vzít do ruky referenční příručku a začít dekódovat :-) Pak několika POKE umrtvit problematickou instrukci, změněný blok dat uložit zpět na kazetu a teprve pak to nahrát jako program. Jó to byly časy :-) Nikdy později už mě nic nemotivovalo tolik, jako potřeba rozchodit AY hudbu ze ZX Spectrum 128K na Didaktiku s AY interfacem. Po několika desítkách „cracklých“ her jsem se cítil býti odborníkem a je pravdou, že jsem rozchodil kde co a nějaký ten „kódovaný“ basic mě tenkrát nerozhodil. A nebyl jsem sám, v té době podobné zkušenosti, znalosti a úspěchy vykazovala značná část „uživatelů“. Tenkrát bylo například běžné, že mnoho lidí assembler umělo, a ten zbytek alespoň věděl, co to je. Dnes se naopak setkávám s tím, že mě někteří jedinci přesvědčují, že imperativní programování je přežitek a kdyby tu nebyla lobby Intelu a AMD, tak by už dávno procesory místo strojového kódu (vrchol to imperativního programování) nativně zpracovávaly Haskell. Z počítače je spotřební zboží a na poli software se čím dál tím více uplatňují programátoři, kteří neznají základy technologie. Jasně, HW abstrakce, netypované jazyky, to vše je krok předem. Ale zatrne mi, když chlapec s VŠ neví, čím se liší typy byte a int a i když mu to vysvětlíte, tak není schopen převést sled 4 bytů na int a na otázku zda ví, co je „little endian“ a „big endian“ odpoví, že tenhle spor je už dávno vyřešen tím, že současné počítače mají všechny Harvardskou architekturu. Člověk pak s pláčem vzpomíná na ty stovky kluků, kteří trávili dny s osmibitovým počítačem a snažili se pochopit jak to funguje. -
JmJ (neregistrovaný)
Na jednu stranu dobry programator musi umet navrhovat algoritmy a nejake inty a byte ho nemusi zajimat. Ono zalezi v jake urovni toho programovni clovek je. Jestli to jen vymysli a jini koduji, obcas si sam neco nakoduje, aby overil zakladni myslenky svych algoritmu, nebo jestli je clovek koder a implementuje algoritmus pro konkretni architekturu/jazyk.
Vetsina programatoru je nekde mezi a je tedy pro ne vyhodne vedet co je „za tim“. I kdyz prijde mlady programator a nevi rozdil mezi int a byte, ale umi vymyslet dobre algoritmy, tak se jiste rad nauci dalsi veci a bude z nej opravdu dobry programator. Kdyz vyleze nejaky trotl z VS, tvrdi ze vystudoval informatiku, myslis si cert vi co neumi, tak s tim uz se neda nic delat, ten je ztracen jako clovek ;-).
A ted trochu nostalgie. Mi prijde, ze dobry spravce site/programator byva ten, kdo to mel opravdu jako konicka. Nestaci napsat ukoly do skoly. Tak to citim ja a tak to zatim vidim kolem sebe. Kazdopadne jen ten konicek nestaci, clovek se musi dale aktivne vzdelavat.
Jaj, driv sem podle zvuku Turba 2000 dokazal poznat, jestli se nahravaji same nuly, kod, znakova sada nebo obrazek :-). Dnes uz pomalu patrim do stareho zeleza. -
Karel (neregistrovaný)
V povrchní rovině máte pravdu. Jenže já jsem zaujatý a trvám na tom, že bez znalosti principů fungování nemůžete dlouhodobě vytvářet efektivní algoritmy. Bohužel mi příroda dá čas od času za pravdu. Měl jsem kolegu, výborný kluk. Nerozuměl sice základům (byte, int), ale programoval dobře. Jenže pak jsme řešili nějaké výkonnostní problémy a zjistili, že pro chlapce je každý datový typ tak nějak atomickým. Zjednodušeně řečeno, v jeho vnímání bylo porovnání dvou čísel stejně náročné jako porovnání dvou stringů. A protože stringy jsou univerzálnější, tak navrhl aplikaci s tím, že tam měl řadu obrovských tabulek, kde primární klíče byly typu VARCHAR2. Oracle to docela dlouho zvládal, pak jsme mu pomáhali indexy, ale prostě jednoho dne to celé umřelo. Po algoritmické stránce výborně udělaná aplikace, ale proč tam doprčic dal texty? Než to po něm předělávat, to jsme radši celý modul odepsali a udělali znovu a jinak.
A to je právě problém lidí bez základů – odvádějí často výbornou práci, ale v nečekané chvíli udělají hroznou krpu, které si nikdo včas nevšimne. -
Pavel TišnovskýZlatý podporovatelSkoro me to pripada, jako jeden projekt, na kterym jsem spolupracoval – vsude se to hemzilo samymi varchary2 i v pripade, ze ve skutecnosti tam byly ulozeny ciselne identifikatory (kvuli varcharum nekontrolovane).
Ale nejvic me dostala jedna aplikace, v niz si programator(ka) ukladala data do listboxu (GUI prvku s nastavenou neviditelnosti :-). Bylo to psany v Delphi, takze kazde ulozeni/smazani polozky z listboxu znamenalo nekde uvnitr volani funkce WinAPI, jeho prekresleni atd. Kolega to prepsal na pouziti poli a zrychleni celeho programu bylo nekolikanasobne. -
Chtel bych se zastat navrhare datoveho modelu one aplikace, nutno podotknout, ze VARCHARu bylo o poznani mene nez CHARu. A kupodivu na dotaz, proc se nepouziva nejaky number se mi dostalo odpovedi, ze z vykonostnich duvodu a pro udrzeni konzistence. To jsem si musel honem sednout. Holt 30 let praxe ve foxce nemam, abych mohl oponovat.
Az Pavlovi dojdou namety na serialy, tak by urcite mohl do sekce zdrojaku psat vtipne historky a ukazky kodu, jak se nema psat enterprise aplikace, treba to v te dobe jiz nebude vyzrazovani know how. Ja bych pak v diskuzi pomohl rozptylovat pochybnosti, ze si to vymyslel… -
Na to proč dělat něco blbě jsem už slyšel tolik věcných argumentů …
Ten nejpravdivější je ovšen ten, který Vám nikdo neřekne (kromě toho, že lidská blbost je nekonečná) – když máte zprzněných tisíce řádků, tak se skoro žádný manager (pokud není idealista) nepustí do zásadního refaktoringu (u enterprise aplikace) – takže pak nezbývá než pokračovat ve starých chybách :(. -
Pavel TišnovskýZlatý podporovatel
To máš pravdu, ale v důsledku to mnohdy vede k tomu, že se další vývoj aplikace strašně prodraží, zvláště tehdy, když odejdou původní tvůrci, kteří ví, kam vložili různé obezličky atd.
Btw ta aplikace, o které se tady s Vlastou A. zminujeme, měla další skvělou vlastnost – když bylo zapotřebí přidat další atributy k objektům, se kterými se pracovalo, tak už se každý bál šahat do struktury tabulek. Namísto toho se nové atributy zapisovaly jako „strukturované poznámky“ do VARCHAR2ového sloupce POZNAMKA, takže se to v aplikaci na x místech parsovalo a zpracovávalo (co vím, tak s minimální kontrolou chyb). -
To si dovedu živě představit – možná jsem viděl něco podobného, i když ne tak strašného. Je otázkou, jestli se má cenu nad tím nějak pozastavovat. Ono k tomu refaktoringu – aby byl úspěšný, tak firma musí mít k dispozici alespoň jednoho výborného programátora a alespoň pár dobrých dobrých – a musí být k dispozici alespoň základní čas a klid. Pokud tyto podmínky neplatí, tak cokoliv je už jen nějaké špatné řešení.
-
MJ (neregistrovaný)
Nehanil bych tak kategoricky použití VARCHAR2 u Oracle v klíčích. Oracle má čísla uložená v BCD a žádný int, nebo byte nezná. Uložení toho stejného klíče uloženého jako VARCHAR2 je max 2× delší než NUMBER. Dám ruku do ohně, že v ta aplikace umřela kvůli něčemu jinému, než jsou klíče ve VARCHAR2. Tipuju na blbý model zamykání. Na tom lidé v ORACLU pohoří mnohem častěji.
Podílel jsem se na vývoji aplikace, kde jedním z požadavků bylo, že musíme být schopni data oddělit, respektive mergovat z jiné pobočky a rozhodovali jsme se jaký budeme vytvářet klíče a rozhodli jsme se, že klíč bude obsahovat id pobočky a id objektu. A protože jsme potřebovali věti než 32b čísla, tak jsme volili VARCHAR, protože byť ORACLE dokázal uložit číslo s libovolnou přesností, myslím, že jsme potřebovali 12cifer, nedokázali jsme čísla s touto přesností zpracovat mimo databázi. Rozdělit klíč do dvou polí jsme nechtěli z důvodu horší čitelnosti kódu a chybám. Báli jsme se, že na jedné pobočce to fungovat bude a až je sloučíme, tak to přestane, protože se někde zapomenou použít klíče v páru. Dělal jsem tehdy výkonnostní testy (také dnes málokdo provádí) a výsledkem bylo, že použití VARCHAR2 klíče je jenom o 20% pomalejší než čísla.
Měl jsem kolegu, který v SQL ke třídění používal GROUP BY místo ORDER BY. Prostě to našel viděl, vyzkoušel a všiml si, že výsledek je pak seřazen. Když jsem to viděl šel jsem do kolen.
Jinak databázové aplikace jsou pěkný příklad toho, že je velice vhodné znát architekturu a jak to vevnitř pracuje. Pokud to neznáte a navrhnete aplikaci tak, že databáze je pouze uložiště dat, tak to velice dlouho může fungovat a jak se zvyšují objemy, tak se to jednou složí a oprava je složitá, nebo i nemožná. -
_dworkin (neregistrovaný)
Heh, podle poctu prispevku nize koukam ze „poukovani“ her byla oblibena zabava vsech majitelu ZX :)
Puvodni clanek z MIKROBAZE 03 (1986)
http://img62.imageshack.us/img62/4881/mikrobaze03341986.jpg
http://img51.imageshack.us/img51/2602/mikrobaze03351986.jpg
http://img195.imageshack.us/img195/306/mikrobaze03361986.jpg
http://img13.imageshack.us/img13/9924/mikrobaze03371986.jpg
http://img717.imageshack.us/img717/6789/mikrobaze03381986.jpg
PS: nemam scaner ani fotak tak pred chvili foceno mobilem.. -
jarous (neregistrovaný)
Novější programy měly jen BASICový zavaděč a přímo v něm strojový kód, který zaváděl bezhlavičkový záznam. Ten kód byl třeba v REM řádce, nebo se pomocí READ-DATA a smyčky někam napoukoval a spustil.Tak nešlo poukovat v BASICU. Pak se POKE pro hry musely provést až po doběhu tohoto strojákového zavaděče. Já to dělal tak,že jsem modifikoval odskok s konce zavaděče na poke-program, který jsem ve strojáku vkládal přímo do obrazovky ( kde nepatrně narušil obr. ) a pak skok na hru.
Největší výzva byly hry, které se nahrávaly v celku i s obrázkem a cestou plynule přepsaly stejným ( skoro ) kódem zavaděč i zásobník a loader končil instrukcí RET. Dokonce jsem se setkal se hrou, která se nahrávala v jednom bloku, po nahrátí zavaděče se tento aktivoval a chytil data z pásku letmo, bez nějakého zaváděcího tónu. Tyto hry se daly kopírovat jen kopírovacímy programy s komprimací ( třeba TF-kopy ).
Tohle všechno mi v paměti udkvělo, ale jak se jmenovaly ty hry , které jsem „poukoval“ už si nevzpomenu. Stejně jsem tím strávil víc času než hraním. -
Cygnus (neregistrovaný)
Podobný trik se používá třeba v TRDOSových booterech. Principielně to funguje tak, že je jeden BASICový řádek a jedna proměnná třeba a$ v níž je uložený stroják. Po načtení BASICu se provede RANDOMIZE USR na adresu a stroják se spustí, modifikuje BASICový řádek podle toho, co uživatel udělá a nakonec se vrátí zpět, provede CLEAR, čímž sám sebe odstraní a zbyde jen výsledný příkaz, kterým se spustí zvolený program z diskety.
http://cygnus.speccy.cz/popis_cygnusboot.php -
Pavel TišnovskýZlatý podporovatel
Dik za odkazy. Jsou to stejne informace jako v manualu „Kladivo na programy“ (taky pro speccy)?
-
_dworkin (neregistrovaný)
Nerozumim presne otazce. Ale Kladivo na programy http://www.grandjihlava.cz/tmp/kladivo.pdf obsahuje v podstate totozne informace. (dokonce to nekdy vypada ze jeden z nich od druheho opisoval)
-
Pavel TišnovskýZlatý podporovatel
Presne tak jsem to myslel, protoze Kladivo na programy je imho docela znama literatura ke Spectru.
-
_dworkin (neregistrovaný)
Hmm tak na netu nakonec jsou ty Mikrobaze.
http://www.mikrobaze03.szm.com/ -
_dworkin (neregistrovaný)
To jsem si mohl usetrit praci.. No pokud chce nekdo prvni i s dotaznikem tak je:
http://rapidshare.com/files/402406540/mikrobaze1.pdf.html jen 10 stazeni..
http://?????.wz.cz/mikrobaze1.pdf a tady to taky nemusi byt dlouho .) -
klusacek (neregistrovaný)
Je legracni jak si tenkrat nekteri predstavovali dalsi vyvoj pocitacu:
http://www.mikrobaze03.szm.com/imagepages/p12.html
Ze budem mit za 20 let transistory mensi nez vlnova delka svetla je asi nenapadlo ani ve snu.
Dnes se optika hodi spis na propojovani jader na chipu, jak se o to snazi IBM. -
Pavel TišnovskýZlatý podporovatel
„Současná technologie doslova vydupala z polovodičových čipů jejich praktické maximum“ – je psali v roce 1985?
-
Pavel TišnovskýZlatý podporovatel
nejsem sice spectrista, ale mozna sis v loaderu vypsal ten posledni znak „I“ a potom nechal na ROM subrutine udelat zbytek?
-
ondra.novacisko.cz (neregistrovaný)
Nikoliv. Ale využil jsem to co je popsáno v článku.
Začátek slova je TAB, což je klíčové slovo a jednom bajtu. Bohužel za TAB je mezera, takže musí následovat zpětná mezera. Výsledkem je tedy
TAB,bk,U,L,K,O,V,A,N,I
má 10 bajtů :-)
Chtěl jsem navázat tím, že tohle býval hodne používaný trik i u her. Nevím už co to bylo za hru, ale pamatuji si napis
Program: GO TO HELL!!! -
Pavel TišnovskýZlatý podporovatel
Aha, pekne reseni :-), to me nenapadlo (Atarko to melo jinak, tam byl Basic od loaderu, konkretne Turba 2000, uplne oddelenej, ale poukovani se samozrejme taky delo pri prevodu do formatu Turba)
jeste bych to rozsiril na LET'S GO TO HELL :-)
Popremyslim o dalsich vetach, ktere jdou slozit ze Sinclair Basicovych prikazu… -
Cygnus (neregistrovaný)
Což mi připomíná zavaděč hry Heroes od George'K, kde byl vylistovatelný tuším jen jeden řádek obsahující REM IF NOT THEN CAT & DOG … a zbytek programu byl ukrytý :-) … ale už jsem to dlouho neviděl, možná si to pamatuju blbě.
Samotná hra Heroes 92' byla soutěžní k 10 letům existence ZX Spectra a kromě samotného řešení hry obsahovala ještě jednu „crackerskou soutěž“ v podobě velmi důmyslné ochrany. Ovšem nikoli proti kopírování, ale proti analýze samotného programu a dat. Po skončení soutěže autor podrobně vysvětlil, jak ochrana funguje – je to v nějakém ZX magazínu z roku 1993.
