MorphOS - nowe zestawienie cech systemu

Discord (online: ) «»

Online: 14

Adam_M
AmiKit
Archi-TECH
b...
Cizar
Heng
IMPBot
juen
Laubzega
m...
MaaG^dA
Marek_B
Mirq
spazma

dołącz do kanału »

MDW
Czytelnik

komentarz #1 wysłany: brak daty

Oczywiscie wszystko co dotyczy akceleracji 3D to fikcja dla uzytkownikow Pegasos+MorphOS. "Trzeci wymiar" dziala tylko na AmigaClassicPPC+MorphOS. Od 3 miesiecy slysze, ze sterowniki do Voodoo3 dla Pegasosa beda za 2 tygodnie...

Odpowiedz

Jacek Piszczek
Czytelnik

komentarz #2 wysłany: brak daty

Ciekawe dlaczego ten news jest publikowany dopiero teraz. Nie ma to jak "newsy" sprzed 2 miesięcy.

Odpowiedz

Rafał Sańda
Czytelnik

komentarz #3 wysłany: brak daty w odpowiedzi na komentarz #1

ale jeden program pod Rave3D udało mi się uruchomić.

Odpowiedz

Paweł Stefański
Czytelnik

komentarz #4 wysłany: brak daty w odpowiedzi na komentarz #3

Ale na nowej plycie czy na starej. Na starej mi nie rusza zaden program wykorzystujacy biblioteke cgx3drave . Oczywiscie z nowym MOS'em. MDW zawsze sobie mozna pozezbic w Softwarowym GL'u

Odpowiedz

Jacek Piszczek
Czytelnik

komentarz #5 wysłany: brak daty w odpowiedzi na komentarz #4

Na starej mi nie rusza zaden program wykorzystujacy biblioteke cgx3drave

Co ma do tego wersja płyty? cgx3drave nie ma nic wspólnego z 3d dla MOSa.

Odpowiedz

Paweł Stefański
Czytelnik

komentarz #6 wysłany: brak daty w odpowiedzi na komentarz #5

A to ja bardzo przepraszam. Tak więc czekam na jakies stuff z Rav'em 3d dla programistów.

Odpowiedz

Dominik Kowalski
Czytelnik

komentarz #7 wysłany: brak daty

Z informacji dostępnych na temat budowy MorphOSa wynika kilka faktów na które nie wiem czy ktoś wcześniej zwrócił uwagę. 1. Koncepcyjnie MorphOS ma tyle samo mniej więcej wspólnego z AmigaOS co każdy inny system na którym zapuszczono UAE lub inny emulator. Procesy AmigaOS chodzą jako wątki w obrębie jednego procesu. Nie zostało powiedziane ze są od siebie odseparowane (z resztą wątki odseparowane od siebie to nie wątki) czyli zakładam, że nie są. Tak więc mogą się nawzajem nadpisać i spowodować że cały ten proces się powiesi. Jest to dokładnie tak samo jak w UAE. Oczywiście MorphOS uruchamia aplikacje PPC czego UAE nie robi (co nie znaczy ze kiedyś nie będzie) ale mówię tu o koncepcji. 2. Jednym z elementów AmigaOSa są binarne komponenty oparte na BOOPSI. Jest to bardzo ważna technologia i w tym punkcie AmigaOS ma nadal przewagę nad wieloma innymi systemami. Ze znanych mi jedynie Windows ma podobny mechanizm (COM) ale nie jest tak dobry – nie ma w nim dziedziczenia i jest bardziej przeznaczony do udostępniania “api aplikacji” niż do jej budowy. W tym zestawieniu cech MorphOSa nie ma słowa na temat BOOPSI czy w takim razie twórcy MOS zdają sobie sprawę ze znaczenia tej technologii. Samo wykorzystanie MUI o tym wcale nie musi świadczyć. 3. Istnieje niebezpieczeństwo ze za jakiś czas zamiast rozwijaniem emulacji AmigaOSa twórcy MorphOSa zaczną zajmować się rozbudową "właściwego" system MorphOS a on nie musi już być podobny do AmigaOSa a nawet może nie mieć z nim zupełnie nic wspólnego, i wcale się nie musi podobać dotychczasowym użytkownikom.

Odpowiedz

MDW
Czytelnik

komentarz #8 wysłany: brak daty w odpowiedzi na komentarz #7

1. MOS rozni sie od UAE jedna WAZNA cecha - system jest natywny. O to walczylismy i to mamy

. Tego nie zastapi milion Amithlonow+UAE. Jest to cos rozwojowego a nie tylko (chociazby nie wiem jak szybki) AmigaOS3_68k do konca swiata bez zadnej mozliwosci rozwoju.

3. Zgadzam sie. Narazie wszyscy (AmigaOS4 i MorphOS) sa jedna wielka rodzina

i maja ze soba wiele wspolnego. Oba staraj sie byc kompatybilne z AmigaOS3. Jednak jak zaczna powstawac programy dla AmigaOS4 i MorphOS (te juz zaczely chociaz najczesciej to tylko porty majace swoje odpowiedniki dla AmigaOS) to oba systemy rozejda sie zupelnie i przestana miec ze soba cokolwiek wspolnego poza kompatybilnoscia ze starym AmigaOS3. Beda to dwie zupelnie inne platformy. Tu nie bedzie tak dobrze jak w czasie wojny "WOS vs PUP" w ktorej sprawe zalatwiala emulacja typu (ppclibemu). Ilosc obecnych amigowcow ktorzy kupia nowa Amige (Peg albo A1) jest mikroskopijna. Do tego ilosc ta podzieli sie jeszcze na dwie czesci... ech, przyszlosc...

Odpowiedz

MDW
Czytelnik

komentarz #9 wysłany: brak daty w odpowiedzi na komentarz #4

Softwareowy? Jakos nie bardzo

. Ech, ciagla prowizorka, ciagle "za 2 tygodnie", a ja juz jestem tak stary, ze zaczynam sie rozgladac za jakims przytulnym domem stracow

.

Odpowiedz

Rafał Sańda
Czytelnik

komentarz #10 wysłany: brak daty w odpowiedzi na komentarz #5

Co zatem linijka if(!(CGX3DRAVEBase=(struct Library *)OpenLibrary("cgx3drave.library",2))) w Goa3D robi?

Odpowiedz

Nowar
konto zablokowane
lub usunięte

Autor tego komentarza otrzymał czerwoną kartkę

Czytelnik

komentarz #11 wysłany: brak daty w odpowiedzi na komentarz #8

Nie bedzie az tak zle. Jak zwykle zwyciezy jedno rozwiazanie. Slabsze i mniej przyszlosciowe bedzie musialo sie przestawic na to lepsze (zadba o kompatybilnosc), lub upadnie... Na razie prowadzi MorphOS. Mam tez nadzieje ze ktos madry zrobi "piracki" port MOSa na AmigeONE (oczywiscie MOSa trzeba kupic legalnie).

Odpowiedz

Jacek Piszczek
Czytelnik

komentarz #12 wysłany: brak daty w odpowiedzi na komentarz #10

Okej, faktycznie cgx3drave jest wykorzystana, ale same sterowniki 3d siedzą już gdzie indziej.

Odpowiedz

Jacek Piszczek
Czytelnik

komentarz #13 wysłany: brak daty w odpowiedzi na komentarz #7

Procesy AmigaOS chodzą jako wątki w obrębie jednego procesu. Nie zostało powiedziane ze są od siebie odseparowane (z resztą wątki odseparowane od siebie to nie wątki) czyli zakładam, że nie są.

