Microsoft Windows forráskód!

Microsoft Windows forráskód!
2003-08-05T20:18:26+02:00
2003-08-11T17:23:46+02:00
2022-11-02T01:41:50+01:00
  • Mi lesz okt. 28-an?
    Mutasd a teljes hozzászólást!
  • 1. valamitol marha lassu lett a szerver.

    2. Valaszok:

    már itt kezdődnek a tévedéseid, hogy ti. az NT kernel nem processzeket ütemez - ahogy te írtad -, hanem szálakat


    Ez igaz, de nem igazan erdekes a problema szempontjabol.

    ... még az OS megszakíthatja, sőt, nem csak, hogy megszakíthatja, de meg is szakítja minden néhány század másodpercenként (a quantum Windows-változatonként eltér, az NT alapú szervereken általában 10ms), és újraütemezi a várakozó szálakat.


    Elmondtam mire volt hasznalva a rendszer. Az emlitett feladatnak nincs nagy memoriaigenye. A hatterben ertelemszeruen nem futott semmit mas program. Csak amit az OS magatol futtatott.

    Memoriahiany nem allt fenn, ergo ha swappolt, akkor azt ok nelkul tette.

    A service-ek le voltak love amit csak le lehetett, mert nem kellett a gepre, es pont az volt a cel, hogy ne masszon kozbe semmi.

    Processzeket atutemezni nem hiszem hogy kellett, ha mas alkalmazas nem futott.

    Mivel csak egy csatlakozot figyelt folyamatosan (konkretan nem emlekszem mit mondott, interruptot adott-e a hardver vagy poll-ozni kellett, de tekintve hogy fel volt haborodva hogy megszakitotta az OS, felteszem hogy igenis portot pollozott).

    Egy olyan oprendszeren amin a service-ek le vannak love, swappolni nem kell, es folyamatosan olvasgatnak egy port-rol, mas io nelkul, es a minimalis reakcioido a cel egy azaz egy processzben, az hogy a user interface megszakitja a processzt, igenis pofatlansagszamba megy. Megis miert van realtime prioritasa a user interface animaciojanak?

    Szerintem a tovabbiakban hanyagoljuk a temat, mert ugyse tudok tobb informacioval szolgalni, egy oprendszer mukodeserol igenis vannak fogalmaim. Nem allitom hogy kernel szinten programoztam barmelyiket is, es windows-al nem is nagyon foglalkoztam programozas szintjen.
    Ergo meg csak leellenorizni se tudom, meg nem is akarom hogy tenyleg igazad van-e. En csak leirtam az esetet mivel ezt kerted.



    Mondjuk kicsit durva kivansag. A Windowsnak nagyjabol a legjobb resze a user interface, tenyleg nem fair kihajitani :)

    Ez is egy szép nagy tévedés. Bár pontos számok nincsenek előttem, de saccra megmondom neked, hogy ha egy standard NT4 workstationben összeszámolnánk az összes elérhető API függvényt (base services, RAS, COM, GDI, USER, Winsock, WinInet, stb.) és megnéznénk, hogy ezeknek mekkora részét teszik ki a júzer interfésszel összefüggésbe hozható GDI+USER függvények, akkor 1%-nál is kisebb értéket kapnánk.


    Figyelj Sting, en megtanultam irni. Te legy szives tanulj meg olvasni. Hol lattad az idezett reszben hogy en azt mondtam hogy legnagyobb? En azt mondtam nagyjabol a legjobb. Szerintem a ketto teljesen mast jelent.

    Gondolom nem direkt adtad a szamba, ugyhogy legkozelebb legy szives figyelmesebben olvasd el mit irnak a lapra, ugyanis ugy nezem neha csak ranezel, es valamit elkepzelsz hogy mit irnak, es arra valaszolsz, kozben teljesen masrol irtak mint amit hittel hogy irtak. Mint pl. most.
    Mutasd a teljes hozzászólást!
  • A Windows modularitásával kapcsolatosan holnap reggel jelenik majd meg egy érdekes hír az oldalon. Érdemes lesz elolvasni itt.
    Mutasd a teljes hozzászólást!
  • Ki várja október 28-át?
    Mutasd a teljes hozzászólást!
  • Linuxon megmondhatod hogy melyik shared object milyen verziojat kered majd betolteni mikor a program toltodik.

    Ugye nem a symlinkes dologról beszélsz? Mert az egyrészt nem az OS szolgáltatása, hanem egy maximálisany "user mode" hack, másrészt ez Windows alatt is tökéletesen ugyanígy megoldható (ha olyan FS-en dolgozol, ami nem támogatja a symlinkeket, akkor persze csak másolással, de a lényeg ua.).
    Mutasd a teljes hozzászólást!
  • haver egy epitoanyaggyarnak fejlesztett vezerloszoftvert a gepekhez.[...]

    Hú, nagyon súlyos hiányosságaid vannak már az operációs rendszerek elméletével kapcsolatosan is. Javaslom a Tized által írt "Mikrokernel architektúrák" nevű sorozatunk elolvasását.

    Attól, hogy realtime egy szál (már itt kezdődnek a tévedéseid, hogy ti. az NT kernel nem processzeket ütemez - ahogy te írtad -, hanem szálakat!) még az OS megszakíthatja, sőt, nem csak, hogy megszakíthatja, de meg is szakítja minden néhány század másodpercenként (a quantum Windows-változatonként eltér, az NT alapú szervereken általában 10ms), és újraütemezi a várakozó szálakat. A realtime-ság csakis annyit számít, hogy a kernel addig nem ütemez nem-realtime szálat, amíg van olyan real-time szál ami nem várakozó vagy inaktív állapotban van.

    Ez utóbbi egyben azt is jelenti, hogy pl. a realtime szálak egymást nem tudják kiszorítani, mert attól, hogy más szálakkal nem versenyeznek a CPU-ért (azokkal szemben abszolút prioritást élveznek), egymással még bizony keményen küzdenek az erőforrásokért.

    E miatt egyáltalán nem kell semmilyen "összedrótozása" a GUI-nak és a kernelnek ahhoz, hogy egy adott alkalmazás által indított realtime szál elől egy másik elvehesse a CPU-t. Ehhez mindössze az szükséges, hogy a másik szál is realtime prioritással rendelkezzen, és máris előbb-utóbb (I/O-aktivitástól, meg attól függően, hogy milyen régen jutott CPU-hoz) ütemezésre kerülhet.

    A te példára vonatkoztatva tehát a desktop simán újrarajzolhatta magát akkor is ha egy másik realtime szál 100%-ban kihasználta a rendelkezésére bocsátott CPU-időt - hiszen ha neki (desktop) is van egy realtime osztályú szála, akkor ez nem probléma.

    Megjegyzem az egyébként önmagában szinte lehetetlen, hogy egy realtime szál 100% CPU-t használjon (ha csak nem egyetlen "while (true);" végtelen ciklus az egész), mert előbb-utóbb valamilyen műveleten biztosan várakozó állapotba kerül (amikor kénytelen lesz más szálakra várni, akár egy grafikus hívás során is). És ha ez megtörténik (és minden más realtime szál is ilyen állapotban van, ami azért időről-időre előfordul statisztikai alapon akkor is, ha viszonylag sok realtime szál működik párhuzamosan), akkor máris ütemezésre kerülhetnek nem-realtime szálak is.

    Szóval egy mondatban összefoglalva: hibás a következtetés, amely abból a tényből, hogy egy v. több realtime osztályú szál futása mellett a desktop újrarajzolja magát, azt a következtetést vonja le, hogy bármi összedrótozás van a GUI és a kernel között. Garantálom neked, hogy ilyen nincs, más téren sem. (A GDI egyébként az NT4 óta el lett mozgatva a kernel felé egy picit performance-okokból, de ez semmilyen összdrótozást nem okoz/jelent, és pláne nincs összefüggésben az általad említett jelenséggel.)

    Mondjuk kicsit durva kivansag. A Windowsnak nagyjabol a legjobb resze a user interface, tenyleg nem fair kihajitani :)

    Ez is egy szép nagy tévedés. Bár pontos számok nincsenek előttem, de saccra megmondom neked, hogy ha egy standard NT4 workstationben összeszámolnánk az összes elérhető API függvényt (base services, RAS, COM, GDI, USER, Winsock, WinInet, stb.) és megnéznénk, hogy ezeknek mekkora részét teszik ki a júzer interfésszel összefüggésbe hozható GDI+USER függvények, akkor 1%-nál is kisebb értéket kapnánk.
    Mutasd a teljes hozzászólást!
  • Egy kis adat:
    -Az eredeti Windows 95 forráskódja 8,5 millió sornyi kódot tartalmaz, Internet Explorer-rel kiegészítve 14 millió

    És egy kis idézet a Microsoft régebbi bejelentéséből:
    -"Ha monopólium volnánk, az operációs rendszer ára a gép árának 25-35 százalékát tenni ki".

    Hozzáfűzés:
    -akkor ezek szerint már monopólium
    Mutasd a teljes hozzászólást!
  • Ezzel szemben windows esetén a kernel felett van a win32, fölötte az alakalmazás. A win32 viszont egységes, annak egyes komponenseit már nem tudod eltávolítani.

    Ez duplán nem igaz.

    Egyrészt a Win32 nem egyetlen összefüggő hatalmas valami, hanem egymástól nagyon jól különválasztott funkciócsoportok halmaza.
    Természetesen az ezeken az API-kon keresztül megvalósított funkciók többé-kevsébé egymásra épülnek (pl. a hangvezérlést és a grafikus függvényeket használja a böngésző, és a médialejátszó is), de ez nem öncélú, és pláne nem összedrótozás, hiszen a függési rendet a funkcionális hierarchia határozza meg. (Drótozás az, amikor ilyen szigorú hierarchia nem határozható meg, hanem gyakorlatilag minden összefügg minden mással.)

    Másrészt ennek az API-nak a nagy részét el lehet távolítani "büntetlenül" abban az értelemben, hogy az OS még simán be fog bootolni tőle. Természetesen azok az alkalmazások és funkciók amelyek az eltávolított komponensekre épülnek nem lesznek működőképesek már - de hát ez már csak logikus.

    Amit itt érdemes észrevenni az az, hogy az OS-be (Windows) nem véletlenül kerülnek bele dolgok, hanem olyan funkcionalitast (API-kat) pakol bele az MS, amit sok alkalmazas hasznal, vagy amiket mar eleve az OS-be epitett alkalmazasok is igenyelnek. Igy tehat tok logikus, hogy ha a jelenlevo komponenseknek akar csak kis reszet is eltavolitja az ember, akkor a rendszer sulyos mertekben veszit kepessegeibol.

    Mar csak azert is, mert mas rendszerekkel szemben sokkal egysegesebb a platform, es sokkal kevesbe redundans (azaz pl. nem tartalmaz minden alkalmazas sajat, vagy legalabbis 3-4-fele konyvtarakat a hanggeneralastol kezdve az ablakozasig, hanem minden alkalmazas pontosan ugyanarra az egyetlen, minden Windows-ban jelenlevo konyvtarra epit).
    Mutasd a teljes hozzászólást!
  • Mondjuk inkább úgy minden distriben életre lehet kelteni.Az általa készített programokkal már jobb a helyzet, az szépen műxik Debiantól RedHat-ig mindenen, de a K3 elég érzékeny jószág. Egyrészt bizonyos kernel verziókban van egy hiba amit nem szeret és ez a bug sajnos elég sok gyári kernelben benne van (RedHat 9, SuSE 8.1 még biztosan, 8.2-t nem próbáltam). Ezeken kernelt kell fordítani. A C++ része még további sebekből vérzik, ő aztán tényleg megválogatja hogy min lehet elindítani: csak a nagyon régi és a nagyon új disztribekkel megy, bár ez esetben kell némi további varázslat is ami letölthető a Borland weblapjáról. A dolog a glibc, a szálkezelés és a wine-ra alapuló IDE körül van elásva. Szerencsére a mai disztribekkel (Pl. az én Mandrake 9.1-em) és egy patch segítségével a dolog megoldható. Bár én ennek ellenére inkább a Pascal részét használom: a CLX ahogy a VCL is szerintem sokkal jobban kezelhető Pascal alól, a C++-os interfészével nem igazán vagyok megelégedve (ez egyébként a C++ Builderre is igaz, bár ezzel együtt is 1000x inkább csinálnék C++ Builderrel egy desktop alkalmazást mint Visual C++ 6-tal /az újabbakat nem ismerem lehet hogy azóta sokat fejlesztett rajtuk a M$/).
    Mutasd a teljes hozzászólást!
  • Az én tapasztalataim szerint sokfélén megy, de biztos nem mindegyiken, viszont a c++ ide-je egyes disteken nagyon rakoncátlan tud lenni
    Mutasd a teljes hozzászólást!
  • Most már értem mire gondoltál. Sejtettem is, de nem akartam feltételezésekbe kavarodni :)


    Szóval én egy szóval sem mondtam, hogy jó a monopólium vagy, hogy arra vágyok...

    Valóban kellenek a konkurencia OS-ek, mert különben nagyon elszállnának az MS árai :)


    Csak az nem jó, amikor van 1 oprendszer alatt sok különböző platformmegoldás.

    pl: Gondolj abba bele mennyivel egyszerűbb úgy fejleszteni adatbázisos programot, hogy tudod a célplatformot. Mert ugyan sokan mondják, hogy az SQL az szabvány és átültethető másik SQL szerverre, de ez csak a mesében igaz :) Sokat szívtam már Interbase -> Oracle és Interbase -> MSSQL portolással :)


    Tehát a Linuxnak nem biztos, hogy az a legjobb megoldás, ha minden feladatra fejlesztenek 28 különböző megoldást azon a címen, hogy legyen választási lehetőséged!


    Tehát nem a MS monopoliumára szavazok - annak ellenére, hogy én ilyen szoftvereket veszek magamnak és ajánlok a megrendelőimnek is - hanem arra, hogy a Linux 1 (!) úton járjon.

    Nagyon sok fejlesztő dolgozik rajta és a mostaninál sokkal komolyabb eredményeket érhetnének el - akár desktop szinten is - ha nem mindenki a maga feje után menne és egymás után dobnák ki a különböző distribeket, hanem csinálnának 1 Nagy Általános Linux-ot. (a nevét holnap levédetem NÁL-ra :) -


    Mert az áltag usernek még azt is problémát tud okozni, ha másik verziójú word elé ültetem le, mint amit otthon megszokott. Nem hogy más ablakkezelőt rakok alá...

    Én ugyebár a programozónak sem mindegy, hogy hány verzión kell tesztelnie...


    Ui főképp LC-hez: A Kylix minden distriben megy, vagy vannak ilyen jellegű korlátai? Anno a bemutatón még valami ilyet hallottam a Borland-osoktól.
    Mutasd a teljes hozzászólást!
  • Ez a gondolatmenet ide vezet: akkor miért is rossz az MS monopóliuma?


    Mert a monopólium a természetes evolúcióval ellentétes, nincs verseny, nincs valódi fejlődés.

    Péter
    Mutasd a teljes hozzászólást!
  • arra hogy:
    - a felhasználóknak jobb, ha 1 féle programot használnak, egyszerűbb megtanulni
    - a programozóknak is

    Ez a gondolatmenet ide vezet: akkor miért is rossz az MS monopóliuma?

    d5
    Mutasd a teljes hozzászólást!
  • Linuxon egy .so-nak tobb verzioja letezhet a rendszerben, egymas mellett ugyanazon .so kulonbozo verzioju valtozataira hivatkozhatnak az egyszerre memoriaban levo programok, a dinamikus linkeles megtartasaval (nem kell statikusan beleforditani). Ertsd, egy .so-nak tobb verzioja lehet egyszerre a memoriaban.


    Ez tökéletesen így van Windows alatt is a DLL-ekkel. Egy DLL akárhány verzióját használhatja egyetlen processzus. Statikus linkelés esetén gond lehet, ha a DLL verziószáma nincs a bináris nevében kifejezve, mert akkor az előre meghatározott úton fogja először keresni a rendszer, alapesetben a program mellett, majd tovább másutt, most hadd ne nézzek utána, hogy a standard %PATH%-on túl hol keres még.

    Emlexem en anno olyasmire hogy msvcrt.dll vagy valami hasonlo nevu dll-nek kulonbozo verzioit, meg kulonbozo modositott verzioit is installaltak a programok es agyba fobe szivattak egymast, azzal hogy mas jott fel a path-bol mint amit akartal.


    Lusta és rossz programozók ellen nem lehet védekezni :(

    Péter
    Mutasd a teljes hozzászólást!
  • "De az biztos hogy jóval előbbre tartana a világ ha nem lenne külön KDE és Gnome hanem egy közös..."

    Ebben 100%-ig egyetértek. Az egységesség nagyon fontos, hisz ezen dől el hogy adott szoftvert mekkora költséggel lehet fejleszteni és a szoftvernek mennyi futtatóplatformja lehet.

    Ezért érzem úgy, hogy 1 többet ér mint a sok.
    Mutasd a teljes hozzászólást!
  • Akkor szólj hozzá ahhoz
    Mutasd a teljes hozzászólást!
  • Jó lenne, ha a köv. hozzászólások már a Microsoft Windows forráskód! nevű topic-hoz kapcsolódnának!
    Mutasd a teljes hozzászólást!
  • A Gnome object modellje a Bonobo, ez az Orbit nevű Corba implementációra épül. A KDE-ben KParts van ha jól tudom. De az biztos hogy jóval előbbre tartana a világ ha nem lenne külön KDE és Gnome hanem egy közös (lehetőleg GTK alapú) rendszer lenne. A gáz az hogy a KDE jókora előnnyel indult amiből elég sokat máig is megtartott, ez a kényelmesebb, szebb felszín, ugyanakkor szvsz több szempontból is zsákutca.
    Mutasd a teljes hozzászólást!
  • A developer.gnome.org-ról:

    The GNOME Component Model

    CORBA and components enable GNOME programs to reuse code, add scriptability, and enhance interoperability.

    Bonobo
    Bonobo is a set of standard interfaces that are used as part of the GNOME project to provide standard component programming in Unix.

    DOM
    Document Object Model is a standard interface for access to document elements.

    bonobo-activation
    The Bonobo activation framework.

    ORBit
    The CORBA implementation used by GNOME.

    Mutasd a teljes hozzászólást!
  • Szerintem az két külön dolog, nálam pl most installálva van a bonobo, orbit, orbit2
    Bár mindegyik a corba-hoz kapcsolódik
    Mutasd a teljes hozzászólást!
  • Az orbit az a Gnome1-ben volt asszem. Gnome2-ben bonobo-nak hivjak mar, ha jol tudom.
    Mutasd a teljes hozzászólást!
  • Linux egy fajta van. A glibc egy fajta rajta. A KDE egy fajta, a GNOME egy fajta, a GTK a QT egy fajta (kulonbozo verziok vannak, mint minden programban amit aktivan fejlesztenek, MFC-vel is vannak verziok).

    A diszribuciok kozti kulonbseg, hogy melyik 3-4 ezer alkalmazast kapod vele keszen, gyorsan installalhatoan.

    De mindegyik ugyanazt a Linux kernelt adja (amit frissithetsz magaban is), ugyanazt a glibc-t adja (idoben ez valtozik, de egyidoben altalaban ugyanazok vannak a disztribuciokban).

    A frissebb glibc-vel termeszetesen futnak a korabbira szabalyosan irt (nem hasznalunk olyan fuggvenyt, ami nem az API resze) programok. Egyket ellenpelda akad mindig, de ez altalaban a program fejlesztoinek a hibaja. Nem mindig, de hat a Windows-ban se tudod gond nelkul futtatni a sokkal korabbi verziora irt programokat.

    Ergo az oprendszer altalaban egyfele. A csomagolasnal kovetnek el neha hibakat, de ha egy programot forrasbol forditasz, akkor az menni fog a gepeden (ha megvan minden library ami kell neki).

    A fejlesztoknek mindegy hany oprendszer van, kiveve ha 1 van es azt Microsoft Windows-nak hivjak.
    Mutasd a teljes hozzászólást!
  • Ez csak természetes, Windows alatt is. Vagy egyetlen shared objectben több verzió, úgy érted?


    Nem egeszen ertem a kerdest.

    Linuxon egy .so-nak tobb verzioja letezhet a rendszerben, egymas mellett ugyanazon .so kulonbozo verzioju valtozataira hivatkozhatnak az egyszerre memoriaban levo programok, a dinamikus linkeles megtartasaval (nem kell statikusan beleforditani). Ertsd, egy .so-nak tobb verzioja lehet egyszerre a memoriaban.

    Ez ugyanolyan mintha az egy konkret dll-nek a MSVC3 MSVC4 MSVC5 MSVC6-ban levo verzioi egyszerre lennenek a memoriaban. Emlexem en anno olyasmire hogy msvcrt.dll vagy valami hasonlo nevu dll-nek kulonbozo verzioit, meg kulonbozo modositott verzioit is installaltak a programok es agyba fobe szivattak egymast, azzal hogy mas jott fel a path-bol mint amit akartal.

    Linuxon megmondhatod hogy melyik shared object milyen verziojat kered majd betolteni mikor a program toltodik.

    Mutasd a teljes hozzászólást!
  • Ne felejtsük el, hogy a Linux-on pedig CORBA van a COM helyett. A GNOME object modellje az OrBit, a KDE-é most nem jut eszembe. Az egységes API gondolata nekem is szimpatikus lenne. Első körben javaslom a Windows API összes olyan függvényének a helyettesítését, amiben a WIN, Windows vagy hasonló szavak is benne vannak ))
    Mutasd a teljes hozzászólást!
  • 1999-ből már nemigen tudom előkeresni neked... De volt szó róla és arról is hogy hány ezer sor az új windows forráskódja, hányan csinálták, stb.
    Mutasd a teljes hozzászólást!
  • Nem tudom, mire akarsz célozni.
    Mutasd a teljes hozzászólást!
  • Ha olyan jó a Linux, akkor miért kell belőle ennyi fajta? Miért nem csak 1-et csinálnak, azon minden futna és nem lenne ennyi kompatibilitási kérdés.


    Tovább megyek: a fejlesztőnek nem jobb ha csak egy op.rendszer van? Minek több api-t megtanulni.

    Érted!?

    d5
    Mutasd a teljes hozzászólást!
  • "Ugyanugy ha Windows-on nem dll-be forditasz egy alrendszert, akkor Windows-on is ujra kell forditani az egesz alkalmazast."


    Ez így ebben a formában nem igaz. Itt van a COM egyik óriási előnye.
    Mutasd a teljes hozzászólást!
  • hol irták ezt?
    Mutasd a teljes hozzászólást!
  • (kulonbozo verziok betolthetok egymas melle!!!).


    Ez csak természetes, Windows alatt is. Vagy egyetlen shared objectben több verzió, úgy érted?

    Péter
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd