Tänkte det vore bra med en speciell tråd om detta ämne, ungefär som med mina andra specialintressen. Denna passar nog bättre här än bland "intressanta intressen".

Historiken bakom detta specialintresse är lång. Det var 1988 som jag påbörjade RDOS. Det var av missnöje med Microsofts DOS, som var byggt på ett helt **** sett som gjorde det omöjligt att skapa trådar. Vid den tiden jobbade jag på SMHI, och behövde trådar i ett projekt där.

Idag är RDOS ett stabilt operativsystem som stödjer en hel massa olika hårdvara och mjukvaruprotokoll. Det finns stöd för USB, TCP/IP, IPC (interprocess kommunikation) som fungerar över nätverk, FAT12/FAT16/FAT32 filsystem med långa filnamn, VESA kompatibel grafik, ett avancerat klassbibliotek för att skapa användargränssnitt och grafiska applikationer, seriell kommunikation.

Den främsta styrkan är kanske debugfunktionaliteten. Till RDOS hör en processoremulator för 386-processorn som man kan använda för att felsöka i startupkod. Det finns även en drivrutin i RDOS som kan simulera alla 386-instruktioner som (historiskt) användes för att kunna emulera olika minnesareor för DOS program. Den används fortfarande när man gör video-mode-switch via BIOS. RDOS kärna innehåller en kernel-debugger som kan enkelstega nästan all kod i kärnan (utom schedulern) och i applikationer.

RDOS är idag anpassat till OpenWatcom, och det finns officiellt stöd i OpenWatcom miljön för att skapa applikationer för RDOS. Denna anpassning är extremt effektiv genom att OpenWatcom kan definiera anrop till kärnan direkt på registernivå utan att behöva gå via konvertingsmoduler i assembler. Tidigare användes Borland C++ 4.5/5 som utvecklingsmiljö. Då fanns ett antal Windows-DLL som simulerade viktiga Windows-funktioner så att Borlands verktyg trodde att de körde under Windows (egentligen under en Dos-extender). Det fanns då dessvärre inget stöd för debugging av trådar, eftersom Borlands Turbodebugger behövde mängder av svårsupportade funktioner innan den slog på stöd för trådar. I OpenWatcom finns fullt stöd för debugging av trådar, dock finns vissa brister som behöver åtgärdas i framtida releaser av kompilatorn / debuggern. Release kandidat 3 av 1.9 av OpenWatcom finns när detta skrivs, och en slutrelease kommer troligen inom kort.

RDOS använder en "mixed-bitness" minnesmodell. Detta gör att RDOS potentiellt sett kan köra alla typer av applikationer som finns för 386-processorn: real mode (DOS, körs i "virtual mode"), 16-bitars applikationer (t.ex. 16-bitars Windows-format) och flat (t.ex. 32-bitars Windows format, Linux ELF format) eller OS/2 48-bitars minnesmodell. RDOS kärna använder nästan uteslutande 16-bitars kodsegment. Alla pekare skickas via register (med få undantag), och innehåller då segment och offset. Det finns tre olika typer av "entry-points" till kärnan som applikationer kan använda:

* Real mode. Denna modell innehåller automatisk översättning av segment till selektorer.
* 16-bitars. Offset är 16 bitar
* 32-bitars. Offset är 32 bitar

Det finns oxå en gemensam "entry-point" för anrop som inte innehåller pekare.

Det är drivrutinen som hanterar en "entry-point" som definierar den. Till en början så är anropet definierat som en call genom selektor 0, som ger en "protection fault" när den accessas. Den översätts i kärnan till en "call gate", som då går till den position som drivrutinen tidigare definierat. När den nya "call gaten" skrivit över det ursprungliga ogiltiga anropet, så återstartas instruktionen. Nästa gång anropet sker så går det direkt utan "protection fault". Det finns alltså ingen gemensam "syscall" som alla funktioner går igenom som DOS, Windows och Linux har.

