🚀 go-pugleaf

d < 0 pisze:
>     wyobraźmy sobie, że wśród użytkowników komputerów osobistych popula-
> rność  zyskały  różne  architektury maszyn (w skrócie: różne komputery),
> ale  nie  znikomo różna —jak jest teraz, lecz absolutnie różne. załóżmy
> na  przykład, że  ludzie  mają i będą mieli w użytkowaniu stare typy ma-
> szyn, które  różnią  się  przynajmniej  tym, że mają mało pamięci ‘ram’,
> i ci  użytkownicy  chcą  być ‚nowocześni’— używać nowego oprogramowania.
> jakkolwiek— nowe  jest pisane jednostronnie— na nowe maszyny, na szybkie
> maszyny i mające sporo pamięci ‘ram’. stare komputery się… ;-) nie psu-
> ją… e… tak, nie  mają wbudowanego przez producentów, ukrytego wyłącznika
> wywołujacego  awarię, by  zmusić  tych  użytkowników do wymiany sprzętu.
> ;-) (patent, patent! to ja napisałem. ;-D )
>     a teraz— programy napisane nawet w tzw. ‛przenośnych’ technologiach,
> mimo  że  dałyby  się  skompilować  na  stare  maszyny, to  się  na nich
> ·nie· wykonają  z powodu niezgodności oczekiwań oprogramowania z dostęp-
> nymi  na  sprzęcie. i nie  pomoże  tu  symulacja  środowiska, w którym
> jest dużo pamięci, bo jedynym rozwiązaniem jest napisanie programu, któ-
> ry ·nie  ma· tych  wygórowanych wymagań i spełnia mniej wygórowane cele,
> lub  robi to —oczywiście (co się pomija, bo taniej)— optymalniej, ekono-
> miczniej dla użytkownika.
>     i jak to pogodzić? ‚spór’ chyba już trwa zbyt długo ;-) i chyba wa-
> rto  to pogodzić. wiadomo— jedną z metod jest pisanie wersji oprogramo-
> wania, które  są  na różne platformy sprzętowe, lecz czym to miałoby się
> różnić  od  pisania wielu programów. i zaznaczam: architektury docelowy
> są  drastycznie  różne, niezgodne  pod  względem  dostępnego  sprzętu,
> a nie  tylko  algorytmy  sprzętowe  są niezgodne (np. takie jak ‘big-en-
> dian’, ‘little-endian’). mówię  o niezgodności  maszyn, która  nie może
> być  uzgodniona przez odwzorowanie matematyczne (np. projektowe odwróce-
> nie kolejności bajtów w liczbie).
>     jakie  są  inne rozwiązania? w zasadzie— jakie są w ogóle rozwiąza-
> nia, ponieważ  ja nie znajduję niczego poza pustym słowem „przenośność”,
> którego skuteczność opiera się jedynie na tym, że nikt nie stosuje real-
> nie  niezgodnej maszyny, lecz odpowiednio niezgodnej, czyli konwertowal-
> nej. dlaczego  mam mieć najnowszą kartę graficzną, by móc zagrać w naj-
> nowsze ‚wypasione’ szachy, jeśli na starym komputerze wystarczy mi nary-
> sowanie planszy w trybie tekstowym lub choćby podawanie ruchów tekstowo,
> ponieważ zyskiem gry w szachy na komputerze w tym wypadku jest gra z in-
> ną  osobą  na  krańcu  świata  bez konieczności oczekiwania na odpowiedź
> o ruchu przez ‘e‐mail’? ale jeśli mam nowiuteńki sprzęt prosto z fabry-
> ki, to  chcę  go  użyć  do zobaczenia pięknej wizualizacji związanej też
> z opcjami konfiguracyjnymi drugiego gracza o jego bierkach.
>     i jak ugryźć ;-) przenośność?

 Można pisać programy mające wszystkie opcje, ale uruchamiające je na
