Windows är ju en familj med lång historia.
Den rätt-trogna/e räknar Windows 3.0 som den första men det finns givetvis en Win 1 o 2 oxo.

Att påstå att Win 3.x hade riktiga (pre-emptive) trådar i kärnan är rätt vidlyftigt. Även win95/98 hade yild-threads och gissa om detta leder till lås-problem..
Först med Win NT kom pre-emptive threads och som bekant är Win NT's kärna helt nyskriven relativt Win 3.11 (f.ö. av hjärngänget bakom DEC WAX'en OS)
Med NT 4 började kärnan kunna hantera fler än en processor på ett bättre sätt än rent multiprocss/tasking-stöd, dvs trådar i kärnan.

Idag är det tveksamt om man kan säga att Windows är *ett* operativ. Oavsett vad MS kallar det i sin marknadsföring ör det rätt stor skillnad på en kärna som körs i deras mer kvalficerade server-konfigurationer och den som körs i Vista -home.
Och det är *väl känt* att MS servrar inte gör ett speciellt bra jobb på multi-kärne-system vilket säger en del om både deras multiprocess/tasking och deras trådmodell.

Det du anger som exempel "Den här datorn", IE och epostklienten." visar f.ö. enbart på brister i deras scheduler och ingenting om deras trådhantering.


"Nyligen" är ju ett relativt begrepp men jag anar ett slags snobbism i det du skriver. Linux trådmodell är väl så god som Win-whatever.
Det är ju ingen vits att släppa en Linux-kärna om den inte är bra men MS tänker inte så, de verkar tänka att det ser bra ut att kunna skriva i sina ads att det har en finess, hur bra den sedan fungerar verkar underordnat.

Det är också *väl känt* att i kvalificerade server-konfigurationer är Linux outstanding.

Din passus om Unix (och därför Linix) fork() är ju bara dumheter! Det är ett namn på ett syscall. I windows heter det ngt annat och när du har multitasking i ett realtidsoperativ (inte alla har det utan enbart multi-thread) så heter det återigen något annat. fork() +exec() är en tung, relativt threads, metod men mycket väl fungerande.
Motsvarande om din släng åt ioctl. Hur mycket har du skrivit mot en Unix/Linux-kärna?

Och till sist, du jämför Windows/Lunix med realtidsoperativ!
Det är ju litet som att jämföra färgen vindruvor och grapefrukt.

Windows och Linux' relatidsegenskaper är.. sparsmakade?
Inget konstigt med det! De är inte skrivna med realtidsrespons som designkriterium. Som konsekvens får du också att kernel-debugging inte
är lika lätt tillgängligt som när du jobbar med ett realtidsoperativ där du har ett minimal kärna och enbart de moduler du själv plockat in att ta hänsyn till.

Om du tar vilket som helst RealtidsOperativ, i ordets bemärkelse, och försöker få det att fungera bra som bas för det Linux och Windows är gjorda för, så får du jobba!!

lillmupp skrev:Windows är ju en familj med lång historia.
Den rätt-trogna/e räknar Windows 3.0 som den första men det finns givetvis en Win 1 o 2 oxo.

Jo, och så fanns MSDOS i en 6 versioner. De första versionerna av Windows var ju bara grafiska skal till DOS och inga egna operativsystem.
MSDOS är nog det värsta skräp som någonsin gjorts. Det var ju något Bill Gates knåpade ihop i sitt garage, typ.

lillmupp skrev:Att påstå att Win 3.x hade riktiga (pre-emptive) trådar i kärnan är rätt vidlyftigt. Även win95/98 hade yild-threads och gissa om detta leder till lås-problem..

Det stämmer nog dessvärre.

lillmupp skrev:Det är ju ingen vits att släppa en Linux-kärna om den inte är bra men MS tänker inte så, de verkar tänka att det ser bra ut att kunna skriva i sina ads att det har en finess, hur bra den sedan fungerar verkar underordnat.

