Na figyelj...
Hardeware-s Debugger: igénytől függően 12-15 milla... huh...
A sw debugger mem debugger... már írtam...

>Valójában ez elszomorítóan kevés.
Én nem mertem írni...


Majd egyszer leírom... Egyébként nem q*va nagy katasztrófa: a winfos is működik...

pro

Szia pro!

Bocs, nem láttalak, valószínű, hogy egyszerre írtunk. Válaszolok neked is:
1.) Írd le milyen rövidítések jelentésére vagy kíváncsi. Báááár... Asszem MOST indítványozom egy rövidítésgyűjtemény létrehozását, amit a morfeus site-ra ki kéne tenni. Ebben legyen benne MINDEN rövidítés, a jelentése, és egy kis magyarázat kísérje. Ezen néha én sem igazodok ki, és a Sápi Zoli is megjegyezte. EZ KELL - nem kétség.

2.) Preprockó: jól hangzik. Bár ezt a robinak kell mérlegelni, de azt hiszem igazad lehet.

3.) debug: a CEEPER nem debugger! A CEEPER egy olyan felügyelő, ami alsó szinteken (0-1pl) a managerek és a driverek hibáit kezeli, és a megfelelő kivételeket kezeli le, magas szinten (2-3) pedig már csak a hibák kezelésével foglalatoskodik. A debugger megírása a VXCd-ben lenne jól megvalósítható (értsd: OTT KELL LENNIE!), mert az a futtató környezet, melyet a legtöbb esetben használni fog a rendszer. A driverekhez lehet hogy tényleg kéne egy hw-s debugger. De ez hogyan lenne megoldható? Az E-mag (E=Engine - mi ezt a szót használjuk a mikrokernel helyett, mert az hosszú és ocsmány) viszont atomi lesz. Abban könnyű lesz hibátkeresni, ha jók a rendszertervek, és a dokumemtálást is komolyan vesszük. Én komolyan veszem, mert tudom, hogy NAGYON fontos. A többi viszont Robi dolga - az ő nevében nem tudok nyilatkozni.

4.) Létszám: Sajnos ennyi ember tűnik jelenleg JÓL használható segéd- és társ erőnek. Valójában ez elszomorítóan kevés. De gyarapojunk --> gyere te is, és többen leszünk!

5.) A 4pl: Nem egy nagy cég ajánlata, hanem egy könyv-író emberé. Én eszes megfontolásnak tartom. Nem értem, nem tudom megérteni miért akkora qr*a nagy katasztrófa a négy priv.szint kihasználása. Ha van, mért ne éljünk vele????

Tisztelettel:
Dobai Csaba (MORFeuS Team)

Szesz!

Válaszok: (ehhehehehheheööhöehööheeöehhhee) )))
2 Sonic:
>Lenyeg a lenyeg: PL#2 és PL#3 szinteken valojaban csak
>DATA jellegű Selector-ok orzik a futo alkalmazasokat, nem?
>Vagy meg itt is gepi kodot akarsz futtatni?
Mér akarnék gépikódot a 2 & 3 pl-en? Mikor mondtam ilyet? Rémeket látsz. Tőlem az egyes pl-en is lehet VXC, de a drivereket (nem a démonokat!) ott is gépiben kéne megírni. Egy driver úgy sem lesz soha hw-független.

>Ha a Sun erosebb lesz az MS-nel akkor Galamb!
Nem. Galamb akkor lesz, ha a MORFeuS erősebb lesz. mint a M$.

>A Cache Manager-t a Disk Manager-ben kellene megoldani...
Ez látod nem így van. A CacheMan-nek külön kell futnia, mert ha jobban belegondolsz nem csak a lemezeket kell cache-elni, hanem a billentyűzetet (bill. puffer), a TCP/IP package-eket, és még mittoménmit.
>Hm es kis flopyra is kene cache-eles (lasd regebbrol:
>Norton Cache), pl beolvassuk egy egesz, modositunk, varunk
>egy picit, aztan visszatoljuk a cumot.
Kis floppy-n a cache nem túl szerencsés dolog. Ugyanis könnyen biztonságtalanná válhat a lemez kezelés, ami adatvesztéssel jár(hat). Amíg nem lehet megakadályozni, hogy a user kivegye a floppy-t a meghajtóból, addig szerintem tegyünk le a cache-eléséről. Veszélyes ugyanis.
>Illetve a lemez felmountolasanal kell beolvasni, aztan
>mindig csak a memoriaba mentunk. Persze ezt csak OFS-re
>formazott kislemeznel tesszuk meg. Amikor le akarja
>mountolni hogy kivegye a lemezt, akkor mentunk ki
>fizikailag. Igen, lassabb lesz. De vagy biztonsagos lesz,
>ami idobe kerul, vagy egy gyors FAT es barmikor kidobhatod
>a lemezt az ablakon...
A kivehető média esetében el kell felejteni a mount-ot. És az írás-cache-t! Ha a user betesz egy CD-t, akkor az jelenjen meg, ha kiveszi, tűnjön el. Ez mounttal csak mindenféle körmönfont módon valósítható meg. A kivehető médiumok ne mounttal kerüljenek a rendszerbe! A mount ebben az esetben kényelmetlen, lassú, és biztonságtalan - NAGYON biztonságtalan!
>Ki mit gondol, hogy lehetne arany kozeputat talalni (az OFS
>egy hibaturo filerendszer, ezert tobbet szoszmotol a
>kelletenel... vagyis pont annyit, amennyi a biztonsaghoz
>szukseges).
Már készül a MasterFS v1.4. Újdonságok:
-hálózaton keresztüli összecsatolás
-nagyobb bizonság
-hibatűrés enabled
-nagyobb sebesség(!)
Ami marad:
-nem fog több helyet foglalni (asszem, de ez most még nem tuti!)
Ha mégis:
-akkor sem lesz jelentős (komolyan!)

NA EZ LESZ A GALAMB!!!

Ennyi (Üdv & Tisztelet):
Dobai Csaba (MORFeuS Team)

ps: a MasterFS v2 már ilyesztően közel van. De az már tényleg baromi durva lesz!

Hello...

Van időm ==> írok... lehet hogy visszatérek?

Kérés ha lehet egy két dolog rövidítését azért írjátok ki, ha megkérhetlek, mert így alég nehéz... De már kezd összeállni a kép.


Szépen sorban:
asm:
Szép gondolat asm-ben írni a czucc alját, csakhogy ha nem írtok inkább egy nektek a célhoz kellő fordítót akkor elvesztetek... Ha egy kernelt meg az egész alját csak asm-ben akarjátok írni akkor a későbbi "felveszek egy embert bízva abban, hogy majd megérti" dolog meg van lőve... doksi ide vagy oda...
Tényleg dolgoztam eleget asm-ben meg magasabb szintű nyelvben is és látom, hogy önmagában egyik sem alkalmas opr írására. Ez az én véleményem, de majd megértitek amikor a felét át kell írni... Egy jó kódra fordító preproccessor sokkal célravezetőbb lenne szerintem. (ha már így csináljátok akkor storno)

debugger:
Én nem a ti ceeperetekre gondoltam... A sw-s debugger nem debugger... csak halvány kisérlet (még a DR reg-ekkel kiegészítve is).
Komoly munkához (pl.: opr) komoly (hw-es) debugger kell... nincs mese...

létszám:
Kicsit kevének tűnik... Tervezéshez már majdnem elég...

privilege level:
Minek 4??? Mert az Intel annyit használ?
A Motorola csak 2-öt mégis jobb procikat gyárt... Nem kell mindent elhinni amit az Intel v. egyébb nagy cég állít...
Egyáltalán nem szabad megengedni, hogy egy adott pl-en lévő process belekutyuljon egy másik process cuccaiba! Akkor meg minek 2-nél több pl.?
Visszatérve az asm-re... az egész opr-t OOP-ben kell megcsinálni ami meg macerás, ha nincs közted és az asm között egy preprocessor...

na remélem nem hagytam ki semmit


pro

201. beszolasnak alljon itt egy IRC idézet:

<haha> zseni vagy?
<[Mancs]> dehogy
<[Mancs]> csak programozo
<[Mancs]> ;>
<[Mancs]> meg neha gondolkodni is szoktam

-

