Visst låter det konstigt? Det var en snubbe från sydafrika som kontaktade mig innan idag som tydligen sysslar proffessionellt med inbyggda system i Afrika. Tydligen var han intresserad av att använda RDOS i något projekt som skulle kunna spridas över Afrika. Iofs coolt, och kan bli lönande oxå. RDOS är ju inte gratis för kommersiella system.

På mitt jobb håller vi dessutom på med ett projekt med EMV-betalkortslösningar med SAGEM. Det systemet måste köras på PC, och det är väl inte omöjligt att RDOS blir valt som OS trots allt. Jag kommer iaf att utveckla betalkortsdelen under RDOS. sedan återstår att se om detta blir porterat till Linux eller inte. Dessa terminaler lär ju hamna lite överallt, bl.a. i Danmark och Norge.

Rdos och Afrika låter som en förvånande kombination ja.

Har du alltså haft rdos tillgängligt för nedladdning för att testa så de har hittat det den vägen och tyckt att det är konkurrenskraftigt? Är det seriösa och kunniga kunder så är det ju ett väldigt bra betyg åt dig i så fall. Problemet är förstås att du måste ta det på allvar med support och buggfixar och sådant om du kommersialiserar det på allvar.

Vad är det som lockar? Är det prestanda och funktionalitet eller lockar du med lågt pris jämfört med konkurrerande produkter?

Rdos + Afrika... är det inte sånt som brukar kallas livets ironi...?

Grattis i alla fall, hoppas att det leder till något lönsamt när du lagt ner så mycket jobb på det.

Kvasir skrev:Har du alltså haft rdos tillgängligt för nedladdning för att testa så de har hittat det den vägen och tyckt att det är konkurrenskraftigt?

Javisst. Det har funnits på min hemsida sedan mitten av 1999. Det är därför sajten heter rdos.net

Kvasir skrev:Är det seriösa och kunniga kunder så är det ju ett väldigt bra betyg åt dig i så fall. Problemet är förstås att du måste ta det på allvar med support och buggfixar och sådant om du kommersialiserar det på allvar.

Njäee, RDOS använder en modifierad GPL-licens. Det innebär att det är fritt att använda för hobbyprojekt men att man måste betala för att använda det i kommersiella system. I GPL-licensen ingår att det inte finns någon som helst garanti emot buggar och att man använder det på egen risk

Å andra sidan så är RDOS ett mycket stabilt system idag om man använder det i inbyggda system med supportad hårdvara. Däremot är det inget bra val för "skrivbordet" som M$ brukar tjata om.

Kvasir skrev:Vad är det som lockar? Är det prestanda och funktionalitet eller lockar du med lågt pris jämfört med konkurrerande produkter?

Förmodligen de ytterst små hårdvarukraven som varken Windoze eller Linux kan matcha. Det går iaf i princip att köra en avancerad applikation på en 386:a med 4MB ram och utan hårddisk, tangentbord och mus. Hela RDOS är ju kodat i 386-assembler och kärnan bygger på en avancerad metod för användning av segementskydden som förmodligen är unik. Trots att kärnan i princip är skriven för 16-bitars segmentering så kan man köra alla typer av program effektivt, såväl segmenterade som moderna 32-bitars "flat".

Uppdatering om RDOS. Som jag skrivit på andra ställen har jag jobbat en hel del med RDOS de sista veckorna - månaderna. Lite om nya funktioner:

1. Drivrutin för OHCI-baserade USB chips. Med denna så stödjer RDOS nu USB i de flesta datorer.

2. Stöd för flera nätverkskort (just nu bara med RTL-baserade chip, men principen fungerar även för andra).

3. DHCP-server.

Vi har nu oxå snart en färdig terminal med avancerad grafik som inom kort ska testas av PBS i Danmark och då bli certifierad för att köra bankkort emot PBS. Vi visade upp den för DinX i veckan.

Ett stort jobb som återstår är att implementera stöd för ljudkort. När det är klart så kan man nog använda RDOS i multimedia sammanhang. Det borde finnas OpenSource kod för att kunna visa video i realtid, vilket säkert skulle kunna fungera utmärkt med RDOS.

Vårt företags nya terminaler kommer med andra ord att bygga på RDOS och inte på CE eller Linux.

