🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: pl.comp.os.advocacy
Article #2771

Re: Używanie narzędzi M$ przez studentów

#2771
From: Paweł Paroń
Date: Thu, 15 Jan 1998 09:50
82 lines
5572 bytes
On Thu, 15 Jan 1998 03:08:18 GMT, Piotr Trzcionkowski <ZmieńNa_trzcionk@us.edu.pl> wrote:

>O boziu, zaczyna się ta sama dyskusja.
>
>Plik tekstowy ma sekwencyjną naturę. Jedynym rozsądnym sposobem
>skorzystania z niego jest przeczytanie całości od początku do końca.
>Toteż programy tak robią i wszystko ładują do pamięci. Całe te
>240..300KB wylądowało więc w pamięci. Gdyby nawet program usiłował
Co nie znaczy, że te 300KB w pamięci cały czas siedzi. Program czyta
plik, ustawia sobie jakieś tam parametry i nic nie stoi na przeszkodzie,
żeby potem tę pamięć zwolnić. Oczywiście pod Unixem, zwalnianie raz zajętej
pamięci pod windą jakoś tak się nie sprawdza, a przynajmniej nie do końca.
>[...]
>
>Teraz opiszę jak to wygląda w Windows. Zamiast plików tekstowych są
>binarne. Cechą plików binarnych jest możliwość skakania po nich.
I niemożność naprawienia, jak się coś zwali, czy też "rozjedzie" (jak mi to
sam napisałeś, że "w rejestrze coś tam, w pliku *.ini coś innego, bo 
się _rozjechało_"...

>Wymaga to oczywiście pewnej organizacji jednak pozwala na
>skonstruowanie czegoś takiego jak windowsowe zasoby. Zasoby to różnego
>rodzaju dane czy to ciągi, czy np. bitmapy, które są połączone z
>plikiem wykonywalnym, lecz nie są wczytywane do pamięci wraz z
>uruchomieniem programu. 
Nie. Zasoby, to jest po prostu coś, czego w windzie ubywa po każdym
uruchomieniu i zamknięciu jakiegoś programu. 

>Dopiero jawne odwołanie się w kodzie programu
>do zasobu powoduje, że znajdzie się on w pamięci fizycznej. Czyli
>jeśli program wyświetla okienko z zapytaniem to tylko wtedy. Jako, że
>wiadomo, gdzie (w exe,dll) mieści się oryginał, pamięć zajęta przez
>niego nigdy nie zostanie wymieciona do pliku wymiany tylko co najwyżej
>zwolniona. 
Zwykle nieskutecznie. Tak sie składa, że w swoim czasie pisałem trochę w C
pod windoze (nie w jakimś Visual, ani w żadnym C++, również bez dodatkowych
gadżetów, trefnych bibliotek typu owl, itp.). Robiłem programy do symulacji
sieci neuronowych, które z natury potrzebowały dużo pamięci i przy tej
okazji dane mi było się przekonać, ile jest warta winda. Praktycznie każde
zaalokowanie i zwolnienie większego obszaru pamięci powoduje, że owych
tajemniczych "zasobów" ubywa w zastraszającym tempie. Nawet jak program nic
nie robi, tylko alokuje i zwalnia pamięć. A jak już ruszy swapowanie, to
można się popłakać - wydawałoby się, że zabrakło tylko paru kb, a twardziel
rzęzi, przerzuca gigabajty w tę i z powrotem, jeden ruch myszką i gotowe -
niebieski ekran.

>Z tego też powodu plików używanych w systemie windows nie
>da się modyfikować, kiedy są "uruchomione". W taki to właśnie sposób
>da się oszczędzić ogromne ilości pamięci i nigdy całe 300KB nie
>znajduje się w pamięci tylko jakiś skromny procent. 
300KB to nie są "ogromne ilości pamięci". Zwłaszcza jak na windę, w której
300KB potrafi zniknąć bezpowrotnie po otwarciu okienka "About...".

>Niektóre z języków
>programowania robią jeszcze lepszą robotę. Np. w Delphi
>resourcestringi są integralną częścią języka. Odwołuje się do nich jak
>do zwykłych łańcuchów tekstowych. Nie dość tego Delphi próbuje
>odnaleźć właściwy moduł językowy na podstawie locale i lokalizacja
>polega na podłożeniu modułu (już tylko zasoby, bez kodu) dla danej
>wersji językowej. 
Kruczki, sztuczki, cała ta winda działa tylko dzięki serii magicznych
tricków, nie powiem, że trywialnych, ale po co to wszystko? To powinno
działać _normalnie_. Myślę, że gdyby przejrzeć źródła tych wszystkich
wordów, exceli i eksploderów, to pękłby człowiek ze śmiechu.
A zadaniem kompilatorów w prawdziwym systemie nie jest "robienie jeszcze
lepszej roboty", tylko po prostu kompilowanie, mające na celu uzyskanie
działającego poprawnie i efektywnie programu, którego źródła sobie sam
piszesz (a nie rysujesz, malujesz, składasz z kolorowych bloczków w
bajeranckich okienkach, itp.)

>Jak widać Linux "może się schować" ze swoimi pliczkami tekstowymi.
>ZAWSZE będzie zżerał więcej zasobów (rozumianych ogólnie).
U mnie już się schował w paru miejscach, m.in. na strychu. Raz go postawiłem
i działa, jeszcze trochę i zapomnę gdzie on sie schował.

>A cały ten wywód dowodzi tylko jak bardzo ograniczona jest wiedza
>linuxiarzy na temat nowoczesnych technik w szczególności tych
>zastosowanych w windows.
W windows zastosowano kilka nowatorkich technik. Takich jak nadzwyczaj
skuteczna technika ściemniania i ogłupiania małolatów.

Paweł
Technical Details
Message-ID: <slrn6brqnh.8gl.pawelp@rodan.rodan.pl>
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!pingwin.icm.edu.pl!news.icm.edu.pl!news.atm.com.pl!gajowy.rodan.pl!pawelp
References: <69g437$9md$1@sunrise.pg.gda.pl> <35251cc3.481832191@zeus.polsl.gliwice.pl> <34BCECBE.4019@krysia.uni.lodz.pl> <69j1lq$a6b$2@newsfeed.onet.pl> <69jane$2m8$1@sunrise.pg.gda.pl> <34fd7c93.571909582@zeus.polsl.gliwice.pl>

Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!pingwin.icm.edu.pl!news.icm.edu.pl!news.atm.com.pl!gajowy.rodan.pl!pawelp
From: Paweł Paroń <pawelp@rodan.rodan.pl>
Newsgroups: pl.comp.os.advocacy
Subject: Re: Używanie narzędzi M$ przez
 studentów
Date: 15 Jan 1998 09:50:44 GMT
Organization: Rodan-System
Lines: 84
Message-ID: <slrn6brqnh.8gl.pawelp@rodan.rodan.pl>
References: <69g437$9md$1@sunrise.pg.gda.pl> <35251cc3.481832191@zeus.polsl.gliwice.pl> <34BCECBE.4019@krysia.uni.lodz.pl> <69j1lq$a6b$2@newsfeed.onet.pl> <69jane$2m8$1@sunrise.pg.gda.pl> <34fd7c93.571909582@zeus.polsl.gliwice.pl>
Reply-To: pawelp@rodan.pl
NNTP-Posting-Host: dls059.ikp.pl
Mime-Version: 1.0
X-Newsreader: slrn (0.8.8.1 UNIX)
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit