Komentowana treść: RNOArchive
14.06.2021 14:08
[#1]
Re: RNOArchive
Ten program jest totalnie skopany. Binarka dla OS3 zajmuje ponad 3MB. Binarka MUIUnArc to poniżej 24KB. Ki diabeł?
14.06.2021 14:23
[#2]
Re: RNOArchive
@Cedrat, post #1
Wersja w Hollywood wpisuje się w nowoczesne metody tworzenia aplikacji. W świecie „prawdziwych, dorosłych” platform dzisiejszy byle program do notatek zajmuje znacznie więcej RAMu i dysku niż soft na któryn powstawało np. „Toy Story”.
Chcieliśmy nowoczesności to mamy nowoczesność.
A to jeszcze nie jest świat webowy. Ten to dopiero potrafi sponiewierać RAM i CPU. W świecie natywnych aplikacji jednostką pamięci jest bajt. W świecie webowym - megabajt. I to często nie jest wina developerów tylko technologii, trendów w takim programowaniu, wymuszonej architektury, (pseudo)uniwersalności rozwiązań.
Ostatnia aktualizacja: 14.06.2021 14:26:05 przez MDW
Chcieliśmy nowoczesności to mamy nowoczesność.
A to jeszcze nie jest świat webowy. Ten to dopiero potrafi sponiewierać RAM i CPU. W świecie natywnych aplikacji jednostką pamięci jest bajt. W świecie webowym - megabajt. I to często nie jest wina developerów tylko technologii, trendów w takim programowaniu, wymuszonej architektury, (pseudo)uniwersalności rozwiązań. Ostatnia aktualizacja: 14.06.2021 14:26:05 przez MDW
14.06.2021 14:45
[#3]
Re: RNOArchive
@MDW, post #2
„wpisuje się w nowoczesne metody tworzenia aplikacji” - TextEdit z OS 3.2 nie zajmuje jakichś kolosalnych ilości pamięci na kod. IBrowse 2.5 też nie. Nawet DOSBox na Amigę to poniżej 900KB kodu, DukeNukem 3D niewiele więcej. Archiwum stosu TCP/IP RoadShow zajmuje grubo poniżej 2MB.
Połknięcie 3MB na kod GUI dla archiwizerów to to nie jest normalne, no kurde.
Ostatnia aktualizacja: 14.06.2021 14:45:59 przez Cedrat
Połknięcie 3MB na kod GUI dla archiwizerów to to nie jest normalne, no kurde.
Ostatnia aktualizacja: 14.06.2021 14:45:59 przez Cedrat
14.06.2021 15:09
[#4]
Re: RNOArchive
@Cedrat, post #3
Też tak uważam. Ale odpal podobny program pod macOS czy Windows i zobacz w jakimś Activity Monitor czy Task Manager ile RAMu zajmuje. Wcale się nie zdziwię gdy to będzie 100MB. 
Zresztą aplikacje dla iOS czy Android dokładnie tak samo. To jest dzisiejsza norma. Nowoczesność...
A jeżeli chodzi o soft pod Hollywood to pewnie jest dolinkowna jakaś biblioteka będąca warstwą pośredniczącą między aplikacjami napisanymi w hollywoodzkim skrypcie, a systemem operacyjny. To jest cena uniwersalności. Gdy się kompilowało programy w AMOSie to też mogła być dołączana biblioteka amos.library (chociaż była opcja niedołączania jej ale wtedy musiała być w LIBS:). Takie rozwiązania to są taki minisystemy działające w obrębie systemu często dublujące, nadpisujące natywne funkcje systemu operacyjnego. To są takie prawie samowystarczalne "państwa w państwie". Dzięki temu kilkoma ruchami ręki, przy zachowaniu pewnych zasad, robione są wersje na tak różne systemy operacyjne. Hollywood to taki trochę AMOS naszych czasów. O tyle lepszy, że powstałe aplikacje działają pod systemem. No ale inne rozwiązanie dzisiaj by nie przeszło na tak zwanych amigowych systemach "nowej generacji". To już nie czasy A500, którą można (chociaż nie trzeba) było traktować jak Atari XL/XE i rzeźbić kod jak na ośmiobitowcach.
Ostatnia aktualizacja: 14.06.2021 15:12:10 przez MDW
Zresztą aplikacje dla iOS czy Android dokładnie tak samo. To jest dzisiejsza norma. Nowoczesność... A jeżeli chodzi o soft pod Hollywood to pewnie jest dolinkowna jakaś biblioteka będąca warstwą pośredniczącą między aplikacjami napisanymi w hollywoodzkim skrypcie, a systemem operacyjny. To jest cena uniwersalności. Gdy się kompilowało programy w AMOSie to też mogła być dołączana biblioteka amos.library (chociaż była opcja niedołączania jej ale wtedy musiała być w LIBS:). Takie rozwiązania to są taki minisystemy działające w obrębie systemu często dublujące, nadpisujące natywne funkcje systemu operacyjnego. To są takie prawie samowystarczalne "państwa w państwie".
Dzięki temu kilkoma ruchami ręki, przy zachowaniu pewnych zasad, robione są wersje na tak różne systemy operacyjne. Hollywood to taki trochę AMOS naszych czasów. O tyle lepszy, że powstałe aplikacje działają pod systemem. No ale inne rozwiązanie dzisiaj by nie przeszło na tak zwanych amigowych systemach "nowej generacji". To już nie czasy A500, którą można (chociaż nie trzeba) było traktować jak Atari XL/XE i rzeźbić kod jak na ośmiobitowcach.Ostatnia aktualizacja: 14.06.2021 15:12:10 przez MDW
14.06.2021 16:58
[#6]
Re: RNOArchive
Faktycznie tworzenie archiwum jest bajecznie proste. Jednakże coś jest skopane, ponieważ po uruchomieniu wyświetlało mi komunikat "Failat - nie znane polecenie", mimo iż jest ono w ROMie. Wrzuciłem więc to polecenie do C, z jakiejś starej kopii OS3.0 w tedy pojawił się inny komunikat w stylu "LHA - nie odnaleziono archiwum". Za jakiś czas na Aminecie pojawiła się paczka zawierająca wersję dla OS3.2 i ta działa u mnie dobrze, pod OS3.9.4. Natomiast gdzieś czytałem, że programy stworzone w Hollywood będą trochę ważyć, ponieważ skrypt HWS jest pakowany razem z grafikami, dźwiękami, czcionkami i samym playerem w jeden plik. Kiedyś jak bawiłem się w AmigaBASIC to istniała możliwość zapisu listingu razem w jeden plik. Tu jest podobnie.
Przecież to program "wyklikany" w Hollywood więc czego się spodziewałeś? 
17.06.2021 12:45
[#9]
Re: RNOArchive
@Cedrat, post #1
Excuse my Polish, but I wanted to explain little about the filesize :)
Hollywood is a scripting language, which always needs an interpreter program to run the programs made with it. Or actually when you distribute a program, a player program is needed to run the programs that are compiled to applets (which are in Hollywood bytecode). The player program is about 2.5MB on Amiga 68k nowadays, it has grown a bit during the years, but as the player program has to be able to handle all the features Hollywood offers, it's actually quite small still.
There are two options for a 3rd party developer then, either release your programs as applets and require users to have the Hollywood Player installed in their system OR link the whole player into your executable to bypass the previous requirement. I have chosen to link the player in my programs to make them more stand-alone. In RNOArchive's case I also decided to link even the three required Hollywood plugins (MUI, ZIP, XAD) into the executable to make it more dependency free solution this time. The exe can be placed alone anywhere you want now and you don't have to have plugins in the progdir or libs.
Source code size for the program is currently under 70kB, and I could compile it to an applet that's size would be under 30kB and spread that, but then users would need to install more stuff in their system. I have thought that it's easier to bundle everything I can into a single executable, because I think that HD space isn't an issue nowadays.
This program was requested to be made for AROS, where they lack this kind of program, so it's targetted more to NG platforms and is a bit resource hungry on 68k. But as I code with Hollywood, programs can be released for other platforms too as a by-product. So, why not, even if it may require a bit more than just a standard classic Amiga.
And if I get requests to release my programs as small applets, I can do that too. I've just preferred to release them as all-inclusive solutions for easiness, but sacrificing on executable and archive sizes.
Hollywood is a scripting language, which always needs an interpreter program to run the programs made with it. Or actually when you distribute a program, a player program is needed to run the programs that are compiled to applets (which are in Hollywood bytecode). The player program is about 2.5MB on Amiga 68k nowadays, it has grown a bit during the years, but as the player program has to be able to handle all the features Hollywood offers, it's actually quite small still.
There are two options for a 3rd party developer then, either release your programs as applets and require users to have the Hollywood Player installed in their system OR link the whole player into your executable to bypass the previous requirement. I have chosen to link the player in my programs to make them more stand-alone. In RNOArchive's case I also decided to link even the three required Hollywood plugins (MUI, ZIP, XAD) into the executable to make it more dependency free solution this time. The exe can be placed alone anywhere you want now and you don't have to have plugins in the progdir or libs.
Source code size for the program is currently under 70kB, and I could compile it to an applet that's size would be under 30kB and spread that, but then users would need to install more stuff in their system. I have thought that it's easier to bundle everything I can into a single executable, because I think that HD space isn't an issue nowadays.
This program was requested to be made for AROS, where they lack this kind of program, so it's targetted more to NG platforms and is a bit resource hungry on 68k. But as I code with Hollywood, programs can be released for other platforms too as a by-product. So, why not, even if it may require a bit more than just a standard classic Amiga.
And if I get requests to release my programs as small applets, I can do that too. I've just preferred to release them as all-inclusive solutions for easiness, but sacrificing on executable and archive sizes.
17.06.2021 19:11
[#10]
Re: RNOArchive
@jPV, post #9
Czyli jest tak, jak napisałem wyżej. Skrypt razem z Hollywood Playerem i całą resztą jest kompilowany w jeden plik wykonywalny. Autor mógłby opublikować go w formie appletu, czyli pliku HWA i użytkownicy uruchamiali by go za pomocą playera. W tedy jednak nie ma mowy np. o podpięciu go pod DefIcons.
Ja nie narzekam, wręcz cieszę się, że ktoś cokolwiek robi dla Amigi, w dodatku non-profit.
Ostatnia aktualizacja: 17.06.2021 19:12:33 przez Ponki1986
Ja nie narzekam, wręcz cieszę się, że ktoś cokolwiek robi dla Amigi, w dodatku non-profit.
Ostatnia aktualizacja: 17.06.2021 19:12:33 przez Ponki1986