Hej!

Så RDOS är ett operativsystem? I så fall är det ju supercoolt, du måste vara en riktigt baddare på programmering rdos.

Hälsningar

Lilla Gumman

Lilla Gumman skrev:Så RDOS är ett operativsystem?

Jepp, mitt längsta specialintresse. Jag började omkring 1988 med RDOS (det är ju 20 år sedan nu, borde ha jubileum). På den tiden var 386-processorn hypermodern och det fanns inget 32-bitars Windows eller Linux. Jag läste olika Intel-manualer kring systemprogrammering och anade att 32-bitars program skulle bli framtiden, men insåg oxå vilka problem "flat" kunde ställa till med i ett operativsystem. Därför så utvecklades RDOS med segmentering och i assembler för att jag ville ha full koll på vad som hände.

En annan motivation till att RDOS kom till var att vanliga DOS var skrivit på ett extremt klantigt sätt som gjorde att multitasking blev ett rent helvete. RDOS är fortfarande "DOS-kompatibelt" idag, förmodligen mer än XP och Vista, och hanterar mutlitasking i DOS utan vidare. Det kan oxå köra 32-bitars program. Det finns numera oxå ett egenutvecklat klassbibliotek i C++ för grafik och enkla Widgets, Jag har oxå kommit halvvägs i att lägga till support för RDOS i GCC/Newlib projekten.

Lilla Gumman skrev: I så fall är det ju supercoolt, du måste vara en riktigt baddare på programmering rdos.

Jag har väl vissa talanger på området.

Mest så att jag kan läsa min egen assemblerkod som jag skrev för 10-20 år sedan och har i huvudet hur det mesta i RDOS fungerar. Jag har oxå lärt mig effektiva metoder för att strukturera kod. Egentligen så jobbade jag objektorienterat i assembler i RDOS redan för 20 år sedan, trots att jag inte lärde mig C++ förrän senare. Jag har ju oxå jobbat med programmering av inbyggda system i 10 år nu.

rdos skrev:Mest så att jag kan läsa min egen assemblerkod som jag skrev för 10-20 år sedan och har i huvudet hur det mesta i RDOS fungerar. Jag har oxå lärt mig effektiva metoder för att strukturera kod. Egentligen så jobbade jag objektorienterat i assembler i RDOS redan för 20 år sedan, trots att jag inte lärde mig C++ förrän senare. Jag har ju oxå jobbat med programmering av inbyggda system i 10 år nu.

Det är ju just strukturering och abstraktion och sådant som är det viktiga när man programmerar, inte språket. Likaså har objektorientering egentligen inget med språket att göra, utan är just ett sätt att strukturera och abstrahera. Kristen Nygaard, som var en av de två uppfinnarna av objektorientering en gång i tiden, sade något tänktvärt på ett seminarium:
"Många företag skickar iväg sina Fortranprogrammerare på kurser i C++, och så kommer dessa hem och fortsätter programmera Fortran, fast i C++. Då är det bättre att skicka dem på en kurs i objektorienterad programmering så de kommer hem och fortsätter programmera Fortran, fast objektorienterat."
Du verkar ha insett det utan att ha hört honom.

Sedan är det naturligtvis så att det är lättare att skriva objektorienterad kod i språk som är designade för det, liksom det är lättare att programmera funktionellt i språk som är designade för det osv. Å andra sidan så är C++ inte egentligen ett objektorienterad språk ens enligt Stroustrup själv, utan han säger bara att det har stöd för objektorienterad programmering.

Kvasir skrev:Det är ju just strukturering och abstraktion och sådant som är det viktiga när man programmerar, inte språket. Likaså har objektorientering egentligen inget med språket att göra, utan är just ett sätt att strukturera och abstrahera.

Skillnaden ligger ju hur man tänker egentligen. Antingen tänker man i sekvenser som den typiska Fortran-programmmeraren (NTn) gör, eller så tänker man i egenskaper, metoder och händelser, vilket sammanfaller med objektorientering. Tyvärr så finns inte just händelser med i typiska objektorienterade språk, och inte heller process / realtidstänket, vilket är en klar brist.