RDOS kommer inte att stödja den nya 64 bitars moden i Intel/AMD processorerna. Detta beror på att dessa processorer kräver en kärna som är gjord i 64-bitars "flat", vilket är emot designprinciperna för RDOS. Alla 64-bitars processorer har dock "legacy 386" stöd, och stöd för simulering av "386" mode inom 64 bitars mode. Detta gör att RDOS kommer att fungera även i framtida processorer många år än. Emuleringen inom 64 bitars mod stödjer dock inte hardware taskswitching, så detta håller på att fasas ut i RDOS.

Som indikerades tidigare så håller jag på med multiprocessorsupport för RDOS (jag skaffade en eMachines mini-PC med Intel Atoms hyperthreading för ändamålet). Detta projekt var svårare än förväntat. Jag fasade ut "hardware taskswitching" som första del. Sedan har jag skapat indirekta anrop för ett antal schedulerfunktioner som skiljer sig väsentligt (prestandamässigt) om man kör dem med en processor eller flera. Jag har oxå skapat spin-locks och tagit bort nästan alla "cli/sti" (stänga av / sätta på avbrottssystemet) som förut användes för att skydda schedulern.

Tyvärr så finns stabilitetsproblem (som kanske är fixade nu) med vår professionella betalkortsapplikation med nya schedulern. Det värsta med detta är att det skiljer flera hundra releaser mellan något som verkar funka och nuvarande release. Det går liksom inte att gradvis gå ifrån hardware taskswitching till software taskswitching och multiprocessorsupport. Till saken hör oxå att schdulern är ifrån slutet av 1980-talet, och inte alls speciellt välskriven med nuvarande mått sett.

Det verkar som allt är stabilt igen nu. Betalkortsapplikationen har nu kört 3-4 dagar utan att det hänt något. Jag har oxå fasat ut några andra funktioner som inte är kompatibla med multiprocessing. Förut fanns "snabbvägar" till nuvarande tråd, nuvarande TSS, nuvarande applikation och några andra liknande funktioner som hanterades via paging och små förändringar i page-tables som gjordes varje gång som schedulern kördes. Dessa är nu borta, och försämrar prestandan lite. Å andra sidan är presetandan bättre i schedulern dels för att page-tabellerna inte behöver modifieras, och dels för att man inte behöver "flusha" TLB vid varje scheduling (bara när man byter process).

Jag har oxå lagt in "global pages" (för processorer som stödjer detta), och använder invlpg istället för CR3 när TLB behöver "flushas". Detta påverkar prestanda positivt för processorer som stödjer det.

Multiprocessorfunktionen funkar dock inte än, men förutsättningar för att få igång den finns nu. Behöver några bättre debug-funktioner som jag tänkte göra idag.

Nu går det att köra båda kärnorna samtidigt, dock bara så länge ena kärnan bara kör nolltråden, men det schduleras med jämna mellanrum så den viktigaste synkroniseringen mellan kärnorna verkar fungera någorlunda nu.

Det tar sig! *hejar på*

Körde ett obelastat test inatt, och det fungerade. Fast efter att jag varit ute på hårddisken och gjort "dir", så stannade det plötsligt. Kernel-debuggern antyder en loop någonstans som "äter upp" kernel-stacken. Nåväl, det går säkert att lösa.

Förresten så är vår nya terminal som körs med RDOS på väg ut till flera olika kunder nu. Nästa vecka installeras en tankanläggning åt Waxholmsbolaget där man ska tanka båtar. Det är fem olika tankställen, var och en med egen terminal. Man bygger en helt ny kaj där. Sedan ska en E.ON gasstation i Svedala oxå köras igång. Som tur är så kör jag en stabil version där utan flera kärnor

Nu fungerar multiprocessorfunktionen (fick byta ordning på ett lock). Det var första gången jag såg applikationsprocessorn (den extra processorn) listas som den som körde själva "state" funktionen. Det gick även att köra mer komplexa multitrådade program. Det verkar dock finnas några andra brister i vissa drivrutiner, för vissa testprogram är inte helt stabila. Felen verkar dock finnas på andra ställen än i schedulern.

Sedan behövs nog oxå några tillägg till schedulern, speciellt när trådar återstartats efter att ha varit blockerade. De bör återstartas på den processor som har den tråd som har lägst prioritet istället för på den som råkar återstarta (oftast boot-strap processorn).