szal total orulok, hogy ez a 201. hozzaszolas, plane akkor orulnek, ha ez mar a 2001. lenne ;> de remelem, egyszer eljon az is!

2 Sonic:
lenyeg a lenyeg: PL#2 és PL#3 szinteken valojaban csak DATA jellegű Selector-ok orzik a futo alkalmazasokat, nem? Vagy meg itt is gepi kodot akarsz futtatni? Ugye nem, mert akkor vegkepp hordozhatatlanna valik a rencer. Dr Benyo Balazs mar alig varja hogy vegre nativ JRE futtatas is legyen (ne csak interpreter), azt mondja, ez egy eleg jo dolog lenne. Lehet, hogy 5 ev mulva mar mindenki megutalja a Java-t, de az is lehet, hogy nem. Ha a Sun erosebb lesz az MS-nel akkor Galamb!

++

A Cache Manager-t a Disk Manager-ben kellene megoldani es a Virtualis Memorija swap reszet is de valahogy atlathatoan.
Hm es kis flopyra is kene cache-eles (lasd regebbrol: Norton Cache), pl beolvassuk egy egesz, modositunk, varunk egy picit, aztan visszatoljuk a cumot.

hm

Illetve a lemez felmountolasanal kell beolvasni, aztan mindig csak a memoriaba mentunk. Persze ezt csak OFS-re formazott kislemeznel tesszuk meg. Amikor le akarja mountolni hogy kivegye a lemezt, akkor mentunk ki fizikailag. Igen, lassabb lesz. De vagy biztonsagos lesz, ami idobe kerul, vagy egy gyors FAT es barmikor kidobhatod a lemezt az ablakon...

-

Ki mit gondol, hogy lehetne arany kozeputat talalni (az OFS egy hibaturo filerendszer, ezert tobbet szoszmotol a kelletenel... vagyis pont annyit, amennyi a biztonsaghoz szukseges).

--

Na udv all, have a nice weekend!

NRI

Hmmm... Akkor is én leszek a 200-ik beíró )) Jeeeee.

Szia mindenky!

Szóval:
>Szoval. Azert van 4 szint, mert "igen azert, hogy bonyolultabb legyen".
Nem. Nem azért, hogy bonyolult, hanem, hogy biztonságos legyen. Így pl. nem lehet jól bevált trükköket (szándékosan nem írok példákat) alkalmazni arra, hogy mittomén egy picike időre rendszergazdai jogokkal induljon el egy alkalmazás, vagy hogy egy normális alkalmazás lássa egy shell teljes adatt- és kód területét. Nem véletlenül találták ki a négy szintet, és ha lehet élni vele, akkor kell - feltéve, hogy az hasznos. Szerintem nem emészt fel annyi erőforrást, mint ugyanezen szintek szoftveres emulálása. Például. Arról nem is beszélve, hogy ha stabil rendszert akarunk írni, nem pedig egy reklámkampányt, akkor élni kell a négy pl lehetőségével, mert a biztonság sokkal lényegesebb, mint (ha egyáltalán veszteséges) 10-12 órajel elvesztése. Nem ettől lesz lassú a rendszer, hanem ha ezer task fut a háttérbe.
Egyébként szerintem a platformfüggetlenséghez pedig pont az ETP miatt nincs semmi köze. Az ETP gondoskodik a négy szintről logikailag. Az, hogy ezek léteznek -e a célplatformon, az lényegtelen. Ha úgy lenne jó, hogy öt pl kéne, akkor fogni kell egy új EENG-hez csatolódó ágat, és kész. Az egy dolog, hogy az "ötödik" szintre kerülő cuccokat az Engine a negyedikre teszi. Csak ennek nincs értelme. Mintahogy annak sem, hogy csak két szintet használjunk fizikailag, ha logikailag levezettük, hogy az így a tisztább.
Persze ebbe bele lehet kötni, meg vitatkozni lehet vele, de senki se felejtse el, hogy amíg nem próbáltuk ki, hogy milyen, addig nem valószínű, hogy elfog dőlni. A külsősök pedig azért nem nagyon tudnák megrengetni ezt az elképzelést, mert nincs belelátásuk a rendszer felépítésébe. Így véleményt mondani pedig nagy felelőtlenség lenne.

Más:
Megértettem a portos dolgot, lejegyzem, és belegyúrom a CEEPERLO-ba. Apropó - kitaláltam a CEEPER-ek ikonját. A CEEPER-LOW-nak egy kisördög, a CEEPER-HI-nak meg egy glóriás angyal. Az egyik kezében vasvella, a másikéban meg egy kard.

Pro:
>1- Az egyik ilyen dolog (úgy látom ezt ti is így akarjátok csinálni) a jelenlegi dolgokkal való teljes szakítás, mert (majdnem) mind görget már magában valamilyen hibát.
Ez így van.

>2- Gondolni kell a későbbi teljes mértékű kompatibilitásra ==> semmi olyan nem lehet benn, hogy "na nem baj... azért egész jó"
A rendszer rugalmasságát, és átalakíthatóságát szerintem legendaként fogják emlegetni az utánunk következő generációk. És nincs benne "nanembaj" féle dolog. Mindent átgondolunk, mérlegelünk - tervezünk - DE NAGYON.

>3- A 0. pl-en könyörgöm ne ellenőrizzünk semmit! Fogadjuk el, hogy amit már odaraktunk az OK. Ne lassítsuk feleslegesen...
Nem tudom robi mit szeretne, de én is ezen a véleményen vagyok. Ez egyértelmű.
>4- Minek 2 pl-nél több? Hogy bonyolult legyen?
Erre most válaszoltam.

Tisztelettel & Üdvözlettel:
Dobai Csaba (MORFeuS Team)

Bocs, hogz belesyólok.
Először is már rég olvastam ezt a topicot, és most csak a végét volt időm pótolni, de ezt azért szeretném idfirkantani.

>Ennek az adatnak max informatív jellege lehet, mert hát én
>úgytudom, hogy prot kezeléssel gépet lepusztítani
>lehetetlen (hacsak valaki nem forraszt egy lefagyasztó
>panelt ).

Rosszul tudod...
Még a processzort is ki lehet vele nyírni... persze csak a hibásakat...

Valamire még had hívjam fel a figyelmeteket: rengeteg (értsd: több mint kellene) hw hiba van az IBM pc-ben... Tényleg elégé sok... Kezdve a tervezési hibától, egészen a "ja csak elfelejtettem ezt befejezni" hibáig... Ezzel is kell valamit kezdeni. (ha már gondoltatok rá akkor bocs)


2 Dobai Csaba:
>Mitől lesz szerinted versenyképes egy opr?

Sok mindentől...
1- Az egyik ilyen dolog (úgy látom ezt ti is így akarjátok csinálni) a jelenlegi dolgokkal való teljes szakítás, mert (majdnem) mind görget már magában valamilyen hibát.
2- Gondolni kell a későbbi teljes mértékű kompatibilitásra ==> semmi olyan nem lehet benn, hogy "na nem baj... azért egész jó"
3- A 0. pl-en könyörgöm ne ellenőrizzünk semmit! Fogadjuk el, hogy amit már odaraktunk az OK. Ne lassítsuk feleslegesen...
4- Minek 2 pl-nél több? Hogy bonyolult legyen?

Hogyan fogjátok megoldani a Kernelt? (nem is inkább, hogy hogyan hanem, hogy milyen taktikát követtek itt)

Tényleg sokat tudnék írni róla, de nem feltétlenül szeretnék most egy regényt írni...

Lehet nekem is egy pár kérdésem?
1- Kb. hányan vagytok akik mondjuk legalább napi 4 órában bütykölik?
2- Miben írjátok?
3- Hol tart a terv, a dokumentáció és a megvalósítás?
4- Milyen eszközök állnak a rendelkezésetekre, mind hw, mind sw, mind debuggar oldalról?
5- Csak PC opr-lessz, vagy egy rugalmas könnyen (akár 0 munkával) modósítható?


Most így hirtelen ennyi...


pro

1.
Portkezeles++

>Mi van ha vki megcimez egy porton vmi belso cimez
Mi van ha mi van???

>aztan vmi miatt meghal a progi (pl halara gyakja a ceeperlo)
Már mér gyakna le bármit is a CEEPER-LOW