Kolega chyba nie do końca zrozumiał o co chodzi. Na kernelu MorphOSa, Quarku, faktycznie działa (obecnie) 1 task. Jest to ABox, który stanowi warstwę kompatybilną z Amigą. Dla użytkownika te rzeczy pozostają jednak niewidoczne. MorphOSa używa się przecież tak samo jak AmigaOS. Co do odseparowywania wątków to coś takiego NIE JEST możliwe w środowisku AmigaOS bądź kompatybilnym. NIE będzie tego miał żaden system, który chciałby zachować zgodność z AmigaOS. Polecam zapoznanie się z zasadami działania AmigaOS.

Jednym z elementów AmigaOSa są binarne komponenty oparte na BOOPSI (...) W tym zestawieniu cech MorphOSa nie ma słowa na temat BOOPSI czy w takim razie twórcy MOS zdają sobie sprawę ze znaczenia tej technologii.

Proszę poczytać sobie RKRM na temat Boopsi. Jak kolega wyobraża sobie możliwość odpalania progamów zgodnych z AmigaOS przy braku BOOPSI??? Oczywiście, że stanowi ono integralną część systemu. Zaśmiecanie listy "features" takimi podstawami jest bzdurą, choćby dlatego, że najwyraźniej niewielu wie czym BOOPSI jest.

Istnieje niebezpieczeństwo ze za jakiś czas (...) twórcy MorphOSa zaczną zajmować się rozbudową "właściwego" system MorphOS a on nie musi już być podobny do AmigaOSa

Po pierwsze, MorphOS NIE JEST emulatorem AmigaOS. Nie zamierzamy zaprzestania rozwoju MorphOS'a. Po drugie proszę przyjrzeć się planom AmigaINC, AmigaDE czy OS5 nie mają ABSOLUTNIE NIC WSPÓLNEGO z AmigaOS, nie oferują ŻADNEJ z nim zgodności.

Odpowiedz

Dominik Kowalski
Czytelnik

komentarz #14 wysłany: brak daty w odpowiedzi na komentarz #13

Kolega chyba nie do końca zrozumiał o co chodzi

Czyżby? Napisałeś to samo co ja.

Na kernelu MorphOSa, Quarku, faktycznie działa (obecnie) 1 task. Jest to ABox, który stanowi warstwę kompatybilną z Amigą.

Warstwę mogą stanowić szeroko rozumiane biblioteki proces to jest proces. W przedstawionym zestawieniu cech jest napisane że ABox to wielowątkowa aplikacja będąca procesem kernela Quark. Rozumiem z tego ze procesy/taski AmigaOS są właśnie tymi wątkami a ABox i biblioteki tworzą im takie środowisko żeby były przekonane że działają pod AmigaOS made by Commodore i dokładają jeszcze trochę rozszerzeń (RTG itd).

Dla użytkownika te rzeczy pozostają jednak niewidoczne. MorphOSa używa się przecież tak samo jak AmigaOS.

To co jest widoczne w tej chwili dla użytkownika to zupełnie inna spraw niż to co się dzieje w środku. ABox jest procesem Quarka mogą zatem chodzić też inne procesy Quarka korzystające z API nie mającego nic wspólnego z API AmigaOS i kontaktujące się z użytkownikiem przez konsole czy jakieś GUI. I co się dzieje gdy padnie cala “Amiga” wewnątrz ABoxa? Rozumiem ze może się zrestartować bez restartowania MorphOSa a gdy padnie process ABoxa? Odpalamy sobie nowy? Z tego co jest napisane to jest to możliwe wystarczy mieć odpaloną konsole jako proces obok procesu ABoxa. Zatem tak jak już pisalem nie ma różnicy w koncepcji między tym jak jest realizowane działanie aplikacji AmigaOS w MorphOsie i w UAE.

Co do odseparowywania wątków to coś takiego NIE JEST możliwe w środowisku AmigaOS bądź kompatybilnym. NIE będzie tego miał żaden system, który chciałby zachować zgodność z AmigaOS.

“Sądy kategoryczne niezwykle są dogodne, dorodne
I poniekąd modne gdy mówisz do tłumu”

Popełniasz błąd generalizacji bo jak rozumiem duże litery świadczą o głębokim przekonaniu do tej tezy. A ja bym ją osłabił i powiedział że nie zawsze jest możliwe. Problemy są w zasadzie dwa:
-Wymiana wiadomości miedzy procesami poprzez Messages,
-Dostęp do struktur systemowych.

Problem pierwszy dotyczy tylko procesów, które kontaktują się między sobą a ich aż tak dużo to raczej nie ma. Taką wymianę informacji można wyśledzić (w runtime sprawdzając do kogo chcą wysyłać swoje wiadomości) i takie procesy nie odseparowywać od siebie ale od innych procesów tak.

Problem drugi. Obecnie programy otwierają biblioteki i mają dostęp do danych zawartych w ich bazach. Nadpisanie tych danych może prowadzi do zawieszenia systemu. Problem ten można rozwiązać zwracając w OpenLibrary strukturę która wygląda jak baza biblioteki ale wcale nią nie jest. Każde otwarcie takiej biblioteki dawało by osobną strukturę tak więc nadpisanie swojej kopi nie miałoby wpływu na dane odczytywane przez inne procesy sama biblioteka tez by na nich nie działała i jedyne co by robiła to w razie potrzeby odświeżała zawartość kopi uaktualniając jej dane.

Polecam zapoznanie się z zasadami działania AmigaOS

Jak widzisz jestem zapoznany

Ja natomiast polecam myślenie Out of Box i tego Boxa możesz sprefixować dowolną literą

Proszę poczytać sobie RKRM na temat Boopsi.

Naprawdę sądzisz że ich nie czytałem?

Jak kolega wyobraża sobie możliwość odpalania programów zgodnych z AmigaOS przy braku BOOPSI??? Oczywiście, że stanowi ono integralną część systemu. Zaśmiecanie listy "features" takimi podstawami jest bzdurą, choćby dlatego, że najwyraźniej niewielu wie czym BOOPSI jest.

To że BOOPSI musi być zaimplementowane jest oczywiste. Mi chodzi o coś innego o czym nie przeczytałem w żadnej informacji na temat MorphOSa.

Może mała dygresja żeby wszystko było jasne. Na swoje własne potrzeby dziele systemy operacyjne na trzy grupy:

-Te dla których wszystko jest plikiem np.: Linux
-Te które zdają sobie sprawę z tego że wszystko jest obiektem np.: AmigaOS, Windows
-Te które traktują to na prawdę poważnie np.: java, .net

(Nie chcę tu tłumaczyć dlaczego javę uważam w pewnym sensie za system operacyjny)

I teraz pytanie do której kategorii należy MorphOS ale nie ABox tylko Quark/QBox? I drugie jak bardzo rozwój ABoxa będzie oparty na BOOPSI i w ogóle jak bardzo ukierunkowany na obiektowość?

Po pierwsze, MorphOS NIE JEST emulatorem AmigaOS

Na ten temat już się wypowiedziałem wcześniej ale może jeszcze jedna analogia.

Na Windowsa jest emulator Maca nie pamiętam w twej chwili jak się nazywa ale umożliwia uruchamianie aplikacji Maca bez instalowania MacOSa. Dostarcza samodzielnie API MacOSa aplikacjom. Te funkcje tego API chodzą native na Intelu. W takim razie czy Windows plus ten emulator można nazwać klonem MacOSa lub nowym MacOSem? Nie. A w wypadku MorphOSa mamy identyczną sytuacje.

Nie zamierzamy zaprzestania rozwoju MorphOS'a

A co z ABoxem? Na stronie http://www.morphos.net/overview.php3 czytam:

Because we believe that the original OS design has strong limits for newer technology through its design structure, we also plan a completly fresh and clean OS layer on top of the Quark kernel (called Q-Box now). The A-Box API was nice in its time, but today it has serious limitations because it doesn't hide OS structures and has no concept of memory ownership. This doesn't even cover all kinds of problems in many of the other system modules like layers, graphics, intuition or DOS which we at least try to resolve as far as possible with our A-Box extensions. As a consequence, we will not replicate the A-Box API in the Q-Box but we will try to do a new API without any compromises to the past but based on past experience.