Jag vill nog oxå ha en funktion som balanserar lasten över tid så att alla processorer jobbar lika mycket. Det kan man nog använda en processors null-tråds tidsåtgång för att styra.

Tja, det har hänt en del till. Jag har fått igång min stationära dator med en Athlon-processor (2-kärnig). En del av drivrutinerna verkar dock inte fungera, vilket antagligen beror på att IRQ-linjerna inte är kopplade till standard-interruptkontrollern (PICen), utan bara till IOAPICen. Inte heller verkar processoridentifikationen fungera, utan det verkar som att båda kärnorna har samma ID (vilket får förödande konsekvenser).

Jag har fortfarande en del stabilitetsproblem med sista versionerna, men det verkar iaf som det finns en version utan hardware-taskswitching (och med multiprocessor-support) som klarar av att köra det mesta på en processor utan att krascha (t.ex. vår terminal).

Nu fungerar SMP (Symetric MultiProcessing)-funktionen helt stabilt på min eMachines mini-PC. Alla mina multitrådade testprogram fungerar utan problem, även när de kör samtidigt.

Jag kör oxå sista versionen "skarpt" i Svedala och den är på väg ut till Waxholmsbolaget.

Athlonx2 datorn fungerar dock inte. Det blir nästa projekt att få SMP-funktionen att köra även på en dual-core processor.

Det går nu (iaf delvis) att köra RDOS under Microsoft Virtual PC. Deras videostöd är undermåligt (både för grafik och textmode), så det man kan göra i dagsläget är bara att man kan köra program ifrån kommandotolken i RDOS.

Nu börjar våra EMV-godkända betalkortsterminaler komma ut på allvar. Det är fem stycken som kör skarpt nu och någon till på väg ut. Det fungerar hyfsat bra även om det än så länge är lite för mycket spontana omstarter. Dock är det inga hängningar, utan allt som hänt är några oförklarliga omstarter. Ska designa en ny funktion som skriver ned en taskdump till en fast position på hårddisken när något gått snett. När omstarten sedan är gjord, så ska jag skicka hem denna dump så att alla spontana omstarter kan analyseras.

rdos skrev:...Alla 64-bitars processorer har dock "legacy 386" stöd, och stöd för simulering av "386" mode inom 64 bitars mode. Detta gör att RDOS kommer att fungera även i framtida processorer många år än. Emuleringen inom 64 bitars mod stödjer dock inte hardware taskswitching, så detta håller på att fasas ut i RDOS.

Imporerande arbete!

Håller tummarna för att legacy -stödet för 386 finns kvar länge än, bortom Intel Core i7. AMD har säkert också något bra att bjuda på...

Jag tittade för länge sedan lite på Minix, ungefär samtidigt som Linux skapades (ca 1991/92). Men att ta in alla kunskaper om hur man skapar ett operativsystem kändes övermäktigt tillsammans med högskolestudierna...

Nu kör jag Ubuntu 10.04 (dvs Linux ) på den bärbara, fungerar i alla fall klart bättre än Windows Vista som var på den tidigare. Men ibland längtar man efter att förstå mer av vad som händer under ytan.

Hur som helst var det en inspirerande läsning, RDOS.

Numera finns det lite drygt 30 betalkortsterminaler ute runt om i Sverige som använder RDOS. Antalet fel har minskat successivt under hösten-vintern, och numera är RDOS helt stabilt med en kärna, medan det kvarstår lite problem med applikationen (och hårdvaran). Håller oxå på med en drivrutin till en USB-baserad kvittoskrivare för att kunna skriva ut snygga, grafiska, kvitton.

Det finns nu oxå en väl fungerande miljö för automatiska uppdateringar, såväl av RDOS kärna som applikationer och tillhörande filer som ligger på en central FTP-server.

Borlands miljö har nu oxå helt fasats ut. Det går numera att bygga även drivrutiner med OpenWatcom (dock enbart i assembler än så länge). I IDEn kan man t.o.m. definiera vilken kod och dataselektor som en modul ska använda, vilket är en betydande fördel jämfört med tidigare då detta hårdkodades i drivrutinerna. Stöd för RDOS drivrutiner kommer officiellt i nästa release av OpenWatcom. Det finns oxå stöd för att via OpenWatcoms debugger stega in i kärnan, och visa koden på källkodsnivå.