>es egy ideig senki nem ir arra a portra. Aztan valaki megint ir ra - ekkor viszont cim helyett adatot rak bele
Miről van itt szó. Ez értelmetlen.

>pedig o cimrol tud, aztan adat helyett meg cimezne es akkor elszabadul a pokol.
Szerintem egy protra csak adat kerülhet. Vagy mit értesz te cím alatt. Minek a címe?

>Ezert kell, hogy egy teljes portra iras ATOMI, oszthatatlan muvelet legyen es az opre felugyelje.
Ezt teszi a CEEPER-LOW. Rövidesen elküldöm a részleteit, holnapra biztos készen lesz.

>Mint ahogy minden fontos eroforras a JO oprendszerekben.
Ez most hogy jön ide?

>Vegre letezik: http://morfeus.fw.hu/
Majd +nézem.

>Megkaptam Nagy Ferencz baratunktol az MCC forrasat. Wow. Ugyhogy bele kell huznunk mert az MCC mar mukodne, mar csak a VXC futtatasat kell megoldani.
Igen. Csak ahhoz viszont kéne egy futó engine. És mi még mindig a prot kezelésen szötymörgünk...

Üdv:
SonicRulez

1.
Portkezeles++

Mi van ha vki megcimez egy porton vmi belso cimez aztan vmi miatt meghal a progi (pl halara gyakja a ceeperlo) es egy ideig senki nem ir arra a portra. Aztan valaki megint ir ra - ekkor viszont cim helyett adatot rak bele, pedig o cimrol tud, aztan adat helyett meg cimezne es akkor elszabadul a pokol. Ezert kell, hogy egy teljes portra iras ATOMI, oszthatatlan muvelet legyen es az opre felugyelje. Mint ahogy minden fontos eroforras a JO oprendszerekben.

2.
Vegre letezik: http://morfeus.fw.hu/

3.
Megkaptam Nagy Ferencz baratunktol az MCC forrasat. Wow. Ugyhogy bele kell huznunk mert az MCC mar mukodne, mar csak a VXC futtatasat kell megoldani.

Udv all: NRI

Nah. Kezd derengeni: Te valahol elakarod tárolni azt, hogy melyik processnek milyen porthoz van köze. Nos, akkor viszont valóban kell egy GIO. Csakhogy ennek mi értelme van? Ennek az adatnak max informatív jellege lehet, mert hát én úgytudom, hogy prot kezeléssel gépet lepusztítani lehetetlen (hacsak valaki nem forraszt egy lefagyasztó panelt ).
Persz nem lehet baj avval, ha lehet tudni hogy egy driver milyen protokat használ.
Azonban akkor így minden portot lekellene foglalni megosztásra, mint egy resource-öt, maly használat után felszabadítani. Persze más (tehát nem PC alapú) architektúráknál már nem biztos hogy a port kezelés ennyire lefagyásmentes.

TEHÁT: Legyen igazad. Tényleg kell hogy legyen egy ProtRes. Vagyis egy erőforrás kezelő a portok menedzseléséhez - ha úgy tetszik egy GIO.

ÁM LEGYEN.

Üdv:
SonicRulez (Dobai Csaba - MORFeuS Team)

ps.: Lehet, hogy a végén még megértjük egymás nyelvét? (Hűha) ))

Szasz!

>0-ás szinten nem kell????????????????????????????????? és akkor az ESH-nak ki fogja kiadni a portot, mint szolgáltatást?
Mért kéne szolg. lennie?

>Nem jobb valamit egyszer megírni hibátlanra, aztán kiexportálni függvényhívásnak
Az IN és OUT portkezelő asm utasítások szerinted hibásak lennének?

>, hogy mindenki azt használja - ahelyett, hogy néhány ESH komponensbe ugyanazt újra és újra beleírjuk?
Mit kell újra írni azon, hogy "IN" vagy "OUT"?

Sonic

0-ás szinten nem kell????????????????????????????????? és akkor az ESH-nak ki fogja kiadni a portot, mint szolgáltatást? Nem jobb valamit egyszer megírni hibátlanra, aztán kiexportálni függvényhívásnak, hogy mindenki azt használja - ahelyett, hogy néhány ESH komponensbe ugyanazt újra és újra beleírjuk?

Vagyis mire gondolsz G. I/O alatt. Mert ha a port kezelést, akkor azzal nincs gond. A CEEPER arra van, hogy figyelje az IN és OUT asm utasításokat (is), bár meggondolandó a dolog. Ugyanis ezt az Engine szintjén (a 0-ás szinten) nem igazán kell. Csak lassítana, a biztonság pedig nem változna. A tov. szinteken viszont szükséges. Ami az 1-es szintet illeti - nos lehetne ezzel is vitázni, majd gondoljuk meg. A CEEPERHI viszont reklama nélkül KELL hogy figyelje ezeket a privilégizált utasításokat.

Ennyi, mennem kell:
SonicRulez (Dobai Csaba - MORFeuS Team)

Ühümmm....

Mit értesz Te General I/O komponensnek?

(szőkenő) Én ezt nem értem...

Sonic

Még annyit tennék hozzá: az OFS még hiperprerelase-ultramegabeta v0.0000000001-es verziónál jár kb., úgyhogy nem ezzel az FS-sel fog kijönni a rendszer, hanem a ZenFS-sel és a MasterFS-sel. Nomeg a BootFS-sel, ami azért baromira kell... )

Ennyi:
Sonic

Folytatás:

További lényeges lépés: megegyeztünk abban, hogy elfeledjük az Engine-szintű POSIX kompatibilitást. Az EVUI nem UNIX! A leghasználhatóbb POSIX hívásokat sajátokra írjuk, úgy, hogy az a lehető legjobban illeszkedjék a rendszer lelkéhez. Nem erőszakoljuk meg vele, mert csak leragasztaná a rendszert.
Azonban a későbbiekben kidolgozunk egy démonszintű POSIX alrendszert. Ez mindenbizonnyal szükséges lesz, de mindenképpen leakarjuk vetkőzni az eddig felgyülemlett szabványokat, melyek gátlásként lennének részei a rendszernek. Úgyhogy éljen a szabadság!

Miután az ETP nem csak ebből a struktúrából áll, hanem, mivel ez egy protokoll, más szerkezeti meghatározások is szerepelnek benne, melyek megtalálhatóak ugyan a honlapunkon, mégis úgygondoltam: itt is közzé teszem.

Az ETPv1 már tartalmazta az alábbi privilégizált hívási menetet, de leírom: Minden szintről csak az előző, és az aktuális szint rutinjai hívhatóak. Ne feledjük, hogy a 0-ás szint a legmagasabb-, és a 3-as a legalacsonyabb szint. A hívások pedig így alakulnak:

3-ik pl.: 3. - 2.
2-ik pl.: 2. - 1.
1-ik pl.: 1. - 0.
0-ik pl.: 0.

A pl. a privilage-level rövidítése.

További lényeges dolgok:

Ez a struktúra az Engine objektum-orientált elérését teszi lehetővé, mely kellő rugalmasságot és könnyű programozhatóságot biztosít. Minden kulcs rendelkezik metódusokkal és belsőváltozókkal.

1.1). Kulcsok és erőforrások

Néhány fogalmat mindenekelőtt tisztázni kell. A fenti lista egy térkép, eszerint épül fel a teljes engine. Az engine komponenseit tartalmazza, a komponensek leíróját kulcsnak nevezzük. A térkép azon komponenseit, amelyek fizikailag csakis az engine és engine shell rétegben érhető el - valódi komponensnek, kulcsát valódi kulcsnak (RKEY, Real KEY) nevezzük. A shellek és az alkalmazások a komponenseket az Emulációs Interfészen (továbbiakban: EIF) keresztül érhetik el, amely virtuális kulcsokon keresztül nyújt szolgálatot valamelyik valódi komponens segítségével. A virtuális kulcson (VKEY, Virtual KEY) keresztül a komponens így virtuális komponensnek látszik. Ezekután célszerűnek tartjuk a komponens helyett az erőforrás (RES: resource) szót használni, függetlenül attól, hogy az hardver, vagy szoftver erőforrás.
Ne tévesszen meg senkit, hogy az EIF az Engine-Shell szinten helyezkedik el. Ne feledjük, hogy az alkalmazások a számítógép eszközeit ill. az emulált eszközöket már az EVUI-n keresztül érik el!