Niebezpieczeństwo o którym mówiłem w poprzedniej wypowiedzi jest takie, że pewnego dnia może się okazać że ABoxowi “dziękujemy” a jedyny słuszny jest QBox. Skąd mamy mieć pewność że tak się nie stanie. Ze celem ludzi stojących za MorphOSem nie jest przejęcie dotychczasowych użytkowników AmigaOS po czym zmigrowanie ich na własną technologie.

Po drugie proszę przyjrzeć się planom AmigaINC, AmigaDE czy OS5 nie mają ABSOLUTNIE NIC WSPÓLNEGO z AmigaOS, nie oferują ŻADNEJ z nim zgodności.

No już zauważyłem że każda rozmowa na temat MorphOSa konczy się “co z tego ze my to skoro Amiga inc tamto”. To nie argumentacja. Z drugiej strony dziwie się skąd masz takie dokładne dane na temat AmigaOS5. Do tej pory bardzo mało o nim mówiono i dość ogólnie więc sądzę że wypowiadasz własne (tendencyjne) domysły i próbujesz je przedstawiać jako fakty. Co się tyczy AmigaDE to jest to zupelnie inna sprawa do innych zastosowań po prostu odrębny produkt i nie należy patrzeć przez jego pryzmat na AmigaOS.

Odpowiedz

Jacek Piszczek
Czytelnik

komentarz #15 wysłany: brak daty w odpowiedzi na komentarz #14

Zatem tak jak już pisalem nie ma różnicy w koncepcji między tym jak jest realizowane działanie aplikacji AmigaOS w MorphOsie i w UAE.

UAE to emulator hardware'u Amigi, nie jest systemem operacyjnym, nie posiada własnego kernela. Jak w ogóle możesz coś porównywać?

Problem pierwszy dotyczy tylko procesów

Nie masz racji. Jest sporo programów które komunikują się ze sobą poprzez na przykład wypełnianie jakiś przestrzeni w pamięci danymi (nie ważne, czy jest ona zalokowana, czy nie). Jak chciałbyś coś takiego wykryć? Jedną z zasad, na jakich oparty został AmigaOS, jest brak ochrony pamięci. Niestety zgodność z AmigaOS wymaga jej braku (ochrona pamięci a la zabezpieczenie niezalokowanej przestrzeni czy ochrona kernela to nie jest prawdziwa ochrona pamięci).

Problem drugi. Obecnie programy otwierają biblioteki i mają dostęp do danych zawartych w ich bazach. Nadpisanie tych danych może prowadzi do zawieszenia systemu.

Pierwszy raz słyszę o takim problemie. Żaden normalny program nie zapisuje nic w bazie biblioteki. Koledze najwyraźniej chodzi o program nadpisujący pamięc, której nie zalokował (np. alokacja 100 bajtów a zapis/odczyt ze 101 bajtu).

I drugie jak bardzo rozwój ABoxa będzie oparty na BOOPSI i w ogóle jak bardzo ukierunkowany na obiektowość?

ABox, tak jak i mówiąc ogólnie AmigaOS nie mają zbyt wiele wspólnego z obiektowością. BOOPSI jak sama nazwa wskazuje dotyczy intuition i ogólnie GUI. Przy braku jakiegokolwiek wsparcia dla obiektowości ze strony exec.library czy dos.library bawienie się w "uobiektowianie" systemu nie ma imo sensu - żaden istniejący program by z tego nie skorzystał.

Ze celem ludzi stojących za MorphOSem nie jest przejęcie...

Gdybyś trochę lepiej znał AmigaOS zrozumiałbyś, że pewnych rzeczy w ABoxie po prostu nie da się zrobić. Stąd konieczność stworzenia innego systemu, na którym możnaby już skorzystać z dzisiejszych technologii. MorphOS pomyślany jest tak, by te systemy mogły ze sobą koegzystować. Nikt nie będzie od nikogo wymagał przesiadki.

Odpowiedz

michalsc
konto zablokowane
lub usunięte
Czytelnik

komentarz #16 wysłany: brak daty w odpowiedzi na komentarz #14

Popełniasz błąd generalizacji bo jak rozumiem duże litery świadczą o głębokim przekonaniu do tej tezy. A ja bym ją osłabił i powiedział że nie zawsze jest możliwe. Problemy są w zasadzie dwa:
-Wymiana wiadomości miedzy procesami poprzez Messages,
-Dostęp do struktur systemowych.

Problem pierwszy dotyczy tylko procesów, które kontaktują się między sobą a ich aż tak dużo to raczej nie ma. Taką wymianę informacji można wyśledzić (w runtime sprawdzając do kogo chcą wysyłać swoje wiadomości) i takie procesy nie odseparowywać od siebie ale od innych procesów tak.

I w tym momencie wykazujesz braki w wiedzy na temat AmigaOS. Procesow czy zadan wymieniajacych miedzy soba wiadomosci jest cala masa. Ba! Od wymiany tych informacji zalezy cale funkcjonowanie systemu. Chcesz przyklad bardzo czesto komunikujacego sie z innymi procesu? Wez dowolny filesystem. To jest normalny proces, ktory w petli czeka na nadchodzace wiadomosci. Cala komunikacja z nim odbywa sie dzieki wiadomoscia. Czy dasz takiemu procesowi dostep do calej przestrzeni adresowej? Wtedy ochrona pamieci nic Ci nie da, bo jednym programem bede w stanie wywalic w powietrze dowolny inny.

Inna sprawa to separacja przestrzeni adresowych. Jak rozwiazalbys to w AmigaOS? Zauwaz, ze nawet ludzie piszacy AmigaOS 4 nie wspominaja o pelnej ochronie pamieci. NA poczatek beda blokowali mozliwosc pisania sobie po kernelu albo po niezaalokowanej pamieci. A reszta?

BOOPSI tez nie opakowuje calego systemu operacyjnego w klasy. Owszem, mozna sie dopatrzyc elementow obiektowosci (kazda biblioteka to tak jakby klasa ktora ma pewne pola publiczne, pewne prywatne, a ponizej jej adresu bazowego ciagnie sie fikusnie skonstruowana tablica funkcji wirtualnych), ale BOOPSI wszedzie sie nie wetknie.

i tak dalej i tak dalej...

Odpowiedz

Piotr Zadora
Redaktor

komentarz #17 wysłany: brak daty w odpowiedzi na komentarz #15

Zatem tak jak już pisalem nie ma różnicy w koncepcji między tym jak jest realizowane działanie aplikacji AmigaOS w MorphOsie i w UAE.

UAE to emulator hardware'u Amigi, nie jest systemem operacyjnym, nie posiada własnego kernela. Jak w ogóle możesz coś porównywać?

Jak rozumiem spór dotyczy analogii pomiędzy UAE i A-Box'em. Żaden z nich nie jest samodzielnym systemem operacyjnym. Każdy z nich jest procesem dla macierzystego systemu operacyjnego: UAE dla windowsa, linuxa, amigaOS, BeOS, itd ... ; A-Box dla Quark'a. Każdy z nich dostarcza API i tworzy środowisko umożliwiające uruchomienie procesów AmigaOS'u. Do tej pory wszystko jest zbieżne i dlatego można je ze sobą porównywać.
Dopiero potem zaczynają się niewielkie różnice w szczegółach "udawania" środowiska Amigi: A-Box, np. nie wspiera układów dedykowanych Amigi ale emuluje procesory m68k; UAE wspiera układy dedykowane ale już niekoniecznie musi emulować m68k, np. na oryginalnej Amidze, itd.
Ciekawe z tego punktu widzenia byłoby porównanie hipotetycznej wersji UAE dla Quarka (bo przecież możliwej, prawda?) z A-Boxem.
A mnie w tym momencie i tak najbardziej interesuje: porównanie wydajności emulacji tych samych amigowych programów dla m68k oraz programów dla PPC, kompilowanych z tych samych źródeł (abstrahuję od niezbędnych zmian w nazwach funkcji a więc identycznych w sensie algorytmicznym) w OS'ie 4 i w MOS'ie. Bo przecież dodanie kolejnej warstwy (A-Box) czyli wydłużenie ścieżki wykonania przy założeniu takiej samej prędkości emulacji m68k (Petunia vs. Trance) powinno przynajmniej teoretycznie przynieść zmniejszenie wydajności działania amigowych programów pod MOS'em w porównaniu z ich działaniem pod AmigaOS'em 4.