Linux har Unix-arvet kring signaler och processer som ett slags bagage. Det är säkert därför som det tog så pass lång tid innan man fick till riktiga trådar. I Windows fanns ju ingen multitasking alls (DOS-arvet) så då kunde man designa helt från skratch, dessutom med hjälp av folk från DEC/VMS.

lillmupp skrev:Din passus om Unix (och därför Linix) fork() är ju bara dumheter! Det är ett namn på ett syscall. I windows heter det ngt annat och när du har multitasking i ett realtidsoperativ (inte alla har det utan enbart multi-thread) så heter det återigen något annat. fork() +exec() är en tung, relativt threads, metod men mycket väl fungerande.

Nej, fork är inte namnet på en syscall. Det är namnet på en idiotisk metod att skapa nya processer / trådar som bygger på kloning av miljön man kör i. Det vet jag mycket väl efter att ha provat att portera LIBC för Unix till RDOS.

lillmupp skrev:Motsvarande om din släng åt ioctl. Hur mycket har du skrivit mot en Unix/Linux-kärna?

Inget alls, men jag har studerat diverse drivrutiner när hårdvaruspecarna för chippen varit svåra att få tag i. IOCTL är en primitiv metod att komma åt hårdvara på, som har sina rötter i tidigare UNIX, MSDOS och CP/M-system. Sådant skräp borde inte finnas i moderna operativsystem.

lillmupp skrev:Windows och Linux' relatidsegenskaper är.. sparsmakade?
Inget konstigt med det! De är inte skrivna med realtidsrespons som designkriterium. Som konsekvens får du också att kernel-debugging inte
är lika lätt tillgängligt som när du jobbar med ett realtidsoperativ där du har ett minimal kärna och enbart de moduler du själv plockat in att ta hänsyn till.

RDOS har inte en minimal kärna. Det har en vanlig monolitisk kärna, men designades med tanke på realtidsegenskaper, segmentskydd och optimala felsökningsmetoder. En av dessa designval var en inbyggd kernel-debugger. Skulle gått lika bra att bygga in i Windows och / eller Linux om man designat om multitaskingmodellen.

lillmupp skrev:Om du tar vilket som helst RealtidsOperativ, i ordets bemärkelse, och försöker få det att fungera bra som bas för det Linux och Windows är gjorda för, så får du jobba!!

RDOS är inte heller ett riktigt realtidsoperativ i ordets rätta bemärkelse, däremot så har det mycket bättre inbyggt stöd för felsökning och konfiguration av inbyggda system än vad Windows och / eller Linux har. Dessutom så kan inga blå skärmar eller felmeddelanden från kärnan hamna på skärmen när det körs som ett inbyggt system, helt enkelt för att något sådant inte finns implementerat. Istället kan man installera en watchdog-device som startar om datorn om olika slags skyddsfel inträffar. Detta i sin tur är direkt kopplat till debug-designen.

Du pratar gärna om rdos som om det vore resultat av gudomlig inspiration..
Har du möjligen hackat ihop det själv?

Din klagan på andra system luktar litet "self-promotion"

lillmupp skrev:Du pratar gärna om rdos som om det vore resultat av gudomlig inspiration..

Har du möjligen hackat ihop det själv?

Nej, riktiga programmerare hackar inte ihop operativsystem. De designar dem utifrån sådant som är kasst i andra system. Hackning lämnar jag åt Linux och M$-folket.

Riktiga programmerare hackar visst! Att vara en "hacker" är att vara en dj-el på att skriva bra program, vilket innefattar god design med avseende på funktion, struktur och underhållsbarhet.

Tyvärr har denna ursprungliga betydelse förvanskats med den utspädning av kompetens som följde av 90-talets hysteri kring webben mm. Ett-åriga utbildningar som skulle skapa "programmerare" till industrin. Det man fick var hoper av folk som kudne skriva kod men det kan ju vilken 5-åring som helst, frågan är bara hur bra.

Jag förknippar hacking med dåliga program och snabba fixar. Möjligt att det inte var så till att börja med.

Du har säkert rätt om de ettåriga utbildningarna, och framförallt folk som lärt sig programmera med verktyg som Visual Basic och liknande.