Kvasir skrev:Kristen Nygaard, som var en av de två uppfinnarna av objektorientering en gång i tiden, sade något tänktvärt på ett seminarium:
"Många företag skickar iväg sina Fortranprogrammerare på kurser i C++, och så kommer dessa hem och fortsätter programmera Fortran, fast i C++. Då är det bättre att skicka dem på en kurs i objektorienterad programmering så de kommer hem och fortsätter programmera Fortran, fast objektorienterat."
Du verkar ha insett det utan att ha hört honom.

Just precis så är det. Kom att tänka på hur min föregångare gjorde när han skulle implementera "inkappsling". Han gjorde helt enkelt en Set / Get metod för varenda variabel istället. Sådant ser man tyvärr ganska ofta, men när man gör så har man missat något väsentligt. Man får ju inte ett objektorienterat system bara för att man definierar hundratals Get / Set metoder. Normalt sett tror jag man kan se en programmerares kompetens på objektorienterad programmering genom att studera antalet Get / Set metoder. Desto färre desto bättre.

Ett ännu mer häpnadsväckande förfarande jag oxå sett var när en programmerare skrev en metod som exporterade hela den interna strukturen. När man gör så har man verkligen inte fattat något alls.

Kvasir skrev:Sedan är det naturligtvis så att det är lättare att skriva objektorienterad kod i språk som är designade för det, liksom det är lättare att programmera funktionellt i språk som är designade för det osv.

I assembler kan vad som helst implementeras. Egentligen finns ännu mer flexibilitet i assembler än i C++. I C++ implementeras alltid objektet genom en extra parameter som innehåller en pekare till objektet. Virtuella metoder implementeras genom ett indirekt anrop. I assembler kan man naturligtvis implementera på samma sätt, t.ex. genom att allokera en selektor som man passerar i ett segmentregister mellan metoder. Virtuella metoder skapar man genom att definiera procedurer i denna selektor, antingen vid uppstart eller när som helst under körning oxå.

Ett annat sätt som ger bättre skydd & säkerhet är att använda en "handle" istället för en direkt referens till objektets data. Då blir det fullständigt omöjligt att manipulera ett objekts interna struktur. Just handles används oxå flitigt mellan applikationsprogram och operativsystem. Detta är att betrakta som ett objektorienterat koncept som dock C++ inte kan hantera.

Kvasir skrev:Å andra sidan så är C++ inte egentligen ett objektorienterad språk ens enligt Stroustrup själv, utan han säger bara att det har stöd för objektorienterad programmering.

Nä, precis, allt som kan göras i C kan i stort sett kompileras under C++ oxå.

I RDOS så finns ett C++ interface till alla funktioner. Minst 90% av dessa är inkapslade i klasser där själva klasspekaren är en handle. För att detta ska fungera så måste varje metod ha en liten assembler-snutt som gör nödvändiga konverteringar, laddar in parametrarna i register och anropar en "call-gate" till operativsystemet.

RDOS API är alltså egentligen definerad på registernivå, och inte med stack-frames som är normalt. Man kan tycka att det är en begränsning eftersom det inte finns mer än 6 generella register och 4 segmentregister. Detta är dock en finess, eftersom metoder / funktioner med flera än 6 parametrar normalt inte är väl genomtänkta.

Dessutom finns det inga parametrar som är definerade som strukturer. Sådana tenderar att missbrukas för att komma åt objekts interna data. Inte heller används uppräknade datatyper i gränssnitt. Dessa implementeras hellre med flera olika metoder eller flera diskreta variabler.

Hej!

Från hösten 1993 till våren 2006 läste jag data och multimedia på en folkhogskola. De två första åren läste jag data. Under det första året fick vi jobba mycket med GW Basic, och senare även QBasic.

Vi fick skriva kod som ritade upp en gubbe på skärmen. Vi fick göra en lastbil som åkte fram över skärmen. Vi gjorde ett enkelt program som adderade två tal som man skrivit in. Som slutprojekt gjorde vi ett program som skulle räkna ut kostnaden för att byta däck på bilen eller något liknande.

Jag minns att jag också laborerade med programmet och gjorde program där man fick upp en fråga på skärmen som man skulle svara rätt på, gjorde man rätt kom det ett meddelande om att man svarat rätt, annars kom det ett meddelande att man svarat fel. Sen kom nästa fråga.