Odpowiedz

Jacek Rzeuski
Czytelnik

komentarz #18 wysłany: brak daty w odpowiedzi na komentarz #17

UAE zawsze emuluje 68k. Nawet na Amidze. A porównanie prędkości działania programu m68k wcale nie musi wyjść na korzyść AmigaOS4 tylko dlatego, że pracuje on jako osobny proces na kernelu.

Odpowiedz

Dominik Kowalski
Czytelnik

komentarz #19 wysłany: brak daty w odpowiedzi na komentarz #15

UAE to emulator hardware'u Amigi, nie jest systemem operacyjnym, nie posiada własnego kernela. Jak w ogóle możesz coś porównywać?

Z UAE używamy oryginalnego AmigaOS a ABox ma własną implęmętacje api AmigaOSa i tym się różnią ale ja caly czas mówię o koncepcji, o tym jak się mają procesy systemu który jest uruchomiony na komputerze do procesów AmigaOSa i tym się od siebie nie różnią oba te rozwiązania.

Nie masz racji. Jest sporo programów które komunikują się ze sobą poprzez na przykład wypełnianie jakiś przestrzeni w pamięci danymi (nie ważne, czy jest ona zalokowana, czy nie).

Jeżeli ten obszar nie jest zaalokowany to i pod AmigaOSem jaki mamy dzisiaj to nie może działać a jeśli działa to przez przypadek i do czasu aż ktoś tej pamięci nie zaalokuje i nie nadpisze

Jak chciałbyś coś takiego wykryć?

Jeżeli dwa programy chcą się ze sobą komunikować muszą to jakoś rozpocząć nawet jeśli potem będą robić to tylko przez obszar pamięci. Albo przesyłają wiadomości albo wpisują coś na standardowe wejście tego drugiego albo jeden wywoła drugi i poda mu jakieś parametry. Oprócz tego ten dostęp do wspólnej pamięci muszą jakoś synchronizować czyli używać tych samych semaforów. Wszystko to można wyśledzić i budować odpowiednią mapę pamięci w zależności od potrzeb. A gdyby to wszystko zawiodło to pozostaje jeszcze ingerencja użytkownika który powie jak ma być odpalany dany program na podstawi swoich obserwacji czy informacji od producenta i gdzieś to będzie zapisane choćby w ToolTypes a system z tego skorzysta.

Jest sporo programów które komunikują się ze sobą

No to przykład z życia. Robimy coś i mamy odpalone edytor tekstu, program do poczty i odtwarzacz mp3. Które z nich muszą między sobą przesyłać jakieś dane? Żadne, można bez problemu je rozdzielić.

Jedną z zasad, na jakich oparty został AmigaOS, jest brak ochrony pamięci. Niestety zgodność z AmigaOS wymaga jej braku (ochrona pamięci a la zabezpieczenie niezalokowanej przestrzeni czy ochrona kernela to nie jest prawdziwa ochrona pamięci).

Chodzi o to by przejść do całkowitej ochrony pamięci. Jak już pisałem można zastosować rozwiązania które umożliwią to w wypadku części obecnych programów. Nowe programy powinny być pisane w taki sposób żeby chodziły z ochroną pamięci i tak uruchamiane przez system.

Pierwszy raz słyszę o takim problemie. Żaden normalny program nie zapisuje nic w bazie biblioteki. Koledze najwyraźniej chodzi o program nadpisujący pamięc, której nie zalokował (np. alokacja 100 bajtów a zapis/odczyt ze 101 bajtu).

Pierwsze słyszysz ale już po chwili wiesz o co chodzi
Dokładnie o taką sytuacje. Należy zapobiec uszkodzeniu bazy biblioteki równocześnie umożliwiając odczyt danych tam zawartych.

ABox, tak jak i mówiąc ogólnie AmigaOS nie mają zbyt wiele wspólnego z obiektowością. BOOPSI jak sama nazwa wskazuje dotyczy intuition i ogólnie GUI.

Nazwa może tak ale użyć można BOOPSI do czegokolwiek. Datatypes to tez klasy BOOPSI a co mają wspólnego z intuition. MUI także posiada klasy nie wizualne będące BOOPSI.

Przy braku jakiegokolwiek wsparcia dla obiektowości ze strony exec.library czy dos.library bawienie się w "uobiektowianie" systemu nie ma imo sensu - żaden istniejący program by z tego nie skorzystał.

Istniejący nie ale przyszłe tak.

Gdybyś trochę lepiej znał AmigaOS

Znam bardzo dobrze.

zrozumiałbyś, że pewnych rzeczy w ABoxie po prostu nie da się zrobić.

Oczywiście że się nie da zrobić wszystkiego tylko ja uważam że jest jeszcze dużo możliwości które nie zostały wykorzystane. Zarzucasz mi brak znajomości AmigaOSa a to raczej ja musze powiedzieć że Tobie brakuje pomysłowości skoro widzisz problemy tam gdzie tak na prawdę ich nie ma.

Stąd konieczność stworzenia innego systemu, na którym możnaby już skorzystać z dzisiejszych technologii. MorphOS pomyślany jest tak, by te systemy mogły ze sobą koegzystować. Nikt nie będzie od nikogo wymagał przesiadki.

Czyli będzie to wyglądać tak że ABox osiągnie jakiś poziom rozwoju. Następnie część albo nawet całość ludzi którzy go tworzą zacznie robić QBoxa. Tak? I co dalej za jakiś czas mamy dwie opcje albo piszemy pod ABoxa który stoi w miejscu a na pewno nie rozwija się tak dynamicznie ja by mógł albo przesiadamy się na QBoxa, który nie wiadomo jaką ma architekture, jakie api, jaką dokumentacje, po prostu nic. I nadal nie wiem jaki to tak na prawdę system (jeśli chodzi o podział z poprzedniej wypowiedzi) czy old-schoolowy z architektura z przed kilkunastu/kilkudziesięciu lat czy może jednak coś nowocześniejszego. A dalej czy za jakiś czas nie pojawią się wersje MorphOSa bez ABoxa? Bo na przykład przeznaczona dla PDA czy czegoś innego gdzie będą ograniczone zasoby. I co wtedy? Jak wiele będzie to miało wspólnego z AmigaOSem i Amigą?

Odpowiedz

Jacek Piszczek
Czytelnik

komentarz #20 wysłany: brak daty w odpowiedzi na komentarz #17

Żaden z nich nie jest samodzielnym systemem operacyjnym.

Kolega chyba nie rozumie znaczenia słowa mikrokernel. Jądro linuxa na przykład jest bardzo rozbudowane, Quark natomiast zajmuje kilkadziesiąt kilobajtów (!), nie można więc o nim mówić jako o systemie. Prawidłowym wyobrażeniem byłoby raczej widzenie ABoxa jako zewnętrznego uzupełnienia Quarka, widzenie tego jako całość.

czyli wydłużenie ścieżki wykonania przy założeniu takiej samej prędkości emulacji m68k