1.2). Objektumok

Minden erőforrást objektumként érhetünk csak el. Ez több szempontból is előnyös lehet. Az objektum-orientált programozási technológia egyik alapvető fogalma az encapsulation, azaz egységbe foglalás. Ez arra használható, hogy egy bizonyos adaton (ezek az objektum adattagjai) jól definiált műveletek végezhetők el (ezeket az objektum metódusai szolgálják ki).

Az adattagok és metódusok (a továbbiakban együtt: tagok) leszármaztathatóak, méghozzá bizonyos szabályok szerint, a tagok ugyanis elláthatók protected, private és public jellemzőkkel, melyek rendre a következőt jelentik: a védett tagok csak az objektumon belül érhetők el, de származtathatók; a privát tagok nem származtathatóak (adatrejtés), a publikus tagok pedig mindenki számára származtathatóak és elérhetőek.

A polimorfizmus fogalmának megértéséhez képzeljünk el legalább két metódust, melyeknek neve azonos, de funkciójuk kissé eltér a paraméterükben megadott adat típusának és/vagy számának megfelelően. Ezeket a metódusokat virtuális metódusként kell létrehozni, s hívásukkor majd az objektumkezelő választja ki fizikailag azt a metódust, amelyik az adott típusú és/vagy számú paraméterhez tartozik.

Megemlítendő még a late binding (kései kötés) is, ez olyan dinamikus kötési mechanizmus, amely egy adott adatnak csak akkor foglal memóriát, mikor arra hivakozás történik.

Végül és nem utolsósorban: meg kell különböztetni osztály-t és objektum-ot. Az osztály egy objektumtípust, mint deklarációt jelent; az objektum viszont az osztály egy élő példányát.

1.3). A komponenstérkép és a hivatkozások kapcsolata

Többféle hivatkozás létezik az engine-ben. Az 1). hivatkozás a korn-kapu-n keresztül történik, ez a kapu az engine shell réteg komponenseinek és az engine komponenseinek kommunikációjára használható; ezen keresztül hívhatunk alacsony szintű eljárásokat (hardverközeli funkciók: port kezelés, matematikai processzor, stb.). A 2). és 3). hivatkozás az engine shell réteg komponensei közötti kommunikáció, ezek általában 2). események, ekkor szignálok küldéséről beszélünk; vagy 3). függvényhívások, melyek kiszolgálása már az objektumkezelőn keresztül történik "RKEYname::objectname::methodname(...)" formában. A 4). szintű hivatkozást a shell rétegben használjuk, ez már az EIF-en keresztül, "VKEYname::objectname::methodname(...)" formátumban történik. Az 5). szintű hivatkozás pedig egy VXC üzenet (TMessage Class), ezt az alkalmazások használják, ez a legmagasabb szintű kiszolgálást jelenti.

Kövessünk végig egy C szintaxisú utasítást, miként fog lefutni:

f+=20; /* where "f" is float */

A C-fordító ezt az alábbi 5). szintű hivatkozásra fordítja:

TMessage(
EifThread, MathObject, PlusEq,
2,
TrcVxc, SelfThread, MainObject, Variable(f),
TrcXdrInt, 0x00000014)

Ezt a hívást az EIF egy transzláció folytán 3). szintű hivatkozássá alakítja (a 4. szintű hivatkozást olyan eszközöknél ajánlatos használni, amelyeknél előre nem megállapítható a kapcsolódó hardver, pl.: FDD, HDD, PRN). Az objektumkezelő az EIF-től egy MathObj::PlusEq(f, 20) hívást kap, aminek hatására...

... meghívódik az EENG::KORN::MATH::PLUSEQ 1). szintű függvény, paramétereként pedig egy átmeneti változót kap, aminek értéke az "f" változó értéke lesz. Miután a függvény visszatért, az EIF visszaírja az "f" változó értékeként a függvény visszatérési értékét, méghozzá úgy, hogy megkéri egy 2). szintű hívással...

pid(VXCDaemon), pid(Application#??), set(mainobject, f)

... a VXC daemont, ami megállapítja, hogy milyen byte indexen található az "f" változó, majd odaírja a változó új értékét.

1.4). Folyamatok és szálak

A virtuális-futtatás szervező (VEM) szálak, a Korn Scheduler-e folyamatok ütemezésére fejlesztendő ki. Egy szál (thread) a párhuzamosan futó kódrészlet legkisebb egysége, egy folyamat része. A folyamat (process) nem más, mint egy program élő példánya, amely legalább egy szálat tartalmaz. Ha több folyamatot indítunk el egy feladat elvégzésére, akkor munkafolyamat-ról (job) beszélünk.

Az ütemező esetünkben gépi kódú processzek ütemezésével foglalkozik (ezeket a szakirodalom kernel módú folyamatoknak hívná), ezek csakis az engine shell rétegben fordulhatnak elő. A processzekhez prioritást és szinteket rendel, minden 100. tikknél öregítést is végez. Azonos szint és/vagy prioritás esetén Round Robin FCFS-t használ, egyébként a szintek sorrendje és a prioritások szerint ütemez.
Engine SHell szinten mindössze négy futási státusz lehetséges: Created, Running, Sleeping és Zombie.
A legtöbb processzoridőt általában az Object Manager, az EIF, a VEM és az EVUI veszi el.

A virtuális-futtatás szervező a Shell és az Application szintű alkalmazások ütemezéséért felelős. Mivel ezek VXC-ben futnak, a VEM ütemezője egy preemptív, prioritásos scheduler, ami hasonló bonyolultságú, mint a Korn Scheduler, mivel itt a Resource Manager válaszától is függ egy szál beütemezhetősége.
Shell és Application szinten már több futási státusz lehetséges: Created, ReadyToRun, Running, Preempted, Suspended, Swapped és Zombie.
Mivel a VEM biztonságos és preemptív, tehát megbízható szálkezelést nyújt, célul tűzhető ki, hogy egy szál akár egy másik munkafolyamat valamelyik processzének valamelyik szálját is elérhesse (TMessage üzeneten keresztül); így biztosítja az engine azt is, hogy nem csak objektumokat, hanem szálakat is megoszthassunk (Section Thread).

1.5). Section Object

A "section object" egy olyan átmenetileg (pl. megosztási céllal) létrehozható objektum osztálya, amelyet egy megnyitott erőforráshoz (állományhoz, memórialaphoz, stb.) rendel az Object Manager. Ebben a rendszerben a section object olyan fogalom és alapegység, mint a UNIX-ban a file. Itt azonban az adatokon jól definiált módszerekkel végezhetünk tevékenységeket, tehát itt nem lehet egy könyvtárleírót állományként értelmezni, vagy egy hardveres eszközre mint állományra, bájtonként írni. Ezzel a koncepcióval is növeljük az engine megbízhatóságát.

2.1). Memóriakezelés

- Kétlépcsős memóriafoglalás automatikus lapozással

A kétlépcsős memóriafoglalás, mint ötlet a bankár-algoritmusból származik; a módszer lényege az, hogy először tudatjuk, hogy mekkora memóriaszeletet szeretnénk, majd pedig elkezdjük a tényleges foglalást. Hasonló elven működik a Windows NT memóriakezelése is, de a mi módszerünknél a foglalás bejelentése után nem egy virtuális címet kapunk, hanem egy section objectet, aminek mérete a kért mérettel egyezik meg, a foglalt memórialapok pedig a lokátorlistában jelennek meg; nekünk más dolgunk nincs, mint írni a section objecttel, a section objectet kiszolgáló komponensek pedig majd automatikusan lapoznak.

Ha így egy szál lefoglal néhány lapnyi memóriát, de nem ír rá és egy másik szál is szeretne annyi memórialapot lefoglalni, amennyit a rendszer csak úgy tud neki kiosztani, hogy az előző szálnak kijelölt memórialapokat adja át, akkor megteheti. Ez a lényege a két lépcsőnek: ha egy szál egy nagy területet kér, aztán valamiért elaltatják (pl. egy erőforrásra várakozik, amit csak több perc múlva kap majd meg), egy másik szál lefutását nem akadályozza. Ez a módszer az engine áteresztőképességét javítja.

