Komentowana treść: OWB 1.10 (1.12)
21.02.2008 18:47
[#123]
Re: OWB 1.10 (1.12)
@MinisterQ, post #119
AOS4: Rozszerzone o nowe właściwości i komponenty GUI,
MOS: tak jak w 3.1 + dodatkowo nie systemowe MUI,
AOS4: Nowy system zarządzania pamięcią - nie wszystkie aplikacje to przeżyły,
MOS: tak jak w 3.1,
AOS4: Nowy interfejs bibliotek wprowadzający przestrzenie nazwy,
MOS: tak jak w 3.1 - nadal problem z powtarzającymi się nazwami.
Znalazło by się pewnie więcej przykładów jakby dokładniej się przyjrzeć dodatkowo sam MOSTim pisał, że chodzi o kompatybilność na poziomie 3.1 bo 3.5 i 3.9 z powodów ideologicznych były dla nich niefajny (ach te urażone ambicje no i pieniądze za MUI).
MOS: tak jak w 3.1 + dodatkowo nie systemowe MUI,
AOS4: Nowy system zarządzania pamięcią - nie wszystkie aplikacje to przeżyły,
MOS: tak jak w 3.1,
AOS4: Nowy interfejs bibliotek wprowadzający przestrzenie nazwy,
MOS: tak jak w 3.1 - nadal problem z powtarzającymi się nazwami.
Znalazło by się pewnie więcej przykładów jakby dokładniej się przyjrzeć dodatkowo sam MOSTim pisał, że chodzi o kompatybilność na poziomie 3.1 bo 3.5 i 3.9 z powodów ideologicznych były dla nich niefajny (ach te urażone ambicje no i pieniądze za MUI).
21.02.2008 18:57
[#125]
Re: OWB 1.10 (1.12)
@wali7, post #120
Akurat tak się składa, że kilka osób już Ci tłumaczyło, że to Ty nie masz racji a wciąż się upierasz przy swoim mimo, iż nie jesteś w stanie podać żadnych rzeczowych argumentów. Jak tak bardzo chcesz uruchamiać aplikacje z AOS4 to go kup a nie żeruj na cudzej pracy. Jeżeli autor OWB uzna, że chce zrobić wersję dla MOSa to ją zrobi to naprawdę nie jest problem.
21.02.2008 19:45
[#128]
Re: OWB 1.10 (1.12)
@smith, post #123
AOS4: Rozszerzone o nowe właściwości i komponenty GUI,
MOS: tak jak w 3.1 + dodatkowo nie systemowe MUI,
Oba rozwiązania są w taki sam sposób systemowe. MUI opiera się na mechaniźmie który udostępnia OS, i działa na wszystkich amigowych systemach, również pod OS4.
Nowe właściwości i komponenty w reaction GUI - owszem, tu różnice są, ale nie wiem czy to może być brane pod uwagę jako argument odmienności OS4 od 3.1 na tle braku odmienności MOSa od 3.1 pod tym względem - MOS też ma nowe komponenty GUI i właściwości, i pod tym kątem również nie trzyma się "na siłę" kompatybilności z 3.1.
AOS4: Nowy system zarządzania pamięcią - nie wszystkie aplikacje to przeżyły,
MOS: tak jak w 3.1,
Eno, sorry, ale te aplikacje nie przeżyły tego tylko z powodu iż były źle napisane, i grzebały w systemowych bebechach! Nowy system zarządzania pamięcią niczego nie zmienił w API, i zmiany nie dotknęły w żaden sposób tego co było napisane prawidłowo.
Nie jestem pewien czy te same aplikacje robiąc podobne rzeczy miały by racje bytu pod MOSem (kwestie pamiętania wskaźnika pamięci przez AllocVec())
AOS4: Nowy interfejs bibliotek wprowadzający przestrzenie nazwy,
MOS: tak jak w 3.1 - nadal problem z powtarzającymi się nazwami.
Tu nie jestem do końca pewien, ale morgoth mi kiedyś pokazywał nowy interfejs dla bibliotek który również "ma wyjść" razem z 2.0. Jednakowoż nie wiem czy, i jak jest tam rozwiązana kwestia przestrzeni nazw. Ale wiadomo jak jest z nowym MOSem, więc tu nie ma o czym się rozwodzić.
Tu można by przyznać rację, jednakowoż na chwilę obecną i tak nic nie wykorzystuje tego mechanizmu (widział ktoś bibliotekę OS4 która wykorzystuje inny interfejs niż "main"?), a wszystkie aplikacje z OS3.x daje się bez większych przeróbek kompilować na OS4.
MOS: tak jak w 3.1 + dodatkowo nie systemowe MUI,
Oba rozwiązania są w taki sam sposób systemowe. MUI opiera się na mechaniźmie który udostępnia OS, i działa na wszystkich amigowych systemach, również pod OS4.
Nowe właściwości i komponenty w reaction GUI - owszem, tu różnice są, ale nie wiem czy to może być brane pod uwagę jako argument odmienności OS4 od 3.1 na tle braku odmienności MOSa od 3.1 pod tym względem - MOS też ma nowe komponenty GUI i właściwości, i pod tym kątem również nie trzyma się "na siłę" kompatybilności z 3.1.
AOS4: Nowy system zarządzania pamięcią - nie wszystkie aplikacje to przeżyły,
MOS: tak jak w 3.1,
Eno, sorry, ale te aplikacje nie przeżyły tego tylko z powodu iż były źle napisane, i grzebały w systemowych bebechach! Nowy system zarządzania pamięcią niczego nie zmienił w API, i zmiany nie dotknęły w żaden sposób tego co było napisane prawidłowo.
Nie jestem pewien czy te same aplikacje robiąc podobne rzeczy miały by racje bytu pod MOSem (kwestie pamiętania wskaźnika pamięci przez AllocVec())
AOS4: Nowy interfejs bibliotek wprowadzający przestrzenie nazwy,
MOS: tak jak w 3.1 - nadal problem z powtarzającymi się nazwami.
Tu nie jestem do końca pewien, ale morgoth mi kiedyś pokazywał nowy interfejs dla bibliotek który również "ma wyjść" razem z 2.0. Jednakowoż nie wiem czy, i jak jest tam rozwiązana kwestia przestrzeni nazw. Ale wiadomo jak jest z nowym MOSem, więc tu nie ma o czym się rozwodzić.
Tu można by przyznać rację, jednakowoż na chwilę obecną i tak nic nie wykorzystuje tego mechanizmu (widział ktoś bibliotekę OS4 która wykorzystuje inny interfejs niż "main"?), a wszystkie aplikacje z OS3.x daje się bez większych przeróbek kompilować na OS4.
21.02.2008 23:09
[#132]
Re: OWB 1.10 (1.12)
@smith, post #125
Co najmniej równie duża grupa osób tłumaczy Ci z kolei, że Ty nie masz racji. :) I co z tego wynika? Niewiele, bo faktów nie ustala się w plebiscytach.
Proszę, podaj pod tym postem rzeczowe argumenty, że ta konkretna (opisana przez itixa) zmiana API w OS4 nie jest wymierzona przeciwko MOSowi, ale coś (konretnie co) daje.
Udowodnij, że twórcy OS4 mają prawo (nie, nie moralne) wymusić na deweloperach softu dla OS4 brak kompatybilności binarek z Morphosem.
Bo mimo bardzo wielu wypowiedzi w tym wątku, nie potrafiłeś ww rzeczy przekonująco uzasadnić. Jedyne co wynika z Twoich postów, to to, że zdajesz się wierzyć w to co piszesz. Ale w to nie wierzę...
Ostatnia edycja: 21.02.08 23:16:48
Proszę, podaj pod tym postem rzeczowe argumenty, że ta konkretna (opisana przez itixa) zmiana API w OS4 nie jest wymierzona przeciwko MOSowi, ale coś (konretnie co) daje.
Udowodnij, że twórcy OS4 mają prawo (nie, nie moralne) wymusić na deweloperach softu dla OS4 brak kompatybilności binarek z Morphosem.
Bo mimo bardzo wielu wypowiedzi w tym wątku, nie potrafiłeś ww rzeczy przekonująco uzasadnić. Jedyne co wynika z Twoich postów, to to, że zdajesz się wierzyć w to co piszesz. Ale w to nie wierzę...
Ostatnia edycja: 21.02.08 23:16:48
22.02.2008 22:08
[#134]
Re: OWB 1.10 (1.12)
@wali7, post #132
Prawda lezy po srodku.Zabezpieczenia robi sie przewaznie dla konkurencji,a jedyna konkurencja jest tu MOS.Smieszy troszke calosc sytuacji.Systemy niszowe,ktore sa praktycznie ignorowane przez caly swiat.Newsy o nich sa podawane w formie ciekawostek.Dla mnie MOS czy AOS4 nie sa produktami stricte marketingowymi.To jest tylko krzyk w morzu chaosu informatycznego ;) .
Hyperion zabezpiecza swoj produkt paranoicznie.To sie zdaje psu na bude,bo co sie zakodowalo da sie rozkodowac.Po drugie,przy tak malym rynku to jest poprostu smieszne.
Niech Hyperion swoje a os4emu swoje.Po drugie co za problem napisac soft ktory wezmie binarke i usunie zabezpieczenie.Jezeli jest to w clibie wiec mozna ta czesc kodu namierzyc i izolowac.Zaden problem robic to w zaciszu swojego komputera(poprzez jakis program) a nie udostepniac zmodyfikowane binarki...
Hyperion zabezpiecza swoj produkt paranoicznie.To sie zdaje psu na bude,bo co sie zakodowalo da sie rozkodowac.Po drugie,przy tak malym rynku to jest poprostu smieszne.
Niech Hyperion swoje a os4emu swoje.Po drugie co za problem napisac soft ktory wezmie binarke i usunie zabezpieczenie.Jezeli jest to w clibie wiec mozna ta czesc kodu namierzyc i izolowac.Zaden problem robic to w zaciszu swojego komputera(poprzez jakis program) a nie udostepniac zmodyfikowane binarki...
25.02.2008 16:07
[#137]
Re: OWB 1.10 (1.12)
@Drako^lM, post #126
.so Ci przeszkadza w AOS4 a ELF w MOSie nie? Pliki z rozszerzeniem .so nie występują tylko w linuxie więc nie wiem dlaczego niby AOS4 miałby się linuxowić. Poza tym lepiej napisać loadera dla nich niż przerabiać każdą potrzebną bibliotekę na .library i być w związku z tym zawsze dwie wersje do tyłu bo nie będzie miał kto tego zrobić.
25.02.2008 16:19
[#139]
Re: OWB 1.10 (1.12)
@MinisterQ, post #128
Oba rozwiązania są w taki sam sposób systemowe. MUI opiera się na mechaniźmie który udostępnia OS, i działa na wszystkich amigowych systemach, również pod OS4.
Jeżeli jest rozwiązaniem zewnętrznym dublującym funkcjonalność systemu to jest rozwiązaniem niesystemowym. A to, że na kawałku systemu musi się oprzeć jest oczywiste bo inaczej by nie działało.
Eno, sorry, ale te aplikacje nie przeżyły tego tylko z powodu iż były źle napisane, i grzebały w systemowych bebechach!
I o tym właśnie mówię. W AOS4 się tym nie przejmowano (i bardzo dobrze) a MOS stara się być kompatybilny z 3.1. Efekt tego będzie niedługo taki jak w Windowsie gdzie też wszystkie błędy i nie udokumentowane cechy wykorzystywane w aplikacjach są zachowywane i jak to na niego wpływa wszyscy widzą. A należy takie rzeczy eliminować bo jak za długo posiedzą w systemie to "wchodzą" do API i jest coraz trudniej z nich zmigrować.
Jeżeli jest rozwiązaniem zewnętrznym dublującym funkcjonalność systemu to jest rozwiązaniem niesystemowym. A to, że na kawałku systemu musi się oprzeć jest oczywiste bo inaczej by nie działało.
Eno, sorry, ale te aplikacje nie przeżyły tego tylko z powodu iż były źle napisane, i grzebały w systemowych bebechach!
I o tym właśnie mówię. W AOS4 się tym nie przejmowano (i bardzo dobrze) a MOS stara się być kompatybilny z 3.1. Efekt tego będzie niedługo taki jak w Windowsie gdzie też wszystkie błędy i nie udokumentowane cechy wykorzystywane w aplikacjach są zachowywane i jak to na niego wpływa wszyscy widzą. A należy takie rzeczy eliminować bo jak za długo posiedzą w systemie to "wchodzą" do API i jest coraz trudniej z nich zmigrować.
25.02.2008 16:32
[#140]
Re: OWB 1.10 (1.12)
@wali7, post #132
Co najmniej równie duża grupa osób tłumaczy Ci z kolei, że Ty nie masz racji.
Nie chciałbym nikogo dyskryminować ale jest różnica gdy pisze to użytkownik, któremu może zależeć na tym by uruchomić interesującą aplikację na swoim komputerze a developer, którego takie działanie bezpośrednio dotyka.
Proszę, podaj pod tym postem rzeczowe argumenty, że ta konkretna (opisana przez itixa) zmiana API w OS4 nie jest wymierzona przeciwko MOSowi, ale coś (konretnie co) daje.
Chyba nie uważnie czytałeś. Od początku pisałem, że zakładam iż zmiana ta miała właśnie "wyłączyć" OS4emu.
Udowodnij, że twórcy OS4 mają prawo (nie, nie moralne) wymusić na deweloperach softu dla OS4 brak kompatybilności binarek z Morphosem.
To jest ich produkt więc mogą zrobić wszystko a nikt nikogo nie zmusza żeby z niego korzystać.
Bo mimo bardzo wielu wypowiedzi w tym wątku, nie potrafiłeś ww rzeczy przekonująco uzasadnić.
Kilka razy Ci tłumaczyłem jak to jest więc może przeczytaj to jeszcze raz bez emocji i spróbuj zrozumieć. Zauważ że sprawa ta bezpośrednio Ciebie dotyczy a mnie nie dlatego raczej Twoje postrzeganie tego problemu może być wypatrzone a nie moje.
Jedyne co wynika z Twoich postów, to to, że zdajesz się wierzyć w to co piszesz. Ale w to nie wierzę...
A co to ma wspólnego z wiarą? To są fakty.
Nie chciałbym nikogo dyskryminować ale jest różnica gdy pisze to użytkownik, któremu może zależeć na tym by uruchomić interesującą aplikację na swoim komputerze a developer, którego takie działanie bezpośrednio dotyka.
Proszę, podaj pod tym postem rzeczowe argumenty, że ta konkretna (opisana przez itixa) zmiana API w OS4 nie jest wymierzona przeciwko MOSowi, ale coś (konretnie co) daje.
Chyba nie uważnie czytałeś. Od początku pisałem, że zakładam iż zmiana ta miała właśnie "wyłączyć" OS4emu.
Udowodnij, że twórcy OS4 mają prawo (nie, nie moralne) wymusić na deweloperach softu dla OS4 brak kompatybilności binarek z Morphosem.
To jest ich produkt więc mogą zrobić wszystko a nikt nikogo nie zmusza żeby z niego korzystać.
Bo mimo bardzo wielu wypowiedzi w tym wątku, nie potrafiłeś ww rzeczy przekonująco uzasadnić.
Kilka razy Ci tłumaczyłem jak to jest więc może przeczytaj to jeszcze raz bez emocji i spróbuj zrozumieć. Zauważ że sprawa ta bezpośrednio Ciebie dotyczy a mnie nie dlatego raczej Twoje postrzeganie tego problemu może być wypatrzone a nie moje.
Jedyne co wynika z Twoich postów, to to, że zdajesz się wierzyć w to co piszesz. Ale w to nie wierzę...
A co to ma wspólnego z wiarą? To są fakty.
25.02.2008 16:43
[#141]
Re: OWB 1.10 (1.12)
@Drako^lM, post #133
No akurat wolę szybszy procesor od wolniejszego. A swoją drogą poza szybkością to widzisz jakieś różnice gdy używasz Maka na Intelu i PPC? Nie bardzo. Po prostu procesor nie ma znaczenia więc już dawno o PPC powinno się zapomnieć. Skoro dużo większe Apple przeszło na Intela to my powinniśmy to zrobić jeszcze wcześniej i w sumie się tak stało (AROS). Gdyby jeden osobnik nie wymyślił sobie, że będzie pisał MOSa a Amiga inc. została pozostawiona samej sobie to od dłuższego czasu przynajmniej ze sprzętem nie byłoby problemu.
25.02.2008 16:47
[#142]
Re: OWB 1.10 (1.12)
@smith, post #139
Jeżeli jest rozwiązaniem zewnętrznym dublującym funkcjonalność systemu to jest rozwiązaniem niesystemowym.
No pewnie, pod tym kątem to każdą klasę BOOPSI napisaną przez niezależnego developera można tak określić. Tylko że to ma się średnio do praktycznych realiów.
I o tym właśnie mówię. W AOS4 się tym nie przejmowano (i bardzo dobrze) a MOS stara się być kompatybilny z 3.1.
Celowo wyciąłeś dalszą część wypowiedzi, w której wyraziłem wątpliwości, czy ta sytuacja nie dotyczyła również MOSa? Możliwe że nawet wcześniej niż developerzy OS4 dotknęli ten kawałek kodu w systemie.
No pewnie, pod tym kątem to każdą klasę BOOPSI napisaną przez niezależnego developera można tak określić. Tylko że to ma się średnio do praktycznych realiów.
I o tym właśnie mówię. W AOS4 się tym nie przejmowano (i bardzo dobrze) a MOS stara się być kompatybilny z 3.1.
Celowo wyciąłeś dalszą część wypowiedzi, w której wyraziłem wątpliwości, czy ta sytuacja nie dotyczyła również MOSa? Możliwe że nawet wcześniej niż developerzy OS4 dotknęli ten kawałek kodu w systemie.
25.02.2008 16:47
[#143]
Re: OWB 1.10 (1.12)
@AmiChris, post #134
Po drugie,przy tak malym rynku to jest poprostu smieszne.
Raczej jest tym bardziej istotne bo każdy nowy użytkownik się liczy.
Po drugie co za problem napisac soft ktory wezmie binarke i usunie zabezpieczenie.Jezeli jest to w clibie wiec mozna ta czesc kodu namierzyc i izolowac.
I to wskazuje wyraźnie, że teza o tym iż jest to zabezpieczenie jest nieprawdziwa. Gdyby chcieli zabezpieczyć mogliby zrobić to skuteczniej.
Raczej jest tym bardziej istotne bo każdy nowy użytkownik się liczy.
Po drugie co za problem napisac soft ktory wezmie binarke i usunie zabezpieczenie.Jezeli jest to w clibie wiec mozna ta czesc kodu namierzyc i izolowac.
I to wskazuje wyraźnie, że teza o tym iż jest to zabezpieczenie jest nieprawdziwa. Gdyby chcieli zabezpieczyć mogliby zrobić to skuteczniej.
25.02.2008 16:56
[#145]
Re: OWB 1.10 (1.12)
@MinisterQ, post #142
No pewnie, pod tym kątem to każdą klasę BOOPSI napisaną przez niezależnego developera można tak określić.
Nie każda tylko zastępująca to co jest w systemie. Czyli jeżeli napisze labela to zastępuję ale jeżeli napiszę np. źródło danych, które umożliwi mi wyświetlanie zawartości pliku csv w liście to już nic nie zastępuję.
Celowo wyciąłeś dalszą część wypowiedzi, w której wyraziłem wątpliwości, czy ta sytuacja nie dotyczyła również MOSa?
O ile pamiętam pod MOSem to działało.
Nie każda tylko zastępująca to co jest w systemie. Czyli jeżeli napisze labela to zastępuję ale jeżeli napiszę np. źródło danych, które umożliwi mi wyświetlanie zawartości pliku csv w liście to już nic nie zastępuję.
Celowo wyciąłeś dalszą część wypowiedzi, w której wyraziłem wątpliwości, czy ta sytuacja nie dotyczyła również MOSa?
O ile pamiętam pod MOSem to działało.
25.02.2008 18:40
[#147]
Re: OWB 1.10 (1.12)
@smith, post #145
Nawet jeżeli to działało, to to nie jest ŻADEN argument. Zmianie nie uległo API, tylko wewnętrzne bebechy systemu, to bardzo duża różnica.
A co do MUI i kwestii systemowości... Wszystko co działa w zgodzie z wytycznymi systemu operacyjnego jest systemowe, takie jest moje zdanie na ten temat, i w przypadku MUI nie przekonasz mnie że jest inaczej.
A co do MUI i kwestii systemowości... Wszystko co działa w zgodzie z wytycznymi systemu operacyjnego jest systemowe, takie jest moje zdanie na ten temat, i w przypadku MUI nie przekonasz mnie że jest inaczej.
26.02.2008 11:27
[#148]
Re: OWB 1.10 (1.12)
@Olo, post #146
Hyperion przyjął podobny model jak Apple czyli sprzęt z komputerem co miało zapewnić to, że każdy użytkownik go kupi a nie spiratuje. Niestety producent sprzętu okazał się nie producentem itd. Zrobieniu AOS4 na Pegaza sprzeciwiała się Amiga Inc, a nie Hyperion. Poza tym ponieważ sprzedałby się pewnie tylko jeden egzemplarz to szkoda wysiłku.
26.02.2008 11:34
[#149]
Re: OWB 1.10 (1.12)
@MinisterQ, post #147
Nawet jeżeli to działało, to to nie jest ŻADEN argument. Zmianie nie uległo API, tylko wewnętrzne bebechy systemu, to bardzo duża różnica.
Co z tego, że się w środku zmieniło skoro nie dało żadnej nowej funkcjonalności a o tym przecież piszemy o różnicach w stosunku do 3.1.
A co do MUI i kwestii systemowości... Wszystko co działa w zgodzie z wytycznymi systemu operacyjnego jest systemowe, takie jest moje zdanie na ten temat, i w przypadku MUI nie przekonasz mnie że jest inaczej.
Zgodnie z wytycznymi programowania pod system operacyjny komponenty wizualne miały dziedziczyć z gadgetclass a nie z rootclasss.
Co z tego, że się w środku zmieniło skoro nie dało żadnej nowej funkcjonalności a o tym przecież piszemy o różnicach w stosunku do 3.1.
A co do MUI i kwestii systemowości... Wszystko co działa w zgodzie z wytycznymi systemu operacyjnego jest systemowe, takie jest moje zdanie na ten temat, i w przypadku MUI nie przekonasz mnie że jest inaczej.
Zgodnie z wytycznymi programowania pod system operacyjny komponenty wizualne miały dziedziczyć z gadgetclass a nie z rootclasss.
26.02.2008 11:46
[#150]
Re: OWB 1.10 (1.12)
@smith, post #149
Co z tego, że się w środku zmieniło skoro nie dało żadnej nowej funkcjonalności a o tym przecież piszemy o różnicach w stosunku do 3.1.
No ale to Ty użyłeś tego argumentu jako czegoś, co odróżnia OS4 od OS3/MOSa... A wychodzi na to że nie zmieniło się nic na zewnątrz, a głównie wewnątrz, i to aplikacje same sobie są winne z tego względu że nie używały wytycznych systemu 3.x...
Zgodnie z wytycznymi programowania pod system operacyjny komponenty wizualne miały dziedziczyć z gadgetclass a nie z rootclasss.
Jeśli dało się zrobić inaczej, lepiej, stworzyć narzędzie o większej funkcjonalności, to dlaczego nie?
Jeśli da się po czymś dziedziczyć, to się dziedziczy. To jest przecież jedno z założeń obiektowości. To nie są amosowe hacki które kompletnie omijają system, tylko coś co korzysta z mechanizmów udostępnianych właśnie przez system.
No ale to Ty użyłeś tego argumentu jako czegoś, co odróżnia OS4 od OS3/MOSa... A wychodzi na to że nie zmieniło się nic na zewnątrz, a głównie wewnątrz, i to aplikacje same sobie są winne z tego względu że nie używały wytycznych systemu 3.x...
Zgodnie z wytycznymi programowania pod system operacyjny komponenty wizualne miały dziedziczyć z gadgetclass a nie z rootclasss.
Jeśli dało się zrobić inaczej, lepiej, stworzyć narzędzie o większej funkcjonalności, to dlaczego nie?
Jeśli da się po czymś dziedziczyć, to się dziedziczy. To jest przecież jedno z założeń obiektowości. To nie są amosowe hacki które kompletnie omijają system, tylko coś co korzysta z mechanizmów udostępnianych właśnie przez system.