Jag köpte en Dummies-bok till nåt Windows-baserat program och lyckades göra E-note (skriv in texten i programmet och skriv ut på skrivaren, tror inte det gick att spara ens), E-writer (skriv in texten, byt färg på bakgrunden, ändra teckenstorlek mellan 12, 18 och 24, spara texten och skriv ut texten) samt en enkel miniräknare.

Men sen dess har jag tröttnat. Programmering är svårt.

Hälsningar

Lilla Gumman

Lilla Gumman skrev:Från hösten 1993 till våren 2006 läste jag data och multimedia på en folkhogskola. De två första åren läste jag data. Under det första året fick vi jobba mycket med GW Basic, och senare även QBasic.

Körde Basic på min ZX81 / ZX Spektrum på 80-talet, men jag tröttnade snabbt på detta och började programmera allt i assembler istället. På den tiden fick man översätta till maskinkod manuellt. Minns fortfarande en del operationskoder för Z80 processorn än idag.

Lilla Gumman skrev:Vi fick skriva kod som ritade upp en gubbe på skärmen. Vi fick göra en lastbil som åkte fram över skärmen. Vi gjorde ett enkelt program som adderade två tal som man skrivit in. Som slutprojekt gjorde vi ett program som skulle räkna ut kostnaden för att byta däck på bilen eller något liknande.

Jag minns att jag också laborerade med programmet och gjorde program där man fick upp en fråga på skärmen som man skulle svara rätt på, gjorde man rätt kom det ett meddelande om att man svarat rätt, annars kom det ett meddelande att man svarat fel. Sen kom nästa fråga.

Jag köpte en Dummies-bok till nåt Windows-baserat program och lyckades göra E-note (skriv in texten i programmet och skriv ut på skrivaren, tror inte det gick att spara ens), E-writer (skriv in texten, byt färg på bakgrunden, ändra teckenstorlek mellan 12, 18 och 24, spara texten och skriv ut texten) samt en enkel miniräknare.

Men sen dess har jag tröttnat. Programmering är svårt.

Ovanstående låter inte direkt som något som jag skulle sett som en utmaning.

Jag vill göra det som ligger bakom som att skriva ut tecken direkt emot ett bildskärmskort, styra ett USB-chip direkt på hårdvarunivå eller något sådant.

Ett annat (unikt, eller nästan unikt) koncept i RDOS är att precis allting ifrån första instruktionen som bootloadern kör på något sätt kan debuggas. Detta utvecklades tidigt i RDOS.

Det allra första var "panic" funktionen som utifrån olika processor-fel som page-fault, protection fault osv. kunde dumpa registerinnehåll på skärmen och sedan låsa upp datorn så man kunde läsa. Just att sätta upp en miljö i protected mode i 386-processorn i real-mode (DOS läge) är bland det besvärligaste som finns. Nästan alltid resulterade detta i "tripple fault" som gjorde att datorn helt enkelt startade om.

Nästa funktion var processorsimulatorn som är en integrerad del av RDOS idag. Den kan simulera varenda instruktion i processorn, och som fristående simulator kan den simulera hela uppstartsprocessen och man kan enkel-stega igenom alltsammans. I RDOS används simulatorn till att hantera instruktioner som inte kan köras "på riktigt". Sådana är t.ex. att köra DOS-baserade program, att simulera BIOS-data arean för flera olika processer och virtualisera olika resurser som DOS har direkt åtkomst till. Mode-switchen på olika grafikkort är ett annat exempel. Denna körs genom BIOS och kräver omfattande virtualisering för att inte sabotera för RDOS.

Det finns oxå en integrerad debugger i RDOS. Denna kan användas för att enkelstega olika trådar i RDOS. Till skillnad från Windows och många andra debuggers så fryser inte RDOS debugger andra trådar / processer. När en tråd hamnar i debug-läge genom en breakpoint eller ett skyddsfel, så hamnar den i en speciell debuglista medan resten av systemet körs vidare. I denna integrerade debugger kan nästan allting i kärnan enkelstegas och olika funktioners uppförande kan verifieras. Detta använder jag hela tiden vid utveckling av ny kod. Det enda man egentligen inte kan debugga är scheduleringskoden och kod som körs innan första processen startar.