- Lusta írás

Tegyük fel, hogy egy processz tíz szála is megnyitja ugyanazt az állományt írásra-olvasásra. Ez esetben a régi módszerekkel tízszeres méretű memóriát kellene foglalni, teljesen feleslegesen. A lusta írás lényege az, hogy amíg a szálak csak olvassák ezt az állományt, addig egy section objectet látnak, ha viszont írnak bele, akkor annyi módosított section object készül el, ahány szál írja az állományt - a változás viszont csak arra a lapra (a módosított section object-ben a SOList egy-egy eleme újonnan foglalt memórialapra mutat) lesz érvényes, amely területen az írás történik.

Az állomány mentésekor két eset állhat fenn:
- 1). ha más-más lapokra történtek az írások és az állomány méretét nem változtatták meg, akkor minden módosítás egyszerűen menthető, hiszen az állomány struktúrája nem sérül;
- 2). esetben egy frissítés-eseményt, mint üzenet kapnak meg azon szálak minden írási műveletüknél, melyek azonos lapot módosítanak. Ezt az eseményt nem a szál kezeli le, hanem a VEM, visszadobja abba a futási állapotba, ahol a már módosított adat újraírását kezdeményezte volna (újratölti a section objectet és COUNT mutatóját beállítja a módosítás elé) lehetőséget adva így arra, hogy megvizsgálja a program, valóban szükséges-e az új módosítás, ezzel kikényszeríti a szinkronizálást (pl. TMonitor objektum használata).

2.2). Object File System

Ez az állományrendszer meglehetősen eltér az eddig megszokottaktól. Alapvetően három pillérre épít: elsőként rendelkezzen objektumorientált interfésszel; másodsorban hibatűrő legyen: hibái legalább észrevehetők, legfeljebb javíthatók legyenek, s működés közben javítsa meg önmagát; harmadsorban POSIX-szerű elérést is biztosítson. A két alaptulajdonságát mindig egyszerre kell tartani, méghozzá a következőképpen: minden könyvtárleíró (deszkriptor) valójában egy statikus objektumlista legyen, ezek a deszkriptorok azonos lemezterületnyi távolságban legyenek egymástól és tartalmazzanak három azonos tartalmú őrobjektumot, melyekből az eredeti deszkriptorok hiba esetén újraépíthetők legenek. Ha valahol így hiba keletkezik a tárolón, nem veszhet el a teljes lemeztartalom, legrosszabb esetben is csak egy folt veszik el, hiszen a deszkriptorokról biztosan tudjuk, hogy azonos távolságban találhatók, s hogy hol (ezért kell statikus lista), az állományok pedig mindig fejléccel kezdődnek (az SBF és az MFS ötletéből), szintúgy meghatározott helyeken, így ha esetenként lassabb is lesz a fájlhozzáférés sebessége, nem kell attól tartani, hogy elvesznek az állományaink.

Az objektum-orientáltság az encapsulation tulajdonság okán is fontos jellemzője az állományrendszernek, hiszen biztosítja az állományok és könyvtárak védettségét és konzisztenciáját. A deszkriptor objektumok mindegyike rendelkezik repair() metódussal, melyet bármikor meghívhatunk, így nem kell explicit lemez-szervizelő programot használni, mivel a fájlrendszer saját magát ellenőrzi és javítja.

Az állományok és könyvtárak POSIX formátumú exportálása gyorsítja a fájlműveleteket, lehetővé téve linkek használatát. Ennek az a magyarázata, hogy felesleges deszkriptorokat létrehozni olyan esetben, ahol nem indokolt (hardlink segítségével gyorsabban lehet mozogni, mint ha objektumlistát dolgoznánk fel).

Nos egyelőre ennyi:
Dobai Csaba és Németh Róbert - MORFeuS Team

ui.: itt ugyan nem esik szó róla, de érdemes megjegyezni, hogy az SE, azaz a Soul-Executable egy olyan indítható állomány, mely az Engine-hez, az Engine-Shellhez, vagy a User-mode Interface Levelhez (UIL) csatlakozik a betöltése után! Azért Soul, mert a rendszer lelkében motoszkál...

+lesz...

Na szoval

ennalam az ETP szintjei igy korvonalazodtak (anno)

KORN - engine korn layer
ESH - engine shell layer (daemons)
SH - shell layer (user interface)
APP - applications

Szoval ebben nincs is hiba. Figy feltoltottem az ETP v1.5.1-et, nezd meg, kivancsi vagyok a reakcioidra.

FONTOS:
Talalkozzunk az ETP v2.0-ban, addigra rendezunk mindent magunk kozott. Nem hinnem, hogy parhuzamosan, de nem osszedolgozva mennenk is valamire. Szoval pl.: a paratlan alverziokat en irom, a paraosakat Te. Ha pedig egyenlore nem is, Febr 23-an biztosan rendezodik az ETOP, az EENG, az EVUI es mindenek ugye. En worxolok, s neked is jo munkat:

NRI

Helló!

Nos, úgynéz ki van 1 kis félre értés. Rendezzük hát:
Valóban eltolódott egykét dolog. Így nem csoda, hogy párhuzamosan futunk most (azaz csak a végetelneben - de talán ott se - találkozunk). Az ETP v1.4-ben a következő eltérések vannak:
KORN - ez az Engine-mag
DRV - ez az Engine-hély
ESH - ez a Shell-szint
APP - ez az alkalmazások szintje.

Ez tehát egy **** nagy elírás. Javítva:
KORN - Engine-mag
ESH - ez a volt DRV, azaz EZ az Engine-héj
SHLEV - ez a volt ESH, de valójában ez a Shell-szint
APP - ez az is marad ami volt.

A démonok pedig még csak véletlenül sem felelnek meg a DOS-os drivereknek. Láttál te már olyan DOS-os driver-t ami behúzott volna egy másikat? Én nem.
A modulok felelnek meg a driverrel, mert azok tartják a kapcsolatot a hw és a kernel közt, a démonok ilyet nem igazán csinálnak. A démonok betöltenek megfelelő modulokat viszont, és egy stabil, szabványos interfészt biztosítanak a user-módú alkalmazások és a driver közt. Lásd Linux/UNIX. Legjobb példa erre a sound-daemon. De a network démon is ezt teszi, és az inetd is.
Így viszont nem értem a kételjeidet az EVUI-t illetően. Az hogy az X-Server nem démon (ebben nem vagyok biztos), az minket nem kell, hogy zavarjon. Az EVUI más démonokkal, az enginnel, és felhasználói alkalmazásokkal is kommunikál. Ezért lesz itt démon.
Az ETP szabályai szerint (amit mindenki, TE is elfogadtál) _nem lehet más_, különben nem hívhat Engine-mag és héj rutinokat sem!

Ennyi:
SonicRulez
ps: a szerkezetet megmódosítom majd: ez lesz az ETPv1.4.1

Hali!
"Nem birtam a sajat forumunkra belepni, ugyhogy ide valaszolok:"
bammeg, jah, ijen volt velem is;] azer akkor mar gaz van, ha egy forumka
irokaja nemtud belelepni a sajat iromanyaba;]
szegenyket nagyon le kene mar cserelni;]
az volt a gond:
- ugyebar login-nal kukizik egyet
- ez a cookie 1 oraig el, aztan meghal (addig vagy belepve)
- namarmost ha az en itthoni idom az mondjuk par oraval a serverido elott
jar (nekem 1 honap volt, **** itthon a datummal) akkor a browser
(IE5.5 es QNX-es Voyager-rel probaltam) mar keletkezesekor torli is, merhogy
az 1 ora mar reg lejart.
eztet nagyon meg kene oldani, mashogy;]
udv,
W_Irving

Futty!

Sonic:
Nem birtam a sajat forumunkra belepni, ugyhogy ide valaszolok:

Alapvető lelki durvaságok:

1.
Az Engine shell nem azt jelenti, hogy az engine köré húzott héj?
Ha azt jelenti, akkor mit keres ott egy shell program?
A shell eredetileg (UNIX) arra jó, hogy a rendszerhívások
fölé emelkedve, azokat használva paraméterezetten indítson
programokat. Tehát: a "Shell program" ebben a fogalomban használatos
minden szakirodalomban. Továbbá: a shell program jelenti a
user interface-t, így tehát az EVUI valójában egy shell!!!

