Moje dwa grosze na temat tego stareńkiego programiku.

Według mnie program wymaga sporo pracy a w zasadzie przepisania go od nowa. Główny powód dla mnie to powtórzenia. Mi utrudniają one czytelność i musze sprawdzić czy przypadkiem autor nie zapomniał czegoś zamknąć (jakieś biblioteki na ten przykład). Nie wiem czemu autor uskutecznia cały ten maxsize(t) zamiast użyć AvailMem(MEMF_TOTAL), chyba że się mylę to proszę mnie poprawcie. Program ma błąd przy case CLOSEWINDOW, brakuje WaitIO((struct IORequest*)&timereq) zaraz po AbortIO. Bo na przykład mogą przyjść dwa sygnały równocześnie. Ten cały case CLOSEWINDOW jest zły. Przypuśćmy że mamy kilka wiadomości, odbieramy CLSOEWINDOW i radośnie kończymy program.
Oczywiście + to co cholok napisał.

To tak na szybko po szybkiej analizie.

nie mogl uzyc flagi MEMF_TOTAL bo jej nie ma w ks1.3 - pojawila sie dopiero w 2.0

@docent
Dzięki, teraz rozumiem skąd ten kawałek kodu maxsize(t).

@_arti
Z tego co wiem w TinyMeter jest katalog nostalgic i tam jest TinyMeter 1.0, trzeba by sprawdzić czy działa pod kick1.3, może ta pchełka Ci wystarczy a jak nie to trzeba zakasać rękawy.

namiastka = ubogi w opcje != ubogo napisany

Nie znamy alternatyw, ale może wyjść tak, że 90% kodu będzie Twoje, a wtedy fajnie jakby drobiazgi były dopracowane, bo zakładanie, że ktoś nie będzie miał więcej jak 4MB RAM brzmi trochę prowizorycznie :) (skalowanie paska zapewne zmieści się w jednej linijce obliczeń). Możliwe, że z takiego drobnego bajeru chętnie skorzystaliby i właściciele bardziej dopalonych sprzętów, więc nawet możesz prowadzić ten projekt tutaj (+github ewentualnie), z pewnością jakichś wskazówek będziesz potrzebował.

Ja sądzę, że skoro program ma działać na 1.3, to warto (najpierw) dopracować kwestię parametrów dla 1.3. Padło tu kilka propozycji - argc/argv, ARP.library, ToolTypes. Przyda Ci się to też na potrzeby innych utilków dla 1.3.

Według mnie najwygodniej dla użytkownika jest użyć ToolTypes w ikonce z pomocą icon.library. Należy skorzystać z funkcji FindToolType()

Jeżeli potrzebujesz tu pomocy, to może któryś z kolegów poda Ci gotowy przykład, ja podałem dla ReadArgs().

Co do jakości kodu GfxMem, to moim zdaniem spełnia on kryteria, które określam jako dobry styl programowania (i tę cechę posiada wiele spośród poznanych przeze mnie programów z dysków Freda Fisha).

Jakieś niedociągnięcia w każdym programie mogą się znaleźć. Oczywiście zauważone błędy w działaniu, o których wspominają koledzy (funkcja skalująca, kwestia WaitIO itp.) - powinno się poprawić.

Sam nie sprawdzałem kodu programu pod kątem poprawności, tylko szukałem w nim miejsc, które należy zmodyfikować. Pozostają jeszcze te funkcje _main() i _exit(), ale ich korekta nie powinna nastręczać trudności.

Zaletą GfxMem jest jego prostota. Służy tylko konkretnemu celowi.

Bo np. na dysku 111 Freda Fisha znalazłem program AmyLoad, który też zawiera kod źródłowy, ale jest kombajnem, korzysta z własnego device i z tego co przeczytałem wyświetla zajętość CPU, Blittera i pamięci.

Podobnych programów jest zapewne więcej.

Trzeba wybierać między prostotą a skomplikowanym w zarządzaniu programem. Zależy to też od Twoich potrzeb, ale chyba je już określiłeś?

Dodam, że ze starszymi programami jest tylko zazwyczaj problem ze standardem K&R, który poprzedza ANSI. GfxMem i inne programy z tego okresu są w K&R. Jednakże Amigowe kompilatory powinny sobie z tym standardem poradzić.

To, że te programy są starsze nie implikuje z góry, że są napisane w złym stylu bądź niepoprawnie. Dowodem są takie pakiety jak np. Adventure Definition Language (ADL) z lat 80., który według mnie jest świetnie zrealizowany.

Ostatnia aktualizacja: 15.10.2021 17:47:25 przez Hexmage960