Detta är verkligen saker man saknar i såväl Windows som i Linux.

Helt klart storartat att skrivit ett eget operativsystem.
Annars har du inte bidragit med kod till något större projekt som .t.ex Linux kärnan eller är det roligare och köra på ett helt eget?

Angående C++ så tycker jag egentligen att det är jävla språk rent ut sagt, men det har vissa fördelar som ändå gör att jag har lärt mig tycka om det, för vissa ändamål. Precis som du säger så har det en massa brister ur rent objektorienteringssynvinkel, som att objekt inte egentligen är helt skyddade även om det finns protected classes. Å andra sidan ska man nog se både C och C++ som språk som i första hand ska användas när man har behov av effektiv och maskinnära programmering, och då kan man även behöva göra lite fula saker ibland, och det kan finnas behov att faktistk komma åt objekts inre struktur. Man ska nog se klasserna i C++ som ett stöd för att skriva snyggare och mera strukturerade program snarare än att skriva program med skyddade objekt. Sedan är det ju så att det nästan alltid går att komma runt skyddsmekanismer om man anstränger sig.

Sedan är syntaxen hopplös, vilket ju beror på arvet från och kompabiliteten med C, och t.o.m. Stroustrup själv raljerar över det i referensmanualen. Du känner förmodligen till historien bakom språket, men jag kan ju dra den ändå. Objektorienterad programmering uppfanns av Kristen Nygaard och en annan norrman, vars namn jag aldrig kommer ihåg, och de skapade Simula som en objektorienterad variant av Algol. Stroustrup "växte upp" i den traditionen, och jag tror att han även var med i Nygaards grupp några år. Sedan fick Stroustrup jobb på Bell Labs, och där var det C som gällde, basta! Han lyckades dock sälja in idén att utveckla ett nytt språk som var mera objektorienterat, förutsatt att det var kompatibelt med C. Därför var det tvunget att i princip bli C med tillägg. Jag kan väl tycka att det var ett historiskt misstag, men å andra sidan hade förmodligen de flesta som idag programmerar C++ fortfarande programmerat C annars, så man får väl se det som en framgång trots allt.

Torsdag skrev:Helt klart storartat att skrivit ett eget operativsystem.
Annars har du inte bidragit med kod till något större projekt som .t.ex Linux kärnan eller är det roligare och köra på ett helt eget?

Nej, jag är en ensamvarg. Dock kan jag idag Linux-kärnan och GCC-verktygen hyfsat bra efter att ha dels försökt porta GCC till RDOS och dels genom att jag tittat på olika drivrutiner i Linux när jag behövt dessa i RDOS och specar inte funnits tillgängliga.

Dr Livingstone, I presume?

Kvasir skrev:Angående C++ så tycker jag egentligen att det är jävla språk rent ut sagt, men det har vissa fördelar som ändå gör att jag har lärt mig tycka om det, för vissa ändamål. Precis som du säger så har det en massa brister ur rent objektorienteringssynvinkel, som att objekt inte egentligen är helt skyddade även om det finns protected classes.

Problemet är ju dels att man exporterar även protected delen av klassen och dels att någon som använder en klass överhuvudtaget behöver inkludera de interna variablerna i klassen. Detta leder till problem när man lägger koden i bibliotek eller DLL-filer.

KrigarSjäl skrev:Dr Livingstone, I presume?

RDOS är ett hobby-projekt, och jag gör bara roliga saker som hobby. Att läsa andras kod tillhör inte direkt mina favoritsysselsättningar, speciellt då inte de värsta spagettiprogrammerarnas kod som ibland syns i Linux.

Dessutom så har jag höga krav på det jag gör, och de medelmåttiga kärnor som Linux och Windows har är inget för mig.

Linux var ju också bara en hobby och nu ska ni använda rdos i seriösa bankterminaler.
tja man får ta och lära sig för att själv kunna avgöra vad som är bra kod.
Ännu kan jag bara grunderna i java.

rdos skrev:

Kvasir skrev:Angående C++ så tycker jag egentligen att det är jävla språk rent ut sagt, men det har vissa fördelar som ändå gör att jag har lärt mig tycka om det, för vissa ändamål. Precis som du säger så har det en massa brister ur rent objektorienteringssynvinkel, som att objekt inte egentligen är helt skyddade även om det finns protected classes.