En annan ny finess är att man kan bygga bootbara system med kod. Detta används i vår terminal när man uppdaterar kärnan. Det förs över en grundkärna, som sedan används för att bygga ett bootbart system inifrån själva uppgraderingsmodulen. Man lägger då på olika inställningar och kundspecifika filer till systemet som sedan inte går att förändra i runtime.

Jag har oxå införskaffat en 4-kärnig Athlon-processor hemma för att få en bättre testmiljö för SMP. Dock så startar inte RDOS på denna dator med mer än en processor. För att hitta dessa problem håller jag på med en SMP-monitor som ska dedikera en kärna till en stabil miljö som kan dumpa status på de andra kärnorna när schedulern havererar. Har två tangentbord till den (ett PS2 och ett USB). USB-tangentbordet används som standard, medan PS2 används av SMP-monitorn. På så vis kan jag felsöka även om RDOS totalhaverar med avstängt avbrottsystem och kan när som helst stoppa med en tangentnedtryckning på PS2 tangentbordet.

Okej, jag trodde att jag var nördig som kör Mac Os X i serverversion, men RDOS slår mig...

Varför RDOS?
Varför inte bara använda Linux istället?

Hur står sig RDOS mot FreeDOS?

Paprika skrev:Varför RDOS?

Fördelen är att nästan ingen kan något om RDOS vilket gör att det är i stort sett totalt säkert mot hackare, vilket är suveränt eftersom det används för bankterminaler. Jag tycker att det är ett genidrag!

Paprika skrev:Varför inte bara använda Linux istället?

Och få med en massa saker som man inte har full kontroll över?

Paprika skrev:Hur står sig RDOS mot FreeDOS?

Det går nog inte att jämföra, men jag tror att rdos är bättre lämpad att svara på den frågan.

Paprika skrev:Varför RDOS?
Varför inte bara använda Linux istället?

För att Linux bygger på en lika antik API (UNIX) som DOS och Windows.

Paprika skrev:Hur står sig RDOS mot FreeDOS?

De har inte något gemensamt längre. Till att börja med så fanns var en viktig aspekt DOS-kompabilitet, men denna byggdes tidigt på emulering. Idag är DOS-emuleringen (liksom DOS-extender och Win32 emuleringen) mer eller mindre helt obsolete. APIn i RDOS är helt egen, designnad från scratch för att vara enkel och utan någon hänsyn till kompabilitet och liknande.

FreeDOS är ett OS för processorns "real mode", och som sådant måste större applikationer använda DOS-extenders. FreeDOS (liksom vanlig DOS) saknar oxå trådar och multiprocessing, något som RDOS haft redan ifrån första början. RDOS kör i protected mode, och som standard är applikationer 32-bitars "flat". De behöver inga DOS-extenders.

Det enda de har gemensamt är att RDOS använder en stomme av deras kommandotolk (FreeCom).

Miche skrev:Fördelen är att nästan ingen kan något om RDOS vilket gör att det är i stort sett totalt säkert mot hackare, vilket är suveränt eftersom det används för bankterminaler. Jag tycker att det är ett genidrag!

Jo, det finns klara fördelar med ett system som inte är så komplext och svårkonfigurerat som Windows och Linux. Vi har alldeles nyligen fyllt i PA-DSS för terminalen, och fått den godkänd av PanNordic. Det var faktiskt hur enkelt som helst eftersom de flesta punkterna hörde ihop med säkerhetsbrister i Windows/Linux.

Några exempel:

* Det finns inga användkonton

* Det finns ingen "remote access" eller fjärrskrivbord