2.
A daemon attól daemon, hogy állandóan, minden folyamattal
párhuzamosan fut és egy bizonyos hardver, vagy szoftver ESZKÖZ
kezeléséhez nyújt szolgáltatásokat. Ezt DOS alatt driver-
nek hívják. Szóval az Engine-Shell layerben a helye. Ahol
azonban az EVUI-nak nincs helye. Viszont: az EVUI-nak a
Shell layerben van helye, ahol az EVUI alapja futkározik,
mert gondolom, az EVUI nem egy progi, hanem egy programrendszer
lesz, aminek van egy kernele, shell szinten és a hozzá
tartozó progik application szinten futnak - tehát virtuálisan
futnak. Így minden application szintű progi felügyelhető,
hiszen nincs olyan application, ami gépi kódban futna,
tehát nem fagyaszthat le semmit.

3.
"ha rövid idöre (kb 1-2 percre) megáll valamiért az ütemezés
(pl lehal egy alacsony szintü driver)"
Ilyen NEM fordulhat elő. Nem szabad előfordulnia.
Addig kell a daemonokat tesztelni, amíg totál stabilak nem
lesznek. Egy jó ütemező prioritásos és preemptív,
tehát elveszi a gépi kódban futó processztől is
a processzort, ha lejár a kvantumja (sok szempontból helyesnek
tartom az NT ütemezőjét, de néhány elvvel nem értek egyet:
a NT kernel módú ütemezése egy kutyulék massza - a UNIX sokkal
egyértelműbben kivitelezett, persze a UNIX sosenem fog
kernel processt megszakítani).

4.
Az executable fájlok már _k2001_ alatt is sirály header-rel
(k2002 alatt meg pláne) rendelkeztek vala. Különben nem is
működött volna normálisan semmi.

Az SE-k két headerébe belenyugodtam.

5.
Azt nem bírom a pici agyammal föfogni, hogy miért kellene
az interruptokat kiadni a progik számára. Az platformfüggővé
tenné az egész cumót. Elég baj az is, hogy néhány daemont
assemblyben kell majd megírni, de ezt minél gyorsabban
szeretném elhagyni, mert az csak megnehezíti a hordozhatóságot.
Kell egy egyértelmű objektumhierarchia, amit a programfejlesztő
eszközök is az EENG::ESH::EIF-en keresztül érnek el és
mindenki azon keresztül érje el. Plusz: ne lehessen egymás között
kutyulódni, össze-vissza ESH szinten. Egy daemon ne érhesse el
a másik daemon címterét, mert abból csak a baj van.
Harmadik szintű progi viszont minden idegbaj nélkül nyithat
egy-egy section objectet (lásd NT), amin keresztül más
harmadik szintű progik osztottan érhetik el a metódusokat,
adattagokat, vagy közös csatornákat (mert a fájlokat és a
memórialapoka csatornán keresztül a legjobb poén elérni).

-

Na, egyelőre ennyi, még jelentkezem...

Várom válaszod, most lehet, hogy mérges vagy rám,
de én csak arra morgok, ami megnehezíti egy rendszer
áttekinthetőségét, egyértelműségét...
Bizony az NT-t is hasonló okokból nehéz megérteni,
de a UNIx az sima ügy. Zwack um pakk, úgy ahogy van,
egészben lenyelhető. A k2002 fölé alkotott cumó is,
de pl az NT executive-jának alsó rétege nem pöttyet szutyok.

Legalább mi ne rontsuk el túl korán a mienket...

-

Tisztelettel:
Németh Róbert István

Üdv MindenkiNET!

Elkezdetem kidolgozni a CEEPER-t azaz a Central Error and Exception ProcEssoR-t, becenevén az Őr-t. Ennek feladata megvalósítani a rendszer hibáinak központosítása, és ezen hibák üzeneteinek megjelenítése (lesz). A CEEPER úgy lesz megcsinálva, hogy a programozónak kedve sem lesz mással kezeltetni a hibákat. Egyszerűvé és biztonságossá teszi a hibák és kivételek kezelését az Engine-mag szintjétől az Shell-ek és Démonok szintjéig. Bővebben sajnos csak akkor fogok tudni írni róla, ha már van egy kész verzióm, most még csak bejelenteni tudom, mert hát most még csak gyerekcipőben jár. Azt, hogy mindez mennyire/milyen szintig lesz publikálható, majd elválik, de az már most nyilvánvaló, hogy lesz 1-2 "műhelytitok".

Egyelőre ennyi:
Sonic

Én kihívásnak érzen, hobbiból írom (mivel nincs olyan barom aki ezt fizetné is), de nekem ez mind a kettőnél _sokkal_ többet jelent.

Üdv:
Sonic

ps: a Sonic kis c-vel _nekem_ sokkal jobban tetszik. Apropó: megnézted már az ETPv1.4-et? Ha igen kéne egy kritika, mert én már szeretném kidolgozni a rutinokat!

Szerintem van olyan, hogy az ember csak azert csinal meg valamit, mert ugy erzi, hogy meg tudja csinalni. Csak ugy, hobbibol. EsVagy mert kihivasnak erzi.

Re SoniC!

1. Miert irom a C-t naggyal? Tok jol nez ki, vagy nem?

2. Hat marciusra biztosan kesz leszunk a bootolhato verzioval. De melyik evben? Nekem ugyanis jopar kernel cokmokot at kell majd irnom, az pedig tesztelessel egyutt kicsit sokaig tart. Foleg, hogy csak nagyon mikrokernel lesz es kell egy gagyi C fordito, amiben irunk majd nehany daemon-t, meg nehagy VXC-re forditott tool-t es majd onnantol kezdve lesz az igazi. Na, persze a regi, k2002 alapu OS-t be lehetne huzni flopirol, poenbol...
Majd meglatjuk...

Udv> ROB

Sziasztok mindenki!

Most hogy itt az ETPv1.3, megtéveszthet bárkit, ezért közlöm: már elkészül (rá két napra) az ETPv1.4. Ez a verzió kissé értelmesebb mint az elözö, és egyelöre csak a MORFEuS Fórumban van nyoma. Ha valakit érdekel, akkor az ott legyen szíves megtekinteni (Operációs Rendszerek|Oprendszerek belsöségei)!
Ez nagy valószínüség szerint csak a fejlesztés megkezdése után fog még esetleg változni kicsit, de ez tiszta dolog. Én személyszerint már szeretnék a rutinokok dolgozni, hogy beleférjünk a márciusi határidöbe. Merthát megígértük, hogy akkorra elkészül a boot-olható változat, _tartsuk hát be, kérem!_

Üdvözlet:
Dobai Csaba alias Sonic

Hi felbovitettem az EENG1.2-t megnezted? Majd rejagajjad lefele, OK?

Udv all> NR

bocsi hogy nem válaszoltam eddig a leveletekre, de el vagyok havazva a melóval (SIM programozás). A fórumnak szerintem nem lesz semmi akadálya. még 1 kicsit tartsatok ki az eddigi helyen aztán dobok mailt.

Ühümm. Bocsi. A neved Hardhead. Sorry. Átlalában nem cseszem el, de most hullafáradt vagyok már. ZH, meg ilyenek nemjó éhgyomorra.

Ühümm. Bocsi. A neved Hardhead. Sorry. Átlalában nem cseszem el, de most hullafáradt vagyok már. ZH, meg ilyenek nemjó éhgyomorra.

Hali all!

Headhard: kissé ködösítesz. Ha kínos lenne neveket íni fojtathatnánk e-mailben (wf-base@freemail.hu). Engem érdekel a véleményed, de ebben a formában kissé használhatatlan... Azért köszi!

Ennyi:
SonicRulez (Dobai Csaba - MORFEuS: vezetőfejlesztő, alapító társelnök)

HAJRĹja...

Na figy, epp folyamatban van az "i2c"-s beszelgetes, majd kiderul... Szal addig is meg csak nezelodok, neha-neha, mert meg van mit vizsgaznom...

Na udv mindenkinek a vizsgazoknak meg egy vagon ****t, + 2^32 kanyiszter borovicskat...