En bra programmerare ska kunna skriva fristående klasser i C++ / C#, ska kunna namnge saker så andra kan förstå vad olika variabler / funktioner gör bara på namnet, ska kunna gå in och modifera sin egen källkod efter 10 år och fortfarande förstå vad den gör (även om den är skriven i assembler). En bra programmerare ska jobba objektorienterat oavsett vilket språk h*n använder (det går att jobba objektorienterat både i C och assembler). En bra programmerare ska oxå förstå realtidsprogrammering / trådar och synkronisering. Jag tror det är väldigt få av de som gått ettårig datautbildning som har sådan kompetens.

Närmare beskrivning av vad som skiljer bra / dålig / aspig / neurotypisk programmering: http://www.rdos.net/eng/it.htm

@rdos
Din sida har en poäng. Även om jag håller mig till PLC.

Läraren:
- Ett tips är ju att börja med huvudsekvensen och arbeta er neråt, glöm inte ha papper och penna, anteckna allt ni gör.... etc. Det blir lätt att hålla i trådarna då.
Jag:
- Nej, jag reflekterar lite kort om funktionen. Bökar ihop nåt provisoriskt. Snyggar till det sen. Sist skapar jag en fin "normal" sekvens, komplett med minnesbitar... osv. Papper, penna, planera, rigid struktur förvirrar mig och snor viktig tankeenergi.

Appråpå anteckna. För mig är det skitjobbigt att få ner realtidstankverksamhet på ett papper. Ett papper är inte alls lika flexibelt som tanken. Min tanke och problemlösning jobbar på tok för flyktigt för att hinna anteckan.
Dvs totalt tvärtom de flesta, som antagligen ser pappret som en hjälp att kunna hålla fokus på uppgiften.

imperativ skrev:Läraren:
- Ett tips är ju att börja med huvudsekvensen och arbeta er neråt, glöm inte ha papper och penna, anteckna allt ni gör.... etc. Det blir lätt att hålla i trådarna då.
Jag:
- Nej, jag reflekterar lite kort om funktionen. Bökar ihop nåt provisoriskt. Snyggar till det sen. Sist skapar jag en fin "normal" sekvens, komplett med minnesbitar... osv. Papper, penna, planera, rigid struktur förvirrar mig och snor viktig tankeenergi.

Jepp, samma här. Jag skapar strukturen i skallen först innan jag börjar programmera. Att skriva ned den på papper ger oftast ingenting, däremot kan det ibland vara bra att diskutera lösningar med andra. Jag har fortfarande kvar det mesta av hela RDOS struktur i skallen trots att delar är 10-15 år gamla (hela projektet är 21 år gammalt). Jag känner neurotyper som skrivit ned massor av anteckningar men som ändå måste fråga om deltaljer i en konstruktion. Oftast vet de inte själva var de har sina anteckningar eller så kan de inte tyda dem efter några år.

imperativ skrev:Appråpå anteckna. För mig är det skitjobbigt att få ner realtidstankverksamhet på ett papper. Ett papper är inte alls lika flexibelt som tanken. Min tanke och problemlösning jobbar på tok för flyktigt för att hinna anteckan.

Samma här. Att anteckna och verbalisera snor tankeenergi. Speciellt illa om man går på föreläsningar. Då var jag tvungen att välja mellan att lära mig nåt eller anteckna. Valet föll på att lära sig något.

imperativ skrev:Dvs totalt tvärtom de flesta, som antagligen ser pappret som en hjälp att kunna hålla fokus på uppgiften.

Ungefär som modern projektstyrning. Sådant är inget för mig. Kanske det funkar för neurotyper, men för mig är dokumentskrivande enbart en belastning.

Modern projektstyrning är väldigt användbart. Även för aspieprogrammeraren. Risken att göra "tokfel" minskas drastiskt. Risken för tokiga missförstånd som kan äventyra ett helt projekt minskas drastiskt.

Projektstyrning är helt ok tycker jag... så länge den inte går in på hur jag ska skapa den efterfrågade funktionen.

