Article View: pl.comp.os.advocacy
Article #2771Re: Używanie narzędzi M$ przez studentów
From: Paweł Paroń
Date: Thu, 15 Jan 1998 09:50
Date: Thu, 15 Jan 1998 09:50
82 lines
5572 bytes
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!pawelpReferences:
<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