-

Sparow, nagon orulok, hogy ujra itt vagy! Mar nagyon hianyoltalak... Vegre megint ujra tudunk konzultalni!

-

Udv all> nrobcsi

Üdvözletem mindenkinek!
Én még csak most olvastam bele ebbe a forumba.
Az első 120 után teljesen belefáradtam... Fantasztikus szövegeket lehet itt találni, komolyan !:) Ha valami informatikai vicclapba gyűjtök egyszer anyagot akkor biztosan ide is benézek . A legtöbb hozzászólás (tisztelet a kivételnek) olyan messze áll a realitástól mint én mondjuk a rakétaépítéstől. Annyi a külőnbség, hogy én nem fogok egy topikot nyitni és a rakétaépítés csinját-binját hirdetni, ha fogalmam sincs róla.
Pedig látszatra megtehetném. Van ugyanis otthon atoszifon. Ez ugye elengedhetetlen kelléke az ALADAR tupusú ürrakétának. Mégse teszem
Kérem a nagyobb arcú kollégákat, hogy legalább annyira legyenek igényesek, hogy egy hozzászoláson belül ne legyen ellentmondás a az informatikai hozzáértésüket illetően. Tudom, hogy ha a másik is hasonló szinten áll akkor nem foglebukni elötte, O sem tudja mi annak a kifejezésnek a jelentése amivel dobálózik, de egy ilyen forumnak talán az lenen a célja, hogy akik olvassák azok okosodjanak. Ha a tagok dezinformációval traktálják a forumot akkor abból senki nem tanul semmi értelmeset.
Hogy azért mondjak valami biztatót is : HAJRÁ!
Üdv!

Szióka!

Nem gyözöm hangsúlyozni: töltsétek fel a fórumot az 12c-re is lécci, mert van olyan elöfizetés amelyik csak ezzel a címmel van kibékülve a mirrorok közül. Ez túl nagy kérés?

Köszi elöre is:
Sonic

Hellóka!

Örülünk, hogy újra vagy, nézz el a k2001.fw.hu címre majd, mert ott van egy fórum, a MORFEuS fórum, ahol a lényegi kommunikáció folyik. Kérlek ha folytatni szeretnéd az irogatást, akkor azt oda tedd meg. Nagyon figyelj, hogy a jelszavadat írd le valahova, mert sajna a freeweb nem támogatja az e-mail-es kiküldést. Lépj be te is "hivatalosan" a MORFEuS-ba. Olvasd el elötte az Alapító okirat menüpont alatt található oldalt!

Ennyi, üdvözöl:
SonicRulez

ui.: Mi a fene az a "Visio"???????

Szia, István!

Kicsit elmaradtam, májustól végétől december közepéig
sajnos be sem apcsoltam a gépemet (((
De mostmár újból itt vagyok!

Az új lapozásnál tartottam, pár napja folytatom a terveket.
Visio-t használok hozzá. Mi a véleményed(nyetek), jó ötlet?

Sparow

PS. még nem olvastam végig amiröl lemaradtam, még van kb.
100 bejegyzés.

Hali!
Tánczos Zoli egyéb kínjai közepette is töretlenül javítgatja a MORFEuS Fórumot. Persze ez is nagyon fontos. Sőt.
Most eppen azt probalom kitalalni, hogy a textarea tag egy formon belul miert nem akar mukodni necckap alatt... majd lelesem, hogy az lx-esek itt hogy csinaltak:)
Nah, akkor inkabb nem irok tobbet, hanem bugot keresek:)
Bye:
W_Irving

Háj!

Megint én vagyok (jééééé). Szerintem nem kéne elfelejteni ezt a fórumot, csak, mert van sajátunk. Ezen (jelenleg) sokkal többen böngésznek, mint a miénken. Ha pedig elzárjuk magunkat a külvilág elől, akkor azzal csak magunknak ártunk!

Ígyhát állapotjelzés következik:
A rendszer fejlesztése az ünnepek és a vizsgaidőszak miatt kissé megtorpant. Azonban Bodnár Andris így is csinálja az MI ügynököt, aminek főképp az MI-s shell kifejlesztésben van nagy jelentősége. Én egy leíró nyelven (EVUI Script Language) dolgozom, ami elégfontos a felhasználói felületet és egyéb területeket illetve. Miután megírtam a BootFS doksiját, robi **** az erőkkel, és elkezte(?) tervezni (csinálni) a boot-olható verziót. De mielőtt ezt tervezni kezdjük, egyeztetünk a rendszer-hívások meghatározása miatt. Ezek a fontosabb fejlesztések.
Tánczos Zoli egyéb kínjai közepette is töretlenül javítgatja a MORFEuS Fórumot. Persze ez is nagyon fontos. Sőt.

Ennyi:
SonicRulez

Hali!

Felfedeztem 1 kis pontatlanságot, illetve elírást a BootFS leírásában:
- az ActAllocBlk nem a foglalt blokkok száma, hanem a foglalt leírók száma. Utóbbi azért hasznos, mert így a keresés leegyszerűsödik vele 1 1*ű számláló ciklusra.

Csak ennyi:
SonicRulez

Hali!

Nos, a GALAMBOK mint yól tudjuk sirály királyok... )))))

Tökölök a keyd-n. Hamarosan az is kész lesz. Azonban pár dolgot megj1eznék:
- nem írok kódot hozzá, mert a rendszer forrását már 3,5 hónapja nem láttam
- úgy írom meg, hogy az beilleszt7ő lesz a _végső_ rendszerbe
- és megtervezem evvel egy időben is az emulációs interfészt is, mert hiszen az motan nékünk marohára köll...

Ennyi:
SonicRulez

ui.: sikert a vizslaivószakhoz... ;>>>>>>

Szio SONIC!

Na ennek orulok, de NAGYON!

Meg annak is orulnek, ha Zsolti@egon.gyaloglo.hu vegre irna nekunk egy emilt es elbeszelgetnenk vele, de komolyan. Csak hat meg nem keresett meg... Teged sem? En nem ertem a sracot. Nem akarja a JOT?

Na, GALAMB legyen Veled! Mert az ero vele van, mint tudjuk )))))))))))))))))))))))

Hali!

BootFS állapot jelentés: KÉSZ

Nos, a legnagyobb dilemmát a mountol6ás kérdése jelentette, ezzel nem kevesebb mint másfél hét ment el! Végül úgy határoztam, hogy nem lesz mount-olható, csak elérhető, de az elérés is csak engine-mag szinten lesz támogatva - így kellően babrás lesz.

Főbb paraméretek:
- maximális kiterjedése 16Mb
- nincs alkönyvtár lehetőség
- csak az utoljára létrehozott fájl törölhető
- nincs allokációs tábla
- Beta-X-Point jelzi a fájlokat, azaz ezek a fájlbejegyzések
- nincsenek attribútumok
- a fájlok neve max 16 karakter
- az állományok csak is egymás után, kihagyás nélül következhetnek
- nincsen tulajdonjog, tehát kompatibilitási szempontból a benne foglalt állományok senkihez sem tartozik, egygedül az engine-maghoz.

MBXP (Main Beta-X-Point):----------------------------------
ID1:"BootFS by Sonic. Only used for EVUI and MagMaTic-engine"
ID2:"Copyright by MORFEuS (c) 2001.12.13."
FrstAllocBlk: DWORD (64 bit == Rel. Sect. ID)
ActAllocBlk: WORD (15 bit) == hány foglalt blokk van
LastAllocBlk: WORD (15 bit) == FS relatív!!!
FirstFSBlk: DWORD (64 bit == Rel. Sect. ID)

BXP (Beta-X-Point):----------------------------------------
FName: 16 BYTE
FBlkLen: WORD
FLen: DWORD


És most pár magyarázat: a fájlok a mindenkori relatív szektor sorszám szerint helyezkednek el fizikailag a tárolón. Tehát például egy vinyón egyetlen partíció egy MasterFS, melynek része a BootFS és az azt követő _valódi_ MasterFS. A BootFS ekkor az alábbiakat fogja tartalmazni:

