Terve. Olen tässä kirjoitellut graafisen käyttöliittymäni alla käytettäväksi omaa DOS-toteutusta, joka pyrkii olemaan enimmäkseen yhteensopiva Digital Researchin ja Microsoftin omien levykäyttöjärjestelmien kanssa. Suunnitelmissa on kuitenkin jättää pois täysin turhia legacy-järjestelmäkutsuja kuten kaikki File Control Blockeihin liittyvä, ja sisällyttää kerneliin muutamia järjestelmäkutsuja joita ei DOSissa yleensä ole, kuten unix-aika.
Video projektista: https://www.youtube.com/watch?v=ecriVQ9QFio
Koodit ja levykuva, jota voi testailla: http://sininenankka.dy.fi/~sami/fdshell/
Kerneli on kirjoitettu lähes kokonaan C:llä ja assemblyä on vain alkulataaja sekä sellaiset keskeytyskäsittelijät ja järjestelmäkutsut, joita ei ollut C:llä mahdollista kirjoittaa. Pyrin siihen, että kernelin voisi portata myös muille kuin 8086:n käskykannalle mahdollisimman pienin muutoksin.
Dynaamisen välimuistin lisäämisen jälkeen tuosta tuli aika paljon nopeampi kuin FreeDOS ja MS-DOS. Kehitystyö jatkuu.
Tämäpä on mielenkiintoinen projekti. IBM-PC ja MS-DOS ovat vaikuttaneet tietotekniikkaan niin paljon, että ansaitsevat vähintäänkin jonkinlaista "museoajoa".
Olen ymmärtänyt, että MS-DOS ja muut levykäyttikset eivät olleen teknisesti ihan huikeita. Käskykanta oli aika pieni. Ne oli kuitenkin alku sille, että käyttöjärjestelmä sijaitsi nimensä mukaisesti levyllä, eikä esimerkiksi rommissa. MS-DOS:in edeltäjän nimi oli QDOS, jossa Q tarkoitti "Quick and dirty". Se taisi olla syy, miksi QBASIC:in nimessä on tuo eksoottinen kirjain...
Omat käyttökokemukseni varhaisista DOS-ohjelmista ovat tosi hyviä. Ohjelmat olivat luonteeltaan natiiveja, eli ne riippuivat lähinnä itsestään. Siksi ne toimivat kuin junan vessa. Nyt kun suosituimmaksi ohjelmointikieleksi on Tioben mukaan luikerrellut se tulkki, ja moni C-ohjelmoija kysyy itseltään kannattaako enää tuskailla muistinhallinnan kanssa, niin tuollaiset videot ovat mieluista katsottavaa. DOS-aikaan nähtiin vaivaa sovellusten teknisissä perusteissa, ja ne ohjelmat toimivat edelleen sujuvasti kuten videosta näkyy.
MS-DOS -keskustelu lämpenee.
Itselläni kokemusta DOS 5.0 lähtien, mutta ikää on vasta noin 40, ensimmäisessä omassa PC-tietokoneessani 1995/1996 oli MS-DOS 6.2 muistaakseni, ja siitä lähtien olen käyttänyt kaikkia loppuja DOS-versioita paljon, ja Windowsit pääosin 3.11 Työryhmä windowseista tuttuja, ja jotkin NT winkkarit, joku Windows-versio taisi jäädä välistä. Otan osaa tähän keskusteluun.
MS-DOS lopulta sitä pidettiin yleisesti huonotaisoisena UNIX-kopiona. Voisiko olla näin, että MS-DOS oli alkusysäys sille, että käyttöjärjestelmä sijaitsi levyllä? Voisin olla vaikka eri mieltä tästä asiasta. Nykyaikaisen modernin moniajokäyttöjärjestelmän historia voidaan katsoa alkaneeksi vuodesta 1970, ja DOS ei ollut moniajojärjestelmäkään, eli ei edustanut mitenkään edistyksellistä kehitystä koskaan historiansa aikana.
Alunperin DOSin historia lähtee siitä, että Bill Gates osti Seattle Computer Productilta käyttöjärjestelmän kaikkineen, jonka tuo SCP oli kehittänyt Intelin 8086 -arkkitehtuuriin, ja se kulki nimellä 86-DOS, ja sitten Bill Gates räätälöi siitä MS -DOSin, jota sitten lähti lisenssoimaan IBM:n kloonivalmistajille, tosin IBM:lle myöhemmin sitten myös.
Oli vähän ohjelmasta, ja ohjelmoijan taidoista muistinhallinnan suhteen lopullisen ohjelman toiminta, kuinka siedettävästi ohjelma toimii. Mitä ne ainakin kaupalliset DOS-sovellukset varmaan enimmäkseen kirjoitettiin C++:lla, niin siinähän on muistinkäyttö täysin ohjelmoijan vastuulla, ja sitten riskit kasvaa ohjelman epävakaudelle ohjelmakoodin paisuessa isommaksi.
Vanhoja PC-pelejä, joita itsekin ostin penskana ja teini-iässä, kun ei ollut nopeita nettiyhteyksiä eikä Steamin kaltaista pilvialustaa, niin niitä pelejä on ihan kiva välillä DosBOXilla pelata, ja sitten on vapaasti FreeDOS joissain yhteyksissä boottisektorilla jos tekee esim USB-tikun jostain erityisestä ohjelmasta, firmwareissa yleensä on jokin FreeDOS:in kaltainen käyttöjärjestelmä, minkä hallinnassa ne ohjelmat toimivat siinä laitelmistossa.
Amiga-aikainakin kiintolevylle pystyi tallentamaan Workbenchin, ja eikö sekin ollut Amigan käyttöjärjestelmä ja sekin oli ennen DOS-aikaa taisi olla.
Onko tämä keskustelupuheenvuoro nyt täysin metsään mennyt? Mitä ajatuksia herännyt?
Ei MS-DOS ollut alkusysäys. Yritin vain avata sanaa "levykäyttöjärjestelmä".
lainaus:
Strictly speaking, this definition does not apply to current generations of operating systems, such as versions of Microsoft Windows in use, and is more appropriately used only for older generations of operating systems.
https://en.wikipedia.org/wiki/
Riskit varmasti kasvoivat ohjelmakoodin paisuessa, mutta DOS-ohjelmat olivat suhteellisen pieniä kokonaisuuksia. Lisäksi niissä käytettiin firmojen omia kirjastoja, joiden yhteensopivuus oli varmistettu. Viimeisinä aikoina poikkeuksena oli DOS/4G, joka lisäsikin epävakautta.
jsbasic kirjoitti:
Viimeisinä aikoina poikkeuksena oli DOS/4G, joka lisäsikin epävakautta.
Meinaatko DOS/4GW:tä? Minun muistini mukaan tuo toimi ihan hyvin. Itse tosin käytin omiin tuotoksiini Causeway DOS extenderiä.
Näkisin, että käyttöjärjestelmäkehityksessä on järkevää käyttää jo CP/M:stä tuttua mallia, jossa kerneli koostuu useasta päällekkäisestä ohjelmasta, jotka käyttävät sen alempana olevan ohjelman tarjoamia palveluja. Näin saadaan pienemmällä vaivalla kehitettyä huomattavasti portattavampi käyttöjärjestelmä kuin yhtä monoliittista kerneliä käyttäen.
DOSin alla oleva BIOS tarjoaa abstraktiotason laitteistoon, jotta DOSin ei tarvitse niin sanotusti iskeä rautaa suoraan. DOS ei itsessään ole kovin kummoinen käyttöjärjestelmä, mutta tarjoaa riittävät palvelut tiedostojärjestelmien hyödyntämiseen, ettei sen ohjelmointirajapintaa käyttävillä ohjelmilla tarvitse olla omaa tiedostojärjestelmäajuria. DOS myös antaa ohjelmointrajapintaansa käyttäville ohjelmille täyden pääsyn laitteistoon, mikä helpottaa varsinkin pelien ja demojen kehittämistä. Hyötyohjelmien kanssa näkisin, että parempi on, jos siinä päällä on vielä yksi kerros, joka mahdollistaa esimerkiksi moniajon.
Tein kernelistä uuden version, jossa korjasin pari muistibugia ja muutin asioiden tapahtumajärjestystä EXE-lataajassa. Nyt tuo kykenee lataamaan hyvinkin isoja EXE-ohjelmia muistiin unohtamatta välimuistejaan, mikä nopeuttaa ohjelmien käynnistymistä entisestään huomattavasti. Seuraava vaihe olisi hioa olemassa olevia toimintoja ja tehdä kiintolevyjen ja osiotaulujen tuki.
Jere Sumell kirjoitti:
Onko tämä keskustelupuheenvuoro nyt täysin metsään mennyt? Mitä ajatuksia herännyt?
On ainakin noiden vuosilukujen suhteen sillä c++ julkaistiin vasta 1985. Amiga julkaistiin seuraavana vuonna. Dossi oli olemassa jo paljon aikaisemmin.
Turakointi kirjoitti:
DOS myös antaa ohjelmointrajapintaansa käyttäville ohjelmille täyden pääsyn laitteistoon, mikä helpottaa varsinkin pelien ja demojen kehittämistä.
Juuri näin. Tälle alustalle tehtiin esimerkiksi Doom, joka mullisti videopelien kehityksen. Ehkä Microsoft on halunnutkin jättää "oven auki" ohjelmoijille, koska se on ollut ohjelmointityökaluja valmistava yhtiö.
Turakointi kirjoitti:
Hyötyohjelmien kanssa näkisin, että parempi on, jos siinä päällä on vielä yksi kerros, joka mahdollistaa esimerkiksi moniajon.
Aluksi Microsoft ratkaisi moniajon niin, että siihen suostuminen oli ohjelmille vapaaehtoista ja omaehtoista (co-operative multitasking). Viestisilmukka oli minusta aika mielenkiintoinen ratkaisu. Sitä käytettiin Windowsissa, mutta olisihan se toiminut DOS-ohjelmillakin.
https://retrocomputing.stackexchange.com/
http://users.jyu.fi/~vesal/kurssit/winohj/html/
https://en.wikipedia.org/wiki/
jsbasic kirjoitti:
Ehkä Microsoft on halunnutkin jättää "oven auki" ohjelmoijille, koska se on ollut ohjelmointityökaluja valmistava yhtiö.
Pikemminkin kyse on siitä, että DOS oli järjestelmä, joka oli tarkoitettu yhden käyttäjän yhden ohjelman ajamiseen kerrallaan. Siinä ei siis ollut mitään tarvetta "estää" yhtä ohjelmaa tekemästä "mitä lystää".
Pikemminkin kuin "ovi oli jätetty auki" voisi sanoa, että turhaa ovea, oven karmeja tai edes seinää ei rakennettu.
Grez kirjoitti:
Pikemminkin kyse on siitä, että DOS oli järjestelmä, joka oli tarkoitettu yhden käyttäjän yhden ohjelman ajamiseen kerrallaan.
Jos MS-DOS:sia vertaa Unixiin, niin on keskeistä, että Dossissa ajettiin yhtä ohjelmaa kerrallaan. Unixissa taas vallitsi työkaluajattelu, jossa kiellettiin monimutkaiset ohjelmat ja turhat sivuvaikutukset.
Olen tässä projektissa pohtinut juuri tuota filosofiaa. DOS-kerneliltä voisi odottaa tukea jollekin korkeamman tason ohjelmointikielelle tai tavukoodille. Mitä jos 286-koneeseen voisi tehdä ohjelmia java-tyyliin C-kielen ja Assyn sijaan, mutta silti säilyttää vapaus rautatasoon! En tiedä onko tuossa järkeä...
jsbasic kirjoitti:
Olen tässä projektissa pohtinut juuri tuota filosofiaa. DOS-kerneliltä voisi odottaa tukea jollekin korkeamman tason ohjelmointikielelle tai tavukoodille. Mitä jos 286-koneeseen voisi tehdä ohjelmia java-tyyliin C-kielen ja Assyn sijaan, mutta silti säilyttää vapaus rautatasoon! En tiedä onko tuossa järkeä...
Sehän tässä minun systeemissä on nimenomaan ideana. Alla olevalla dossikernelillä voi ajaa täysillä oikeuksilla suoraan raudalla toimivia ohjelmia, ja päällä olevan moniajavan osittain POSIX-yhteensopivan systeemin päällä voi moniajaa muistiturvallisesti tavukoodiohjelmia.
Viimeaikaisten Windows-versioiden myötä Microsoftilla on ollut selkeä tavoite rikkoa taaksepäin yhteensopivuus DOS-ohjelmien kanssa, mikä tekee ohjelmien tekemisestä tietokoneelle paljon hankalampaa, kun joutuu käyttämään monimutkaisia frameworkkeja perusasioihinkin. Tämä näkyy yksinkertaisten indie-pelien kehitysmäärän laskuna, eivätkä klassikkopelit enää toimi Windowsilla ilman erikseen asennettavia emulaattoreita. Kuitenkin pitkälle 2000-luvun puolelle asti suuri osa, ellei jopa suurin osa, harrastelijoiden tekemistä peleistä oli DOS-pelejä.
Vaikka muuta usein väitetään, niin matalalle tasolle koodatut pelit ovat kuitenkin loppujen lopuksi kaikkein helpoimpia myös portata alustalta toiselle, kunhan ne on kirjoitettu jollain korkeamman tason kielellä, kuten C:llä. Esimerkiksi PC- ja Amiga-versioiden erona voi olla pelkästään eri rutiinit näytölle piirtoon ja näppäimistösyötteen kaappaukseen, vaikka itse koneissa ei ole kovin paljoa samaa. Kaikkein hankalimpia porttauksen kannalta ovat Windowsille tehdyt pelit, koska koko Windowsin ohjelmointirajapinta on suunniteltu niin, että kaikki tehdään taktisesti hieman eri tavalla kuin esimerkiksi kilpailevissa POSIX-yhteensopivissa käyttöjärjestelmissä.
Kasvava määrä rajapintoja ohjelman ja raudan välissä tekee tietokoneen käytöstä hankalaa myös käyttäjälle. Nykypelien kanssa on normaalia tapella mystisten ongelmien kanssa, kun peli ei vain jostain syystä toimi, eikä kukaan oikein tiedä, onko vika jossain pelin käyttämässä rajapinnassa, näytönohjaimen tai äänikortin ajurissa, käyttöjärjestelmän ytimessä vaiko itse pelissä.
Toki pelien ajaminen moniajavan kernelin päällä mahdollistaa monia asioita, kuten videopuhelun tai näytön striimaamisen pelatessa. Omaan DOS-kerneliini voisin jossain vaiheessa yrittää luoda jonkinlaista kellokeskeytykseen kiinnittyvää pinonvaihdinta (stack switcher) esimerkiksi TSR-ohjelmana. Näillä pinonvaihtimilla on aina sellainen ongelma, että ovat yhteensopivia vain yhden dossikernelin kanssa.
Testailin oman graafisen moniajoshellin käynnistystä: https://www.youtube.com/watch?v=Q1DEhtRdm_k
Turakointi kirjoitti:
Viimeaikaisten Windows-versioiden myötä Microsoftilla on ollut selkeä tavoite rikkoa taaksepäin yhteensopivuus DOS-ohjelmien kanssa, mikä tekee ohjelmien tekemisestä tietokoneelle paljon hankalampaa, kun joutuu käyttämään monimutkaisia frameworkkeja perusasioihinkin.
Eihän tuon kaiken järjen mukaan pitäisi tehdä ohjelmien tekemisestä tietokoneelle yhtään hankalampaaa. Eihän mikään pakota käyttämään tietokoneella Windowsia. Toisekseen jos haluat tehdä ohjelmia Windowsille, niin ei siinä ole edelleenkään mikään pakko käyttää frameworkia.
En myöskään ole ihan samaa mieltä tuosta väitteestäsi että suoraan raudan tukeminen olisi helpompaa vaikkapa DOS:n kautta kuin käyttämällä Windowsia tai Linuxia tai MacOSx. Tai ainakaan minä en edes tietäisi mistä nykyisin alkaa koodata 3D-moottoria suoraan raudalla eli ilman näytönohjainvalmistajien tekemiä ajureita jne. Amigalla näytönohjaukseen oli aina samat (no pari eri versiota samasta) piirit joiden dokumentaatio oli julkisesti saatavilla. PC:llä taas on kymmeniä erilaisia keskenään (perus 2d käyttöä lukuunottamatta) epäyhteensopivia näytönohjaimia.
Turakointi kirjoitti:
Viimeaikaisten Windows-versioiden myötä Microsoftilla on ollut selkeä tavoite rikkoa taaksepäin yhteensopivuus DOS-ohjelmien kanssa, mikä tekee ohjelmien tekemisestä tietokoneelle paljon hankalampaa, kun joutuu käyttämään monimutkaisia frameworkkeja perusasioihinkin. Tämä näkyy yksinkertaisten indie-pelien kehitysmäärän laskuna, eivätkä klassikkopelit enää toimi Windowsilla ilman erikseen asennettavia emulaattoreita. Kuitenkin pitkälle 2000-luvun puolelle asti suuri osa, ellei jopa suurin osa, harrastelijoiden tekemistä peleistä oli DOS-pelejä.
Vaikka muuta usein väitetään, niin matalalle tasolle koodatut pelit ovat kuitenkin loppujen lopuksi kaikkein helpoimpia myös portata alustalta toiselle, kunhan ne on kirjoitettu jollain korkeamman tason kielellä, kuten C:llä. Esimerkiksi PC- ja Amiga-versioiden erona voi olla pelkästään eri rutiinit näytölle piirtoon ja näppäimistösyötteen kaappaukseen, vaikka itse koneissa ei ole kovin paljoa samaa. Kaikkein hankalimpia porttauksen kannalta ovat Windowsille tehdyt pelit, koska koko Windowsin ohjelmointirajapinta on suunniteltu niin, että kaikki tehdään taktisesti hieman eri tavalla kuin esimerkiksi kilpailevissa POSIX-yhteensopivissa käyttöjärjestelmissä.
Itse olen tyytyväinen, että muistia varatessa ei nykyään enää tarvitse kikkailla segmenttien kanssa. Jos totta puhutaan, niin peliohjelmoinnin aloittaminen ei koskaan ole ollut näin helppoa. Saatavilla on älytön määrä kirjastoja joiden avulla voi suoraan keskittyä itse pelin tekemiseen.
Amigan ja PC:n tapauksessa ei suoran peli käännöksen tekeminen ole koskaan ollut järkevää. Amigalla oli kuitenkin omat piirinsä grafiikkaa ja ääntä varten. Otetaan esimerkiksi aikoinaan menetetty mahdollisuus eli Atari Jaguar pelikonsoli. Suurin osa tuolle tehdyistä peleistä oli käytännössä suoria Atari ST käännöksiä eikä Jaguarista otettu irti mitä olisi pystytty.
Suurin osa PC-näytönohjaimista on VGA-yhteensopivia. Myös OpenGL on avoin standardi, mutta en ole siihen sen tarkemmin perehtynyt. Moni myöhempien aikojen dossipelihän sitä kuitenkin käyttää. Suurin osa näytönohjaimista tukee VESA-standardia ja sillä saa isoja resoluutioita ja värimääriä ilman ajureita.
Ei DOSissakaan tarvitse muistia varatessa kikkailla segmenttien kanssa, jos käyttää frameworkkeja. Pointti olikin, että DOS ylipäätään sallii suoran pääsyn rautaan, mutta Windowsin uudet versiot eivät sitä enää salli, vaan jokainen ohjelma on täysin käyttöjärjestelmäytimen ja sen vuorontimen armoilla.
Nykyframeworkkien kanssa jo pelkän Hello Worldin aikaansaaminen vaatii huomattavasti enemmän tietämystä kuin vanhojen, enemmän raudassa kiinni olevien käyttöliittymien päälle ohjelmointi.
Turakointi kirjoitti:
Suurin osa PC-näytönohjaimista on VGA-yhteensopivia. Myös OpenGL on avoin standardi, mutta en ole siihen sen tarkemmin perehtynyt. Moni myöhempien aikojen dossipelihän sitä kuitenkin käyttää. Suurin osa näytönohjaimista tukee VESA-standardia ja sillä saa isoja resoluutioita ja värimääriä ilman ajureita.
Kyllä siinäkin tapauksessa tarvitaan VESA-ajuri. Toki se on standartoitu, ja monelle merkille saa tehtyä yhdellä ajurilla VGA-ajuria suuremman resoluution.
Linukka puolella kyseinen VESA-ajuri on ollut pitkään, mutta löytyykö Win98:lle tai Me:lle edes mitään vesa-ajuria varsinkaan ilmaista. (Itselläni olisi henkilökohtainen kiinnostus, jos löytyisi.)
Turakointi kirjoitti:
Myös OpenGL on avoin standardi, mutta en ole siihen sen tarkemmin perehtynyt.
Olen siinä käsityksessä että OpenGL:ssä ei hypistellä näytönohjaimia suoraan rautatasolla, vaan näytönohjainvalmistaja toimittaa ajurin joka juttelee OpenGL:ää.
Kommenttini ei liittynyt varsinaisesti siihen voiko joku toimia Windowsilla tai DOSilla vaan tuohon harmitteluusi että pelin ja raudan välissä on monia kerroksia kuten ajurit.
Turakointi kirjoitti:
Windowsin uudet versiot eivät sitä enää salli, vaan jokainen ohjelma on täysin käyttöjärjestelmäytimen ja sen vuorontimen armoilla.
Täähän on toivottu ominaisuus useinkin. Koneesi voi ajella turvallisin mielin muita ohjelmia samalla kun peli pyörii. Jos ajatellaan vaikka jotain TeamSpeakia tms, niin sitä olisi hankala käyttää jos peli olisi ominut koneen kokonaan kuten "vanhoina hyvinä aikoina"
Jos haluaa tehdä pelin joka nappaa koneen hallintaansa, niin eihän siihen tarvita edes DOSia, laittaa vaan pelin latautumaan boot sectorilta kuten esim. Amigalla oli usein tapana tehdä.
peran kirjoitti:
Linukka puolella kyseinen VESA-ajuri on ollut pitkään, mutta löytyykö Win98:lle tai Me:lle edes mitään vesa-ajuria varsinkaan ilmaista. (Itselläni olisi henkilökohtainen kiinnostus, jos löytyisi.)
Vastaan itselleni...
http://www.win3x.org/win3board/viewtopic.php?t=2462&language=en
... linkki saattaa olla kokeilemisen arvoinen.
Jere Sumell kirjoitti:
MS-DOS -keskustelu lämpenee.
...
Amiga-aikainakin kiintolevylle pystyi tallentamaan Workbenchin, ja eikö sekin ollut Amigan käyttöjärjestelmä ja sekin oli ennen DOS-aikaa taisi olla.
Taidat olla väärässä...
https://fi.wikipedia.org/wiki/Amiga
peran kirjoitti:
Kyllä siinäkin tapauksessa tarvitaan VESA-ajuri. Toki se on standartoitu, ja monelle merkille saa tehtyä yhdellä ajurilla VGA-ajuria suuremman resoluution.
Ajuri on näissä melko suhteellinen käsite. Loppujen lopuksi oman "ajurin", ts. toteutuksen, voi näissä kirjoittaa melko pienellä määrällä koodia. Tuo oma graafinen shellinikin tukee sisäisesti sekä CGA:n, EGA:n että VGA:n hi-res-tiloja sekä mustavalkoisena että värillisenä. VESA-tiloille sille pitäisi vielä kirjoittaa ihan erillinen ladattava ajuri.
Grez kirjoitti:
Täähän on toivottu ominaisuus useinkin.
...
Jos haluaa tehdä pelin joka nappaa koneen hallintaansa, niin eihän siihen tarvita edes DOSia, laittaa vaan pelin latautumaan boot sectorilta
Vuorontimen armoilla oleminen on toivottu ominaisuus usein, mutta ei läheskään aina. Boottisektorissa on se ongelma, että joutuu tiedostojärjestelmästä lähtien toteuttamaan kaiken itse. Dossikernelin (jollainen Amigassa on ROMilla, PC-yhteensopivien firmis on pelkistetympi) päälle tehdessä moni asia helpottuu paljon, mutta täysi hallinta rautaan säilyy.
Turakointi kirjoitti:
Boottisektorissa on se ongelma, että joutuu tiedostojärjestelmästä lähtien toteuttamaan kaiken itse. Dossikernelin (jollainen Amigassa on ROMilla, PC-yhteensopivien firmis on pelkistetympi) päälle tehdessä moni asia helpottuu paljon, mutta täysi hallinta rautaan säilyy.
Vaikka Amigan Kickstart ROMissa olikin paljon enemmän tavaraa kuin PC:n BIOSissa, niin useat pelit ja demot varsinkin alkuaikoina* latasivat leykkeeltä ihan vaan lukemalla levyltä sektoreita sellaisenaan ilman virallista levyjärjestelmää. Sama käsittääkseni onnistuu PC:n BIOS-rutiineilla.
* alkuaikoina harvalla oli kiintolevy, niin ei niin paljoa haitannut vaikka demoa ei sieltä voinut käynnistääkään.
Turakointi kirjoitti:
Vuorontimen armoilla oleminen on toivottu ominaisuus usein, mutta ei läheskään aina.
Väittäisin kyllä että peruskäytössä nykyisistä tietokoneiden käyttäjistä tuskin 1%:akaan haluaisi palata tilanteeseen että vain yksi sovellus voi olla kerrallaan käynnissä.
Reaaliaikajärjestelmät, yksinkertaiset sulautetut järjestelmät, sun muut erilaiset käyttötapaukset on sitten asia erikseen.
Grez kirjoitti:
Väittäisin kyllä että peruskäytössä nykyisistä tietokoneiden käyttäjistä tuskin 1%:akaan haluaisi palata tilanteeseen että vain yksi sovellus voi olla kerrallaan käynnissä.
Tämä on ilmeisesti aihe, josta tietyt ihmiset eivät vain osaa keskustella asiallisesti ilman olkiukkoilua.
Olen kyllä pyrkinyt ihan asiallisesti asiasta keskustelemaan. Mitä sitten tarkoitit tuolla että "läheskään aina ei ole toivottua olla vuorontimen armoilla", jos mielestäsi oma tulkintani oli olkiukko?
Ehkä mulla on hukkunut mikä sun pointti on ollut. Lähdit siitä että indiepelien määrä on laskenut kun pelejä ei enää tehdä samaan tyyliin kuin dossiaikoihin.
Itse ajattelen että pelejä käyttävät tavalliset ihmiset ja heitä ei todennäköisesti kiinnosta alkaa pyhittämään tietokonettaa pelkälle pelille, josta johtuen pelejä ei ole myöskään järkevää kehittää esim. DOSille (ellei sitten omaksi tai pienehkön harrastajajoukon huviksi)
Uskon että todennäköisempi syy miksi indiepelien määrä on vähentyntyt (jos niin edes on käynyt) on se, että keskimääräiset pelien kuluttajat ovat tottuneet sellaisiin pelikokemuksiin mihin ei yksittäinen pelin tekijä tai edes pieni tiimi pysty, ainakaan jotain valmista alustaa. Lisäksi myös tarjonta on nykyään niin laajaa että harva lähtee tekemään peliä itse vain "jotta olisi jotain kivaa pelattavaa", kuten joitakin vuosikymmeniä sitten saattoi käydä.
Jalski kirjoitti:
Jos totta puhutaan, niin peliohjelmoinnin aloittaminen ei koskaan ole ollut näin helppoa. Saatavilla on älytön määrä kirjastoja joiden avulla voi suoraan keskittyä itse pelin tekemiseen.
Mihin ne indiepelit ovat siis kadonneet? Jos pelinteko oli vaikeaa (vaikeus ei ole helposti mitattavissa), niin voihan olla, että ennen juuri haluttiinkin niitä haasteita. Assembly/C/C++ oli kovin arvostettu taito ja osoitus siitä, että tuote on laadukas. Kun pystyi tuottamaan oman "standalone-exen", niin lähes lunasti ohjelmalleen paikan esimerkiksi ilmaisrompulla.
Toisaalta rauta ei ole ohjelmoijan ainoa haaste, vaan ohjelmoinnissa tarvitaan ajattelua. Ohjelman käyttökelpoisuus riippuu sisäisestä arkkitehtuurista. Suorituskyky riippuu ennenkaikkea ohjelmointitaidosta, oli kieli mikä tahansa, minkä olen oppinut täältä Putkasta. Mutta en ihmettele jos raudanhallinta ja muu laatu korreloi eri projekteissa. Dossissa rautatason kehitys kulkee muun ohjelmakehityksen mukana kunkin projekti sisällä. Se on tavallaan ymmärrettävää. Toisaalta Linuxia on kritisoitu siitä, että sovelluskehittäjät joutuvat käyttämään valmiita kirjastoja, mikä tuo ongelmia:
https://en.wikipedia.org/wiki/
Etenkin Linuxissa on "älytön määrä kirjastoja". Missä siis viipyvät indiepelit? Kirjastojen määrä ei paljon auta, jos niiden rajapinta on mitä sattuu: Muuttuvat sekä ajallisesti että jakelullisesti.
jsbasic kirjoitti:
Mihin ne indiepelit ovat siis kadonneet?
Onko ne sitten kadonneet? Esim. App Storessa on noin 300 000 peliä, 40 000 enemmän kuin puoli vuotta sitten. Kehtaisin väittää asiaa mitenkään tutkimatta, että niistä ainakin kolmasosa on indiepelejä.
Microsoft storesta löytyy ihan osasto "esiin nostetut indiepelit", jossa on 108 peliä
https://www.microsoft.com/en-us/store/collections/indiegamespotlight
Montakohan niitä "ei esiin nostettuja" on.
Windowsille julkaistaan varmasti indiepelejä muutakin kautta.
Omassa Android-puhelimessani on kymmenkunta indiepeliä asennettuna. Ja määrän pienuus ei johdu siitä etteikö tarjontaa olisii vaan siitä, että pelaaminen ei nykyään juurikaan kiinnosta.
En ole paljonkaan tekemisissä nykyisten nuorten kanssa mutta omassa nuoruudessa minulla oli paljon tietokoneita harrastia kavereita, mutta vain yksi joka osasi sen verran ohjelmoida että teki jonkinlaisen matopelin tai muuta vastaavaa joka ei kuitenkaan muutamaa kaveria pidemmälle levinnyt. Tällä hetkellä tuttujen lapsista on ainakin 3 alle 18-vuotiasta, jotka ovat tehneet ja julkaisseet pelin tai pelejä itse.
jsbasic kirjoitti:
Kun pystyi tuottamaan oman "standalone-exen", niin lähes lunasti ohjelmalleen paikan esimerkiksi ilmaisrompulla.
Karrikoiden ehkä näin, mutta täytyi siinä jotain sisältöäkin olla. Eli ääriesimerkkinä pelkkä 60 tavun "Hello world" .exe ei vielä taivaita aukaissut silloinkaan. (Tai 20 tavun .COM nimettynä .EXEksi :p )
Grez kirjoitti:
En ole paljonkaan tekemisissä nykyisten nuorten kanssa mutta omassa nuoruudessa minulla oli paljon tietokoneita harrastia kavereita, mutta vain yksi joka osasi sen verran ohjelmoida että teki jonkinlaisen matopelin tai muuta vastaavaa joka ei kuitenkaan muutamaa kaveria pidemmälle levinnyt. Tällä hetkellä tuttujen lapsista on ainakin 3 alle 18-vuotiasta, jotka ovat tehneet ja julkaisseet pelin tai pelejä itse.
Näin se maailma kehittyy. Olin itse ensimmäisten onnekkaiden joukossa, jossa yliopistossa haasteellisen matemaattisen yhtälöiden ratkaisuksi riitti graafisen laskimen ohjelmointi yhtälön ratkaisemiseen. Hauska nähdä myös lukio-opetuksen tulevia suuntia erityisesti matematiikan saralla. En näe mitään järkeä vääntää vaikeaa neljän sivun vastausarkin (integraaliyhtälön?) ratkaisua itse, koska nykyisin hommat hoitaa tietokoneet sadasosasekunneissa. Jättäisin korkeintaan ratkaisun validoinnin opiskelijan hartioille. Näinhän hommat käytännössäkin tapahtuu. Kynällä ja paperilla ei ole juurikaan käyttöä..
Grez kirjoitti:
Tällä hetkellä tuttujen lapsista on ainakin 3 alle 18-vuotiasta, jotka ovat tehneet ja julkaisseet pelin tai pelejä itse.
Pelikulttuuri on miten se koetaan ja omat kriteerini poikkeavat nuorten omista käsityksistä pelien tekemisestä. Jos peruskoulussa opitaan vähänkin Pythonia, ovat oppilaiden kyvyt ohjelmoida paremmat kuin meillä, jotka kopioimme BASIC-rivejä kirjasta. Mutta lasten (ja meidän vanhempienkin) matematiikan taidot ovat heikkenemässä ja viihteellisyys kasvaa, niin painopiste siirtyy ns. helppoihin kieliin ja metodeihin senkin vuoksi. No, tämä on vahvasti tulkittu, mutta olen itse taantumassa helpomman kielen suuntaan, joten tämä on sen aiheuttamaa pohdintaa.
jsbasic kirjoitti:
(07.02.2022 22:13:56): ”– –” Pelikulttuuri on miten se koetaan ja omat...
Sanoisin, että hyvä matemaattinen lahjakkuus ja ohjelmointitaito kulkevat jonkin verran käsikädessä. Ongelmien ratkominen ohjelmoimalla vaatii myös matemaattista lahjakkuutta. Ainakin itse olen ajatellut asian näin. Voin toki olla väärässäkin. Onko tämä väite liikaa kärjistetty? Nyt kaikki noobit matemaatikot ja hyvät ohjelmoijat nostakaa rohkeasti käsiä pystyyn! : )
mpni kirjoitti:
Nyt kaikki noobit matemaatikot ja hyvät ohjelmoijat nostakaa rohkeasti käsiä pystyyn! : )
No mikä sitten on noobi matemaatikko? Osaa keskustella sujuvasti Riemannin hypoteesin ehdotetusta ratkaisusta mutta ei osaa todistaa sitä vääräksi?
Itse osaan soveltaa matemaattisia kaavoja ja ehkä todistaa jotain ihan yksinkertaisia asioita, mutta kyllä nuo useiden sivujen todistukset mitä matemaatikot pyörittelee menee sen verran vaikeiksi ettei niitä vapaaehtoisesti viitsi tutkia.
Toisaalta ollen myös ohjelmoijana keskinkertainen.
Ennen kaikki oli paremmin, mutta toisin kuin Turakointi antaa ymmärtää, tuskin se muutoksen juurisyy on kuitenkaan siinä, ettei ohjelmia enää tehdä suoraan rautaan kiinni.
Grez kirjoitti:
(03.02.2022 14:29:51): ”– –” Pikemminkin kyse on siitä, että DOS oli...
Tähän liittyen on syytä tunnustaa tosiasiat: ennen tietokoneet olivat muutenkin yksinkertaisempia, eri laitteita oli vähemmän, ominaisuuksia ja asetuksia vähemmän, tarvittavat ajurit pienempiä.
Kyllä, jos on tarkoitus tehdä äänet ja piirtäminen prosessorilla ja soittaa äänikortilla 2-kanavaista ääntä ja piirtää näytölle pikselidataa, niin tämä kyllä onnistui kivasti reaalitilassa mutta vaatii nykyään ainakin pari kerrosta väliin. Näin yksinkertaisessa asiassa ne välikerrokset ovat varsin hyviä ja luotettavia.
Mutta jos on tarkoitus tehdä laitteistokiihdytettyä 3D-grafiikkaa eri valmistajien eri korteilla, käyttää fysiikkalaskuihin GPU:n laskentatehoa, tukea ääniä kaiuttimien ja kuulokeportin ja ehkä jopa Bluetoothin kautta ja tukea verkkoyhteytenä suojattua WLANia sadalla eri verkkokortilla, niin 16-bittisestä reaalitilasta loppuu muisti välittömästi ja ylipäänsä ”suoraan raudalla toimivia ohjelmia” ei ole mielekästä tehdä, koska ohjelmasta 99% on eri laitteiden ajureita.
Ei ole pelkästään Microsoftin tahtotila, että pakotetaan käyttämään rajapintoja, vaan jokainen asiasta mitään ymmärtävä koodari on kiitollinen, ettei kaikkea edellä mainittua tarvitse tehdä itse rautatasolla, ja jokainen pelaaja voi olla kiitollinen siitä, että näytönohjaimen uusimmat ajurit saa valmistajalta eikä tuurilla jokaiselle pelille erikseen.
Turakointi kirjoitti:
Nykypelien kanssa on normaalia tapella mystisten ongelmien kanssa, kun peli ei vain jostain syystä toimi, eikä kukaan oikein tiedä, onko vika jossain pelin käyttämässä rajapinnassa, näytönohjaimen tai äänikortin ajurissa, käyttöjärjestelmän ytimessä vaiko itse pelissä.
Oletko vakavasti sitä mieltä, että nykypelien ongelmat johtuvat pelkästään useasta kerroksesta? Eli ratkaisiko ongelma, jos pelit tehtäisiin ”matalalla tasolla” eli laitettaisiin käyttöjärjestelmän ja ajureiden ominaisuudet pelin mukaan? Silloin tilanne olisi kyllä yksinkertaisempi, koska vika olisi varmasti pelissä, mutta tuskin se tekisi vian etsimisestä juuri sen helpompaa.
Tai kääntäen: Jos teet DOS-tasoisen pelin, joka siis pyörii vain prosessorilla ja työntää grafiikat ja äänet ulos käyttäen jotain Windowsin perusrajapintaa, niin väitätkö, että siinäkin on odotettavissa käyttöjärjestelmästä tai ajureista johtuvia outoja bugeja? En usko.
Turakointi kirjoitti:
Viimeaikaisten Windows-versioiden myötä Microsoftilla on ollut selkeä tavoite rikkoa taaksepäin yhteensopivuus DOS-ohjelmien kanssa, – – eivätkä klassikkopelit enää toimi Windowsilla ilman erikseen asennettavia emulaattoreita.
Oletko tietoinen, että virtuaalinen 8086-tila toimii vain 32-bittisestä tilasta ja ei enää 64-bittisestä tilasta? Tämä ei ole tietääkseni Microsoftin vika.
Muutenkin DOS-ohjelmien "yhteensopivuus" on menetetty siinä vaiheessa, kun niillä ei ole enää oikeutta sorkkia kaikkia laitteita itse eikä koneessa edes ole esimerkiksi SB-yhteensopivaa äänikorttia. Tästä eteenpäin kaikki on ollut jonkinlaisen emulaattorin varassa.
Pitääkö emulaattorin olla Windowsiin integroituna, on sitten toinen kysymys. Käytännössä Windowsin kautta DOS-ohjelmien ajamisessa on ollut jo kauan ongelmia ja erilliset emulaattorit ovat toimineet paremmin. Ongelmana on ollut virtualisoinnissa liika nopeus (osa peleistä toimii aina prosessorin täydellä nopeudella) ja emulaattoreissa taas hitaus uusimmissa DOS-peleissä.
Turakointi kirjoitti:
tekee ohjelmien tekemisestä tietokoneelle paljon hankalampaa, kun joutuu käyttämään monimutkaisia frameworkkeja perusasioihinkin.
Tämä on ihmeellinen väite. Esimerkiksi SDL 1 on mielestäni paljon helpompi rajapinta kuin käsipelillä näytön tai äänikortin käsittely DOSissa, ja vaikka se on kirjastona nykymittapuulla alkeellinen ja rajoittunut, niin kyllä se ainakin reaalitilaan suunniteltujen pelien porttaamiseen riittää enemmän kuin hyvin.
Turakointi kirjoitti:
Tämä näkyy yksinkertaisten indie-pelien kehitysmäärän laskuna,
Eiköhän se vika ole pikemmin valtavan suuri tarjonta, jossa yksinkertaiselle indie-pelille ei ole enää helppoja markkinoita. Netti ja kännyköiden sovelluskaupat ovat täynnä pieniä pelejä kaikenlaiseen makuun. Tilanne on aivan toinen vaikka 2005.
Turakointi kirjoitti:
Vaikka muuta usein väitetään, niin matalalle tasolle koodatut pelit ovat kuitenkin loppujen lopuksi kaikkein helpoimpia myös portata alustalta toiselle, – – Kaikkein hankalimpia porttauksen kannalta ovat Windowsille tehdyt pelit,
Tämä on koodarin valinta. Kyllä edelleenkin ohjelman voi koodata yhtä ”matalalle tasolle”, ja tarvitsee vaihtaa vain näytön käsittelyyn ja näppäimistön lukemiseen liittyvät rutiinit, jos pelin rakenne on sopiva. Sopivilla kirjastoilla pääsee jopa siihen, että ei tarvitse itse portata peliä, kun kirjaston tekijä on jo portannut kirjaston.
WinAPI:n käyttäminen pitkin ohjelmaa on oma valinta, ei mikään välttämättömyys. Ihan samanlainen valinta on sekin, jos reaalitilan ohjelmaan on siroteltu suoraa näytön käsittelyä sinne tänne. Miten helposti porttaaminen onnistuu, jos jossain yllättävässä kohdassa ohjelmaa onkin päätetty piirtää pari pikseliä käsin: *(char*)0xa0008=0x12;
Turakointi kirjoitti:
Kasvava määrä rajapintoja ohjelman ja raudan välissä tekee tietokoneen käytöstä hankalaa myös käyttäjälle.
Tekeekö?
Nykyään ei tarvitse itse tietää, minkä merkkinen näytönohjain tai äänikortti koneessa on, mikä vaihtoehdoista on tämän kanssa yhteensopiva, mikä osoite, IRQ ja DMA pitää valita asetuksista jne. Nykyään ei tarvitse tietää, minkä numeroiseen COM-porttiin toinen hiiri tai sarjaporttikaapeli on kiinnitetty kaksinpeliä varten. Nykyään ei tarvitse lisätä CONFIG.SYSiin käsin rivejä vaikka CD-aseman ajureille eikä säätää vaihtoehtoisia asetuksia tilanteisiin, joissa kyseinen ajuri on tarpeeton ja ehkä jopa estää jonkin reaalitilan pelin käynnistämisen. Muistatko tällaisia?
Vai onko käsityksesi DOSista sittenkin siltä ajalta, kun näitä ei enää mietitty vaan Windows tarjosi DOS-ohjelmille emuloidun äänikortin mutta piti ehkä osata valita sopivat EMS- tai XMS-muistiasetukset pikakuvakkeisiin ja varoa sekoittamasta DOS-ohjelmia pitkillä tiedostonimillä? Helppoa kuin heinänteko!
jalski kirjoitti:
jsbasic kirjoitti:
Viimeisinä aikoina poikkeuksena oli DOS/4G, joka lisäsikin epävakautta.
Meinaatko DOS/4GW:tä?
DOS/4GW oli Watcomin kääntäjän mukana tullut ilmainen rajoitettu versio DOS/4G:stä. En usko että jsbasicin kommentin kannalta oli olennaista, oliko kyse täydestä vai kevytversiosta.
Joskin DOS/4GW oli vissiin versiota 1.97 joten se oli vakaampi kuin aikaisemmat DOS/4G versiot.
Grez kirjoitti:
(08.02.2022 10:52:20): ”– –” DOS/4GW oli Watcomin kääntäjän mukana tullut...
En tajunnutkaan, että DOS4GW oli Watcomin kääntäjän mukana tullut versio vaikka tuosta W:stä olisi kyllä pitänyt tajuta...
Turakointi, toimiiko tuo DOS toteutuksesi perus reaalitilassa vai käväisetkö suojatussa tilassa asettamassa "unreal mode":n ja saat ohjelmille käyttöön 4 gigan datasegmentin?
Se on ihan kokonaan real mode -systeemi. Toki unreal moden alustaminen onnistuisi alkulataajallakin, eihän kernelin sitä varsinaisesti välttämättä tarvitse tukea.
Joskus Plan 9 käyttöjärjestelmää käyttäneenä pidin tätä mielenkiintoisena lukemisena.
Metabolix kirjoitti:
Tämä on koodarin valinta. Kyllä edelleenkin ohjelman voi koodata yhtä ”matalalle tasolle”, ja tarvitsee vaihtaa vain näytön käsittelyyn ja näppäimistön lukemiseen liittyvät rutiinit, jos pelin rakenne on sopiva.
Mutta mikään ei kuitenkaan takaa, että rutiinit toimivat samalla tavalla. Esimerkiksi funktioiden suoritusaika voi vaihdella. Jos näytölle piirretään konekielen muistioperaatioilla, siihen kuluva aika on helppo ennustaa. Emulaattorin hitaus tai nopeus on pieni ongelma siihen nähden että yksittäisten rutiinien kesto vaihtelee kellojaksoissa.
Metabolix kirjoitti:
WinAPI:n käyttäminen pitkin ohjelmaa on oma valinta, ei mikään välttämättömyys. Ihan samanlainen valinta on sekin, jos reaalitilan ohjelmaan on siroteltu suoraa näytön käsittelyä sinne tänne. Miten helposti porttaaminen onnistuu, jos jossain yllättävässä kohdassa ohjelmaa onkin päätetty piirtää pari pikseliä käsin: *(char*)0xa0008=0x12;
Tuo on äärimmäinen esimerkki, mutta todellinen. Esimerkiksi Commodore 64:n peleissä näyttömuistia käytettiin tavallisena muistina. Joskus yhtä näytön merkkiä käytettiin laskurina ohjelman sisäisessä toiminnassa.
Metabolix kirjoitti:
jokainen asiasta mitään ymmärtävä koodari on kiitollinen, ettei kaikkea edellä mainittua tarvitse tehdä itse rautatasolla
Ohjelmakoodilla on käytännössä aina jonkin verran sivuvaikutuksia. Sivuvaikutuksista on keskusteltu melkein sata vuotta liittyen vuonna 1936 julkaistuun turing koneen malliin ja lambda-kalkyyliin. Sellainen funktionaalisten kielten ihanne, jossa jokainen toiminto erotetaan omaksi rutiinikseen, ei ole käytönnössä toimiva. Ajatellaan esimerkiksi 3D-peliä unix-putkessa:
peli | unity_tai_muu_3d_moottori | ffplay
Tässä siis pelin stdout ohjataan 3D-moottorin kautta näytölle piirtävään video-ohjelmaan. Tämä olisi ihanteellinen funktionaalinen tapa tehdä 3D-peli, mutta käytännössä tämä olisi tehotonta. Paljon samankaltaisia toimintoja jouduttaisiin laskemaan useassa eri ohjelmassa.
Tämä oli siis teoreettinen esimerkki. Uskon että kerroksia tarvitaan käytännössä helpottamaan koodirien työtä, mutta yhtä lailla sivuvaikutuksista voidaan saada hyötyä tai haittaa. Toisaalta tietokoneen monimutkaisuuden kasvu johtaa siihen, että sivuvaikutuksia pyritään välttämään yhä enemmän. Kehitys on nopeaa ja minusta perinteinen ohjelmointi (jossa on minkää vertaa näitä rautatason juttuja) alkaa olla uhattuna.
jsbasic kirjoitti:
Mutta mikään ei kuitenkaan takaa, että rutiinit toimivat samalla tavalla. Esimerkiksi funktioiden suoritusaika voi vaihdella.
Tämä käytännössä ei nykyään ole ongelma, koska ohjelmia ei muutenkaan voi kirjoittaa niin tarkasti suoritusajasta riippuviksi, koska jopa saman arkkitehtuurin tietokoneita on eri nopeuksisia.
jsbasic kirjoitti:
Esimerkiksi Commodore 64:n peleissä näyttömuistia käytettiin tavallisena muistina.
C64:ssä näyttömuisti oli tavallista muistia.
Implementoin DOS-APIn dokumentoimattoman järjestelmäkutsun int21,58 ja nyt Cutemouse-hiiriajuri näyttää toimivan moitteetta.
Tein boottilevykkeen, joka käynnistää oman dossikernelin ja sen jälkeen lataa graafisen lEEt/OS-moniajojärjestelmän siihen päälle. Kerneli tukee nyt myös tiedostojärjestelmään kirjoittamista. Pitää tehdä kiintolevyjen tuki seuraavaksi.
Mitä en käynyt vähään aikaan täällä Putkassa, vaan tänään sunnuntaina 20.03.2022 päivitin itseni ajan tasalle, mitä uutta tullut, niin tämä säie poikinut uusia postauksia sitten viime lukemani.
Otan nyt kantaa tuohon, kun tässä aiemmin säikeessä mainittiin, että onko matemaatiikan ymmärrys jotenkin korreloiko se ohjelmointitaitoihin, niin loppupeleissä varmaan onkin niin, kun ohjelmointia voi varmaan kait jossain pisteessä pitää pelkkänä matematiikkana.
Tähän pyydettiin vastauksia hyviltä ohjelmoijilta, mutta vastaan vielä vähän laajemmin oman näkemykseni avaten taustoja, vaikka en ole erityisen hyvä ohjelmoija, enkä erityisen pätevä matematiikassakaan.
Mitä tietojenkäsittelytiede on alunperin matematiikan sivujuonteena päätynyt ainakin Turun Yliopiston ainevalikoimaan, ja matematiikassa se kehittyminen ja sen taju on sillä tavalla astettaista, että mitä pidemmälle sitä opiskelee, ymmärrys laajenee ja sitten sama, mitä joka alalla on, tietyn keskitason voi saavuttaa ihan normaalilla älykkyysosamäärällä kovalla harjoittelulla ja työnteolla, mutta sitten vaaditaan erityistä lahjakkuutta, jos halutaan aivan huipulle. Sama se on tässä musiikkihommassakin, mitä itse harrastan kitaran soittoa.
Käytännön esimerkki tästä todellista lahjakkuutta vaativasta huippuymmärryksestä on esimerkiksi, että varmaan maailmassa on useitakin fyysikkoja, jotka ovat perehtyneet Albert Einsteinin suhteellisuusteoriaan, mitä miestä pidettiin 1900 luvun merkittävimpänä fyysikkona, niin siitä porukasta, joka perehtynyt siihen todella paljon, ymmärtäväkö siitä populaatiosta monikaan sitä niin perusteellisesti, että osaisi jotain mielenkiintoista keskustelun avausta siitä tarjota argumentoiden siten, että voisi kyseenalaistaa jotain siitä?
2000-luvun ensimmäisen toistaiseksi vuosisadan merkittävmpinänä fyysikkona pidetään varmaan Stephen Hawkingiä, joka eli mielestäni erityisen elämän, ja varmaan sama tämän esittämillä lopputulemilla ja papereilla niillä merkittävimmillä, mitä mies on esittänyt.
Eli kovalla työllä voi saavuttaa myös keskiverto-ohjelmoijan taidot ja matematiikan tajun tiettyyn pisteeseen saakka, mutta sitten todellinen huippu-osaaminen vaatii matemaattista luontaista lahjakkuutta.
Mitä itsekin itsetutkikelun empiriaan pohjautuen olen havainnut, että kyllähän ohjelmoidessa tai jotain ohjelmointiongelmaa miettiessä aivoissa aktivoituu samoja osa-alueita, mitä esimerkiksi ajan kuluksi täyttäisin Sudokua kynä/paperi -menetelmällä, joka sekin vaatii jonkinlaista matemaattisen logiikan tajua.
Sitten, jos selkounia harrastaa, mitä joskus itsekin pidin niistä päiväkirjaa, se jäänyt jo monta vuotta sitten, niin matemaattisten ongelmien ratkominen, kun herää aamuyön tunteina, ja aktivoi aivoissa niitä osa-alueita omaehtoisesti, jotka aktivoituvat matemaattisia ongelmia ratkottaessa, niin sitten kun menee noin puolen tunnin päästä uudestaan nukahtaa, pisimmän REM-univaiheen on todennäköisempää päästä Lucid-tilaan.
Kiintolevyjen tuki on vastatuulessa, koska kerneliä piinaa kiusallinen bugi, joka liittyy jotenkin levylle kirjoittamiseen. Kirjoitusoperaation jälkeen kerneli saattaa täysin satunnaisesti mennä aivan sekaisin. Ennen kiintolevyjen tuen toteuttamista aion tuon bugin korjata, mutta en ole vielä keksinyt, mistä se johtuu.
Viimeisin uusi ominaisuus kernelissä on laiteajurirajapinta. Laiteajureilla saa varattua tiedostonimiä, eli esimerkiksi jos laiteajuri haluaa laitenimekseen COM, niin tiedostonimet alkaen merkkijonosta "COM0" ja päättyen merkkijonoon "COM65535" ovat sitten varattuja tiedostonimiä, ja tuollaisen nimisen "tiedoston" avaaminen sitten avaakin laiteajurin siihen tiedostokahvaan. Laitetiedostoon voi normaalisti kirjoittaa ja lukea mielivaltaisia tavumääriä kerrallaan.
Tässä videossa demonstroin sarjaporttiajurin toimintaa: https://www.youtube.com/watch?v=RCoYLX7ZHLQ
Varattuja tiedostonimiä ovat myös kaikki merkkijonolla "DRV:"-alkavat nimet. Avaamalla esimerkiksi tiedoston DRV:A saadaan luettua osiolta raakadataa ja tehtyä näin esimerkiksi levykuva tai kopio tiedostojärjestelmästä helposti. Levykkeen kopiointi onnistuu yksinkertaisesti komennolla "copy DRV:A DRV:B".
Sarjaporttiajurin avulla on tarkoitus laittaa joku TSR-ohjelma kirjoittamaan sarjaporttiin kernelille tehdyt järjestelmäkutsut ja niiden vastaukset, jotta näen paremmin, mitä kernelissä oikein tapahtuu ennen sekoamista.
Ajurirajapintaa tehdessä löysin mielenkiintoisen dokumentoimattoman ominaisuuden x86-prosessoreista. Segmenttirekisterien arvojen muuttaminen viivästyttää keskeytyksien käsittelyä, mutta speksin mukaan ainoastaan sitä segmenttirekisterin arvoa muuttavaa konekäskyä seuraavan konekäskyn loppuun asti. ( https://www.pcjs.org/documents/manuals/intel/8086/ )
Käytännössä kuitenkin keskeytykset pysyvät segmenttirekisterin muuttamisen jälkeen poissa hieman pitemmän ajan. Käytännössä prosessorin liukuhihnalle jo valmiiksi haettuja käskyjä saatetaan suorittaa useampikin ilman keskeytysten käsittelyä käskyjen välissä. Ajurirajapintani koodissa oli kaksi melko tiukkaa silmukkaa, jotka keskeytyvät vain kolmesta mahdollisesta syystä: Joko ajurin read- tai write-funktio palauttaa arvon joka ei ole 0, ajuri palauttaa virhekoodin tai käyttäjän havaitaan painaneen CTRL+BREAK-näppäinyhdistelmää.
Koska tuo silmukka on varsin tiukkaa koodia ja se sisältää paljon ES-rekisterin muutteluja sekä eri koodisegmenttien välillä hyppiviä funktiokutsuja, niin prosessori ei sitten missään vaiheessa ehtinyt käsitellä keskeytyksiä. Kun ES- tai CS-rekisteriä muuttava käsky aina aiheuttaa keskeytyksien käsittelyn siirtymisen myöhemmäksi ja segmenttirekisterin arvon muuttamisen jälkeen tulee vain muutama yksinkertainen liukuhihnalle jo valmiiksi haettu aritmeettinen käsky, jossa useimmiten on operandeina vain rekistereitä tai prosessorin välimuistissa jo valmiiksi olevaa dataa, niin nuo käskyt sitten tulevat suoritetuksi niin nopeasti, etteivät keskeytykset ehdi mennä takaisin päälle. Sitten tuleekin taas jo joku segmenttirekisteriä muuttava käsky, joka siirtää taas keskeytyksien käsittelyä tuonnemmas. Sain siis yksinkertaisella silmukalla tietokoneen kokonaan jumiin niin, ettei prosessori kyennyt käsittelemään mitään laitekeskeytyksiä, ja ainoa tie silmukasta ulos oli nimenomaan se CTRL+BREAKin painaminen, jonka havaitseminen tietysti olisi edellyttänyt näppäimistökeskeytyksen käsittelyä.
Yritin ensin "korjata" ongelmaa lisäämällä silmukkaan HLT-konekäskyn (lyhenne sanasta "halt"), mutta se ei sitä korjannut. Syy on todennäköisesti se, että koska keskeytyskontrollerissa oli jo valmiiksi kellokeskeytys (joka sattuu olemaan korkeimman prioriteetin keskeytys) odottamassa, niin HLT-konekäskyn jälkeen prosessori vain sai heti käsitelläkseen sen kellokeskeytyksen ja alemman prioriteetin keskeytykset kuten se näppäimistökeskeytys jäivät sitten käsittelemättä, PC:n keskeytyskäsittelijä kun kykenee pitämään "jonossa" vain yhtä keskeytystä ja siinä "jonossa" korkeamman prioriteetin keskeytys aina menee alemman prioriteetin keskeytyksen päälle. Kesken korkeamman prioriteetin keskeytyksen käsittelyn "jonoon" ei voi myöskään tulla odottamaan matalamman prioriteetin keskeytystä, vaan keskeytyskontrolleri ei noteeraa matalamman prioriteetin keskeytyksiä ennen kuin sen ohjausrekisteriin on kirjoitettu End Of Interrupt -tavu (0x20).
Loppujen lopuksi ongelma korjautui lisäämällä silmukkaan peräkkäin konekäskyt STI ja NOP. Ensinmainittu noista laittaa keskeytykset päälle (lyhenne sanoista "set interrupt)", vaikka ne toki olivat päällä jo valmiiksi. STI-käskyllä on kuitenkin sellainen erikoisominaisuus verrattuna noihin segmenttirekisteriin kirjoittaviin käskyihin, että prosessori käsittelee keskeytykset tarkalleen STI-käskyä seuraavan käskyn jälkeen. NOP-konekäsky ei tee mitään (lyhenne sanoista "no operation"), ja se on siinä vain varmistamassa, ettei STI-konekäskyn jälkeen tule mitään sellaista käskyä, joka taas siirtäisi sitä keskeytysten käsittelyä myöhemmäksi. Nyt näppäimistökeskeytys tulee käsitellyksi ja muuten loputtomasta silmukasta pääsee pois painamalla CTRL+BREAK-näppäinyhdistelmää.
Noiden STI- ja NOP-konekäskyjen tilalla myös esimerkiksi kirjainten näytölle tulostaminen BIOS-kutsuilla näytti saavan prosessorin käsittelemään keskeytykset normaalisti. Ratkaisun piti kuitenkin olla sellainen, joka ei vaikuta ohjelman logiikkaan eikä näy käyttäjälle millään tavalla.
Nyt sarjaporttiajuri tukee myös XON/XOFF- ja RTS/CTS-vuonohjauksia. Kirjoitin sille myös MODE-ohjelman, jolla muutetaan sarjaportin asetuksia.
Viestissäni 244419 selittämäni laitekeskeytyksien triggeröitymättömyys johtuikin siitä, että ohjelmistokeskeytyksen triggeröivä INT-konekäsky asettaa prosessorin lippurekisterin IF-lipun (interrupts enable, keskeytykset päällä) nollaksi. En ollut tästä ominaisuudesta tietoinen, koska valitettavasti nykyinternet on täynnä väärää tietoa aiheesta, ja Google ja muutkin hakukoneet usein priorisoivat hakutuloksissa disinformaatiota, kun yrittää löytää tietoa teknisistä aiheista.
Tuo laitekeskeytyksien triggeröitymättömyys kyllä siltikin on ihan oikea olemassa oleva ja osittain dokumentoitu ominaisuus intelin x86-prosessoreissa. Segmenttirekisterin arvon muututtua on ainakin seuraavan konekäskyn suoritusajan pituinen ajanjakso, jonka aikana suoritin ei käsittele laitekeskeytyksiä. Siitä ei kuitenkaan tässä tapauksessa ollut kyse. Siirsin STI-käskyn aikaisempaan vaiheeseen 21h-keskeytyskäsittelijässä ja keskeytykset alkoivat toimia normaalisti.
Olen tehnyt DOS-käyttöjärjestelmäytimeen kiintolevyjen tukea. Kernelissä on edelleen jokin omituinen bugi, joka välillä korruptoi tiedostojärjestelmän. Ongelmasta tekee hankalan selvitettävän se, että eri tietokoneilla tuo bugi ilmenee eri tavalla, vaikka kaiken järjen mukaan ohjelmavuon pitäisi eri tietokoneissa olla täysin identtinen, jos vain perusmuistin määrä on sama. Kaiken kaikkiaan bugi ilmenee täysin satunnaisesti ja joillain tietokoneilla ei välttämättä ilmene ollenkaan. Bugi ilmenee niin, että käyttöjärjestelmäydin yhtäkkiä ylikirjoittaa FAT-tiedostojärjestelmän juuritiedostokansion klusteritaululla. Olettaen, että jokin muistibugi ei muuta käyttöjärjestelmäytimen koodia sopivasti toisenlaiseksi, niin tuon tapahtuminen vaatii dynaamisen FAT_COPIES-muuttujan muuttumisen lennosta, ja kyseiseen muuttujaan sijoitetaan arvo ainoastaan yhdessä kohdassa koodia. Kyseinen muuttuja myös on aina samassa kohdassa muistia ja olen kokeillut siirtää sitä eri paikkaan, mutta bugi ei sillä korjautunut eikä muuttunut toisenlaiseksi.
Oman graafisen käyttöliittymän käynnistys 150-megahertsisellä Pentium-mikrotietokoneella oman levykäyttöjärjestelmäytimen päällä: https://www.youtube.com/watch?v=6CEq_mJccCk
Oman levykäyttöjärjestelmän asennus tyhjälle kiintolevylle: https://www.youtube.com/watch?v=tji8HGZ7wHc
Omituinen tiedostojärjestelmää korruptoiva bugi on korjattu. Luulin sen olevan jokin muistibugi, mutta vika olikin tiedostojärjestelmäallokaattorissa, joka virheellisesti varasi tilaa tiedostojärjestelmän lopusta alkaen, kun sen olisi pitänyt aloittaa varausyksikköjen täyttäminen tiedostojärjestelmän alkupäästä. Sen lisäksi allokaattorin tyhjiä varausyksiköitä etsivä funktio palautti välillä olemattomia varausyksiköitä, jotka "overflowasivat" juuritiedostokansion päälle. Ongelmaa ilmeni joissain koneissa enemmän kuin toisissa johtuen levyn geometriassa olevista eroista, koska funktio laskee levyn sylinterikohtaisen sektoriluvun perusteella, kuinka monta peräkkäistä vapaata varausyksikköä pitää vähintään olla olemassa, jotta levyä voidaan alkaa täyttämään siitä kohdasta.
Nyt kerneli näyttäisi asentuvan oikein kaikille tietokoneille ja virtuaalikoneille, joilla olen sitä testannut. Testiversion voi ladata tästä linkistä: http://sininenankka.dy.fi/~sami/fdshell/
Parantelin myös alkulataajakoodia ja sain 474 tavuun mahtumaan yleiskäyttöisen FAT-parserin, joka osaa ladata kernelin kokonaisuudessaan muistiin sekä FAT12- että FAT16-tiedostojärjestelmistä. Sama alkulatauskoodi toimii sekä levykkeiden että kiintolevyjen kanssa. Periaatteessa tuo itseboottaava levykuva pitäisi siis olla mahdollista hyvin pienin muutoksin (käytännössä pelkän media descriptor -tavun muuttamisen pitäisi riittää) tallentaa dd:llä vaikka USB-muistitikullekin ja asentaa kerneli siitä kiintolevylle, mutta en ole vielä testannut tätä käytännössä. Toki BIOSin täytyy tällöin tukea muistitikkuja, mutta useimmissa modernihkoissa tietokoneissa se sitä tukee.
USB-tikulta boottaaminen ei olekaan mahdollista samalla alkulataajalla, koska alkulataaja ei voi oikein mitenkään tietää USB-tikun geometriaa. Joutuu käyttämään sektoreiden LBA-indeksointia käyttävää BIOS-kutsua int13,ah=42, joka taas ei toimi levykkeiden kanssa. Tein alkulataajasta muunnoksen USB-tikkuja varten. USB-tikkujen alkulataaja on kovakoodattu käyttämään FAT12-tiedostojärjestelmää ja itse kernelin lataamiseen se käyttää LBA:ta. Nyt tämän käyttöjärjestelmän saa sitten käynnistettyä uusillakin koneilla.
Latauslinkki USB-levykuvaan: http://sininenankka.dy.fi/~sami/fdshell/
mpni kirjoitti:
Sanoisin, että hyvä matemaattinen lahjakkuus ja ohjelmointitaito kulkevat jonkin verran käsikädessä. Ongelmien ratkominen ohjelmoimalla vaatii myös matemaattista lahjakkuutta. Ainakin itse olen ajatellut asian näin. Voin toki olla väärässäkin. Onko tämä väite liikaa kärjistetty? Nyt kaikki noobit matemaatikot ja hyvät ohjelmoijat nostakaa rohkeasti käsiä pystyyn! : )
En ole kauheasti aiheeseen tutustunut, mutta kuulemma todistusten ja ohjelmien välille voidaan löytää Curryn–Howardin isomorfismi. Eli ilmeisesti ohjelmointiongelmia voi ratkoa ainakin teoriassa todistamalla ja joitakin todistuksia voi tehdä tietokoneella.
Migratoin 486-palvelimen käyttämään tätä omaa levykäyttöjärjestelmää. Nyt siinä on kokonaan minun itse kirjoittama käyttöjärjestelmä.
486-palvelimen osoite: http://486servu.dy.fi
Seuraillaan järjestelmän vakautta. Eihän sitä ohjelman toimintaa käytännössä voi muuten testata kuin käyttämällä sitä.
Onko koodi vieläkään versionhallinnassa kuten GitHub tai GitLab? Sellaisesta olisi helpompi selailla, ja lokitietoihin kertyisi automaattisesti eräänlainen ”ploki” muutoksista ja bugikorjauksista.
Sivuilla on aika kivasti kerrottu palvelimen toteutuksesta. Tietoturvaa koskeva osio on kyllä paras, hienoa, että sekin puoli on huomioitu (varsinkin noin assembyn kanssa touhutessa).
Tehonkulutus ei ole ihan tätä päivää. :D Paljonko lisää näyttö vie, vai oliko se jo laskettu?
Näyttö taisi olla noin 60-wattinen, mutta en pidä sitä päällä.
Taisin lopultakin saada korjattua kernelistä sitä pitkään vaivanneet tiedostojärjestelmän korruptoitumista aiheuttaneet bugit. Nyt isojenkin tiedostojen kopiointi onnistuu luotettavasti.
Ongelman aiheutti sellainen bugi, että kun DMA-puskurista sektoreita välimuistiin tallentavaa save_rawcache()-funktiota suorittaessa välimuistista haetaan aina vähiten haetun sektorin sisältävä välimuistisolu ylikirjoitettavaksi uudella datalla, niin havaitessaan kyseiseen sektoriin olevan tallennettu dataa aiemmin välimuistissa koodi sitten kutsui muutetut sektorit levylle tallentavaa flush_caches()-funktiota, joka sitten muutti sen DMA-puskurin sisällön toiseksi kesken save_rawcache()-funktion suorittamisen, mikä korruptoi levyvälimuistin.
Nyt tuo kerneli alkaa toimimaan aika luotettavasti. Tosin sellaisen bugin huomasin, että jos ensimmäisen aseman juurihakemiston ensimmäinen tiedosto on suoritettava ohjelma, niin sen suorittaminen ei onnistu.
Kerneli tukee nyt myös isoja tiedostojärjestelmiä kahteen gigatavuun asti. Myös MS-DOS-tyylisen osiotaulun sisältäviä levyjä voi käyttää, mutta osioiduille levyille ei nykyisellään ole bootloaderia olemassa, vaan käynnistyminen onnistuu vain osioimattomalta levyltä.
Korjasin edellisessä viestissä mainitun bugin ja myös muutamia bugeja, jotka estivät kernelin toiminnan alkuperäisellä IBM PC:llä ja XT:llä. Saisin tehtyä 4,77-megahertsisestä 8088-koneesta vaikka moniajavan web-palvelimen.
Kauankohan mahtaa TLS 1.3 pyyntöön vastaaminen 2048 bit RSA / 256 bit ECDSA sertifikaateilla kestää 4,77MHz 8088:lla :o
Grez kirjoitti:
Kauankohan mahtaa TLS 1.3 pyyntöön vastaaminen 2048 bit RSA / 256 bit ECDSA sertifikaateilla kestää 4,77MHz 8088:lla :o
Mutta yritä arvioida, kuinka nopeasti nykysuorittimet pystyisivät kyseisen suorittamaan, kun koko 640 kt:n muistiavaruus mahtuu prosessorin sisään.
Olettaen, että Turakointin DOS toimii myös nykykoneessa.
peran kirjoitti:
Olettaen, että Turakointin DOS toimii myös nykykoneessa.
Toimii, ja aika nopeasti toimiikin, kun kaikki käsiteltävä muisti mahtuu prosessorin välimuistiin.
Sain nyt alkuperäisen shareware-Doomin toimimaan ST-DOSissa.
Tein tiedostojärjestelmämountteriin tuen MS-DOS-tyylisen osioinnin loogisille osioille. Samalla huomasin taas yhden UEFI-pöhisijöiden valheen.
UEFIn markkinointipropagandassahan väitetään, että IBM PC-yhteensopiva BIOS ei tue yli kahden teratavun levyjä. Väite perustuu sille, että MS-DOSin käyttämä osiotaulu ei tue yli kahden teratavun _osioita_*¹. BIOSiin tuo rajoite ei kuitenkaan liity mitenkään - IBM PC:n BIOS oli olemassa jo ennen MS-DOSia ja vasta MS-DOSin versio 2.0 ylipäätään tukee minkäänlaista osiointia. MS-DOS 1.x:ssä tiedostojärjestelmä alkaa vain levyn alusta eikä mitään osiotaulua ole. BIOS ei bootatessaan tee muuta kuin lataa käynnistyssektorin (levyn ensimmäinen sektori) muistiin osoitteeseen 0x7C00 ja suorittaa sen, eikä välitä eikä edes tiedä mistään osioinnista tuon taivaallista. UEFIn markkinointipropagandassa kuitenkin jostain syystä väitetään myös, että BIOS olisi jotenkin lukittu tuohon myöhempien MS-DOS-versioiden käyttämään osiotauluun eikä muka osaisi bootata ilman sitä*².
Myös ainakin joissain varhaisissa BSD:n versioissa juuritiedostojärjestelmä alkaa levyn alusta ensimmäiseltä sektorilta ja /etc/fstab-tiedostossa on sitten kerrottu muiden osioiden alkukohdat, eli mitään varsinaista osiotaulua ei ole. BIOS pystyy käynnistämään sellaiset käyttöjärjestelmät ilman mitään ongelmia, mutta UEFI ei pysty.
UEFI-markkinointipropagandassa väitetään myös, että MS-DOSin käyttämä osiotaulu ei tue yli 2 teran *¹_levyjä_, mutta sekään ei pidä paikkaansa. Yksittäisen osion alkusektori voi olla vain 32-bittinen luku, mutta loogisten osioiden sisältämien "aliosioiden" alkusektori ynnätään loogisen "isäntäosion" alkusektoriin ja loogisia osioita voi olla sisäkkäin loputon määrä. Näistä 32-bittisistä luvuista voidaan saada yhteenlaskemalla vaikka miten isoja lukuja ja osion alkukohta voi siis helposti olla levyllä paljon myöhemminkin kuin kahden teratavun kohdalla.
Ylipäätään tuo Microsoftin MS-DOS-järjestelmästä asti käyttämä osiotaulu on kaikesta huonoudestaan huolimatta silti parempi ja joustavampi kuin GPT-osiointi, jota UEFI pakottaa kaikki käyttämään, UEFI kun ei osaa edes *²bootata jos levyllä ei ole GPT-osiotaulua. GPT:ssä osioita voi olla vain 256 kappaletta ja lisää ei saa mitenkään. Yksi melko todennäköinen käyttötapaus, jossa tuo raja voi tulla vastaan, on esimerkiksi joku monen käyttäjän UNIX-tietokone, jossa jokaiselle käyttäjälle halutaan kotikansioksi oma fyysinen tiedostojärjestelmä.
UEFIn markkinointi on kyllä kummallista sikäli, että se on suurelta osin pelkkää vertailua kilpailevaan järjestelmään (BIOSiin) ja omituisten paikkaansa pitämättömien väitteiden esittämistä siitä. Näin käyttöjärjestelmäkehittäjän näkökulmasta UEFIn ohjelmointirajapinta on myös kaikilla tavoilla uskomattoman typerästi suunniteltu ja sisältää kaikenlaisia omituisia rajoitteita, joilla ei tunnu olevan oikein mitään teknistä perustetta.
Olen suunnitellut omaa osiotaulua, joka tukee joustavasti loputonta määrää osioita levyllä ja jossa osion alku- ja loppusektorit esitetään 64-bittisellä kokonaisluvulla, eli osion maksimikoko ei tule ihan heti vastaan. Aion jossain vaiheessa kehittää ST-DOSille sitä omaa osiotaulua käyttävän mountterin ja osiointiohjelman.
Turakointi kirjoitti:
UEFIn markkinointipropagandassahan väitetään, että...
UEFI:n esikuvana tuntuu olevan huolestuttavassa määrin Microsoftin WinAPI (ja varsinkin Secure Boot -kumppanina MS). Varmaan kaikki esitetyt väitteet kannattaa tarkistaa siitä näkökulmasta, pitävätkö ne paikkansa UEFI:n kehittämisen aikaisissa Windowsin versioissa.
Turakointi kirjoitti:
GPT:ssä osioita voi olla vain 256 kappaletta ja lisää ei saa mitenkään. Yksi melko todennäköinen käyttötapaus, jossa tuo raja voi tulla vastaan, on esimerkiksi joku monen käyttäjän UNIX-tietokone, jossa jokaiselle käyttäjälle halutaan kotikansioksi oma fyysinen tiedostojärjestelmä.
Minusta tämä on aika epärealistinen tilanne. Kiinteiden osioiden ongelma on, että tila on ennakkoon varattu yhtenäinen pötkö. Toisiin jää paljon hukkaa, ja toisaalta tilan täyttyessä laajentaminen on melko mahdotonta. Lisäksi osiointi on sidoksissa yhteen fyysiseen laitteeseen ja osion ja käyttäjän yhteys pitää jotenkin manuaalisesti määrittää. Vaikea nähdä, miksi kukaan haluaisi rakentaa noin monelle käyttäjälle noin vaikeasti hallittavan staattisen rakenteen. Jos välttämättä haluaa, jotain tuollaista varten on vaikka LVM2, jossa tilaa voi nimetä ja jakaa joustavammin, muuttaa jälkikäteen ja vaikka yhdistää useita levyjä.
Metabolix kirjoitti:
UEFI:n esikuvana tuntuu olevan huolestuttavassa määrin Microsoftin WinAPI (ja varsinkin Secure Boot -kumppanina MS). Varmaan kaikki esitetyt väitteet kannattaa tarkistaa siitä näkökulmasta, pitävätkö ne paikkansa UEFI:n kehittämisen aikaisissa Windowsin versioissa.
UEFI käyttää jopa ohjelmabinääreilleen Windowsin EXE-tiedostojen PE-formaattia, jossa tiedoston headerissa pitää speksin mukaan olla kokonainen DOS-ohjelma. Siinä ei ole mitään järkeä, koska tuota DOS-ohjelmaa ei UEFI-ympäristössä ikinä edes pystytä suorittamaan. Siinä menee tavuja aivan turhaan hukkaan.
Tuo väite BIOSin lukkiutuneisuudesta MS-DOSin osiotauluun ei pidä paikkaansa edes Windowsin kontekstissa, koska 64-bittinen Windows XP käyttää automaattisesti osiointina GPT-osiointia, jos levyn sektorikoko on jotain muuta kuin 512 tavua (esim. 4 kt). Windows XP:ssä ei tietenkään ole mitään UEFI-yhteensopivuutta, vaan sitä käytetään aina BIOSin kanssa.
UEFIn markkinointimateriaalissahan väitetään tosiaan myös, että BIOS ei tukisi yli 512 tavun sektoreita. Sekään ei pidä paikkaansa - jo alkuperäisen IBM PC:n BIOS tukee kaikenkokoisia sektoreita 128 tavun ja 65536 tavun väliltä, kunhan sektorin koko tavuina on jokin kahden potenssi. BIOSin ohjelmointirajapinta siis tukee kyllä eri kokoisia sektoreita.
Metabolix kirjoitti:
Minusta tämä on aika epärealistinen tilanne. Kiinteiden osioiden ongelma on, että tila on ennakkoon varattu yhtenäinen pötkö. Toisiin jää paljon hukkaa, ja toisaalta tilan täyttyessä laajentaminen on melko mahdotonta. Lisäksi osiointi on sidoksissa yhteen fyysiseen laitteeseen ja osion ja käyttäjän yhteys pitää jotenkin manuaalisesti määrittää. Vaikea nähdä, miksi kukaan haluaisi rakentaa noin monelle käyttäjälle noin vaikeasti hallittavan staattisen rakenteen. Jos välttämättä haluaa, jotain tuollaista varten on vaikka LVM2, jossa tilaa voi nimetä ja jakaa joustavammin, muuttaa jälkikäteen ja vaikka yhdistää useita levyjä.
Minusta tuo on hyvinkin realistinen tilanne, jos asia halutaan tehdä yksinkertaisemmin ja varmatoimisemmin. Jos jokaiselle käyttäjälle on levyllä oma osionsa, niin silloin käyttäjäkohtaisen levytilan hallintaan ei tarvita mitään monimutkaista ja bugiherkkää kernelimoduulia, vaan käyttäjäkohtainen tiedostojärjestelmä voi kaikessa yksinkertaisuudessaan olla vain liitetty käyttäjän kotikansioon. Tilan ennakkoon varaaminen voi olla ihan toivottukin ominaisuus, jos minkäänlaista "overcommitointia" ei haluta syystä tai toisesta tehdä.
Turakointi kirjoitti:
Jos jokaiselle käyttäjälle on levyllä oma osionsa, niin silloin käyttäjäkohtaisen levytilan hallintaan ei tarvita mitään monimutkaista ja bugiherkkää kernelimoduulia, vaan käyttäjäkohtainen tiedostojärjestelmä voi kaikessa yksinkertaisuudessaan olla vain liitetty käyttäjän kotikansioon.
No osiothan toimii kernelmoduulin kautta joka tapauksessa, joten "vikaherkän kernelmoduulin" se tarvii joka tapauksessa. Mutta eihän sinun omassa käyttiksessä (tai edes Linuxissa) ole pakko rajoittua GPT tai MS-DOS osiointitauluun vaan voit tehdä Turakointi™-osiointitaulun vaikka yhteen GPT-osioon (jos kerran se GPT vaaditaan että kone buuttaa)
Kernelimoduulin tiedostojärjestelmää varten on oltava olemassa joka tapauksessa, tai muuten käyttöjärjestelmä ei pysty käsittelemään tiedostoja tai kansioita ollenkaan. Käyttöjärjestelmä voi kuitenkin olla hyvin käyttökelpoinen ilman mitään käyttäjäkohtaista tallennustilaa hallinnoivaa moduulia.
Minusta muuten näyttää, että GPT:ssä on 32-bittinen luku osioiden määränä, kunhan osiotaulun koon säätää jo alussa haluamakseen. Linuxissa on katsottu hyväksi rajaksi ilmeisesti 255 per levy ja Windowsissa 128, ja varmaan valmiit työkalut toimivat tämän mukaan. Mitä firmware tukee, sen voit itse testata.
Nyt levykäyttöjärjestelmässä on ATAPI-CD-ROM-asemia tukeva BIOS-laajennus, CD-ROM-laiteajuri ja ISO9660-tiedostojärjestelmäajuri. Myös tiedostojärjestelmäajurirajapinta on siis valmis ainakin lukufunktioiden osalta. Toistaiseksi ISO9660 on ainoa olemassa oleva tiedostojärjestelmäajuri ja sen takia kirjoittamista dynaamista tiedostojärjestelmäajuria käyttävälle tiedostojärjestelmälle ei ole vielä voitu testata.
Parin bugikorjauksen jälkeen levykäyttöjärjestelmäydin kutsuu nyt int28h-joutokäyntikäsittelijää myös CD-levyä lukiessa.
Tein KEYB-toteutuksen, jota ei vielä toistaiseksi ole mahdollista saada pois muistista, kun näppäinkartta on kerran muistiin ladattu. Tein sille suomalaisen näppäinkartan tuen. Tuossa vähän videota toiminnasta: https://www.youtube.com/watch?v=xWENTEYMmaI
Käyttäjät voivat helposti tehdä omia näppäinkarttoja.
Kirjoittamisessa ei oikeasti ole latenssia, vaikka videossa näyttää siltä. Android-puhelimen kameraohjelmassa on epäsynkkaa äänen ja videon välillä.
Parantelin levykäyttöjärjestelmän asennusohjelmaa. Nyt myös CD-aseman ajurit ja näppäinkartta asentuvat automaattisesti.
Tein levykäyttöjärjestelmään oman levyn osiointijärjestelmän, joka toimii kuin yksinkertainen tiedostojärjestelmä, jossa kaikki tiedostot ovat levyllä yhtenäisinä lineaarisina paloina niin, että käyttöjärjestelmän ydin osaa kiinnittää ne tiedostojärjestelmiksi. Osioita voi hallita, lisätä, poistaa ja merkitä osioiksi ja käynnistettäviksi osioiksi kiinnittämällä "juuritiedostojärjestelmän" erityistä tiedostojärjestelmäajuria käyttäen ja lisäämällä tai poistamalla ATTRIB-komentoa käyttäen P- ja B-lipun, tosin tämä osuus on vielä dokumentoimatta ja seuraava homma olisikin kirjoittaa ohjetiedostot asiaa koskien.
Käyttöjärjestelmän pitäisi tukea kiintolevyjä kahden teratavun kokoon asti, mutta en ole vielä testannut sitä niin isojen levyjen kanssa. Myös sitä isommat levyt toimivat joko laiteajuria käyttäen tai pienillä muutoksilla ytimen koodiin, mutta näitä asioita on niin hankalaa testata nykyisellä laitteistollani, että en ala siihen nyt.
ST-DOSin asennusohjelma ajaa automaattisesti osioidenteko-ohjelman, joka osaa täyttää kiintolevyn 2047 megatavun kokoisilla FAT16-osioilla. Automatiikka luo kuitenkin maksimissaan 20 osiota. Lopputila jää vapaaksi ja sinne voi säilöä isoja tiedostoja, kunhan ensin lataa rootfs-tiedostojärjestelmäajurin.
Osiot näkyvät juuritiedostojärjestelmässä aivan tavallisina levykuvatiedostoina, ja sinne voi myös lisätä/kopioida muualta levykuvatiedostoja ja merkitä ne osioiksi ATTRIB-ohjelmalla, jolloin ne mounttautuvat automaattisesti seuraavan uudelleenkäynnistyksen yhteydessä.
ST-DOSissa on nyt pilvi. Tiedostojärjestelmien jakaminen ST-DOSia käyttäviin koneisiin on mahdollista sekä Linux-koneilta että DOS-koneilta.
Tein videon pilvipelaamisesta ST-DOSilla. https://www.youtube.com/watch?v=iW4KVJcfmz8
Turakointi kirjoitti:
Tein videon pilvipelaamisesta ST-DOSilla. https://www.youtube.com/watch?v=iW4KVJcfmz8
very nic