Några saker som är återkommande med just PLC-programmering är att programmet ska vara uppbyggt på sådant vis att:
- det är lättöverskådligt. (ingår hundratals parametrar i denna punkt)
- det är lätt att felsöka.
- kommentarer! ALLT ska förklaras in i minsta detalj.
- variabelnamnen ska vara lättförstådda.
- spegla alla skarpa variabler till minnesbitar.
- använd inga skarpa variabler i programmet.

Hmmm..
Verkar som vi tre "ser" program i mentala bilder.. Är detta "aspigt" eller är det så att alla program/systemutvecklare gör detta?
"Ser" f.ö. alla algoritmer, system, ekvationer, logiksystem som ett slags "bilder" som "relaterar" till varandra.
Och när detta sedan blir kod får jag ibland kommentaren att den är "vacker".. Hmmm

Men visst ska jag erkänna att jag ibland kladdar litet på ett papper för att få en bra bild att gå vidare med..

Om projektstyrning: Jag är stark anhängare av SCRUM/XP. Minimum av papper, maximal produktivitet med optimal funktion givet kalendertid och bemanning.
Fungerar oavsett programmeringsspråk eller ens abstraktionsmodell även om objektorientering ger bäst effekt/utfall. Således även PLC.

lillmupp skrev:Hmmm..
Verkar som vi tre "ser" program i mentala bilder.. Är detta "aspigt" eller är det så att alla program/systemutvecklare gör detta?
"Ser" f.ö. alla algoritmer, system, ekvationer, logiksystem som ett slags "bilder" som "relaterar" till varandra.
Och när detta sedan blir kod får jag ibland kommentaren att den är "vacker".. Hmmm

PLC-programmering är underbart. För där kan man i ladder och funktionsblock verkligen visualisera runt i tanken då hela programmeringen är grafisk.
Sekvensprogrammering är också grafisk, dock är den väldigt översiktlig och det är ofta fruktansvärt bökigt att göra ändringar mitt i sekvensen.

lillmupp skrev:Hmmm..
Verkar som vi tre "ser" program i mentala bilder..

Njääe, jag "ser" inte programkod, snarare att jag hör den då. Jag tror att min primära domän är hörseln. I vilket fall som helst så tänker jag varken i ord eller bilder.

I veckan satt jag och programmerade mitt allra första riktiga PLC-program. Dock vet jag inte om det funkar ännu, då ingen maskin är färdigmonterad.

Intressant, fick en uppgift som gick ut på att "uppfinna hjulet en gång till". Så det fanns ett "facit" på programmet. Men till min otroliga förvåning:
- Det gamla programmet var ca 150 bytes större än mitt.
- Tack vare mitt användande av minnesbitar blev mitt program mer flexibelt. (Speglade utgångar gör att man kan adressera speglingen som "fejkutgång" hur många ggr som helst iom att en riktig utgång bara går adressera EN gång i programmet. )
- Jag kan inte påstå att mitt var "lättförståeligt", å andra sidan så kan jag påstå att det var ett rent helvete att böka sig in i det programmet som redan fanns.
- Gamla hade 6 subrutiner, 1 huvudrutin. Mitt hade 8 subrutiner, 1 huvudrutin. Vrf? För att jag delade in programmet i övergripande funktioner (ex. felkod, manuell styrning) och objekt. I det gamla var det 100% objektifiering (felkoder och manuell styrning låg inte separat).
- Jag har sett brister i min programmering. T. ex så kunde jag ha tagit alla ingångar som krävs för att starta maskinen och spegla till en minnesbit man kan kalla "Start". Samma sak med "Stopp". Denna programkod blir en egen subrutin kallad "Start/stopp" (ska nog bli standard i mina program framöver). ^^

imperativ skrev: - Det gamla programmet var ca 150 bytes större än mitt.

Alltså, 492 bytes mot 344 bytes.
(betyder bara att mitt program exekveras ca 10-15 millisekunder snabbare eller nåt sånt. gör eg ingen skillnad alls då PLCns cykeltid är 50 millisekunder.)

imperativ skrev:

