Czy jest jakaś przyczyna (poza estetyką), dla której nie używa się powszechnie skrótów (CRC-32 lub podobnych) opisując, publikując i katalogując wersje gier i programów?
Szczególnie ważne wydaje mi sie to dla dyskietek z DOS-em, języków programowania, użytków do kopiowania itp. Istnieją wersje shackowane, jakieś składankowe, zepsute kopiowaniem, zrzucane z uszkodzonych nośników...
Ludzie wydają kolejne wersje nowych produktów, stare fruwają w milionie nazw i konwencji (wiem, mamy tu konwencje TOSEC i Kaz'a). Na pigwie coś się nazywa jakoś, na prywatnej stronie jakoś. A plik ten sam. Albo w jednej z wersji ZWALONY. Uważam, że opisując w artykule jakąś precyzyjną wersję produktu dobrze wrzucać skrót.
Ja uważam, że MD5 jest super i możnaby to zautomatyzować - i poszukać duplikatów systemowo. Ale mamy 2 problemiki: - ktoś musi to zrobić :) - powyższy problem z wyliczeniem tego dla poszczególnych plików na dyskietce (o ile są)
i kto to zapisze, przecież długopisy są drogie, takie narzędzie koniecznie musi nas w tym wyręczyć, musi zapisać do pliku tekstowego nazwe pliku i sumę kontrolną dla niego
Ale pytanie - po co, żeby było? mi brakuje bardziej informacji, że dany program działa lub ma błąd. Takiej informacji nie ma w atarionline.pl, ale jest u homesoft, gdzie wszystkie publikowane programy raczej na pewno działają.
Podaję rzeczywisty scenariusz. Mam kupę różnych Forth-ów. Zabawa z edytorem powoduje często zmianę na dysku (niechcianą), więc chcę mieć pewność czy działam na niezmienionym pliku.
Wymyśliłem tak: - tworzę swoją kartę SD z ATR-ami, XEX itp - na PC odpalam generowanie CRC dla wszystkich plików XEX, ATR itp, skróty lądują w pliku tekstowym (do odczytu na Atari) - i teraz by się prosiło aby użyć generowania CRC spod SDX, ale pliki ATR to tylko kontenery, SDX potrzebuje pliku - alternatywa to zmiana w softcie typu SDrive albo Config FujiNeta... i info czy / kiedy plik się zmienił w stosunku do oryginału (wymaga przeliczenia, może trwać) - FN ma moc, mógłby to robić (przy ściągnięciu pliku ściągać też CRC, pokazywać przy wybranej stacji czy plik się zmienił), oczywiście musiałbym sam to napisać na ochotnika
Wiem że wymyślam trochę bzdury ale kombinuję jakie są możliwości w "toolchainie". Nie zawsze chcemy mieć plik RO ale info czy mamy originalny plik czy zmieniony jest chyba ważny dla celów archiwalno-zabawowych?
CRC-32 by Russ Gilbert; press "F" to generate an output file (*.DAT is an ATASCII textfile). The program will generate a CRC-32 for every file on the diskette or ATR image (COM/XEX, BAS, PIC, SND, SMP, etc.) and save it as a .DAT file ( = textfile, you may simply rename it to *.TXT).
Tested with DOS II types, like DOS 2.0, DOS 2.5, XDOS, DOS II+D, MyDOS, etc., but unsure and untested if it also works under SDFS (SpartaDOS, SDX, BeweDOS, RealDOS). Also never tested with subdirs nor large 16MB and 32MB partitions (find out yourself).
Program works only with filedisks / diskfiles, does NOT work with bootdisks (also does not work with LiteDOS, DOS 3, DOS 4, DOS XE). It skips DIR remarks or special entries on DOS II type disks with 000 sectors length.
-----
I love packers and crunchers. In the past I packed A8 programs with Bewesoft's Superpacker, then I used Code3-Cruncher, then DJ-Packer and currently Superpacker/Exomizer by TeBe. So it would e.g. be possible to have one and the same A8 program a) unpacked, b) packed with Superpacker, c) packed with one of several Code3-Crunchers, d) packed with DJ-Packer 1, e) packed with DJ-Packer 2, f) packed with Exomizer - and allthough all of these packed files had the same unpacked sourcefile, these packed versions will generate different CRC numbers. So only a human would be able to see that these files are actually the same (only packed with different packers), while a computer program or CRC-checker would not be able to see this...