* Jag vet exakt vilka tjänster som kör (man väljer vilka som ska vara aktiva i konfigurationsfilen.

* Det går inte att slå på tjänster lokalt

* Det går inte att ändra applikationen, OS-konfiguration eller viktiga filer lokalt

* Känslig data ligger inte i filsystemet, och "syns" därför inte

* Det finns ingen kommandotolk eller GUI i skarpa versionen (= man kan inte starta program lokalt, eller ändra i filsystemet)

* Det finns inga "blå skärmar" som användaren får när något gått snett. Istället så triggar fel i appliationen och kärnan att viktig information sparas på fixa disksektorer, datorn startas om, och så förs informationen över till vår centrala FTP-server för vidare analys.

rdos skrev:* Det finns inga "blå skärmar" som användaren får när något gått snett.

Jag fattar inte hur fan man kan bygga bankomater på Windows... (anledningen till att jag skriver det är att jag sett blåskärm på en bankomat...)

Hur säkert är det på en skala?

Tycker att RDOS måste vara typ en miljon gånger säkrare...

Miche skrev:

rdos skrev:* Det finns inga "blå skärmar" som användaren får när något gått snett.

Jag fattar inte hur fan man kan bygga bankomater på Windows... (anledningen till att jag skriver det är att jag sett blåskärm på en bankomat...)

Hur säkert är det på en skala?

Tycker att RDOS måste vara typ en miljon gånger säkrare...

Typ det värsta vi varit med om är att en terminal fick en felaktig konfiguration av kärnan, vilket gjorde att den stod och startade om hela tiden.

Själva uppgraderingsfunktionen var det en del problem med i början, men nu fungerar den i det närmaste helt perfekt. Jag skulle definitivt inte lita på att standard installationsskript för Windows/Linux skulle fungerat helt utan manuell intervention i alla lägen.

Det finns t.o.m. en allra yttersta utväg om disken skulle bli helt korrupt. Då kan man antingen via systemmenyn, eller på annat sätt, radera hela terminalapplikationens partition. När terminalen då startar om så konfigurerar den sig helt ifrån start. Det tar en stund, men det fungerar som sista utväg. Det är även denna metod jag använder för att skapa nya system. Det tar 10s att skapa själva konfigurationsfilen på servern, och sedan tar det kanske 1 minut att ladda ned det som behövs via lokalt nätverk. Att installera en typisk XP eller Linux distribution på aktuell dator (en 500MHz Pentium) tar säkert en timme.

Just nu är det enda som verkar hända att det blir omstarter ibland (dock ganska få just nu). Vi har nog inte ett enda exempel på att själva systemet hakat upp sig på något sätt. Omstartsfunktionen tar så gott som alltid dessa lägen och gör en kontrollerad omstart. Däremot så har delar av applikationen hamnat i fellägen som krävt manuell omstart.

Miche skrev:

Paprika skrev:Varför RDOS?

Fördelen är att nästan ingen kan något om RDOS vilket gör att det är i stort sett totalt säkert mot hackare, vilket är suveränt eftersom det används för bankterminaler. Jag tycker att det är ett genidrag!

Det låter ju som security through obscurity. Nu vill inte jag göra något anklagande, men vill påpeka att hypotetiskt så kanske koden är full av säkerhetshål.

Miche skrev:

Paprika skrev:Varför inte bara använda Linux istället?

Och få med en massa saker som man inte har full kontroll över?

Och få med en massa trevliga, nödvändiga, användbara saker som är mogna, bevisade och testat av miljontals användare på olika hårdvare och olika konfigurationer.

rdos skrev:För att Linux bygger på en lika antik API (UNIX) som DOS och Windows.

Linux bygger på POSIX API och följer Single Unix Specification (SUS).
Unix var väldesignat från grunden till skillnad mot DOS, Windows 9x, etc.
NT var däremot även det väldesignat från grunden.
Så att Linux bygger på en like antik API som DOS tycker inte jag är ett argument som håller, då Unix var väldesignat och DOS skräp.

rdos skrev:De har inte något gemensamt längre. Till att börja med så fanns var en viktig aspekt DOS-kompabilitet, men denna byggdes tidigt på emulering. Idag är DOS-emuleringen (liksom DOS-extender och Win32 emuleringen) mer eller mindre helt obsolete. APIn i RDOS är helt egen, designnad från scratch för att vara enkel och utan någon hänsyn till kompabilitet och liknande.

FreeDOS är ett OS för processorns "real mode", och som sådant måste större applikationer använda DOS-extenders. FreeDOS (liksom vanlig DOS) saknar oxå trådar och multiprocessing, något som RDOS haft redan ifrån första början. RDOS kör i protected mode, och som standard är applikationer 32-bitars "flat". De behöver inga DOS-extenders.

Det enda de har gemensamt är att RDOS använder en stomme av deras kommandotolk (FreeCom).

Låter som RDOS inte är så mycket DOS som ett operativ system med DOS emulering.
Då skulle man ju lika gärna kunna köra DOXBox, DOSEMU, eller nåt.

rdos skrev:Några exempel:
...

Mycket av det där kan man ju åstadkomma i Linux också.
Köra utan SSH och X.
Mounta filsystemet i read-only.
Kerneloops och watchdog.
SELinux.
Dessutom får man en brandvägg.

rdos skrev:Det tar 10s att skapa själva konfigurationsfilen på servern, och sedan tar det kanske 1 minut att ladda ned det som behövs via lokalt nätverk. Att installera en typisk XP eller Linux distribution på aktuell dator (en 500MHz Pentium) tar säkert en timme.

Du jämför äpplen med meloner.
Ett minimalistiskt inbyggt system och ett fullfjädrat desktop system med webläsare, kontorspaket, mediaspelare, etc.
Finns ju minilinuxdistribioner för inbäddade system på bara någon megabyte, dessa tar mindre än en minut att ladda och installera.

Paprika skrev:through obscurity[/url]. Nu vill inte jag göra något anklagande, men vill påpeka att hypotetiskt så kanske koden är full av säkerhetshål.

Det finns inga säkerhetshål eftersom det inte finns någon access utifrån.

Paprika skrev:Och få med en massa trevliga, nödvändiga, användbara saker som är mogna, bevisade och testat av miljontals användare på olika hårdvare och olika konfigurationer.

Jo, eller något som hackats ihop och inte testats av någon i stort sett. Sånt finns oxå.

Paprika skrev:Linux bygger på POSIX API och följer Single Unix Specification (SUS).
Unix var väldesignat från grunden till skillnad mot DOS, Windows 9x, etc.

Håller inte med. Unix gjordes för mycket länge sedan (70-tal skulle jag gissa) och möter därför inte på något sett krav man kan ställa på ett modernt OS.

Paprika skrev:NT var däremot även det väldesignat från grunden.

Nej, NT är inte väldesignat. Det räcker med att studera nätverksspecen (för M$ nätverk) för att inse att det inte är väl designat. Varenda OS-version har i stort sett sina egna små special som gör hela protokollet till en röra utan like. Dessutom så lanserar M$ nya APIer på löpande band, något man givetvis inte skulle behöva göra för ett stabilt koncept.

Paprika skrev:Låter som RDOS inte är så mycket DOS som ett operativ system med DOS emulering.
Då skulle man ju lika gärna kunna köra DOXBox, DOSEMU, eller nåt.

Du missade poängen. RDOS har inget med DOS att göra öht, och DOS emuleringen är skrotad.

Paprika skrev:Dessutom får man en brandvägg.

Brandväggar finns för att användare saknar kunskaper om konfigurering av sina system. Vilket beror på att detta är en enda röra såväl i Windows som i Linux.

Nu har jag kommit en bra bit på vägen att köra standard C-kod i kärnan. Speciellt vill jag kunna köra Intels ACPICA-kod utan modifieringar som en drivrutin. Den är skriven i C och använder en del av standard-C biblioteket.

Jag har porterat över stora delar av clib i OpenWatcom nu till "32-bitars compact" minnesmodell. Det är den minnesmodell som bör fungera bäst i kärnan. Den använder ett enda kodsegment, men flera datasegment. Alla pekare är 48-bitar, precis som i RDOS drivrutiner, medan alla anrop är "near" (32-bitars).

Själva ACPICA koden kompilerar helt utan fel nu, men länkaren saknar fortfarande några funktioner.

jag har väl nämnt den förut, men har du funderat på att utnyttja tekniken "cache-as-ram" för att slippa externt RAM-minne?