A deviceokkal kapcsolatos alapotlet ott tudja kamatoztatni kepessegeit, hogy pl a filekezeles magasszintu vezerleset is ezzel oldjuk meg (es csak ezzel). Ez azt jelenti, hogyha pl van egy prgd, mondjuk egy kep editor, amihez kaptal a fejlesztotol jpeg, gif, bmp formatum irao-olvaso device-t (ezek nelkul sokkal bonyolulutabb lenne megirni a programot) , es van meg mondjuk egy kep convertalo prgd, amihez kaptal pcx, fif meg eps deviceokat; a ket progi felinstallalasa utan automatikusan mind a ket progi (illetve az osszes) tudja mind a 6 formatumot irni, olvasni...
Mas. Mivel pc-re meg nem lattam VMS-t (es mivel az OS elso verziojat PCre irjuk) ez nem isgat annyira.
A Mainframe-ek objektumorientaltsaga egy kicsit mas, mint amit mi elterveztunk. A mienk ha lehet meg annal is sokkal alltalanosabb lesz.
Objectum fa, vagy DB mindegy hogy hogy hivjuk, nalunk is kulon lesz, tobb adatbaziban, kulonbozo reszei kulonbozo keppen kodolva, stb...
Mivel egy kezdetleges C fordito megirasa nem olyan nagy feladat (foleg, hogy mire ide eljutunk az OS alapbol kezel majd ebbol a problemabol egy csomo dolgot), viszont elengedhetetlen, mivel nem gepei kodot kell majd forditania, hanem byte kodot, amit mi fejlesztunk ki. Ettol lesz majd hordozhato a progi.
Mint mar emlitettem, hogy a hardware deviceokat nem erdemes igy megirni, hiszen minden gephez mas processzor, IO felepites bus kezeles tartozik. Ezek ugyan ugy mint a kernel, assemblyben irodnak. Egyebken Arpi nem rosz az otlet, mar meg is valositottak: JAVA :)
Ezt mi csak sebessegi megfontolasok miatt vetettuk el... :)
Nagyon jo otlet, mert a presentation layer nagyon kell az ablak devicehoz. Meg a keprenyodevicehoz se art. Sot, inkabb meg egyet tegyunk bele tartaleknak.
Tenyleg, ha Leonyid is benne van project-ben, akkor valoszinuleg sikerul a dolog. Ha nincs, akkor surgosen vegyetek be, mert remek halozati szakember. A presentation layer a szakterulete.
De gyerekek. miert nem szoltok a leonyidnak. O mindent tud azenterol. Csak az a baj, hogy nem tudom, hogy hol van most a leonyid.
Tudja valaki, hogy hol van a leonyid?
De a tarhonya tok jo fej. Meg igaza van. Tenyleg nincs a karcoraban zenekar.
Es jo lenne egy kicsit megnezni az MVS-t vagy a VMS-t vagy akarmelyik junikszot oszt abbol venni az ecat., nem a windoze assemblybol.
Fel kellene ebredni fiuk, mert igen nagy atveres reszesei vagytok. Cyborgyn meg eleteben nem latott szamitogepet kozelrol, legfeljebb Sony PlayStationt. Az aki a kepernyo es az ablakkezelo device-t tudja megemliteni egy keszulo operacios rendszerbol az a hetzeneskarcoraban is kereste a zenekart.
cyborgyn:
- Ingyenes lesz, oke. Es van ra garancia, hogy az is marad?
- Szerintem tul nagyok a vagyak... Assemblyben kernelt, device drivert, C forditot... Ebbol mar kulon a C fordito is eleg nagy falat.
Egyaltalan, minek kell C forditot irni? Miert nem jo a GNU C forditoja?
- Monolitikus vagy mikrokernel lesz? (csak ugy erdekel)
- Assemblyvel az a baj, hogy lehet, hogy ma optimalizalod a kodot Pentiumra, de lehet, hogy PII-re, Mercedre, stb. teljesen mashogy kell optimalizalni.
Egy jo C fordito pont az optimalizalasban jo, a leforditott program, bar nyilvan lassabb lesz az assembly parjanal, de nem sokkal.
Nem akarlak elkeseriteni, de en nem latok nagy jovot a dologban. Persze nem lehetetlen megirni, jora is akar, csak sok munka, sok ido es nehez. Nameg ld. hasonlo projectek.
Egy ötlet, ami talán nekem jutott eszembe először, talán nem:
Ha nagyfokú stabilitást és processzor-kompatibilitást akartok és kis kernelt: Írjatok egy virtuális processzort, amiből akárhány futhat egyidőben, és egymással jól kommunikálnak akár lassú vonalon is. Így bármilyen új procira csak egy kis valamit kell ráilleszteni, optimalizálni, és megoldható a feladatok igazi multiprocesszálása. Gondoljátok végig! Szerintem az új gépek és oprendszerek alapja lehet ez a gondolat. Még ha nekem jutott eszembe, akkor is. :o)
Termeszetesen a kernel minden procin mas lesz... Ez kikerulhetetlen. A felhasznalo szintu deviceok meg a felhasznaloi programok lesznek csak hordozhatok! (a hardware kezelo deviceokat ertelmetlen es lehetetlen lenne megirni igy, nem de?).
Egyebkent DOSban, Novell Netware 4.11ben (NLM) meg Windows assemblyben elegge otthon vagyok :) Linuxot ennyire meg nem ismerem, de ami kesik nem mulik! :)
En szemely szerint a Windows clonoknak meg vagy 3 evet josolok, addigra ez is el fog keszulni. Persze Hardware Device programozokra szuksegunk lesz! Ugyhogy mar is varunk port kezeles szinten jartas emberkeket!
Gyakorlatilag ki is talaltad az egyik alapotletunket... Egy hasonlo Objektum fat tervezunk bele mi is, ez kezelne tovabba a rendszer mukodesehez szukseges deviceok betolteset, felhasznaloi jogosultsagok, stb... Majdnem mint a Novell 5-ben (csak jobb :)
Ingyenes lesz, es majd le lehet tolteni a netrol. (Ez persze nem lesz nagyon nagy feladat, mivel maga a kod eleg kicsi lesz, thanx to Assembly).
Assemblyben pedig csak a kernelt, meg a drivereket + deviceokat irjuk csak, meg hozza az elso C forditot :)
Mivel a rendszeren belul mindent device kezel (pl kepernyo, ablakok stb...), ezert a felhasznaloi programokon kivul ez gyakorlatilag mindent jelent :)
Assemblynek meg van meg az az elonye is, hogy olyan gyors tud lenni, amilyen csak akar! :)
A tesztelokhoz csak annyit, hogy meg egy kicsit varni kell, mert meg csak most kezdtuk el specifikalni!
Ez ugye vic ? Hol lesz akkor a Win95 mire egy ilyen rendszer elkeszul ?
Reklam: C64, es Win95 emulator is van hozza
Nezo: Mi az a Win95 ? :)
OK, lesz egy uj oprendszer. Van mar vagy 10.000 vagy megtobb.
DE ennyi szolgaltatast megalmodni ?
Szerintem amig nem lesz meg egy jo C fordito ami mar leforditotta magat, addig nem erdemes a tavlatokrol _gondolkozni_ sem.
Vegyes processzorkornyezetre tervezni asembler programot :)
Hanyan irjak a HURD-ot, es meg mindig csak hol tart...
Nem hiszem, hogy szerencses dolog, hogy erre ennyi idot forditotok.
Talan jobban jarnatok - ha komolyan gondoljatok, es nem csak vicc - ha nehany _evig_ alaposan tanulmanyoztok egy _letezo_ oprendszert, beszalltok a fejlesztesbe, es akkor mar jobban fel tudjatok merni az idoszuksegletet a dolognak.
Kérdések:
- Milyen licensze lesz? (GPL?)
Ingyenes vagy pénzes lesz?
- Miért assembly-ben írjátok?
Onnan nagyon nehéz (ha nem lehetetlen) lesz portolni más architektúrákra.
Legyen az oprendszer szerves része egy objektumorientált adatbázis, ami egybe van integrálva a lokál fájlrendszerrel.
Így a fájlrendszer is faul-tolerant lenne...
Dinamikus scheduling, független jogosultság model...
Mennyi idobe fog kerulni mire megirtok egy ilyet?
Hozzam is eljuttathatnal majd egy tesztpeldanyt :))))
Ja igen! Kezelheto legyen a Win95 generacio szamara is...
Sok szerencset
bnoplwk2!
- megbizhatosag... ez az elsodleges, mind futas, mind adatbiztonsagot tekintve
- jol dokumentaltsag nem gond, mivel a spcifikacio is teljesen reszletes,
- fault recovery ki fog terjedni meg a hibas mem modulok kezelesere is,
- filekezeles az "objectum fa"ban szereplo speci device-okkal tortenik,
- teljeskoru - akar manualis - eroforras konfiguralas
- irrealisan kicsi kodmeret (az egesz assemblyben keszul!!! :)
- kesobb talan lesz majd Mac, Casio HHPC stb... valtozat is... A lenyeg, hogy az osszes progi futni fog a kulonbozo gepeken! :))