(Relatív 0-ik blokk!)
MBXP (Main Beta-X-Point):----------------------------------
ID1:"BootFS by Sonic. Only used for EVUI and MagMaTic-engine"
ID2:"Copyright by MORFEuS (c) 2001.12.13."
FrstAllocBlk: 1
ActAllocBlk: 3
LastAllocBlk: 78
FirstFSBlk: 2+32768+1+1 == az MBR és a partíciós tábla által és a BootFS által foglalt blokkok (32769) plusz az azt követő blokk

BXP (Beta-X-Point):----------------------------------------
FName: "MasterFS.Driver"
FBlkLen: 3
FLen: 1253
::::::::::Data::::::::::
BXP (Beta-X-Point):----------------------------------------
FName: "MFS.BootMMGR"
FBlkLen: 8
FLen: 3712
::::::::::Data::::::::::
BXP (Beta-X-Point):----------------------------------------
FName: "BMMGR.Anim"
FBlkLen: 67
FLen: 33812
::::::::::Data::::::::::

Például. Asszem ez a teljes. Lehet szidni, kérdezni, meg mittom én. Ez még a baromibétatesztverzió...


Ennyi:
SonicRulez

ui.: Ezt magamnak is lemásolom...... )

Szio!

Neha en is idenezek, de most majd egyre ritkabban, mert jon a vizsgaidoszak es akkor egy ideig nagyon nem fog semmi tortenni - reszemrol. Jo lesz bugjavitasra es gondolkodni azon, hogy kapcsolodjak az EVUIhoz...

1elore ennyi udv all: nr

Hali skacc!

Eszembe jutott valami:
Ha azt akarod, hogy a rendszert tényleg EVUI-nak hívhatjuk, akkor ki kell dolgozni egy normális video-interfészt. Ha meglesz, és kész lesz végre a C fordító (persze OOP és COP), akkor én megírom a grafikusz felületet. Ennek felépítéséröl majd _akkor_ dumálunk. Láttad, vannak rendszerterveim erre vonatkozólag.
Apropó EVUI; a rendszer lelke a "szét emulálok mindent" féle gondolkodás. Tehát kell tervezni egy ehhez illeszkedö kivételkezelöt, és egy emulációs interfészt. Utóbbit én megtervezem. Ha gondolod. Persze ez még csak a jövö fuckit-je, majd elválik, hogy hogy fog ez kinézni.

Ennyi:
Sonic

Hali!

Ha már szóba hoztad volne 1 igen komoly:
Linux-al Netscape alatt absolute suxx - azaz nem megy. Azt nem tudom, hogy csak a Liszutykos Netszképpel csinálja (ill. nem csinálja ) vagy a kíndózossal is. Meg kéne nézni.

Addig is allz:
A keyboard daemon tesztje negatív, következésképpen teljesen **** lett. Ez nem baj, csak újabb plusz idö. Ez sem baj, mert már kidolgoztam egy tényleg durva keyd felépítést, ami támogat:
- több kódlapot egyszerre ( Symetric Multi Codepages)
- speciális fontkészlet kezelést
- táblázattal megadható billentyü kombinációkat
- egy folyamatosan frissül billentyü-tömböt a memóriában
Namost; az SMC azt jelenti, hogy ha két progi fut (pl), akkor az egyik szerint (ha az Isten és a júzer is úgy akarja) pl magyar billentyüzet elött ül az ember, a másikon meg angol elött. Azt viszont konkrétan semelyik program sem fogja tudni, hogy milyen a billentyüzete. Ezt majd egy indikátor jelezheti pl, de a billentyüzetröl nem az alkalmazásnak kell tudnia. Söt az eredeti rendszertervekben úgy szól a fáma, hogy a progi arról se tudjon, hogy ez billentyüzet, megosztásos billentyüzet, vagy billentyüzet emuláció -e. Olyan eokorschegeket, mint amit pl 1s Adobe szutykok müvelnek (nem Angol a bill. kiosztás, ezért bevágom a durcát féle szitu) pont ezen okok miatt nem fognak a progik csinálni. Meg aztán az EVUI attól EVUI, hogy nem a rajta futó alkalmazások az okosak, hanem a rendszermag, és a felhasználó. Fontos azonban majd kellö felületet nyitni a bill. emuláláshoz is. Pl ha egy vak vagy mozgássérült beakar diktálni egy szöveget, ahhoz a proginak semmi köze akkor, hogy a bemeneti forrás egy mikrofon, vagy tényleg bill. -e. Ezt szintén a rendszermagnak kell támogatnia, ezért bele lesz dolgozva az erre való interfész is.
A keyd ezen verziója 4.0-tól indul, mert nekem már ki van dolgozva pár 1.x-3.x-ig driver, de ez most meröben más lesz - köv. képp indokoltnak találom a major-verziószám megugrását.

Nos, mára ennyi:
SonicRulez

ps.: Anyámékkal egy hajómodellen KELL dolgoznom, ezért most a méló fogalmam sincs meddig fog tartani. Sietek majd. Még ki kell dolgoznom az algoritmusokat, meg az emulációs interfészt, aztán le7 (meg)örülni...

Hali

Egy apro megjegyzes: a nevem W_Irving nem W_Irwing... ;]

forum: hat, kiderult, hogy en se vagyok tokeletes;] de remelem elobb utobb (inkabb elobb) minden hibat felderitunk, es fikszajjuk ;]

udv:
W_Irving

Kedves mindnyájatok!

Ezt a fórumot addig kell éltetni, amíg meg nem unjuk. Szóval _nem a mai nappal befejezőleg_, hanem amíg bírjuk. Innen tudja meg akülvilág, hogy mi történik Nálunk. Amíg a magyar keresőrendszerek nem ajánlják ki a MORFeuS címét, addig ez az egyetlen fórum, amibven bízhatunk. SupergameZ suxx, Index is Suxx. Azért ez elgondolkodtató. Én mindenesetre megadok mindig egy utolsó utáni esélyt minden embernek. Talán azért, mert még csak próbaidős tanársagéd vagyok és nem kaptam fel a vizet eléggé. A türelmes eber as jó ember, a türelmes tanár a jó tanár. Persze imho, azaz szvsz.

Mindenesetre örülök, hogy mégis egyre többen leszünk és mindig azon izgulok, hogy szét ne essünk. Remélem, ez nem fog bekövetkezni, van elég becsület és barátság bennünk ahhoz, hogy mindenáron fenntartsuk és szeressük, amibe belekezdtünk.

Erőt, békét és szeretetet mindenkinek!

Üdv: nrobcsi

Sziasztok !

SonicRulez:
"A MORFEuS-ba olyanok is bekerül7nek, akik -
mint Te is - "csak beleszólnak" a rendszer működésébe -
mível az ilyeneket hívhatjuk rendszertervezőnek."

Akkor ezúton kérvényezném a felvételemet. ))

To All: Átmentem véglegesen a Morpheus fórumba, ezentúl
csak oda irogatok.

Tisztelettel,
Bodnár András

U.I.: Morpheus fórum RuleZ !!! Thanks to W_Irwing.

Hali!

Nos, köszi W_Irwing a fóRUMot, jöttem, láttam, qrva yo lett.
BA: Köszi a dicséretet (EVUI, MagMaTic), ez mindig jól esik az embernek. Azonban van egy régebbi dolog: A MORFEuS-ba olyanok is bekerül7nek, akik - mint Te is - "csak beleszólnak" a rendszer működésébe - mível az ilyeneket hívhatjuk rendszertervezőnek.

Mégvalami: a KeyDaemon-t már tesztelem (persze csak pascal-os környezetben, mivel nem akartam írni még egy redszerprocesst az image-be). Miheyst tuti: küldöm át.

Robi: TE min kattogtál mostanába ("...csendben durvákat alkotok...")??

Allz: az hogy a fórum döglik, az amiatt van, hogy az országon belül az:
DB emberek összetartása DUP(0)

Ez nem a mi hibánk, hanem a többi emberé, akiket most nem méltatok véleményre, mert csak egy rakás csillagból állna...
Az pedig hogy ezen a topic-on csak ennyien maradtak, az annak köszönhető, hogy sikerült lerostálni a "szemetet" az idő vasszűröin. Háát - a végeredmény _valóban_ megdöbbentő (4 ember)!

Asszem mára ennyi:
SonicRulez

ps.: mindig írok egy ps-t. Most azt, hogy nem írok ps-t. Ennyi.