żądanie lub w razie wykrycia odpowiedniej konfiguracji. Na przykład
program, któremu podasz wszystkie dane na linii poleceń nie musi
uruchamiać GUI składającego się z niewiadomo ilu okienek (zajmujących
oczywiście zasoby) i może skupić się na szybkim wykonaniu zadania.
Jeśli uda mu się zaalokować na przykład 1MB pamięci, może skorzystać z
jednego algorytmu, a jeśli nie, to może pracować według innego, mając
dane w kawałkach po 16kB. Jeśli program wykryje dobrą kartę graficzną,
może załadować bibliotekę z bajeranckim wyglądem, jeśli zostanie
uruchomiony w trybie tekstowym, ograniczy się do niego, tym samym
zużywając mniej pamięci i czasu procesora. Nie jest to równoznaczne z
pisaniem wielu programów, bo program jest jeden i tylko uruchamia
odpowiednie części (lub też nie).

 Maszyna nie musi być "konwertowalna". Skoro mówimy tu o "drastycznie
 różnych" architekturach docelowych, to zapominamy o asemblerze i
przenosimy się na przykład do C czy Javy. Sam napisałem kiedyś program
w Javie, który, jeśli otrzymał wszystko z linii poleceń, działał w
trybie całkowicie nieinteraktywnym i w ogóle nie uruchamiał GUI (które
miał wbudowane). To oznacza, że nie tylko uruchomiłby się na różnych
architekturach (co daje Java), ale uruchomiłby się nawet na maszynie
bez monitora (np. zdalnie na jakimś serwerze) czy w trybie tekstowym.
A program (nawet w sensie binarnym, jak to w Javie bywa) byłby ten sam.

 W programach "mających wszystko" można, według mnie, przyjąć dwa
podejścia:

1) domyślnie wszystko powyłączane (czyli minimalna implementacja),
poszczególne elementy (np. graficzne) uruchamiałyby się po wykryciu
odpowiadającej konfiguracji sprzętowej lub na żądanie użytkownika (w
tym, na przykład, na brak danych), z automatycznym powrotem do
ustawień "słabszych", gdyby w czasie uruchamiania "lepszych" wystąpił błąd

2) domyślnie wszystko włączone, z automatycznym uruchamianiem ustawień
"słabszych", gdy w czasie uruchamiania "lepszych" wystąpił błąd lub
gdy użytkownik zażądał np. tylko interfejsu tekstowego

 Binarka programu może być ciągle jedna i ta sama (i mała), a elementy
opcjonalne (np. interfejs graficzny) byłyby w osobnych modułach,
ładowanych w razie potrzeby. Tak było/jest np. z Wordem czy MSIE (nie
pamiętam dokładnie) - plik EXE programu to było tylko kilkadziesiąt kB
(a wiadomo, że cała funkcjonalność by się w tym nie zmieściła), a
razem z programem były DLLe po kilkaset kB. Podobnie można byłoby
zrobić z owym "przenośnym" programem.

 Jest też oczywiście opcja kompilacji warunkowej (np. w Asm/C/C++) -
program pisany jest ze wszystkimi możliwościami i tylko w czasie
kompilacji pod określoną maszynę podaje się kompilatorowi opcje, by
odpowiednie części kodu programu kompilował lub ich nie kompilował. To
nie jest, nie da się ukryć, pisanie wielu programów, bo kod ciągle
jest jeden (zawierający wszystko), zmienia się tylko wynik jego
kompilacji. W Javie co prawda nie ma bezpośrednio takiej możliwości,
ale można ją "zasymulować" poprzez ręczne sprawdzanie dostępności
elementów środowiska uruchomieniowego lub wychwytywanie błędów. To
podejście ogranicza jednak możliwości programu, gdyż w razie zmiany
konfiguracji sprzętowej maszyny docelowej (np. dołożenie nowej karty
graficznej) niezbędna jest ponowna kompilacja programu. Program
skompilowany w całości (ten z modułami) mógłby po prostu od tej pory
ładować sobie inny moduł interfejsu graficznego.

-- 
Pozdrawiam/Regards - Bogdan                     (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux):http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.JabberPL.org www.TorProject.org Soft (EN): miniurl.pl/bogdro-soft