Komentowana treść: Aktualizacja AmigaOS 4
19.07.2007 17:45
[#121]
Re: Aktualizacja AmigaOS 4
@marcik, post #81
A ze wspoldzielone obiekty w wersji amigowej tak naprawde nie sa wspoldzielone to cala ich fajnosc znika i biblioteki amigowe moga sie czuc niezagrozone
A skąd wiadomo że są nie współdzielone?
Kod w .so jest niezależny od adresu.
Może być załadowany w dowolne miejsce pamięci.
Więc tak naprawdę zależy od implementacji - może być w paru miejscach wirtualnie i jednym fizycznie.
Wówczas można korzystać z wszystkich zalet .so.
A tych w porównaniu do starych amigowych bibliotek jest bardzo dużo.
Ostatnia edycja: 19.07.07 17:46:42
19.07.2007 17:59
[#125]
Re: Aktualizacja AmigaOS 4
@marcik, post #123
Od ich tworcow. Freidenowie od dluzszego czasu nie kryli sie z tym ze te wspoldzielone obiekty nie beda wspoldzielone.
Sprawdziłeś?
Bo moim zdaniem da radę zrobić w Os 4 tak żeby kod był współdzielony, zwłaszcza jak się jest autorem execa.
Nie teraz, będzie następnym razem.
A nawet jeśli nie są współdzielone, to w porówaniu do starych amigowych bibliotek mają tyle zalet że warto je stosować.
19.07.2007 18:25
[#131]
Re: Aktualizacja AmigaOS 4
@marcik, post #127
Potwierdzili to kilka razy, po wydaniu tez.
A gdzie to potwierdzili?
Moglbys w skrocie wymienic?
- łatwość tworzenia takich bibliotek
- łatwość przenoszenia z unixa takich bibliotek
- automatyczne łączenie z obiektami w aplikacji i innych bibliotekach
Moim zdaniem zamiast krytyki Os 4 fanboye MOSa powinni naciskać na MOSTeam, żeby jak najszybciej .so były w MOS.
Ostatnia edycja: 19.07.07 18:26:51
. 19.07.2007 19:29
[#140]
Re: Aktualizacja AmigaOS 4
@norbert74111, post #139
Na przykład wymyśliłem że MOS mógłby prześcignąć A Os 4
gdyby:
- wprowadzono w nim maszyny wirtualne -
np chcę korzystać z programów z linuxa
- jeśli jeszcze nie jest uruchomiona
- uruchamia się gdzieś działająca pod kontrolą MOSa maszyna wirtualna
- na niej program który chcę używać
- na MOSie widąc tylko kolejny screen.
Oczywiście musi się dać przenosić zawartość clipboardu między
MOS a linuxem, muszą się dać pliki przenosić.
gdyby:
- wprowadzono w nim maszyny wirtualne -
np chcę korzystać z programów z linuxa
- jeśli jeszcze nie jest uruchomiona
- uruchamia się gdzieś działająca pod kontrolą MOSa maszyna wirtualna
- na niej program który chcę używać
- na MOSie widąc tylko kolejny screen.
Oczywiście musi się dać przenosić zawartość clipboardu między
MOS a linuxem, muszą się dać pliki przenosić.
19.07.2007 19:41
[#146]
Re: Aktualizacja AmigaOS 4
@marcik, post #94
Czy dla ciebie "support" oznacza tworzenie bibliotek, czy ich używanie, rozumiane jako wykorzystywanie jej zawartości? Ogólnie, oczywiście może to oznaczać i jedno i drugie, ale szczególnie w kontekście newsa chodzi o to drugie. Oto bowiem pojawiły się pliki z kodem typu .so rodem z linuksa do użycia na Amidze i ten temat m.in. omawiamy. Czyż nie?
Zresztą, zaprzeczyłeś tak naprawdę sam sobie, bo przywołałeś przełącznik pozwalający złączyć bibliotekę, a więc jej użyć. Okrasiłeś to przy okazji komentarzem o tworzeniu biblioteki. Bardzo więc proszę o nie rozmijanie się z tematem. Chyba, że to jest jakaś nowa metoda prowadzenia konwersacji. Skoro tak, to raczej nie ze mną.
Co ma też oznaczać ten ostatni wtręt o "protezie" skoro wyraźnie jest powiedziane, że pliki .so nie zastępują modelu bibliotek dzielonych Amigi, a tylko go uzupełniają w celu ułatwienia portowania programów linuksowych? Jakby nie patrzeć protezy służą do zastępowania, a nie do uzupełniania, a więc uparcie zmieniasz temat.
Taka, to jest właśnie z wami "niebieskimi" rozmowa. Ale niech czytelnicy wiedzą, dlaczego nie ma sensu jej kontynuować.
Zresztą, zaprzeczyłeś tak naprawdę sam sobie, bo przywołałeś przełącznik pozwalający złączyć bibliotekę, a więc jej użyć. Okrasiłeś to przy okazji komentarzem o tworzeniu biblioteki. Bardzo więc proszę o nie rozmijanie się z tematem. Chyba, że to jest jakaś nowa metoda prowadzenia konwersacji. Skoro tak, to raczej nie ze mną.
Co ma też oznaczać ten ostatni wtręt o "protezie" skoro wyraźnie jest powiedziane, że pliki .so nie zastępują modelu bibliotek dzielonych Amigi, a tylko go uzupełniają w celu ułatwienia portowania programów linuksowych? Jakby nie patrzeć protezy służą do zastępowania, a nie do uzupełniania, a więc uparcie zmieniasz temat.
Taka, to jest właśnie z wami "niebieskimi" rozmowa. Ale niech czytelnicy wiedzą, dlaczego nie ma sensu jej kontynuować.
19.07.2007 19:48
[#150]
Re: Aktualizacja AmigaOS 4
@norbert74111, post #131
A gdzie to potwierdzili?
Odpowiem nie wprost. Zmuszenie bibliotek .so pod OS4 do wspoldzielenia kodu wymagalo by na tyle duzej rewolucji w podejsciu do zarzadzania pamiecia, ze na pewno by ten fakt oglosili (tym bardziej, ze Fiedenowie maja w zwyczaju chwalenie sie wszystkimi nowosciami, nawet tymi mniej istotnymi).
- łatwość tworzenia takich bibliotek
Amigowe biblioteki tez latwo sie tworzy.
- łatwość przenoszenia z unixa takich bibliotek
To jest jedyny sluszny argument, ale w takim wypadku wystarczylby kernel linuksa i X11. Zobacz tutaj.
- automatyczne łączenie z obiektami w aplikacji i innych bibliotekach
To moze byc zarowno zaleta jak i wada, szczegolnie w amigowym swiatku. Automatyczne (dynamiczne) laczenie z innymi obiektami w trakcie uruchamiania programu powoduje, ze programy zwyczajnie startuja wolniej. Najpierw startuje tzw. Program Interpreter (ld-linux.so). Interpreter musi zaladowac niezbedne obiekty dynamiczne (w przypadku AmigaOS), i relokowac wszystkie niezbedne symbole (odwolania do symboli bedacych w innych obiektach dynamicznych). I skonczy sie wzdychanie do AmigaOS ("bo program laduje sie w 2 sekundy, a podobny program pod linuksem 10 sekund).... ;)
jak sobie pomysle biliotekach w C++ i o rekolowaniu symboli w stylu:
_ZN13QScriptEngine10newQObjectEP7QObjectNS_14ValueOwnershipERK6QFlagsINS_17QObjectWrapOptionEE
(biblioteka libQtScript.so.4.3.0), to mam bardzo mieszane uczucia ;)
Oczyscie mozna to zrobic lepiej. Mozna najpierw uczynic te obiekty dzielone naprawde dzielonymi (jesli nie, to trzeba bedzie amigowcom dokupic troche pamieci). Mozna poprawic kod korzystajac z atrybutu widocznosci symboli (linuksowe/uniksowe bibliteki zadko z tego korzystaja), mozna tez podejsc troche inaczej do sposobu linkowania i relokowania objektow wspoldzielonych (chocby tak jak jest to w windowsie i jego DLL-kach). Tyle, ze te wszystkie "mozna" oznaczaja modyfikowanie lub poprawianie zrodel, a wtedy jedyny w miare sensowny argument - "łatwość przenoszenia z unixa takich bibliotek" znika...
PS. Zarzadzanie wersjami w przypadku .so lezy i kwiczy...
O czyms zapomnialem?