imperativ skrev: - Det gamla programmet var ca 150 bytes större än mitt.

Alltså, 492 bytes mot 344 bytes.
(betyder bara att mitt program exekveras ca 10-15 millisekunder snabbare eller nåt sånt. gör eg ingen skillnad alls då PLCns cykeltid är 50 millisekunder.)

Vad är det för PLC du arbeter med?

På jobbet använder vi Siemens och miljön S7.
Cykeltiden bestäms där av programmets komplexitet. Då blir det väldigt intressant att kunna minska cykeltid om tillämpningen har specifika krav.

lillmupp skrev:

imperativ skrev:

imperativ skrev: - Det gamla programmet var ca 150 bytes större än mitt.

Alltså, 492 bytes mot 344 bytes.
(betyder bara att mitt program exekveras ca 10-15 millisekunder snabbare eller nåt sånt. gör eg ingen skillnad alls då PLCns cykeltid är 50 millisekunder.)

Vad är det för PLC du arbeter med?

På jobbet använder vi Siemens och miljön S7.
Cykeltiden bestäms där av programmets komplexitet. Då blir det väldigt intressant att kunna minska cykeltid om tillämpningen har specifika krav.

I mitt fall här var det en Siemens S7-224 CPU. Programmet är nåt som liknar S7, skräddarsytt för just S7-200serien.

Tydliggör:
En PLCs cykeltid är tiden mellan varje exekvering av programmet.
Cykeltiden 100ms innebär att programmet i PLCn körs var 100ms, att programmet kanske tar 23ms att exekvera påverkar inte. 77 av 100ms så gör PLCn ingenting.

imperativ skrev:

lillmupp skrev:

imperativ skrev:[quote="imperativ"]
- Det gamla programmet var ca 150 bytes större än mitt.

Alltså, 492 bytes mot 344 bytes.
(betyder bara att mitt program exekveras ca 10-15 millisekunder snabbare eller nåt sånt. gör eg ingen skillnad alls då PLCns cykeltid är 50 millisekunder.)

Vad är det för PLC du arbeter med?

På jobbet använder vi Siemens och miljön S7.
Cykeltiden bestäms där av programmets komplexitet. Då blir det väldigt intressant att kunna minska cykeltid om tillämpningen har specifika krav.

I mitt fall här var det en Siemens S7-224 CPU. Programmet är nåt som liknar S7, skräddarsytt för just S7-200serien.

Tydliggör:
En PLCs cykeltid är tiden mellan varje exekvering av programmet.
Cykeltiden 100ms innebär att programmet i PLCn körs var 100ms, att programmet kanske tar 23ms att exekvera påverkar inte. 77 av 100ms så gör PLCn ingenting.[/quote]

Fyller på med tydliggörande då:
Cykeltiden kan ju väljas. Fixerad, som i ditt exempel, eller efter vad programmet klarar.
Fixerad cykeltid är lämpligt i hård realtids-tillämpning, kodstyrd kan man ju köra om det inte gör något att exekveringen går runt.
Just våra tillämpningar medger "fri fart".

rdos skrev:
Samma här. Att anteckna och verbalisera snor tankeenergi. Speciellt illa om man går på föreläsningar. Då var jag tvungen att välja mellan att lära mig nåt eller anteckna. Valet föll på att lära sig något.

Känns igen... Att anteckna förvirrar bara, och hindrar "auto-memoriseringen".

Angående kärn-debuggers, har du hangman i din ddb rdos?

http://www.openbsd.org/cgi-bin/man.cgi? ... ormat=html

Naturligtvis är fork() ett syscall, nummer 2 faktiskt.

Någon nämnde att MacOS(X) är byggd på "nyare" teknik än windows, tveksamt!
Windows är ju en slags Microkernel-hybrid, alltså av nyare snitt än den UNIX/monolitiska modellen. OSX är väl ungefär samma sak, alltså microkernel+drivisar+POSIX...
Alla har dom kompromisser och ineffektiva metoder som man får 'deala' med.
Det är intressant att höra om vad ni har gjort och vad ni arbetar med.