1. |
Re: szamtek alapjai - OS (mind) |
61 sor |
(cikkei) |
2. |
re: szamtek alapjai - OS (mind) |
132 sor |
(cikkei) |
3. |
re: Re: dBase III (mind) |
21 sor |
(cikkei) |
4. |
re: Re: Re: DOS (mind) |
13 sor |
(cikkei) |
5. |
Re: DOS (mind) |
26 sor |
(cikkei) |
|
+ - | Re: szamtek alapjai - OS (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Udv!
On 29 Aug 2003 at 23:16, wrote:
> Felado :
> Koszonom a hozzaszolasokat es a segito sorokat. Magamrol:
> 27 eves vagyok, eveket toltotem a ZX Spectrum elott.
> A 286-ot mar nem programoztam, mert nem is tudtam hogy lehet :-o.
> Zavart is, hogy milyen hulye egy gep, hogy csak jatszani lehet vele...
> A DOSba epitett Qbasicrol csak par eve tudok :-((
> (Kicsit neheztelek a fateromra; igazan szolhatott volna.)
Ja. Tanusithatom, a ZX Spectrum sokkal intelligensebb.
Amikor megkaptam, annyit sem tudtam rola, hogyan kell a
magnokazettarol betolteni a mintaprogramokat.
Ket het mulva elmentem egy klubba, ahol folenyesen
kozoltek, hogy erre a load "" parancs valo.
Hazamentem, kiprobaltam, majd mergelodtem, mert
amit lejatszott, arra kozben mind rajottem magamtol.
> Ez a korai DOS otlet tenyleg hulyeseg. Az zavart, hogy egy szuz
> PCn DOS telepites utan maris hemzsegnek a fajlok. De ha jol ertem,
> akkor ezekbol csak 3 kell, a tobbi nem az oprendszer. (Igy van?)
Csak neked elarulok egy nagy titkot.
Menj be egy muszaki antikvariumba, vagy konyvtarba.
A legnagyobb titokban nezz korbe a polcokon, valahol
rohad a sarokban nehany szivarvany szinu csikos konyv,
tulnyomoreszt citromsarga szinben tunik fel.
Az egyiken az a felirat szerepel, hogy "DOS 3.30".
(Allitolag MS-DOS es PC-DOS is van, nincs lenyeges
kulonbseg kozottuk - talan az egyik ket, a masik 3 kotetes.)
Eleg a tartalomjegyzeket elolvasnod, nagysagrendekkel
bovul a tudasod.
> Idaig asszem jol ertem. Viszont ami az oprendszer mibenletet
> illeti, kezd kialakulni bennem egy kep, marmint arrol, hogy hogyan
> tartja meg a hatalmat a CPU felett. Leirom, kerlek irjatok meg
> ha (es hol) nem stimmel.
Ha elvi vitat akarsz, akkor javaslom ujra a konyvtarat, es keress
CP/M feliratu konyvet. Sokan eskudtek ra, hogy messze jobb,
mint a dos - dehat az usa-ban a penz a lenyeg, nem az esz.
Maris van ket operacios rendszer - sot ez utobbi meg
Zx Spectrumon is mukodott - amit osszehasonlithatsz.
Kivancsi vagyok, mi lesz a velemenyed - akar itt, a listan.
> es 'meg mindig' csak 64kB-os szegmensekben" - irja a konyv.
En atepitettem a Zx Spectrumot 80 k-sra, merthogy lehetett
lapoztatni a RAM-okat 32 k-nkent.
Egy evvel kesobb a BNV-n megjelent egy ceg, kinai exportra
szant Z80 alapu szamitogeppel - merthogy a kinai jeleket
4096 ponton tarolta el - ha jol emlekszem, elvi 2 mb-ig bovitettek
a lapozast, 512 k-sat allitottak ki.
Nem tudom, mi lett a gep sorsa.
elek
|
+ - | re: szamtek alapjai - OS (mind) |
VÁLASZ |
Feladó: (cikkei)
|
> Ez a korai DOS otlet tenyleg hulyeseg. Az zavart, hogy egy szuz
> PCn DOS telepites utan maris hemzsegnek a fajlok. De ha jol ertem,
> akkor ezekbol csak 3 kell, a tobbi nem az oprendszer. (Igy van?)
ezek a DOS segedprogramok, amelyekre szukseged lesz, es alkalmazasok,
amelyek jol johetnek. Nemelyik kivalthato, pl. a Norton Commander eleg
sok funkciot kenyelmesebben megold.
> Ugyanakkor a CD felelesztesehez maris tudomany kell.
Igen, es nehany ujabb file, koztuk a DOS konyvtarban levo mscdex.
> gondolkodott. Megoldas a jobb kihasznaltsagra: tobb user egyszerre.
> Azaz mar nem egy "felhasznalo" progi volt benn, hanem
> egy mindig ott lako, allandoan futo progi, ami be tudott tolten
> "felhasznalo" progikat, azok szamara memoriahelyet biztositott,
> es vedte oket egymastol, minden progi kizarolag a szamara kijelolt
> x (64?) kB-on letezhetett, oda irhatott, onnan olvashatott.
Kapaszkodj meg: a nyolcvanas evek vegen a BME-n levo TPA/PDP gepen
OSSZESEN 64 KB memoria volt es 16 felhasznalo. Az operacios rendszer
kimentette a sajat aktualis allapotat lemezre, betoltotte az egyik
felhasznalo programjat, majd lefuttatta. Adott (rovid) ido elteltevel
egy megszakitas es egy kicsi, memoriaban marado rutin segitsegevel
lementette a program allapotat, visszatoltotte magat es nezte a
kovetkezo programot. Nem veletlen, hogy neha egy billentyu
visszajelzesere 7 mp-et kellett varni, egy program elindulasara pedig 3
percet.
> (+ a BIOS rutinokkal valo adatcsere, persze). De hogyan!?
> Ennek a rendor szerepnek a betoltesehez biztos, hogy kellett
> HW tamogatas, azaz mielott az OS a programszamlalot atirta a
> felhaszn. progi kezdocimere, CPU-nak elore tudnia kellett vhogy,
Ez kizarolag olyan processzorral mukodik amelyik ezt tamogatja (vagy
lehet irni igy mukodo programokat, de azok siman elszallhatnak, ha
rosszul vannak megirva). Ebbol is ketfajta uzemmod letezik:
- virtualis modban a program egy olyan kornyezetben fut, amelyik ugy
nez ki, mintha valos modban futna. Ugyanazok az utasitasok, ugyanolyan
a szervezes - de, ha kilep a sajat teruleterol (akar memoria akar
port), akkor a CPU megszakitast indit es az operacios rendszer lekezeli
a hibat. DOS alatt kedvelt uzemmod. Igy tobb ilyen program futhat
egymas mellett ugy, hogy nem zavarhatjak egymast - kiveve a PC
rendszervaltozokat, amelyek sajnos kozosek.
- valodi vedett uzemmodban a program tudja, hogy o vedett es ennek
megfelelo utasitasok es adatszerkezet hasznalhato. Termeszetesen o sem
tudja felulbiralni a sajat korlatait, de kerhet az operacios
rendszertol uj teruletet, vagy meghivhatja a megfelelo rutint
valamilyen feladat vegrehajtasara. Itt mar sem a 64KB sem az 1MB korlat
nincs. Mindket uzemmodban leiro tablak vannak, amelyeket a CPU kezel es
amelyek megmondjak, hogy az eppen futo modul fizikailag hol van, hol
"latja" magat, mekkora a terulete, milyen portokat kezelhet, program
vagy adat (irhato/olvashato), van-e joga vedett utasitasra, stb. Ha
erre nem lenne kulon cache a processzorban, akkor a vedett uzemmod
minimum negyszer lassubb lenne, mint a valos, hiszen itt minden
utasitasnal cimet kell forditani es jogosultsagot nezni - nem beszelve
az operacios rendszer egyeb teendoirol.
> hogy ezentul hova szabad irnia es hova nem, es idoziteni is kellett,
> hogy az OS legkesobb t ido mulva visszavehesse a hatalmat,
> ha akarja. (Pl. megfelelo bill.kombinacio eseten). Gondolom en...
Ez a rutin az idozito megszakitasara fut le: visszaadja a vezerlest az
operacios rendszernek, az pedig intezkedik. Ha a rendszer vedett
uzemmodban fut, akkor csak hardver hiba vagy rosszul megirt operacios
rendszer miatt allhat fejre.
> A konyv szerint a 8086 "igazi 16 bites", de a 8088 me'g csak belul az,
> kifele' 8 biteskent viselkedik. A 8088 nem a 8086 utan jott idoben??
De, az ok a penz. Olcsobb volt a chip - es be is jott a szamitas, mert
ez terjedt el, szemben az akkori sokkal jobb Motorola processzorral.
> Szinten az all itt, hogy mindketto proci a "bovitohelyek fele' 8 biteskent
> viselkedik". Nem menjuk most bele a bovitohelyekbe, de hat
> hogy viselkedhet egy proci 8 biteskent, ha nem az?? Plane
> csak a bovitohelyek fele', mar csipekkel szemben meg nem??
Szinten penz - draga az erintkezo es sok helyet foglal. Azon kivul
minek egy soros vagy parhuzamos kartyanak, a floppynak vagy egy MDA
videokartyanak az a sok bit?
> Vajon mi lehet ez a 'vedett mod'? A 64kB-os szegmensek a
> cim megadasanak abbol a fura szerkezetebol adodik, amit a multkor
> beszeltunk, gondolom. Lehet, hogy ez is azert van igy, hogy
> hardveresen segitese a szegmensek egymastol valo vedelmet?
Nem. Emiatt az egyik 64KB-os tombod helyett valoban nem fog a masikba
irni a program, de ez ritkan segitseg: nem szall el a program, csak a
legvaratlanabb helyeken szemet lesz az adataid helyen.
> Azaz egy "felhasznaloi progi' hivatalosan csak az offszet cimet (16 bit)
> tudja atirni, a szegmens cimet meg csak az oprendszer kepes?
Ez csak a *.com programnal illetve az olyan *.exe-nel van, amelyben
csak ilyen rovid utasitasok vannak - itt a szegmenseket az operacios
rendszer allitja be (tiny modell - ill. olyan is van, hogy a program
egy szegmens, az adat egy masik, igy max. 128 KB: small modell). Kepes
lenne atirni, de nem teszi meg.
> De terjunk vissza az adatsinre: ugye akkor tenyleg 16 bit a 8086-nal?
> Igy 1 gepi ciklus alatt lefuthat az az utasitas, amihez eddig tobb kellett,
> mert az operandus(ok) hatul kullogtak, igaz? (Gondolom nem veletlenul
> vannak 16..18 bites mikrokontrollerek, azok sem akartak vacakolni.)
Nem. Ha 8 bites sinen viszel 16 bites adatokat, az ket ciklus, 16 bites
sinen viszont csak egy. Dupla sebesseg. Ha veletlenul SX-es gepet
latsz, az ilyen - raadasul gyorsabb memoria is kell bele. Nem
veletlenul volt joval olcsobb annak idejen...
> (Mellesleg, 16 bites adatsinnel 16 cimbit nem 64k-t, hanem 128k-t
> cimez meg... Nem csak gyorsabb, de tobb hely is a programnak.)
Ezt gondold meg meg egyszer :-)
> Es mi a helyzet a programokkal? Hogyan futnak a 8bites adatbuszra irt
> programok a 16 bites rendszeren? Az oprendszer futas elott(kozben)
> atkonvertalja es beteszi egy ideiglenes memoriacimre?, vagy eleve kepes
> 8 biteskent is mukodni? Ez utobbi eseten nagyon bonyi proci lenne,
> olcsobb minden progit egyszer ujraforditani a forraskodbol, nem?
Itt tobb dolgot keversz. 8 bites adatbuszra (8085) irt programok
kivaloan futnak a 8086-on: ezert csinaltak az egeszet. Az operacios
rendszer beallitja a szegmenseket, ezek utan a program 64 KB-ot lat es
igen jol erzi magat :-) max. a ROM BIOS-t hianyolja vagy az IO portok
es a videomemoria teljes atrendezese zavarja - vagy az, ha egy masik
ilyen program, amelyiket kozel raktak hozza, veletlenul felulirja:
merthogy programok kozotti vedelem itt meg nincs.
> Nem ertem. Ugyanezt a kerdest feltehetjuk a 16->32 bites atallasra.
> 386-tol kezdve mar 32bitesek, ugye? (adat is, cim is) Ezt hogyan
En ugy tudom, hogy a cim 24 bit igy egy programblokk max. 16MB.
> sikerul elfednie az oprendszernek?
A DOS es a Win3 kiegeszitok nelkul meg 16 bites, ha Hexiumon futtatod
is - a tobbi pedig ismeri a vedett uzemmodot. Ugy tudom, az ujabb
processzorok, stb. kulon reszegysegekkel oldjak meg a
DOS-kompatibilitast - ertheto, ha ezt lassan szeretnek kihagyni
beloluk. Ezen kivul az ujabb alaplap/processzor parosokat mar nem
igazan tesztelik DOS alatt, igy elofordul, hogy egy 800MHz-es gepen
lassabban vagy rosszabbul fut, mint egy 400MHz-esen (sajat tapasztalat).
> Es akkor a pipelinerol me'g szo sem volt....
Az viszont egy utasitaskezelo technika es fuggetlen az elozoktol.
|
+ - | re: Re: dBase III (mind) |
VÁLASZ |
Feladó: (cikkei)
|
>> nem ismeri a "korszeru" (ertsd: 32 bites Windows) programokat, arra
>> eleg furan neznek - akkor is, ha minden masban profi. Ezekhez viszont
>> semmilyen jelenlegi szemelyi szamitogep nem lehet tul jo vagy gyors.
>>
> Nono. A wint is lehet hatekonyan programozni, persze nem
> "visual" cucokkal. nasm rulz:))
Hogyne. DOS ala is lehet irni sokfele (karakteres vagy grafikus)
ablakos, vedett, csucsszuper, akar 32 bites rendszert (mondjuk, mint
'90-ben a Sinclair QL/Motorola volt), de csak gyenge kiserletek
tortentek. Ugyanigy Win ala sem lesz soha elterjedt gyors es hatekony
program - beleertve magat a Win-t is - sot, minden Win es a legtobb Win
program sokkal nagyobb es lassubb lesz, mint az elodje. Ez van, mar
sokszor megbeszeltuk itt.
> Itt egy szernysegem altal elkovetett komplett win32-es
> alkalmazas, 5kB (nem Giga :)))
> www.tar.hu/a_x/namiez.exe
Vicces program... de nincs kedvem vegignezni, igy futtatas helyett
inkabb toroltem. Egy "bu't" szektort akar 5 KB-al is lehet torolni, 32
bites Win alatt is - viszont megirhatnad meg egyszer az ehhez szukseges
fejlesztokornyezetet: engem is erdekelne.
|
+ - | re: Re: Re: DOS (mind) |
VÁLASZ |
Feladó: (cikkei)
|
>>> Nemtom a DOS-ok mennyire voltak bugosak,
>>Semennyire. A legstabilabb rendszer volt, akarmilyen fapados is. :))))
Nem egeszen. A 4-es elso verziok hibasak voltak.
> na innentol irhatsz amit akarsz
Ne keverd a DOS-t a DOS alkalmazasokkal.A DOS magban nem hiszem, hogy
komoly hibat talalnal. Abszolut stabil, de _nem_vedett_ - viszont ha
barmelyik programod atirja a rendszert, eleg visszatenni 4-5 rendszer
es konfiguracios file-t es minden rendben.
Nem igy _barmelyik_ W-vel kezdodo operazos rendszerben - arrol nem is
beszelve, hogy a kulonbozo frissitesek es a _telepitett_programok_is_
magat az operacios rendszert irjak at - es kulonleges buveszkedes
nelkul azt sem tudhatod, hogy most eppen mit irtak.
|
+ - | Re: DOS (mind) |
VÁLASZ |
Feladó: (cikkei)
|
wrote:
> Sziasztok!
>
>> >> Nemtom a DOS-ok mennyire voltak bugosak,
>> > Semennyire. A legstabilabb rendszer volt, akarmilyen fapados is. :))))
>> Azert ez ebben a formaban nem igaz. Attol fugg, hogy mihez kepest..
>
> Mihez kepest bugos, Balage? En sokat hasznaltam MS-DOS-t (leginkabb 6.22),
> de a rendszer (io.sys, msdos.sys, command.com) hibajabol sosem fagyott
> meg, sosem volt megbizhatatlan a mukodese, egyaltalaban sosem hibazott.
> Kompatibilitasi problemak akkoriban meg nem nagyon adodtak. Ha DOS-rol
> beszelunk en a magot ertem alatta. Abban en hibat nem fedeztem fel, pedig
> rendesen nyuztam. Ha a cullangokra celzol, amit adtak hozza, nos, azok
> kozott volt egy-ket nem tisztafialas segedprg., de meg azzal egyutt is
> csucs a Win95-hoz kepest pl.
A win95 is csak egy dos, grafikus hejjal..
Operacios rendszer a DOS-on kivul is volt par darab, ami lenyegesen nagyobb
stabilitast mutatott..
Peldaul a Unixok, de fel lehetne meg barmi mast is sorolni..
Azert tulzas az, hogy azt mondod, hogy a legstabilabb rendszer volt, max ugy
tudom ezt elfogadni, hogy a legstabilabb rendszer volt, azok kozul, amit Te
ismertel..
Balage
|
|