Problemet är ju dels att man exporterar även protected delen av klassen och dels att någon som använder en klass överhuvudtaget behöver inkludera de interna variablerna i klassen. Detta leder till problem när man lägger koden i bibliotek eller DLL-filer.

Det går ju inte gömma variablerna i en klass eftersom de måste vara med i klassdeklarationen som måste inkluderas när man kompilerar. Det är ju en nackdel jämfört med vissa andra språk (t.ex. Adas generiska paket som inte ens handlade om objektorientering). Men det där hänger väl förmodligen återigen ihop med att effektivitet i både kod och kompilering är ett av huvudsyftena med C++.

Torsdag skrev:Linux var ju också bara en hobby och nu ska ni använda rdos i seriösa bankterminaler.

Inte i bankterminaler, men väl på tankstationer som tar bankkort. Det stämmer ju dessutom att Linux byggts upp av hobbyister, men det används allt oftare i sådana här applikationer oxå. Jag tror att Sagems säkerhetsmodul kör på en Linux-version, och det är den som vi ska använda för själva bankdelen.

Torsdag skrev:tja man får ta och lära sig för att själv kunna avgöra vad som är bra kod.

RDOS är superstabilt när man använder beprövade delar. Jag kollade just de terminaler med RDOS som vi sålde till GLC för en hel massa år sedan. En av dem har inte startats om sedan i oktober 2006. Därmed är den bättre än i stort sett alla de vanliga terminalerna.

Vi har testat Windows CE, och det är ett fuillständigt oanvändbart system som tar timmar att bygga på en modern dator och där modulhanteraren inte kan ge ledtrådar till vilka saker som hör ihop på ett bra sätt. Rena skiten skulle jag vilja säga. Dessutom så körde all kod som priviligerad i den version vi testade, vilket är fullständigt oacceptabelt. I den konfiguration jag lyckades bygga så funkade inget utan att man hade med en extra dator med utvecklingssystemet i [sic].

Är inte ett rdos ett betydligt mindre och kompakt OS, med mindre flexibilitet och finesser men samtidigt mera lämpligt för just realtidstillämpningar (än Linux alltså)? I många realtidstillämpningar varken vill eller bör man köra stora generella OS som Linux eller Windows, t.ex. för att styra bilmotorer.

Kvasir skrev:Är inte ett rdos ett betydligt mindre och kompakt OS, med mindre flexibilitet och finesser men samtidigt mera lämpligt för just realtidstillämpningar (än Linux alltså)? I många realtidstillämpningar varken vill eller bör man köra stora generella OS som Linux eller Windows, t.ex. för att styra bilmotorer.

Jo, det stämmer bra. Speciellt avbrottsthanteringen är anpassad för realtidsprestanda i RDOS. Detta gör att själva avbrottsrutinerna är mycket korta i RDOS. I Linux och Windows är de däremot omfattande och detta ger dåliga realtidsprestanda. Samtidigt så har Linux och Windows möjligen något bättre prestanda i t.ex. TCP/IP stacken genom att stora delar hanteras i avbrottsrutinen. I RDOS används istället en servertråd som avbrottsrutinen skickar en signal till.

Moduluppbyggnaden gör oxå att man inte behöver kompilera om något för att ändra sin konfiguration. Länkningen sker i runtime. I Windows & Linux måste man kompilera & länka kärnan. Så icke i RDOS. Allt styrs med en cfg-fil.

Misstänkte det. RealtidsOS är ju egentligen en helt annan typ av OS än vanliga, ur kravsynpunkt, och där finns väl betydligt mera konkurrens och ingen dominerande aktör som MS är på vanliga OS? Samtidigt misstänker jag att det finns mera utrymme för nischade produkter med vissa speciella egenskaper?

Jag kommer ihåg ett besök på ABB en gång, det var på Windows95-tiden. De hade fått för sig att använda win95 för processövervakning i något stort system, men det gick förstås inte. Det var så mycket minnesläckor att systemet kraschade och fick starta om då och då, och det var ju inte acceptabelt. Fattar inte hur de ens kunde komma på tanken att använda Windows ens från början.