Autor: Grzegorz Szyszlo (znik_at_avalon.wbc.lublin.pl)
Data: Wed 29 Jan 1997 - 20:35:03 MET
KARPIO_at_golem.umcs.lublin.pl (Andrzej Karpinski) wrote:
>>>oczywiscie bzdura. masz dwie mozliwosci -
>>
>>oczywiscie bzdura....
>
>dziekuje za doglebne wyjasnienie. lubie jak odpowiadasz wymownie i z
>sensem. zamiast argumentow, ktore pojawily sie w ilosci dosc duzej po
>moim "oczywiscie bzdrua" ty dopisales swoje i postawiles wielokropek.
>sprytne, bo co bym nie napisal to odpowiesz ze to wlasnie miales na mysli
>(bylo za wielokropkiem). wybacz, ale tak dyskutowac nie bedziemy.
oczywiscie bzdura..... :))))))))))))) przeciez wiesz ze nie masz racji :))
>>>czyli mozesz sobie dowolnie ksztaltowac mape pamieci (!),
>>
>>tak to sie pisalo samobootujace gry na amige 500 (nie wiem czy wyzsze) :))))
>
>tak dziala kazdy program pod dos.
drobna uwaga. niektore dema pod DOS.
>a pod windows nie musze chyba
>tlumaczyc, ze ograniczenie 640kb wlasciwie nie istnieje. nawet pod starym
>winblows 3.0... o czym wiec piszesz, bo nie za bardzo rozumiem?
w takim razie zrozum, zamiast jakies herezje wypisywac.
>pod dosem
>sie da, i tak wszyscy robia, a pod windows etc. takowych ograniczen brak,
>bo system to zalatwia. gdziez tu miejsce na twoje madrosci?
zastanawiam sie gdzie na twoje. pod windows sa takie same ograniczenia
jak i w dosie. mowie o 3.11. czy slyszales o dos extenderach ?
nie wiem czy wiesz (bo jak dotad plotles bzdury), ale te extendery pracuja
glownie jako serwery DPMI. sam windowze tez pracuje jako taki extender DPMI,
roznica jest tylko taka ze udostepnia API do roznych badziewi. No i to dosowe
DPMI ma ochrone pamieci zdaje sie. no nie ?
>>EMS jest standardem pamieci na boku, nie ma ona nic wspolnego z pamiecia
>>operacyjna komputera (do montazu w XTkach). wiec trudno tu mowic o
>>adresowaniu liniowym pamieci procesora, lub tym bardziej o dostepie
>>do jakichkolwiek pamieci wyzszych. jest to "pamiec na boku" :))
>>obecnie emulowana w obszarze XMS.
>zwlaszcza EMS 4.0 - zycze udanej implementacji w postaci karty
>rozszerzenia do XT. w sumie to prosta rzecz podkladac dowolnej wielkosci
>bloki pamieci pod dowolne adresy i wzajemie je podmieniac, zamieniac,
>mieszac ;) czy ty zniku tak naprawdfe rozumiesz co to jest i gdzie jest
>EMS i ze to fizycznie jest najczesciej dokladnie ta sama pamiec, do
>ktorej masz takze dostep via XMS?
czy musisz sie po mnie powtarzac ? przeciez to napisalem ze teraz jest
emulowana. jesli chodzi o specyfikacje EMS 4.0, dokladnie jej nie znam.
tam w zasadzie jedynie uscislili gdzie maja byc ktore bloki, i jakie sa
ograniczenia w ich rozmieszczeniu. pisze o stronach widocznych w obszarze
640KB>....<1MB. chyba ze masz jakies lepsze zrodlo informacji, to prosze
powiedz mi czemu EMS 4.0 nie da sie zaimplementowac na XT. slucham.
>>z kolei w XMS tez nie masz zadnego wplywu na to, gdzie sie znajduja
>>konkretne bloki. po rzadaniu przydzialu obszaru, dostajesz jedynie
>>pewna liczbe (cos w rodzaju deskryptora), ktora jest identyfikowana
>>z tym przydzielonym obszarze. poslugujac sie ta liczba mozesz potem
>>zadac transmisji danych pomiedzy obszarem RAM na dole, a przydzielonym blokiem
>>w XMS.
>ale po co to piszesz?
po to zeby pokazac, ze bzdura jest myslec ze XMS pozwala na liniowe
adresowanie pamieci, i dostep do wskazanych adresow. mozna uzyskac co najwyzej
dostep do wskazanego bloku.
>jesli korzystasz z XMS to masz dostep do
>"odrobinke" wiekszego obszaru pamieci niz 640kb o ktorych rozmawiamy.
>koniec dowodu.
czyli czarne pudelko :)))) zdaje sie ze sie rozwodziles o liniowosci dostepu
do XMS :) ciekaw jestem jak wyjasnisz, ze przerwania sa wstrzymywane
na czas transmisji (dolny obszar RAM)<->(blok XMS) :))))
>>>extendery - dowolne rzeczy w zaleznosci o pomyslowosci autora takiego
>>>extendera). aplikacja (ring 3) faktycznie nie ma pojecia o tym w
>>>ktorym miejscu pracuje - widzi ciagly obszar, ktory sie moze
>>>znajdowac gdziekolwiek (chociazby na dysku).
>>
>>to samo masz w DPMI.
>czytaj uwaznie.
a ty wyciagaj poprawne wnioski.
>>czy dowolne, tego bym nie powiedzial. co najwyzej mozesz okreslac
>>tablice deskryptorow, je aktywizowac i dezaktywowac. oreslac wyjatki,
>>dzieki ktorym mozesz zachowywac zbedne bloki na dysku, a potrzebne
>>odczytywac w powstale wolne miejsca.
>
>dowolnie. wlasciwie dowolnej wielkosci i w dowolnym miejscu, bez wzgledu
>na fizyczna mape pamieci.
no to przydziel mi blok pamieci, ktory bedzie zachaczal o dwa sasiadujace
juz przydzielone bloki :))))
>>>> 1. w trybie rzeczywistym nie mozna zaadresowac wiecej niz 1M+64k-16
>>>> 2. segmenty w rozumieniu trybu chronionego sa czyms zupelnie innym
>>>> niz 64k segmenty (nazwijmy to "fizyczne") w rozumieniu trybu
>>>> rzeczywistego i virtualnego.
>>>> 3. jezeli pomiinac blad o trybie rzeczywistym - mozna zaadresowac
>>>> znacznie wiecej niz caly RAM. i program bedzie dzialal
>>>
>>>1. mozna. 2. masz racje, ale nie o tym mowie. 3. nie dotyczy. jutro
>>>podesle jak zmodyfikowac tablice deskryptorow, by w trybie
>>>rzeczywistym wielkosc segmenu byla rowna 4gb. zapewniam ze da sie to
>>>zrobic (niestety pamiec ludzka tez jest ulotna).
>
>>dac sie da, tylko z czym to bedzie zgodne......
>
>z dosem. co wiecej potrzeba?
no wiec uzywaj swojego kochanego dosa :))))
>albo piszesz program pod dos, i sie klocisz
>ze mna ze nie masz dostepu do calego ramu (wtedy proponuje ci moj
>(wlasciwie to wcale nie moj) patent), albo piszesz pod
>windows/os2/linux/korzystasz z dos-extendera i wtedy nie ma tematu, bo
>widzisz wiecej ramu niz 640kb. po co znowu glupkowata dyskusja? koniec
>dowodu.
>
>karpio
ale z ciebie 'dowodziarz' :)))) tylko co ma wspolnego pamiec
przydzielana przez XMS i serwer DPMI z adresowaniem liniowym :)))
zwlaszcza kiedy od serwera DPMI zarzadasz utworzenia swap file :)
idz sie lepiej wyspij a dopiero potem poczte czytaj.
--
oOOo /===================================\
/=====\__/=====/ http://avalon.wbc.lublin.pl/~znik |
| Grzegorz Szyszlo mailto:ZNIK_at_avalon.wbc.lublin.pl |
\===================================================/
polecam http://www.agh.edu.pl/ogonki/ mime.html
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 15:53:24 MET DST