Eh, jakie wydłużenie??? To co mówisz jest zupełnie bez sensu. Proszę nie tworzyć teorii które nie mają najmniejszej podkładki w Twojej wiedzy.

Odpowiedz

Jacek Piszczek
Czytelnik

komentarz #21 wysłany: brak daty w odpowiedzi na komentarz #19

o tym jak się mają procesy systemu który jest uruchomiony na komputerze do procesów AmigaOSa

Jak już napisałem wyżej Quark jest mikrokernelem. Jest to bardzo dobre rozwiązanie w przypadku procesorów PPC, ale wymusza ono oddzielenie sysemu operacyjnego (tego, co "widzi" użytkownik) od samego jądra. Różnica między UAE a ABoxem jest dość znaczna. UAE działa jako task systemu operacyjnego (w pojęciu makrokernela), a ABox bezpośrednio na mikrokernelu, przejmując np obsługę hardware'u, czego o UAE nie możesz już powiedzieć.

Wszystko to można wyśledzić i budować odpowiednią mapę pamięci w zależności od potrzeb.

Gdybyś choć trochę wiedział, o czym mówisz, zorientowałbyś się, że to nierealne.

A gdyby to wszystko zawiodło to pozostaje jeszcze ingerencja użytkownika

No i jaki sens miałaby mieć ochrona pamięci, skoro właśnie dla tych progamów, które najbardziej ją naruszają, musiałbyś ją wyłączyć? (dobry argument porneL, dzięki!

Tęższe mózgi od Ciebie głowiły się nad tym problemem, ludzie perfekcyjnie znający system Amigi, sami jego twórcy. Jak myślisz, dlaczego ochrony pamięci nikt jeszcze w AmigaOS nie zrobił? Bo byli gorszymi koderami od Ciebie?

Nazwa może tak ale użyć można BOOPSI do czegokolwiek.

Nie, nie można. Podstawowe funkcje BOOPSI znajdują się w intuition, jak zapewne wiesz. Datatypes mogą swobodnie odwoływać się do intuition, w przypadku execa czy dosu byłoby to już odwróceniem wzajemnych zależności panujących w systemie (działanie execa nie może zależeć od działania intuition, etc). Kopiowanie tych funkcji gdzie się da jest także pozbawione sensu. Ogólnie rzecz biorąc BOOPSI dla sterowników, execa, dosu, itp jest pozbawione sensu w AmigaOS...

Zarzucasz mi brak znajomości AmigaOSa a to raczej ja musze powiedzieć że Tobie brakuje pomysłowości skoro widzisz problemy tam gdzie tak na prawdę ich nie ma.

Oczywiście, to jest wykonalne. Znajomość AmigaOS mówi mi jednak, że byłaby to praca NA NIC. Aktualne API może nie wszędzie są takie, jakbyśmy chcieli, ale obiekty po prostu nie sprawdzą się w tym środowisku.

Czyli będzie to wyglądać tak że ABox osiągnie jakiś poziom rozwoju...

Rozumiem argument o PDA, faktycznie nie miałoby to nic wspólnego z Amigą. Na szęście na Eclipsis będzie ABox Postaraj się zrozumieć, że nie da się na przykład przejść na system 64 bitowy zachowując zgodność z 32 bitowym. Nikt nie chce rozstawać się ze środowiskiem AmigaOS, ale pewne technologie NIE SA i NIE BĘDĄ dla niego osiągalne. Stąd konieczność zaoferowania użytkownikowi czegoś więcej. Uważasz, że lepiej byłoby, gdyby każdy musiał kupować drugi komputer by móc pozostać "na czasie"?

Odpowiedz

Carlos / W.F.M.H.
Czytelnik

komentarz #22 wysłany: brak daty w odpowiedzi na komentarz #19

MUI także posiada klasy nie wizualne będące BOOPSI.

Średnio trafiłes. Spróbuj zrobić coś wiecej w przypadku MUI i takich klas, a zobaczysz na ile "atrakcji" się natniesz. To tak lekko OT.

Odpowiedz

Krzysztof Twardy
Czytelnik

komentarz #23 wysłany: brak daty w odpowiedzi na komentarz #21

I o co sie tu klucic, przeciez wszystkim chodzi przede wszystkim o to, zeby system byl szybki, "na czasie" i dzialal stabilnie. Niech sie zmienia, niech ewoluuje, byle tylko zachowal w sobie to cos co czyni go tak wyjatkowym, ze mimo uplywu lat nadal wolimy go od windy, czy linuxa...

Odpowiedz

Piotr Zadora
Redaktor

komentarz #24 wysłany: brak daty w odpowiedzi na komentarz #20

Kolega chyba nie rozumie znaczenia słowa mikrokernel.

Myślę, że większość czytelników tej strony zna znaczenie słowa mikrokernel; najwyraźniej włączając mojego Kolegę adwersarza.

czyli wydłużenie ścieżki wykonania przy założeniu takiej samej prędkości emulacji m68k

Eh, jakie wydłużenie??? To co mówisz jest zupełnie bez sensu. Proszę nie tworzyć teorii które nie mają najmniejszej podkładki w Twojej wiedzy.

Nie po raz pierwszy odnosi się Kolega z widocznym i celowym lekceważeniem do wiedzy swoich adwersarzy.
Nawet jeśli nie ma ku temu żadnych podstaw ani przesłanek. Najwyraźniej został Kolega solidnie zmotywowany do przyjęcia takiej, mało konstruktywnej linii prowadzenia konwersacji, bo przecież trudno to celowe bagatelizowanie nazwać argumentacją.
A co do pojęcia ścieżki wykonania to najwyraźniej Kolega jeszcze się z nim nie spotkał i dlatego myślę, że trzeba dać Koledze czas na zasięgnięcie opinii innych Kolegów zainteresowanych w uzyskaniu przez MOS'a przewagi medialnej. Ale ja jestem bardzo cierpliwy i dam Koledze czas.

Odpowiedz

MDW
Czytelnik

komentarz #25 wysłany: brak daty

Aaaa co mi tam - zapytam. Najwyzej sie naraze

.
Czy ktos jest w stanie mi odpowiedziec czy cokolwiek sie robi w sprawie sterownikow 3D do MOSa i Pegasosa czy to nadal temat tabu wywolujacy glupie usmieszki? Moge jeszcze miec nadzieje ze bedzie na Pegasosie OpenGL korzystajacy z akceleratora (przynajmniej Voodoo3 jezeli juz nie Radeon) czy musze poczekac na AmigaOS4 i jego wersje OpenGLa chodzaca pod nowym Warp3D?

Przepraszam, ze tak przynudzam o tym 3D i ciagle sie tego czepiam, ale zalezy mi. Bez tego nie widze sie jako wlasciciel nowej Amigi (niezlaeznie od tego czy ma to byc A1+OS4 czy Peg+MOS). Tylko nie mowicie, ze "za 2 tygodnie", bo to juz sie robi podobne do obietnic Amiga Inc...

Odpowiedz

Nowar
konto zablokowane
lub usunięte

Czytelnik

komentarz #26 wysłany: brak daty w odpowiedzi na komentarz #25

Nic sie nie narazasz. To my jestesmy gosciami, a nie oni. Mamy takie szczescie ze na codzien mamy dostep do grzyba.Jestesmy prawdziwymi Amigowcami. Mimo uzywania peceta zostalismy przy Ami. "Klient nasz pan" - to powinnismy uslyszec. A jezeli nie, to zaczekamy (juz tak dlugo to robimy). A w miedzy czasie bedziemy sie cieszyc naszymi Powerkami. Nie my dla nich, lecz oni dla nas i dla Amigi.

Odpowiedz

Nowar
konto zablokowane
lub usunięte

Czytelnik

komentarz #27 wysłany: brak daty w odpowiedzi na komentarz #26

"gosciami" czyli goscmi (czyt. czlowiek w porzadku).

Odpowiedz

Dominik Kowalski
Czytelnik

komentarz #28 wysłany: brak daty w odpowiedzi na komentarz #21

...a ABox bezpośrednio na mikrokernelu, przejmując np obsługę hardware'u, czego o UAE nie możesz już powiedzieć.

Pytanie: czy w takim razie każdy proces w MorphOSie może grzebać po hardware? Bo jeśli tak to coś jest nie tak.

Widzisz spierasz się o szczegóły implementacyjne gdy ja mówię o koncepcji a właśnie chodzi o konsekwencje tej koncepcji. A jakie one są? Takie że rodzą się pytania jak to wszystko będzie ze sobą działać. Czy na przykład będzie jakieś IPC między ABoxem a QBoxem? Czy chociaż będzie wspólny schowek? Czy gdy będę miał odpaloną aplikacje pod ABoxem a inną pod QBoxem to czy one będą mogły być na jednym ekranie?

Gdybyś choć trochę wiedział, o czym mówisz,

A Ty w kółko swoje

zorientowałbyś się, że to nierealne.

Trudne (nawet NP trudne ) to nie znaczy nierealne

No i jaki sens miałaby mieć ochrona pamięci, skoro właśnie dla tych programów, które najbardziej ją naruszają, musiałbyś ją wyłączyć?

Widzę że nie zrozumiałeś do końca zagadnienia. Więc może już tak zupełnie łopatologicznie. Chodzi o to żeby zbiór procesów/tasków użytkownika podzielić na rozłączne podzbiory tak żeby osiągnąć jak największą ilość tych podzbiorów i żeby w każdym z nich było jak najmniej elementów ale nie mniej niż jeden .
Czyli jeżeli jakiś program składa się z processow/tasków komunikujących się ze sobą w sposób wymagający wspułdzielenia pamięci (na przykład ustawianie sygnałów tego nie wymaga) to procesy/taski te wchodzą do jednego podzbioru i dzięki temu mieszają tylko sobie.

(dobry argument porneL, dzięki!

Zły argument
Ale widzę że sprawa już zaczęła wymagać konsultacji

Tęższe mózgi od Ciebie głowiły się nad tym problemem,

Znamy się?

ludzie perfekcyjnie znający system Amigi, sami jego twórcy. Jak myślisz, dlaczego ochrony pamięci nikt jeszcze w AmigaOS nie zrobił?

A niby kiedy to mieli zrobić skoro przez cały czas były w produkcji Amigi bez MMU a potem przez 10 lat nic się nie działo?

Bo byli gorszymi koderami od Ciebie?

Kim dla Ciebie jest koder? Bo dla mnie kolesiem, który dostaje specyfikacje i pisze kod na jej podstawie a tu raczej potrzeba projektantów. Czy byli gorsi? Kto to wie

Nie, nie można. Podstawowe funkcje BOOPSI znajdują się w intuition, jak zapewne wiesz.

No nareszcie stwierdziłeś że mogę coś wiedzieć

Datatypes mogą swobodnie odwoływać się do intuition, w przypadku execa czy dosu byłoby to już odwróceniem wzajemnych zależności panujących w systemie (działanie execa nie może zależeć od działania intuition, etc). Kopiowanie tych funkcji gdzie się da jest także pozbawione sensu. Ogólnie rzecz biorąc BOOPSI dla sterowników, execa, dosu, itp jest pozbawione sensu w AmigaOS...

Powód dla którego wspomniałem o BOOPSI był zupełnie inny niż rozstrzyganie do czego ta technologia się nadaje a do czego nie. Wyjaśniłem to w poprzedniej wypowiedzi ale przypomnę: jakim systemem jest MorphOS/QBox jeśli chodzi o podział który przedstawiłem.
W sprawie wykorzystania BOOPSI w AmigaOSie. Jest oczywiste że nie należy wciskać tej technologii wszędzie na siłę ale stosować ją tam gdzie ma to sens a puki co to odnoszę wrażenie że niewielu ją docenia.
To że BOOPSI wylądowało w Intuition nie znaczy że nie można go przenieść gdzieś indziej a w Intuition zostawić tylko przekierowania. Każdy model składa się z warstw co należy konsekwentnie stosować a po wykonaniu powyższych przenosin wszystko by się zgadzało. Oczywiście to nie zmienia tego co napisałem wcześniej że nie należy BOOPSI stosować na siłę.

Rozumiem argument o PDA, faktycznie nie miałoby to nic wspólnego z Amigą. Na szęście na Eclipsis będzie ABox

No wiesz jak rozumiem QBoxa jeszcze nie ma więc się magicznie z powietrza nie weźmie ale mi chodzi o sytuację gdy już będzie.

Postaraj się zrozumieć, że nie da się na przykład przejść na system 64 bitowy zachowując zgodność z 32 bitowym.

Zależy o jakiej zgodności rozmawiamy.
Czy MorphOS/Quark/QBox są 64bitowe?

Nikt nie chce rozstawać się ze środowiskiem AmigaOS, ale pewne technologie NIE SA i NIE BĘDĄ dla niego osiągalne.

Na przykład jakie?

Stąd konieczność zaoferowania użytkownikowi czegoś więcej. Uważasz, że lepiej byłoby, gdyby każdy musiał kupować drugi komputer by móc pozostać "na czasie"?

Postęp jest konieczny co do tego nie ma wątpliwości. Jednak uważam że dotychczasowego AmigaOSa można “wyprowadzić na prostą” a po pewnym czasie (kilka lat) zrezygnować z dodatków zapewniających kompatybilność. Ale nie o tym był zasadniczo mój pierwszy post tylko o faktach i możliwościach jakie zawarte są w specyfikacji a na które może nie wszyscy zwrócili uwagę. Mało tego starałem się ich nawet nie oceniać bo każdy oceni je po swojemu.
Co do MorphOSa Quarka/ABoxa/QBoxa to wydaje mi się że tak jak to zostało zrobione to jest to zmarnowany wysiłek. Według mnie należało zrobić Quarka/QBoxa i zrobić na to wersje UAE. Wyszło by na to samo a byłaby większa kompatybilność i byłby gotowy QBox więc można by od razu pisać pod nowy system. Jeżeli byłby dobry to nie byłoby powodów żeby Amigowcy się na niego nie przesiedli tym bardziej, że chodziłby na sprzęcie który już mają. Dlaczego postąpiono na odwrót? Według mnie bo nie było oznak że coś się ruszy z AmigaOSem i chciano wylansować MorphOSa jako nową wersję AmigaOSa, którą nie jest. Sprawy się pokomplikowały bo nowy AmigaOS jest w produkcji a dwa konkurencyjne systemy na tak małym rynku to o jeden za dużo. Może się to skończyć tak że nikt nie zarobi tyle by móc kontynuować prace.

Odpowiedz

Dominik Kowalski
Czytelnik

komentarz #29 wysłany: brak daty w odpowiedzi na komentarz #16

I w tym momencie wykazujesz braki w wiedzy na temat AmigaOS.

Rozumiem że to stwierdzenie ma zastąpić argumenty merytoryczne

Procesow czy zadan wymieniajacych miedzy soba wiadomosci jest cala masa. Ba! Od wymiany tych informacji zalezy cale funkcjonowanie systemu. Chcesz przyklad bardzo czesto komunikujacego sie z innymi procesu? Wez dowolny filesystem. To jest normalny proces, ktory w petli czeka na nadchodzace wiadomosci. Cala komunikacja z nim odbywa sie dzieki wiadomoscia. Czy dasz takiemu procesowi dostep do calej przestrzeni adresowej? Wtedy ochrona pamieci nic Ci nie da, bo jednym programem bede w stanie wywalic w powietrze dowolny inny.

Oczywiste jest że musiałaby istnieć warstwa zapewniająca możliwość pracy procesów 3.x na nowym systemie. I miałaby ona dostęp do pamięci wszystkich tych procesów ale ta warstwa stanowiłaby fragment systemu operacyjnego i nic w tym dziwnego ze miałaby takie możliwości. Ona właśnie rozwiązywała by tą kwestie o której piszesz przetwarzała by wiadomość dla file systemu z “starej” postaci na “nową” i wysyłała do nowego file systemu który byłby “nowym” procesem przez co separowanym od innych.
I jeszcze tak a propos braków w wiedzy na temat AmigaOS słyszałeś kiedyś o dos.library? Ile programów korzysta prosto z file systemu? Raczej nie cała masa o której wspominasz.

Inna sprawa to separacja przestrzeni adresowych.

Nie inna tylko ta sama bo wszystko się sprowadza do separacji przestrzenie adresowych i do tego żeby stare procesy tego nie zauważyły.

Jak rozwiazalbys to w AmigaOS? Zauwaz, ze nawet ludzie piszacy AmigaOS 4 nie wspominaja o pelnej ochronie pamieci. NA poczatek beda blokowali mozliwosc pisania sobie po kernelu albo po niezaalokowanej pamieci. A reszta?

Może dlatego że w 5 minut się tego nie napisze

BOOPSI ...

Sprawa BOOPSI i obiektowości w systemie dotyczyła w mojej pierwszej wypowiedzi czegoś zupełnie innego czyli: jakim systemem jest MorphOS jeśli chodzi o podział który przedstawiłem. Po prostu w specyfikacji którą przedstawiono brakowało mi na przykład tak sformułowanego zdania: “Komponenty binarne w systemach operacyjnych są ważnym elementem dlatego w QBoxie będzie możliwość ich tworzenia”. Wskazywałoby ono że twórcy MorphOSa dostrzegają zmiany jakie zachodzą dookoła i że nie będzie on systemem z minionej epoki. A tak na prawdę tam nie ma prawie nic na temat QBoxa i stąd moje wątpliwości jakim systemem jest MorphOS poza ABoxem.

tez nie opakowuje calego systemu operacyjnego w klasy. Owszem, mozna sie dopatrzyc elementow obiektowosci (kazda biblioteka to tak jakby klasa ktora ma pewne pola publiczne, pewne prywatne, a ponizej jej adresu bazowego ciagnie sie fikusnie skonstruowana tablica funkcji wirtualnych), ale BOOPSI wszedzie sie nie wetknie.

Jeśli chodzi o kwestie wykorzystania BOOPSI to uważam, że jest to technologia niedoceniona i można by przy jej pomocy dużo więcej zrobić niż jest robione teraz. I że można ją wykorzystać w wielu miejscach nie koniecznie do obudowywania istniejących mechanizmów ale do tworzenia nowych zarówno w systemie jak i w aplikacjach.

i tak dalej i tak dalej...

Czyżby?

Odpowiedz

Nowar
konto zablokowane
lub usunięte

Czytelnik

komentarz #30 wysłany: brak daty w odpowiedzi na komentarz #28

Szanowny Panie...Z punktu widzenia zwyklego uzytkownika Amigi, mowisz Pan galimatias. Jak Pan teraz uzywa Amige? (Prosze nie mowic ze zadna, poniewaz powyzsza wypowidz nie bedzie miala zadnego sensu.

Odpowiedz

Jacek Piszczek
Czytelnik

komentarz #31 wysłany: brak daty w odpowiedzi na komentarz #28

Widzę, że na tym forum się nie dogadamy, zapraszam na kanał #amisia na ircnecie. Albo może podasz email, który nie jest zmyślony? A może nawet nie podpisujesz się swoim prawdziwym imieniem i nazwiskiem?

Odpowiedz

Kornel Lesinski
Czytelnik

komentarz #32 wysłany: brak daty w odpowiedzi na komentarz #28

to procesy/taski te wchodzą do jednego podzbioru i dzięki temu mieszają tylko sobie.

czyli kazdy program moze mieszac "tylko" po exec'u, intuition, device'ach, programie do ktorego nalezy ekran na ktorym okno otworzyl itd...

na co mi ochronienie odtwarzacza mp3 od edytora tekstu jesli caly OS mozna powiesic spokojnie mimo tego?
szkoda pracy na zabawe w takie rzeczy, ktore zrodza jeszcze wieksza niekompatybilnosc.

AmigaOSa można “wyprowadzić na prostą” a po pewnym czasie (kilka lat) zrezygnować z dodatków zapewniających kompatybilność.

no to juz masz - MorphOS. narazie amigowcy robia tylko duze "buuuuu" ze im to i tamto nie dziala, bo zostalo "wyprowadzone na prosta", a to jedynie delikatne zmianki sa.
Jakie sie smiesznosci robia po takim wyprowadzaniu dobrze wiedza ludzie znajacy win32 api.

Odpowiedz

michalsc
konto zablokowane
lub usunięte
Czytelnik

komentarz #33 wysłany: brak daty w odpowiedzi na komentarz #29

I w tym momencie wykazujesz braki w wiedzy na temat AmigaOS.

Rozumiem że to stwierdzenie ma zastąpić argumenty merytoryczne

Nie rozumiem o co Ci chodzi. Przeciez argumenty byly podane dalej.

Oczywiste jest że musiałaby istnieć warstwa zapewniająca możliwość pracy procesów 3.x na nowym systemie. I miałaby ona dostęp do pamięci wszystkich tych procesów ale ta warstwa stanowiłaby fragment systemu operacyjnego i nic w tym dziwnego ze miałaby takie możliwości. Ona właśnie rozwiązywała by tą kwestie o której piszesz przetwarzała by wiadomość dla file systemu z “starej” postaci na “nową” i wysyłała do nowego file systemu który byłby “nowym” procesem przez co separowanym od innych.

Napisanie takiej warstwy sprowadzilo by sie w sumie (dzieki konstrukcji jaka ma AmigaOS do wersji 3.x) do napisania dwoch kerneli, przy czym jeden zapewnialby jaka taka zgodnosc w dol, a drugi udostepnial nowe mozliwosci. Cos takiego masz w Pegasosie.

I jeszcze tak a propos braków w wiedzy na temat AmigaOS słyszałeś kiedyś o dos.library? Ile programów korzysta prosto z file systemu? Raczej nie cała masa o której wspominasz.

A czy ty wiesz, ze funkcje bibliotek (w tym i dos.library) pracuja w przestrzeni adresowej procesu ktory je wywoluje? To znaczy ze twoj proces musi miec rowniez prawo pisania po bazie biblioteki gdyz funkcje biblioteczne moga tego potrzebowac.
Nie chcesz chyba tworzyc dla kazdej biblioteki osobnego procesu (tak, zeby nikt przez zlosliwosc czy glupote nie zepsul Ci chociazby ExecBase) ktory w dodatku przy wywolaniu funkcji potencjalnie naruszajacych ochrone pamieci bedzie analizowal kto chce co wyslac do kogo, ile i dlaczego.

Wiesz tez oczywiscie, ze to wysylanie pakietow ktore lezy w rekach dos.library sprowadza sie do wyslania wiadomosci do filesystemu? dos.library jest w tym miejscu tylko i wylacznie przedluzeniem twojego programu, wiec mala roznice robi to, czy ty sam przesylasz dane do systemu plikow, czy robi to za ciebie bilioteka.

Jeśli chodzi o kwestie wykorzystania BOOPSI to uważam, że jest to technologia niedoceniona i można by przy jej pomocy dużo więcej zrobić niż jest robione teraz. I że można ją wykorzystać w wielu miejscach nie koniecznie do obudowywania istniejących mechanizmów ale do tworzenia nowych zarówno w systemie jak i w aplikacjach.

Jesli chodzi o obiektowosc (pomijajac juz BOOPSI), to rozbudowywanie za jej pomoca pewnych elementow systemu moze sprawiac frajde (np. sterownik do nowej karty graficznej dostarczajacy na poczatku tylko kilka metod a dziedziczacy wszystkie niezaimplementowane), ale nie wszedzie sie nadaje.

Odpowiedz

Dominik Kowalski
Czytelnik

komentarz #34 wysłany: brak daty w odpowiedzi na komentarz #33

Nie rozumiem o co Ci chodzi. Przeciez argumenty byly podane dalej.

Tylko że mało trafne więc wygląda tak, że ten tekst na otwarcie miał je wspierać.

Napisanie takiej warstwy sprowadzilo by sie w sumie (dzieki konstrukcji jaka ma AmigaOS do wersji 3.x) do napisania dwoch kerneli, przy czym jeden zapewnialby jaka taka zgodnosc w dol, a drugi udostepnial nowe mozliwosci.

Nie. Jeden kernel/zestaw bibliotek ze swoim API i warstwa udostępniająca stare API, która nie zawierałaby żadnej funkcjonalności a jedynie tłumaczyłaby i przekierowywała odwołania.

Cos takiego masz w Pegasosie.

Pegasos to chyba raczej sprzęt więc miałeś na myśli MorphOSa.
Przypuszczam, że tak jak napisałeś to jest akurat w MorphOSie. ABox, który korzysta z Quarka a QBox będzie od niego niezależny czyli dwa komplety API z dwoma implementacjami.

A czy ty wiesz, ze funkcje bibliotek (w tym i dos.library) pracuja w przestrzeni adresowej procesu ktory je wywoluje?

W AmigaOS do wersji 3.9 wszystko się dzieje w jednej przestrzeni adresowej.

Nie chcesz chyba tworzyc dla kazdej biblioteki osobnego procesu (tak, zeby nikt przez zlosliwosc czy glupote nie zepsul Ci chociazby ExecBase)

Mylisz przestrzenie adresowe i procesy. Nie trzeba tworzyć osobnego procesu żeby umożliwić izolację od struktur systemowych ,wystarczy odpowiednio zmieniać przestrzenie adresowe na których on działa.

Wiesz tez oczywiscie, ze to wysylanie pakietow ktore lezy w rekach dos.library sprowadza sie do wyslania wiadomosci do filesystemu? dos.library jest w tym miejscu tylko i wylacznie przedluzeniem twojego programu, wiec mala roznice robi to, czy ty sam przesylasz dane do systemu plikow, czy robi to za ciebie bilioteka.

Nie ma znaczenia jak to się odbywa teraz ponieważ rozmawiamy o tym co trzeba zrobić żeby wprowadzić ochronę pamięci. Interesują nas więc punkty w których prosessy/taski kontaktują się z systemem a nie jak to jest dalej realizowane ponieważ to można bez jakichkolwiek problemów zmienić. Takim punktem są funkcje dos.library operujące na plikach. Dostają one w parametrach dane o znanej strukturze i znaczeniu. Można je odczytać i zrobić z nimi cokolwiek przy użyciu procesu aplikacji czy innego procesu i przy ustawionej takiej czy innej przestrzeni adresowej. Nie ma to znaczenia. Ważny jest tylko właśnie ten punkt styku.

Jesli chodzi o obiektowosc (pomijajac juz BOOPSI), to rozbudowywanie za jej pomoca pewnych elementow systemu moze sprawiac frajde (np. sterownik do nowej karty graficznej dostarczajacy na poczatku tylko kilka metod a dziedziczacy wszystkie niezaimplementowane), ale nie wszedzie sie nadaje.

Sama obiektowości to materiał na kolejny wątek. Ale krótko. Tak na prawdę to w zasadzie każdy program jest napisany obiektowo. Jeżeli do jakieś funkcji przekazujemy strukturę i coś z nią robimy to ona reprezentuje nasz obiekt a funkcja metodę. Dlatego trafniej jest mówić o tym że dany język czy technologia wspiera obiektowość czyli że dostarcza mechanizmów, które gdzieś indziej musielibyśmy sami tworzyć.
Co do wykorzystania tych mechanizmów w systemach operacyjnych to na przykład część API w BeOSie jest w C++ są też systemy w całości napisane w C++ czyli wspieranie obiektowości można wykorzystać wszędzie. Czy należy to robić jest kwestią oszacowania potrzeb i wymagań.

Odpowiedz

Dominik Kowalski
Czytelnik

komentarz #35 wysłany: brak daty w odpowiedzi na komentarz #32

czyli kazdy program moze mieszac "tylko" po exec'u, intuition, device'ach, programie do ktorego nalezy ekran na ktorym okno otworzyl itd... na co mi ochronienie odtwarzacza mp3 od edytora tekstu jesli caly OS mozna powiesic spokojnie mimo tego? szkoda pracy na zabawe w takie rzeczy, ktore zrodza jeszcze wieksza niekompatybilnosc.

O konieczności ochrony danych bibliotek i o tym jak można to zrobić pisałem wcześniej. Mieszać tylko sobie czyli tylko po swoich danych a nie po strukturach bibliotek. Sugeruję lekturę poprzednich postów.

no to juz masz – MorphOS.

MorphOS to nie nowy AmigaOS on tylko umożliwia uruchamianie programów z AmigaOS i z tego co czytałem tylko do wersji 3.1 czyli już na starcie jest w tyle. O tym czym jest i jak działa MorphOS też już tu rozmawialiśmy.

narazie amigowcy robia tylko duze "buuuuu" ze im to i tamto nie dziala, bo zostalo "wyprowadzone na prosta", a to jedynie delikatne zmianki sa.

Przeważnie nie działa bo zostało napisane niezgodnie z wytycznymi pisania pod AmigaOS lub z powodu jakiś krzywych patchy pozakładanych na system. Sądzę, że większość programów by nie zauważyła gdyby zostały zastosowane mechanizmy, o których piszę.

Jakie sie smiesznosci robia po takim wyprowadzaniu dobrze wiedza ludzie znajacy win32 api.

Głównie ci którzy nie umieją czytać. W MSDNie jest przy każdej funkcji napisane na czym i jak działa a na czym nie. Z resztą od początku było powiedziane, że nie na każdym Windowsie wszystko będzie działać tak samo.

Odpowiedz

Dominik Kowalski
Czytelnik

komentarz #36 wysłany: brak daty w odpowiedzi na komentarz #31

Albo może podasz email, który nie jest zmyślony?

Z powodu spamu staram się tego nie robić.

A może nawet nie podpisujesz się swoim prawdziwym imieniem i nazwiskiem?

A może mnie nie ma?

Odpowiedz

Dominik Kowalski
Czytelnik

komentarz #37 wysłany: brak daty w odpowiedzi na komentarz #30

Szanowny Panie...Z punktu widzenia zwyklego uzytkownika Amigi, mowisz Pan galimatias.

To, że niektórzy z tego o czym rozmawiamy rozumieją tylko spójniki mnie nie dziwi ale to nie jest moja wina tylko raczej braki w ich wiedzy, której z drugiej strony oczywiście nie muszą posiadać.

Jak Pan teraz uzywa Amige?

Włączam monitor, włączam Amigę a jak się zbutuje to klawiaturą i myszką.

(Prosze nie mowic ze zadna, poniewaz powyzsza wypowidz nie bedzie miala zadnego sensu.

Zapewniam, że to jak używam Amigi nie ma najmniejszego wpływu na architekturę i działanie AmigaOSa, MorphOSa (kolejność alfabetyczna) i jakiegokolwiek innego systemu operacyjnego.

Odpowiedz

eXec - magazyn użytkowników komputerów Amiga

MorphOS - nowe zestawienie cech systemu