Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 226 reacties
Submitter: ik.ben.iemand

Samen met een Amerikaans museum heeft Microsoft de broncode van MS-DOS 1.1 en 2.0 openbaar gemaakt, evenals die van de eerste Word-versie voor Windows. Daardoor moeten toekomstige generaties 'de wortels van de pc' kunnen begrijpen.

De broncode van de Microsoft-software is te downloaden vanaf de website van het Computer History Museum. Hoewel de broncode openbaar wordt gemaakt, mag die niet onbeperkt worden gebruikt voor het maken van afgeleide werken en houdt Microsoft het auteursrecht erop. Eerder maakte het Computer History Museum al de broncode van onder meer DOS voor de Apple II, QuickDraw en MacPaint en Adobe Photoshop openbaar.

De broncode van 1.1 bestaat uit zeven bestanden met assembly-code en gaat gepaard met een e-mail van Tim Paterson, de oorspronkelijke auteur van MS-DOS. De broncode van 2.0 bestaat uit 118 bestanden, die grotendeels uit assembly-code bestaat, evenals de nodige documentatie.  Het zip-bestand met de broncode van Word for Windows bevat vooral C- en C++-code.

Een medewerker van het museum beschikte al over de broncode van MS-DOS 2.0, maar had de toestemming van Microsoft nodig om de broncode te publiceren. Het vinden van de broncode van MS-DOS 1.1 was moeilijker: Microsoft beschikte daar zelf ook niet over. Uiteindelijk ontving het museum de broncode van Paterson. Microsoft beschikte wel nog over de broncode van de eerste Word for Windows-versie.

De eerste versie van DOS werd niet eens door Microsoft zelf ontwikkeld, maar werd in licentie genomen van Seattle Computer Products, een ander technologiebedrijf uit dezelfde regio als Microsoft. Versie 1.1 ondersteunde enkel floppy's; versie 2.0, die een jaar later uitkwam, introduceerde ondersteuning voor folders en harde schijven.

Word for Windows was niet de eerste Word-versie: die kwam al uit in 1983 voor MS-DOS. Desondanks werd die Word-versie niet echt populair. Pas met de introductie van Word for Windows wist Microsoft marktleider WordPerfect van de troon te stoten.

DOS

Moderatie-faq Wijzig weergave

Reacties (226)

Alleen jammer dat de afbeelding onder het artikel een "screenshot" toont van PC-DOS en niet MS-DOS. Al zijn beide natuurlijk ontwikkeld door Microsoft. ;)
Hehe, dat was lang scrollen voordat iemand dit ook opmerkt.
Hoewel de verschillen erg klein waren, heeft natuurlijk MS-Dos uiteindelijk geschiedenis geschreven en is PC-Dos roemloos ten onder gegaan.
Dat een screenshot van PC-Dos hier wordt gebruikt is dan ook wel een soort stille wraak uit het verleden.
"Bad command or file name" en "Abort, Retry, Ignore, Fail?" - lang niet meer gezien. Doet me denken aan de eerste keer dat ik in aanraking kwam met MS-DOS en ik alleen maar had gehoord van het "dir" en "cd" commando en niet wist dat alleen .EXE of .COM-programma's uitvoerbaar zijn. Maar als je die paar commando's doorhad kon je al prima uit de voeten met MS-DOS en ondertussen keken mensen je aan alsof je geheimtaal intypte en geweldige dingen voor elkaar kreeg. Terugkijkend daarop was het wel erg simpel allemaal. Misschien dat ik daarom tegenwoordig de Linux-shell nog zo graag mag.

[Reactie gewijzigd door Tjeerd op 26 maart 2014 11:43]

"C:\Widnows" No such file or directory ;)

En dan de slash parameters, wat een magie was dat. Bijna leuk als een tooltje nog het cmd prompt gebruikt tegenwoordig, of je een bat'je in elkaar mag knutselen. Al is de VGA charme op een LCD scherm wel verloren gegaan, ga het commandoprompt nooit meer scherp zien op fullscreen, geen native resolutie van 't paneel...
Ik vraag me serieus af (als 37-jarige) hoeveel mensen nog Assembly leren en kennen.
(serieuze vraag, geen flame of zo.)

Ik weet nog dat ik dat machtig mooi maar heel moeilijk vond.
En met al die hogere talen tegenwoordig, lijkt het mij dat veel kids er niet veel in zien, en er niet veel van begrijpen.

Mooi initiatief. Voor oldies zoals "wij". ;)

Edit: Zoveel mooie reacties op mijn reactie/vraag, en toch is die reactie/vraag van mij off topic. LMAO!

[Reactie gewijzigd door HMC op 26 maart 2014 08:36]

MASM, TASM, DEBUG.COM. Van een aantal producten heb ik nog steeds de originele manuals en floppies, en soms de dozen.

Vergis je niet hoeveel er in de embedded hoek gebeurd en dat daar nog steeds veel kennis van assembly voor nodig is.

Bovendien is het heel leerzaam om met extreem weinig middelen iets te kunnen produceren. Het werpt je terug op de basisbeginselen, en brengen een ander soort creativiteit naar boven dan wat je met meer "luxe" middelen aan creativiteit kunt leren.
embedded is voor 99% dus C tegenwoordig.
Assembler is nog steeds nuttig ook in die hoek overigens.

Veel van de embedded software wordt natuurlijk gebouwd in India. Bijna geheel en exclusief in C daar.

Natuurlijk staat India met name bekend om de vele bedrijfjes die je daar kunt inhuren voor letterlijk 2.50 dollar per uur (inclusief management overhead en rond de 1 dollar per uur voor wat wij ZZP-ers zouden noemen) voor JAVA en C# werk, maar de C en C++ sector daar zijn ook erg groot :)

Wat gek is, is toch de focus in Nederland op iets onnozels als Java als het gaat om systeemprogrammeringen. Natuurlijk nooit veilig te krijgen, want het wordt ontwikkeld en actief bijgehouden in India. Dit waar toch veel kritieke systemen met java worden ontwikkeld in de Benelux.

Daarentegen in USA is de hele overheid gefocussed op C++ (en dus ook alles met N*SA) met name en kom je daar zonder C++ kennis niet binnen.

Den Haag mag wel weer eens wakker geschud worden met hoeveel opleidingen er alleen java gegeven wordt of C#, terwijl die markt erg klein is in Nederland. De meeste vacatures zijn semi-overheid namelijk en tenzij je daarin dan les gaat geven, is dat geen vetpot voor de overgrote meerderheid (een kleine minderheid die ergens binnen heeft weten te geraken is wel enorm binnen).
Wie heeft er niet de MS-DOS Encyclopedia van Ray Duncan
Zoiets als programmeren op een ZX81 met 1KB geheugen? Dan leer je wel compact te programmeren! :-)
Precies. Zelfs een Raspberry Pi of een Arduino is eigenlijk onmetelijke luxe! (wordt vast als off-topic weggemod <g>)
Zelf doe ik een opleiding Embedded systems. En ik kan je vertellen dat wij een half jaar assembly hebben gehad. Dit hebben wij gehad juist om die reden die jij aangeeft. Het doel was begrijpen wat de compiler voor code maakt. Dit omdat je daar met talen als C/C++ helemaal geen benul van hebt.
Het is inderdaad wel zo dat je het niet gaat gebruiken in een project. Maar de basic assembly is nog wel te begrijpen. En dat is soms nog wel erg handig om te kijken of de optimalisaties die jij in C doet ook echt optimalisaties in assembly zijn.
Ok, dank voor dat antwoord.
Je kan in C natuurlijk naar ASM mode gaan.
Het blijft "het dichtst bij de hardware", zelfs via een C compiler.
Maar ik moet zeggen, ik ben er al een aantal jaartjes uit.
Ik vond dit slechts een interessante vraag.
Ik mis die tijden wel. Zit nu in hele andere beroepsgroep, en hobby proggen (en verwante onderzoeken) ben ik tegenwoordig te lui voor. ;)
Ik heb voor verschillende project werk/afstuderen ÚÚk met Assembly moeten werken omdat C simpelweg te traag was voor wat het moest doen. (OmniVision 'telefoon' camera). Ik moest in 11 instructies poort lezen, And+bitshiften (alleen upper nibble interressant), deze moest vervolgens uit een LUT halen of het een interessante kleur was en met deze true/false moest er een RLE aangepast worden. per pixel (R, G en B) (kreeg bayer patroon binnen).

Ik kan je vertellen, dat kan niet met C. Net zoals het volgende: (microchip 16bit microcontrollers)

repeat 128
move.b [wr0++] [wr1++]

is het zelfde als:

for i = 0, i < 128, i++
dst[i] = src[i]

Alleen dan een heel stuk sneller
Als jij een fatsoenlijke compiler/c library gebruikt en ipv de loop uitschrijven memcpy gebruikt dan wil ik wedden dat de C versie net zo snel is.

De dingen die jij noemt hier zijn bijna 1 op 1 te vertalen naar C instructies
van Assembly naar C wel, maar niet terug. Zoals ik al in mijn tekst meld ging dit om de microchip compiler voor 16-bit PICs.

De code die gegenereerd werd (met optimalisaties!) bevatte meerdere compares voor bijv. die for-loop. Daarbij had ik uiteraard ook gekeken naar memcpy, wederom, die hielt een extra tellertje bij (gewone index) en de gegenereerde assembly was +/- alsvolgt:

begin:
mov 'src' -> wreg
move wreg -> 'dst'
inc srcptr
inc dstptr
inc index
cmp index
branchIfZero
goto begin
klaar.

Zoals gezegd, met optimalisaties aan. dan is die repeat 128, mov[][] gewoon een heel stuk sneller :-)
Als de default memcpy niet de instructie genereert die jij daar gebruikt, is er iets aan de hand waardoor dat niet kan bijvoorbeeld doordat er een aparte ASM instructie gebruikt moet worden voor RAM<->CODE en RAM<->RAM. Het kan zijn dat er door de compilerbouwer een instrinsic gemaakt is voor die situatie, maar zo niet dan zit er idd niets anders op dan asm te gaan pielen.
Een andere optie is om een fatsoenlijke MCU te pakken die dit soort beperkingen niet heeft, de PIC16 is wel behoorlijk 2000 als ik eerlijk moet zijn.
Nee, niet de PIC16, de 16-Bit pics ;-)

PIC16 is 'maar' een 8-bits processor. Ik had een deftige dsPIC33FJ128GP802, 40MIPS (80mHz), is wat anders tegenover de 1-4MIPS van de PIC16 reeks :-)
Alleen dan een heel stuk sneller
Weet je dat zeker? Vroeger schreef ik nog wel stukken code in assembly, om performance redenen, maar met de hedendaagse optimizers heeft dat nauwelijks zin meer.
Jouw stuk code is niet zo ingewikkeld dat ik denk dat een goede C compiler tragere machine code aflevert.
Weet je dat zeker? Een beetje C compiler zet dat simpele lusje om in precies dezelfde assembly en is dus precies even snel. Maar als je 128 bytes wil kopiŽren is beide natuurlijk niet erg slim. Dan zou je in C juist memcpy gebruiken zodat de compiler voor een "block transfer" instructie kan kiezen. Net wat je eigenlijk in assembly zou kiezen ipv een lusje. Tegenwoordig zijn er nog maar weinig echte assembly specialisten, de meeste werken in de compilerbouw.
Ik mis die tijden ook enorm. Ik ben begonnen met programmeren op mijn 6e levensjaar; ik ben nu 36 jaar. In de jaren 90 was de computerhardware voor mij nog bevattelijk. Ik zat on-top of de technologie zeg maar en kon feitelijk met 1 of 2 personen ontwikkelen wat ik wilde - of dat nu in assembler, C of Pascal was. Nu, tegenwoordig, is de hardware dusdanig complex geworden dat het me soms verwondert dat men uberhaupt nog werkende software kan ontwikkelen (let wel: gebruikmakende van en geoptimaliseerd voor de gespecialiseerde hardware). Ik heb tegenwoordig constant het gevoel dat het geen nut heeft wat ik doe; mijn product zal ten alle tijden onderschikt en pre-gedateerd zijn aan grote bedrijven, die bakken aan geld en in-depth techsheets hebben. Om nog maar niet te spreken van een leger aan programmeurs. Het is gewoon niet meer te doen om te competen; uitzonderingen daargelaten natuurlijk.

[Reactie gewijzigd door CoreIT op 26 maart 2014 09:22]

Sommigen beweren zelfs dat dat een van de redenen is dat een moderne PC net zo lang doet over het opstarten als de eerste MS-DOS PC.
Zelf heb ik in de 80er jaren ook n og met Assembly gewerkt. Was lekker snel.
Maar C en C++ worden echt nog veel gebruikt tegenwoordig.
Sterker nog , een gemiddelde MSDOS pc of for that matter een home computer uit de jaren 80 en 90 was sneller opgestart dan de gemiddelde pc nu.

Misschien handig om deze vrijgegen broncode te gebruiken voor lesdoeleinden ed :)

[Reactie gewijzigd door Metro2002 op 26 maart 2014 10:20]

Inderdaad. De Acorn Archimedes (eind jaren '80) startte in luttele secondes op en dat was met volledige WIMP GUI. De reden hier is eveneens dat het besturingssysteem, RISC OS, geheel was geschreven in ARM Assembly.

Bijzonder indrukwekkende machines, zeker in terugblik.
Voor lesdoeleinden kan je beter Minix gebruiken denk ik.

Uit Wikipedia:
MINIX is a Unix-like computer operating system based on a microkernel architecture created by Andrew S. Tanenbaum for educational purposes; MINIX also inspired the creation of the Linux kernel.
Hoewel met moderne windows varianten het beter is, rond winME was een windows bak 10x trager met opstarten dan een DOS doos..
Ik heb Assembly nog kort gehad op de uni bij Elektrotechniek (zo'n 12 jaar geleden :S). Denk niet dat je het nog op veel andere opleidingen krijgt. Vraag me af hoeveel de IT opleidingen het krijgen.
op de IT opleiding die ik jaren geleden probeerde te volgen kregen we pascal en cobol. ik hoop dat dat inmiddels verbeterd is. ;)
Wat is er mis met Cobol? Ik zie nog steeds vacatures voor cobol-ontwikkelaars voorbijkomen, dus het is juist goed dat die taal nog onderwezen wordt.
En pascal... ach Delphi wordt nog wel gebruikt (toch?).
Wat is er mis met Cobol? Ik zie nog steeds vacatures voor cobol-ontwikkelaars voorbijkomen, dus het is juist goed dat die taal nog onderwezen wordt.
En pascal... ach Delphi wordt nog wel gebruikt (toch?).
Het had totaal geen raakvlak met de vraag uit de markt. Die was op dat moment voornamelijk C, C++ en Java. Mensen uit de bovenbouw konden met geen mogelijkheid stageplekken vinden, omdat bedrijven niets aan de mensen hadden, want ze moesten alles nog leren. Cobol is een specialisatie, net zoals Fortran, niet iets wat je op MBO zou moeten doceren als 'basis'. :) (en dat was maar een kleine greep uit de voorbeelden, wij kregen les op ms-dos machines met novell, terwijl de hele markt al op NT 4.0 en windows 95 zat op dat moment.)

Niets slechts over cobol hoor, mensen kunnen er een hele goeie boterham in verdienen, omdat er maar heel weinig mensen zijn die er mee kunnen werken. Het is een niche stuk van de sector (moeten er zijn), maar dat maakt het niet bijzonder geschikt als fundering voor je loopbaan.

[Reactie gewijzigd door arjankoole op 26 maart 2014 10:01]

het is zeker nice, maar omdat cobol programeurs een uitstervend ras zijn is er zeker werk in te vinden.
Zo weet ik dat Oracle nog steeds heel veel cobol gebruikt voor 1 van hun payroll en financials systemen..
Wat is er mis met Cobol?
Het kent geen dynamisch geheugen gebruik.
Dat heeft zowel positief als negatief kanten. Memory mangement is bijvoorbeeld geen issue in COBOL.
COBOL is verder enorm geschikt voor verwerking van sequentiele en indexed gegevensbestanden (daarom nog steeds in gebruik bij banken, verzekeringsmaatschappijnen en overheden die gigantisch veel gegevens verwerken) maar je moet er bijvoorbeeld geen media (foto, audio en video) mee gaan verwerken.
Ik ging net zeggen dat ik nog een paar COBOL programeurs ken, die zowat enkel nog met Mainframes van hele grote banken enzo bezig zijn.
Bij mijn vorige werkgever werd in Delphi geprogrammeerd, dus ja, Delphi wordt zeker nog gebruikt.
Ik gebruik het zelden maar ken het nog wel.

Voor wie er eens mee wil spelen is Flat Assembler een goed startpunt.

Link: flatassembler.net
En deze man is er iets in doorgeschoten:
http://www.menuetos.net/

Een heel OS geschreven in Assembly, van USB 2.0 support, tot aan MP3/AVI/"Paint"/DVB-T en een heuze browser. Waarschijnlijk heeft die persoon veel vrije tijd, wel props voor wat hij heeft gedaan. Heel OS passend op een diskette.

Trouwens wel leuk om te zien dat MSDos ook maar is geschreven door mensen, (Stukje ALLOC.ASM)
arena_free_next:
CMP BYTE PTR DS:[DI],arena_signature_end
; end of road, Jack?
retz ; never come back no more
CALL arena_next ; next item in ES/AX carry set if trash""

[Reactie gewijzigd door XiniX88 op 26 maart 2014 09:09]

Ja wilde hier ook nog eens mijn eigen OS opzetten, als Xen niet bevalt.

Maar mocht dat project ooit doorgaan, dan dat gaat in C worden dan voornamelijk en C++ voor de interface natuurlijk.

Andere keuzes heb je niet voor snelheid.

De windows kernel is in assembler overigens en linux kernel is geheel C natuurlijk.

Het is interessant om te zien hoe meer dan 3 decennia later nog steeds alleen C geschikt is voor iets als een besturingssysteem.

Grappig overigens dat Linus tegenwoordig in USA zit, want men lacht je daar meestal uit als je niet in C++ programmeert. Vooral de (semi-) overheid daar is exclusief bezig in C++.
De windows kernel is in assembler overigens
Ik denk het niet. Windows NT draaide historisch op verschillende platforms (Mips, X86, Alpha, ...), en nu heb je Arm and x86. Dus er zal echt wel een meer porteerbare taal zijn gebruikt.
linux kernel is geheel C natuurlijk
Met hier en daar wat assembly ....
Ik studeer momenteel ingenieur computerwetenschappen aan de universiteit van Gent. Daar zien wij assembly nog steeds. Niet als taal om full time in te programmeren, maar gelinkt aan een vak over hoe en processor ineenzit. Daarnaast komt het ook terug bij het low-level debuggen van software. Het is inderdaad mooi maar zeer moeilijk en onbegrijpbaar op zicht.
Assembly had ik 4 jaar geleden nog op Hogeschool Brussel IT. Was onderdeel van OS'en en CPU's
Tegenwoordig is het ook vaak niet echt nodig meer. Maar als je met microcontrollers programmeert is elke kloktik nog erg waardevol. Hiervoor kan het erg lucratief zijn om direct in assembler codes de hardware aan te spreken en aardig wat snelheidswinst uit het project te persen.
Hangt natuurlijk af van je vakgebied. Voor veiligheidsspecialisten is het juist wel weer goed om dit soort kennis te hebben.

"Vroeger" werden virussen nog veel geschreven in C of assembly. Er is op textfiles.com behoorlijk wat documentatie te vinden: http://textfiles.com/virus/
10 jaar geleden (ja ik weet het, niet heel recent, zeker in IT termen, maar er waren toen ook al genoeg hogere talen) werd het in elk geval op de TU Delft nog wel gegeven als onderdeel van de technische informatica studie. Geen idee hoe dat tegenwoordig is echter.
Nooit gezien :/ Wij kregen wel nog Oberon en dat was al een pest.
Oberon, is dat niet de OO variant van Modula-2?

Ik heb veel met Modula-2 geprogrammeerd, en dat vond ik een hele prettige taal, beter om toepassingen mee te maken dan het academische Pascal.
Op een opleiding als Technische Informatica wordt je hier nog steeds in opgeleid. Je hoeft er niet in te kunnen schrijven, maar kunnen debuggen en begrijpen is voor programmeren in embedded omgevingen nog steeds belangrijk.

Een goede .NET ontwikkelaar wordt ook geacht kennis te hebben van MSIL. Niet om er in te schrijven maar om te debuggen en te begrijpen wat de compiler op de achtergrond heeft gedaan.

[Reactie gewijzigd door cyspoz op 26 maart 2014 08:27]

Ik ben zelf 26 en heb twee jaar geleden de studie "embedded systems engineering" afgerond. Op die studie krijg je nog "gewoon" assembly lessen. Echter ligt de focus op C, C++ en C#. Java hebben we nooit gehad op school.
Tijdens mijn opleiding Technische Informatica aan het HBO leer ik vooral Java en een klein beetje C en C++. Tijdens de minor Embedded Systems hebben wij ons wel verder verdiept in C en in Assembly. Hierbij hebben wij zelf Assembly moeten schrijven voor de Mips processor. Ook vooral om de taal te leren lezen en te kunnen debuggen. Daarnaast hebben we enkele keren in opdrachten Assembly moeten schrijven in C code om met een microcontroller te communiceren. Was erg interessant maar wel moeilijk inderdaad ;)
Als student Elektrotechniek kan ik je vertellen dat wij assembly hebben geleerd. We moesten een project uitvoeren met een PIC die werkte op een kloksnelheid van 4 MHz.
Ex. Technische informatica student aan de HU, wij kregen nog les in assembler voor bepaalde micro processoren (PIC ARM). Ook om daadwerkelijk je programma in te schrijven, niet alleen voor debuggen.
Toevallig ben ik ook 37 :)

Vroeger op de MTS kregen we uitgebreid les in assembly voor de Motorola 68000, ook deden we in het laatste jaar wat met de ADSP2101 van Analog Devices (misschien wel als enige school in Nederland). Was erg leuk en leerzaam om voor een volledig ander soort architectuur te programmeren.

Op de HTS deden we voornamelijk de Motorola 68HC11 microcontroller, en experimenteerde ik voor de hobby met x86/x87 assembly.

Sinds de opleiding heb ik deze kennis goed kunnen toepassen als embedded software engineer, een typische baan waarbij het nog veel gebruikt wordt. Ik heb vooral gewerkt met Intel 8051/8052 en de PowerPC 860. Destijds zag je op deze platformen voornamelijk assembly en C.

Tegenwoordig is de jeugd redelijk begaafd in hogere talen, maar het begrip van wat er onder water gebeurt is beperkt. Maar zonder die kennis kun je je prima redden voor niet-embedded-toepassingen.
Opmerkelijk wellicht maar assembler was juist een van de eerste ervaringen met computers. Destijds nog microprocessors genoemd. In de derde klas van de middelbare school hadden we een conrector die er goed mee bezig was en les gaf. We gebruikten schrapkaarten, en de taal was een vertaalde versie van basic. Mijn vader kocht een CP/M computer voor zijn bedrijf. Toen zat ik in de zesde, examenjaar. Ik mocht buiten schooltijd er mee spelen. Ik had van de consultant schijven gekregen met CBASIC compilers. Later kreeg ik de officiele boeken, en daar stonden assembler voorbeelden in. Bij navraag kreeg ik de assemblers en linkers voor de 8080.
Op de Uni kreeg ik de beschiking over de macro assembler. Die gebruikte de Z80 mnemonics ipv die van de 8080. Nog mooie 4-op-een-rij programma's mee geschreven. WordStar moest altijd aangepast worden voor CP/M aan de gebruikte hardware. Daarvoor was een blok van 256 bytes beschikbaar waarin je de machinecode kwijt kon. Tja, het geheel moest in 32kB kunnen draaien.
Op de Uni kregen we ikv electronische signaalverwerking les in de 6502 (meen ik) voor lowlevel programmering van input en output naar beeldbuis. Dat was ook het moment waarop de eerste 8086's verschenen in bv. de Olivetti.
Later ging ik werken bij een bedrijf die een 4GL verkocht. Om die te kunnen laten praten met externe pakketten op het mainframe heb ik 370 assembler geleerd. Daar heb ik later ook nog les in gegeven. Een 286-based AT was dan uitgerust met een insteekkaart om met het mainframe te communiceren: VM of MVS.

[Reactie gewijzigd door Permutor op 26 maart 2014 09:23]

Alleen mensen met een interesse in de historie van programmeren leren het nog denk ik. Ik zie op de fora nog wel eens een enkeling die er tijd in gestoken heeft.

Ik heb er zelf erg veel baat bij gehad om het te leren (maar ik begon dan ook in het oude dos tijdperk waar het nog goed toepasbaar was), het leert je veel over hoe een computer tikt. Dat is kennis die bij veel programmeurs ontbreekt waardoor ze toch regelmatig tegen muren aanlopen waar ze dan maar van richting veranderen met bouwen in plaats van er doorheen te breken.
In assembly programmeren doe ik al vele jaren niet meer, maar assembly kunnen begrijpen is wel nodig. Zeer recent hadden we een raar floating point exception op Linux in libm. Dan heb je wel kennis van de assembly code nodig (in dit geval SSE2 instructies). Tot enige tijd geleden kon je bij Intel gratis de assembly boeken van moderne Intel processoren krijgen. Realiseer je wel dat ook hogere talen als C, C++, Java uiteindelijk allemaal CPU instructies zijn. En dat is assembly.

Er is dus nog steeds een hele groep programmeurs die compilers maken, runtime interpreters etc, die dus allemaal wel met assmbly te maken hebben, om volledig gebruik te kunnen maken van de nieuwste processor instructies. Ik denk ontwikkelaars van (hardware) drivers dat ook nodig hebben.

In de meeste (zo niet alle) C/C++ debuggers (zoals gdb, visual studio etc) kun je gewoon assembly bekijken (inclusief alle CPU registers). Ik vermoed dat de groep mensen die assembly kennen weleens groter is dan je op het eerste gezicht zou bedenken. Niet iedereen is een HTML of script-junky :)
Tijdens mijn werk als game developer (voor voornamelijk Nintendo consoles) was het af en toe noodzakelijk om wat stukjes assembler te schrijven, maar alleen op performance kritieke stukken waar de compiler niet het beoogde resultaat haalde. Een voorbeeld was een routine om textures naar VRAM te kopieeren mbv DMA tijdens de rendering blank. Maar verreweg het meeste schreven we in C++/C. Voor debugging en analyse van de door de compiler gegeneerde code is kennis van assembler zeker handig.

Als 15 jarige heb ik leren programmeren in assembler op m'n TI-83 rekenmachine; een Z80 met krap 28KB RAM, doe ik nu, 15 jaar later, nog steeds af en toe, just for the fun of it.

Tijdens m'n opleiding (HBO Technische Informatica) is er weinig aandacht aan assembler besteed, de hele opleiding was sowieso gericht op Java. Slechts 1 semester C/C++ en een keuzevak Windows programmeren.

Maar waar ik assembler vandaag de dag voornamelijk voor gebruik is kleine microcontrollers zoals een ATtiny13 (1KB ROM, 64 byte RAM), en dan eigenlijk alleen als het in C niet meer past :)
Om je eerlijk te zeggen vond ik eigenlijk assembly (386 dus geen rekening te hoeven houden met segmenting) makkelijker dan pascal/basic.. Was eind 90er jaren nog bezig met een game-engine in puur assembly, kostte me minder tijd dan de game-editor die ik tentijde ook in pascal ernaast schreef.. dat waren mooie tijden, heb nog steeds spijt dat ik toen ben gaan werken omdat ik 's avonds geen zin meer had in hier nog aan te werken..
Ik heb vorig jaar leren programmeren op een MISC processor in assembly aan de universiteit. We moesten zelfs relatief eenvoudige programma's in hex. code kunnen schrijven op het examen, dus op dat vlak zit het in BelgiŽ nog redelijk goed ;-)
Iedere TI'er krijgt het nog.
Ik heb het zelf ook gehad met daarop nog een verdiepend blok waarin we zelfs micro-assembler kregen (dus echt de instructies bouwen aan de hand van de ALU die in de cpu zit). Natuurlijk enorm versimpelt, met een x86 krijgt de halve klas een hardverzakking, maar de principes worden iedereen bij TI wel aangeleerd.
Ik ben nog iets ouder (44) en kreeg eind jaren 80 nog wel Assembly.
Maar dan voor de Z-80. Volgens mij was het de Micro Professor
Heb noot begrepen wat ik er aan had, omdat ik HBO Algemene en Analytische Chemie deed.
Kreeg ook nog Qbasic (en QuickBasic, en par jaar later vervangen door Delphi) en DBase4 en dar had je toch meer aan
Heb noot begrepen wat ik er aan had
Het leerde je de basis principes te begrijpen van een processor. Ik heb ook geleerd een Z80 te programmeren met machine codes. Het mooie was, dat hoe beter ik begreep HOE het werkte, hoe minder ik kon bevatten DAT het werkte. Nadat je je eerste handshake netwerkje heb gemaakt met Z80's besef je eigenlijk hoe bizar snel alles is geworden. En hoeveel code er wel niet verzet moet worden om een simpel venstertje van A naar B op je desktop te verschuiven... En dan zat je te pielen met een Z80, met zo'n 8500 transistors... tegenwoordig tikken we de 5 miljard al aan. Maar het basis principe is nog steeds hetzelfde.

[Reactie gewijzigd door satoer op 26 maart 2014 09:50]

Hoogstwaarschijnlijk moet ik dat voor mijn opleiding leren (weet ik niet zeker maar mijn vader had dat wel)
Ik ben een student toegepaste informatica en heb 2 trimesters de basis van assembler gezien.
Dus het wordt nog wel gegeven :p
Ik ben bijna klaar met mijn opleiding Informatica en heb php, Java, c# en wat website stuff als Javascript en asp.net gehad. Ik heb expliciet voor C++ moeten kiezen en heb geen uitgebreide wiskunde gehad. HBO van tegenwoordig :P
Eind '80, begin '90 een complete sampler gemaakt op een Z80 machine, afdankertje van de zaak van mn vader. Opslag op floppy's, grafische weergave, basale programmeer tool om loops te maken e.d. Allemaal in assembler. Uitgeprint was het een fors pak papier ;-) (Machine was een Kontrol PSI 80D, met 1MB (!) geheugen, 24bit ad/da converter en rekenprocessor. Gaaf ding! )
We hebben er naar gekeken (Hogeschool Rotterdam, Technische Informatica) maar nooit les in gehad of echt uitgebreid behandeld.
Ik denk niet dat de huidige en toekomstige generatie nog veel van C of C++ weten.
Ik denk niet dat je gelijk hebt, C++samen met Java zijn volgens mij een van de populairste talen waarin je op school les krijgt.
Ik bedoel kennis dat het schoolniveau overstijgt. Op school leer je wel de basis, maar toch niet genoeg om de broncode van MS Dos helemaal te begrijpen. Toch?

Ik weet ook wel dat C en C++ nog vaak wordt gebruikt, maar als ik de vacatures bekijkt, is het toch vooral C#, Java en webtalen zoals HTML etc dat de klok slaat. Ik denk dat de interesse van de jeugd en toekomstige jeugd meer hierin ligt.
De broncode van MS Dos is voornamelijk assembly, dus hoe goed je C of C++ ook kent.. je gaat er deze code echt niet beter door begrijpen..
Op het MBO (Telematica) heb ik les gehad in Pascal,

Op het HBO (Technische Informatica) heb ik les gehad in C en C++.
Java was een keuzevakje, en C# is precies ťťn lesuur aan bod geweest.

edit: namen van de opleidingen toegevoegd.

[Reactie gewijzigd door --Andre-- op 26 maart 2014 11:15]

Je bedoelt C#, althans dat is bij ons zo geweest.
Het zijn nou juist wel de talen die je vooral leert. Dit komt omdat het leren van assambly veel meer tijd kost en niet heel veel beter is.
Assembly is leuk, maar praktisch is het niet in veel gevallen. Het kost je meer tijd om te snappen en te programmeren en is ook nog eens platform specifiek. Zelfs de kleinste microcontrollers zijn zo sterk dat er geen motivatie is om de code te schrijven of optimaliseren in assembly.
Voor veel mensen zal zelfs C++ teveel moeite kosten, vandaar dat je een beaglebone tegenwoordig al via javascript kan aansturen (in mijn ogen is dat erg inefficiŽnt, maar het werkt en geeft lekker snel resultaat).
Ook (vooral?) het aanpassen van assembly is veel arbeidsintensiever dan het aanpassen van een in een gestructureerde taal geschreven programma.. en omdat C(++) erg efficiŽnt is heeft dat over het algemeen de voorkeur.
C kom je voorlopug niet onderuit als je performance wil. Ook komen er nog steeds nieuwe versies en technologieen voor uit.

[Reactie gewijzigd door Gamebuster op 26 maart 2014 10:04]

Juist. Als je C/C++ op Windows SDK (o.a. ATL, STL, IOCP, Media Foundation) kunt en low-latency/high performance media streaming software wilt helpen ontwikkelen, heeft mijn werkgever werk voor je. Vandaag nog. Moeilijk om aan ervaren krachten te komen.
I know. Prachtige branche zit ik in. :D

Ik wil graag mijn kennis uitbreiden tot C/C++ en daar ben ik dan ook actief mee bezig, maar voor nu zit ik met Ruby on Rails en NodeJS, waar ook al heel veel werk in te vinden is.
Ook C is nog steeds een populaire taal wanneer het gaat om embedded hardware design. Er wordt door ons gewerkt op middelmatige ARM processors (60Mhz) en relatief weinig intern/ram geheugen. De programmeertaal C is een goede afweging tussen performance en abstractie niveau.
Er wordt nochtans veel in C of C++ geschreven. Zeer veel embedded software is bijvoorbeeld nog steeds puur C.
Bij ons op school nog flink les gehad in C++, C verder niet. Het klopt wel dat "wij"(Op mijn school) meer les krijgen in talen die minder diep op de hardware zitten als C++, zoals C# en Java.

Edit: Typo

[Reactie gewijzigd door mobstaa op 26 maart 2014 08:38]

Ligt er aan, er is nog steeds een grote poel mensen die netjes met The C Programming Language begint. Op scholen is dat wat minder maar de genen die daar hun eerste aanraking met programmeren hebben zijn daar meestal ook niet naar opzoek.
Op het mbo is het meestal Java of C# inderdaad.
Maar op het hbo gaat het vaak wel dieper. Bij Informatica (iig bij Saxion) krijg je ook c++.

En bij Technische Informatica (waar ik zelf zit) ook Assembly, C en C++ naast Java.
Waarbij C zeker wel ieder blok actief wordt gebruikt voor projecten ed. c++ komt ook meerdere malen terug, oa voor 1 vak geheel gericht op Concurrency (multithreading) met C++.

Tuurlijk is iemand na een algemene opleiding niet in 1 klap guru in 1 taal. Maar dat hoeft ook niet. 't leren Programmeren zelf is belangrijker dan de taal waarin dat gaat.
Elke universiteit in Nederland biedt wel een course aan in C/C++. Zo heeft bijv. de RUG deze driedelige course: http://www.icce.rug.nl/edu/
Klopt helemaal niet! Het is samen met Java onze primaire taal. Waar haal je dat vandaan? En waarin moet men anders werken? :p
Zal je zien dat er allemaal zero day exploits op dos 1.1 verschijnen de aankomende dagen..

:-)

wat leuk om dit stukje computerhistorie door te bladeren zeg.. ik kan me de tijd nog herinneren dat ik de eerste dos prompt zag (3.22 oid?) .. lang geleden...
*zucht*
Goeie oude tijd, die was iedereen nog niet zo gebrand op snelheid, tenminste ... het grootste deel van de gebruikers. Zelf ontdekte ik de PC rond MS-DOS 2.1 niet veel later opgevolgd door 3.0 enz. uiteraard met Word Perfect en op den duur ook Corel Draw.

Sjees wat een tijd was dat !
Heb toen hooguit geprobeerd iets in C te schrijven maar verder dan Hello World kwam ik nooit :-) Wat wel leuk was (op den duur) was toen eenmaal de BBS'n toenamen er veel demo's in assembly werden geschreven om even aan te tonen dat meer geheugen, harddisk ruimte en snelheid niet nodig was en exe files nooit zo groot hadden hoeven zijn:

Demo (demo via youtube Smallest exe & graphics 64k)

En dan vraag ik mij anno 2014 toch af of het allemaal niet kleiner had kunnen zijn qua harddisk capaciteit, geheugen etc.
"iedereen nog niet zo gebrand op snelheid" :?

Ik had de turbo-knop altijd ingedrukt, hoor! :)
Men hoefde niet het snelste van het snelste. Tegenwoordig zie je steeds vaker dat een computer al bij aanschaf is achterhaald. Men wilt steeds vaker een nieuwe computer/laptop omdat er iets snellers is uitgekomen.

In de ms-dos periode keek men nog niet zo zeer naar de enorme snelheden. Het moest werkbaar maar tevens ook betaalbaar zijn, en als een programma 2sec. langer nodig had om te starten dan was het geen enkel probleem. Men was een stuk geduldiger dan tegenwoordig.
Dat is absoluut niet mijn ervaring. Ik en mijn vrienden waren altijd bezig met de volgende generatie processoren, meer geheugen, grotere harde schijven, betere videokaarten en zelfs de soundblasters werden op de voet gevolgd!

Had ik net een Pentium, had een vriend van me alweer een Pentium Pro.. OMG wat een verschil!! Core i3, i7, i5... in de praktijk merk ik weinig verschil...

Tegenwoordig heb ik al 2 jaar een game systeem staan waar ik niets aan heb hoeven upgraden. Alle nieuwe games draaien er nog perfect op.


Wel is het zo dat het inderdaad minder belangrijk is geworden voor programmeurs om zuinig aan te doen met geheugen en cycles, omdat deze nou eenmaal in overvloede aanwezig zijn. Dit heeft weer de deur opengezet voor "hogere" programmeertalen en principes die code makkelijker te lezen maken en dus makkelijker te onderhouden (onderhoud is een veel grotere kostenpost dan snelheidswinst voor de meeste applicaties).
Je zegt het precies goed, JIJ... de gemiddelde consument was echter tevreden zelfs het bedrijfsleven. Wat men nu een Tweaker noemt, was toen een nerd... en die bestonden toen al en van hen moest het allemaal sneller, beter etc.

Het leuke was in die periode nog dat door het simpel wijzigen van autoexec.bat en config.sys al heel wat prestatiewinst behaald kon worden waardoor een PC niet iedere x-jaar vervangen hoefde te worden. Was een memory manager toen nog standaard, nu tegenwoordig merk je er nauwelijks meer iets van (zijn ze er Łberhaupt nog wel? ;)).

Wat ik bedoel is dat men het nu tegenwoordig vaak als straf ziet om een kopje koffie te moeten halen tijdens het opstarten van een programma "wat dan naar mening van de gebruiker, te lang duurt". De eisen aan de PC waren ook lang niet zo hoog maar goed, dat was ook best logisch aangezien het nog niet dermate belangrijk was als nu :)
Het leuke was in die periode nog dat door het simpel wijzigen van autoexec.bat en config.sys al heel wat prestatiewinst behaald kon worden waardoor een PC niet iedere x-jaar vervangen hoefde te worden. Was een memory manager toen nog standaard, nu tegenwoordig merk je er nauwelijks meer iets van (

Sorry, maar je slaat de plank totaal mis. Ja, je kon winst halen door de autoexec en config.sys te wijzigen. Dat was soms zelfs bittere noodzaak om een spel uberhaupt te kunnen draaien. Dat was echter abosluut geen pluspunt; van een slimme memory manager was helemaal geen sprake; aldus het moeten kloten met xms en ems ram etc.etc.etc.

Memory kuch managers waren dan ook al bittere noodzaak, omdat een goede slimme memory manager ontbrak. Tegenwoordig heb je die tools gelukkig niet meer nodig. Dat is vooruitgang.

Verder kan ik me ook niet vinden in je profiel van "gebruikers van toen". We deden het ermee, simpelweg omdat er niets anders was en/of zoweizo veels te duur.
Voor wat ik mij meen te herinneren ontbrak vaak emm386, stonden de autoexec.bat, config.sys altijd boordevol met meuk voor cd-spelers (wisselaars) van mscdex tot aan al die stuurprogramma's. Dat scheelde vaak al een berg waardoor de prestaties uiteindelijk voor sommige mensen zeer zeker flink toenamen.

Enigste wat ik toen was, was hooguit wat rommelen op Packet Radio (AX.25) gedaan en toen Compuserve in Nederland kwam via die manier op de digitale snelweg terecht gekomen. Ook niet te vergeten dat tussendoor geregeld meuk te downloaden vanaf BBS'n.
Verder kan ik me ook niet vinden in je profiel van "gebruikers van toen". We deden het ermee, simpelweg omdat er niets anders was en/of zoweizo veels te duur.
Dat is in principe wat ik al eigenlijk de hele tijd bedoel :)

Was het niet zo at het merendeel van de consumenten hooguit nog een MSX, C64 of Amiga 500/600 had staan en pas ergens rond de 386 ze pas echt tot aanschaf van PC's zijn overgegaan? Van die 8086, 8088, 80286's heb ik n.l. maar weinig voorbij zien komen in die tijd. 386 kwam je al steeds vaker tegen her en der... uiteraard nog altijd alleen bij die mensen die er geld voor hadden.
Voor wat ik mij meen te herinneren ontbrak vaak emm386, stonden de autoexec.bat, config.sys altijd boordevol met meuk voor cd-spelers (wisselaars) van mscdex tot aan al die stuurprogramma's. Dat scheelde vaak al een berg waardoor de prestaties uiteindelijk voor sommige mensen zeer zeker flink toenamen.
Het probleem was volgens mij ook dat bijvoorbeeld games werden gemaakt om op een machine met 4MB ram te kunnen draaien maar dan ging men wel helemaal tot het naadje waardoor je met hardcore minimalistische config- en batchfiles moest werken om een game aan de gang te krijgen op een systeem met 4MB geheugen. Soms had je games die veel extended memory nodig hadden, anderen hadden expanded memory nodig wat dan weer beter ging met de nieuwste hipste geheugenmanager.

Ik ben het ook niet eens met de uitspraak dat het snelste van het snelste toen niet hoefde. Upgrades maakten toen veel meer uit dan nu. Zeker als je op een krap budget zat met middelmatige hardware was je hele tijd bezig met tweaken om games acceptabel te kunnen spelen.
Maar dan zit je al op DOS 5 of later.
Een nieuwe 386 werd typisch verkocht met 4MB RAM.
Er was zo'n tekort aan geheugen dat zelfs de latere 486 DX4's met 4MB verkocht werden. OS2 Warp draaide net aan.
Had je 16MB dan draaide het zelfs super op een 386.
Toch had ik al snel naast mijn Commodore 64 /128 al een PC met de nieuwste Herculeskaart en een hard disk van 20 Mb met een MFM controller. Die maakte behoorlijk herrie. De processor was een NEC-V20 sneller dan 8086. De computer verkreeg ik via een pc-privť project. Hij kosste toen 5200 gulden. Ik heb er veel plezier van gehad. Maar spelletjes deed ik toch op de Commodore.
Het is niet zo dat snelheid destijds niet belangrijk was, die snelheid was simpelweg niet voorhanden.

Ik had maar wat graag gehad dat je een spelletje gewoon kon gaan spelen als je daar zin in had, in plaats van eerst moeten laden en dan een paar uur later kunnen beginnen... maar het was simpelweg niet anders, als je het moest inladen vanaf een cassettedeck.
Volgens mij zijn er niet veel die nog een cassettedeck gebruikt hebben. Inderdaad, lang wachten en met een beetje pech (volume te hoog of te laag) was 't niet goed ingeladen en moest 't overnieuw.

Volgens mij had de C64 bij sommige spellen nog een soort minispel tijdens 't laden. Ligt me vaag iets van bij.

Even zo'n 25 jaar verder en hier staan we met onze 500MB/s SSD systeemschijven.
O ja, ik herinner me nog heel goed al die strepen op het portable tv-tje. En vaak na een kwartier laden, kon je het nog eens over doen. Later had ik een 5,25 diskdrive, dat ging veel beter, Ik had ook nog een tekstverwerker op de Commodore 64 / 128 dat luisterde naar de naam: Vizawrite. Maar het werkte goed.
Er bestond ook nog een turbo mode voor het laden vanaf cassettes. Met de c64 tenminste.
Toch was de Commodore 64 zijn tijd echt ver vooruit, mijn eerste computer met een tapestreamer :+
Je zegt het precies goed, JIJ... de gemiddelde consument was echter tevreden zelfs het bedrijfsleven.
Excuses, wat dat betreft kan ik het gewoon niet met je eens zijn.

Van 286 naar 386(32 bit sprong) naar 486DX (FPU) zijn enorme sprongen in functionaliteit waarbij downward compatibility er wel was, maar upward zeker niet. Daarentegen draait een Core2 alles wat je op een i7 kan draaien (uiteraard wat langzamer^^).

De CPU jumps waren enorm en programma's draaiden dus gewoon niet op oudere cpu's, iets wat al een tiental jaren niet meer zo is. Mijn 8 jaar oude systeem draait alle games. Goed, met wat details minder, maar het draait.

Maar een spel als Doom... dat draaide gewoon niet op een 386. Sterker nog, een 486sx 40 mhz was al kielekiele. Je wilde een 486DX 66mhz.

En zo ook kantoor software. WP draaide dan wel overal op, maar dingen als Lotus, cognos erc... je had gewoon bepaalde hardware nodig.

Kijk maar eens naar wat bedrijven/scholen/bibliotheken draaien: een Vpro core processortje, 2gb ram, windows XP (wat nu uiteraard afgelopen is). Die systemen worden jaar in jaar uit gebruikt. Als ze worden vervangen krijg je meestal gewoon hetzelfde terug :+

De feiten wijzen erop dat juist de snelheids drift minder is geworden voor de doorsnee gebruiker en dat die juist veel groter was in het 286-386-486 tijdperk.
Het leuke was in die periode nog dat door het simpel wijzigen van autoexec.bat en config.sys al heel wat prestatiewinst behaald kon worden waardoor een PC niet iedere x-jaar vervangen hoefde te worden.
Je kon autoexec.bat en config.sys ook gewoon verwijderen. Dan startte je systeem razendsnel op en Wordperfect ging (in veel gevallen) er niet minder goed door functioneren.
Mis. Dit gaat over de 8086/8088 tijd. (3 tot 9MHz) Dus voor de tijd van verwisselbare processoren en grafische kaart upgrades. Pas rond de 386 kwam de upgradetrein echt op stoom, met soundblaster pro's van 400 gulden en dat soort meuk.
En dan krijg je vaak steeds zwaardere games die helemaal niet zo spectaculaire grapics hebben, gewoon zwaarder uit de luiheid van de game maker.
Is niet zozeer luiheid van de game maker maar eerder de markt die sneller nieuwe releases wil..

Vroeger wisten we ons nu eenmaal langer te vermaken met een (relatief eenvoudig) spelletje..

Zoals bijvoorbeeld Decathlon..
Ik kan mezelf nog steeds vermaken met Tetris :)

Maar je hebt een punt, zo wordt er van bv. EA verwacht iedere jaar weer een nieuwe NFS of BF uitkomt en dat geeft de devs te weinig tijd voor een goede game en code.
Monkey Island 1 was voor mij de eye-opener wat betreft grafische mogelijkheden van een PC. Daarvoor was het nog MSX-2(+) en Amiga die het alleenrecht hadden op mooie spellen.
Ben voor Monkey Island met mijn vader een nieuwe grafische kaart gaan halen (heb univesa.exe wel nodig gehad natuurlijk, je kent het wel :) )
Voor mij was het de The seventh guest, ik was op bezoek bij een vriend met een 386 en wist niet wat ik zag.
Heb me een ongeluk gespaard om een 486 dx2 66 bij elkaar te sparen voor 2200 gulden en de rest is geschiedenis.
Men was een stuk geduldiger dan tegenwoordig.
Lees: men was gewend aan het feit dat zaken langer duurden dan tegenwoordig. Niet te verwarren met 'geduld'.
Doorsnee gebruikers misschien niet nee, maar ik kan me nog wel de ram-schijven in het extended memory herinneren om het allemaal nog sneller te laten lopen. 384kB extended memory was toen een nieuwigheid en een luxe. Gewoon WP in de ram schijf zetten en het startte sneller op dan notepad nu.

Daarnaast is sinds de invoering van Windows en de opgang van 16 naar 32 bit alleen maar nadelig geweest voor de snelheid omdat men uiteindelijk aan de ene kant steeds meer onzin in programma's wilden verwerken en anderzijds omdat men sloppy begon te coden en door gebruik te gaan maken van frameworks kwam er ook veel te veel overhead in.

Sla eens een volledig leeg Word document op en kijk naar de bestandsgrootte. Gewoon bizar.

Ach ja, MS DOS, Dr DOS, WP, Norton Commander. Leuke herinneringen :)
Mijn meest gebruikte programma toen was PC-Tools... V6 geloof ik. Dat was de tegenhanger van Norton Commander. Dat programma heb ik gebruikt vanaf mijn XT tot mijn pentium 133 Mhz. Weet het nog goed: op een pentium 120 Mhz draaide het nog perfect, en op 133 Mhz gewoonweg niet meer. Balen was dat toen. Ik was daar toch even niet goed van, ik had dat programma zeker 10 jaar gebruikt. :)
Pardon? Juist toen kocht je veel sneller een nieuwe PC omdat het snelheids verschil enorm effect had op de PC ervaring. Nu is dat veel minder.

Als snelheid niet uitmaakte waarom was het dan in assembly geschreven? Juist om toch net iets sneller te zijn.
Ik weet nog dat in de gebruikersgroep van HCC maar ook de buurthuizen waar ik toen kwam, heel veel mensen toch echt te beroerd waren om honderden of zelfs duizenden guldens uit te geven om steeds maar het neusje van de zalm te kopen.

Het ging toen dus zeker niet sneller dan de afgelopen ~ 10-12 jaar aangezien prijzen juist daarna pas echt gekelderd zijn.
Mmm, mijn ervaring zijn toch echt anders, juist nu gaat mijn PC veel langer mee. Kocht toen ieder jaar een nieuwe PC nu eens in twee/drie jaar.
Men hoefde niet het snelste van het snelste. Tegenwoordig zie je steeds vaker dat een computer al bij aanschaf is achterhaald.
Het is eerder andersom. In die tijd ging de ontwikkeling veel sneller vooruit en groeide tegelijk de snelheidsbehoefte voor nieuwe toepassingen harder dan dat de technologische vooruitgang kon bijbenen. Zeker bij de overstap van DOS naar Windows naar uiteindelijk de NT-gebaseerde varianten van Windows had de techniek een inhaalslag te maken.

Tegenwoordig blijven computers van een jaar of 4 a 5, zeker indien geupgrade met wat geheugen en een SSD, prima voor het gros van de mensen. Dat was destijds ondenkbaar want een machine was na 5 jaar rijp voor de schroothoop. Ik heb zelf het traject Atari XL, 8088, 286, 386SX, 486SX, Pentium, P2, Athlon, G4, C2D, i5 afgelegd. De i5 is een iMac met 16GB en een 1TB SSD en daar doe ik nog zeker wel een jaar of 2 mee. En dan doe ik redelijk intensief ontwikkelwerk en grafische vormgeving en dergelijke, inclusief virtualisering van Windows en Linux.
De 8088 werd in 1979 ontwikkeld en in 1989 gewoon nog verkocht.
In 1989 bestond de 486 al, dus 3 generaties verder. Wat is je punt? De 386 is tot een paar jaar geleden geproduceerd en de 8088 wordt bij NASA nog steeds toegepast. Dat de 8088 in 1989 nog geproduceerd werd betekent niks.
Dat de 8088 in dat jaar naast de industrie ook voor consumenten werd geproduceerd en dat de 8088 ook daadwerkelijk op de compatibility list van veel software stond.
Dat geldt nu nog steeds voor oude processoren, dus je punt blijft vaag. De snelste ontwikkeling van PC-techniek was zo'n beetje tot aan de P4. De hele jaren '90 waren vlotte jaren. Daarna stagneerde de toename van performance. Met de overstap naar multicore-CPU's werd de stagnatie van de kloksnelheidsstijging opgevangen, maar heel veel software maakt er nog altijd amper gebruik van.
De Turbo knop is dan ook bedoelt om je PC langzamer te maken als bepaalde software compatibiliteitsproblemen heeft op de normale (hoge) snelheid.
Hoe zat dat eigenlijk met de ISA bus? Die liep toch altijd op 8 Mhz door een aparte klokgenerator? Of liep die wel met de processor mee?
De ISA bus was origineel direct op de CPU aangesloten en gebruikte gezelfde klok. Toen de CPU's sneller werden, werd een deler op het kloksignaal van de CPU toegepast.
Aha. Ik heb namelijk uit de handleiding van een "modern" (Pentium 3) moederbord dat de ISA bus op 8 Mhz draaide. Duidelijk.
Bij mijn weten is de ISA bus snelheid vanaf de introductie van systemen met een PCI bus, Wat ik me uit kan herinneren is dat er BIOS opties waren waaruit je kon kiezen PCI klok gedeeld door 3 of 4.De PCI klok was dan weer gebaseerd op de FSB.
Had je wel software nodig die 'turbo' aan kon. Dat was de reden van de turbo knop.
Er was geen software die de Turbo knop wel of niet aankon. Het was een schakelaar om de processor sneller te laten lopen 8Mhz met turbo aan 12 Mhz o.i.d....
Het had verder niets met software te maken. Ik had de 'luxe' van een bloedsnelle :+ 16 Mhz 286 en moest de spelletjes altijd zonder turbo spelen (dus in mijn geval op 12 Mhz) omdat het anders veel te snel ging.
De turbo knop was dan ook niet om de pc sneller te maken, maar juist om deze voor bepaalde programma's langzamer te kunnen maken. ;) Met name voor oudere spelletjes die van de CPU afhankelijk waren voor de timing.
& @--Andre--
Bij mijn pc was het als precies andersom verkocht. Mij was toen verteld dat je de turbo kon gebruiken als er even wat extra rekenkracht nodig was. Maar het kon de levensduur van de pc verlengen door hem standaard uit te houden :o (toen dachten ze nog dat een pc jaren mee kon gaan :o )
Mijn favoriete PC game Pango had dat nodig. Dat was niet speelbaar op computers die sneller waren dan 12 Mhz. Ik speelde Pango het liefst op een 4,77 Mhz computer.

Pas toen er snellere computers kwamen (7,14, 9.54, 12, 16 Mhz, etc.) toen kwamen programmeurs op het idee om de klokgenerator te gebruiken ipv processorcycles voor hun timing.

[Reactie gewijzigd door Trommelrem op 27 maart 2014 19:22]

Er was geen software die de Turbo knop wel of niet aankon.
Juist wel.
Oorspronkelijk was de PC 4.77 MHz. Toen er varianten met hogere snelheden uitkwamen, bleek sommige software niet goed te werken.
Daarom starten de meeste snellere XTs op in 4.77 MHz (100% compatible dus), en kon je ze met een tooltje, toetscombinatie of evt een turbo-knop in de hogere snelheid zetten.

Bij latere PCs was het idd niet meer zo dat je met de turbo uit ook echt cycle-exact dezelfde snelheid had als een originele PC, maar toch hielp het wel met bepaalde software die anders te snel draaide en/of crashte.
Dat was ook omdat van elke processor instructie exact bekend was hoe lang die er over deed. Dus timeloops werden geprogrammeerd zonder interne klok. Die kwam later pas.
Dus sommige spelletjes kon je alleen spelen als de juiste klok snelheid ingesteld was.
Polling was ook gebruikelijk.
Maar als je te snel polt, dan heb je een miss, en gaat het programma zonder resultaat verder. Jammer voor communicatie met randapparatuur!
Je was in die tijd inderdaad stukken geduldiger en veel langer zoet met iets..

En ook ik heb me toen in (Turbo-)C verdiept.. om een applicatie voor het bulletin board te schrijven dat ik toen had draaien..

Aparte telefoonlijn dedicated voor de inbellers.. wat een tijden waren dat toch..

En het viel me inderdaad op dat dat C bizar snel was.. ik heb mijn pc nog nooit zo snel zien crashen nadat ik weer eens een verkeerde instructie had geschreven.. lol..

Maar ook toen ik het programma de eerste keer wťl aan de praat kreeg ging ik er van uit dat het niet werkte.. het was immers bijna onmiddelijk klaar?! Tot ik aan het resultaat zag dat alles goed was gegaan..

..en dat op 8 MHz..
Ja... en dat was nog CGA! Daarna pas kwamen EGA en VGA (en Super VGA 8-) )
en Hercules en MDA daarvoor.
Toen ook nog SimCGA nodig om spelletjes te spelen op hercules schermen. Wat een tijd :Y)
En als je een spelletje speelde dat niet gebruik maakte van vsync van je videokaart en je PC was te snel (dus geen 8086) dan had je een TSR programma'tje dat je PC vertraagde zodat alles gewoon liep en niet te snel. _/-\o_

[Reactie gewijzigd door Bux666 op 26 maart 2014 11:27]

ik heb me tot voor de tijd van VGA altijd prima vermaakt met Commodore 64 en Commodore Amiga computers. Spelletjes op die machines zagen en klonken er nog altijd beter uit. Had wel een 8086 kaart in m'n Amiga 2000 met CGA-graphics maar moest daar altijd een beetje om lachen als ik daar spelletjes op speelde. Tekstverwerken met WordPerfect en WordCraft ging dan weer wel supergoed. Zelf gebruikte ik liever Dr. DOS.
[mierenliefhebber-modus] DR DOS, zoals in Digital Research DOS... niet Dr. zoals in dokter ;) [/mierenliefhebber-modus]

Ja, de download staat al aan :) Hehehe old times are coming back: Falcon 3.0 starten nadat je alle drivers in het gebied tussen de 640kB 1MB had lopen proppen om zo 604KB vrij te krijgen, waardoor je de Radiotorens kon horen als je in het gelukkige bezit was van en SoundBlaster...
De tools (voor b.v. geheugenbeheer) bij DR-DOS waren velen malen beter, behalve dat DR-DOS niet compatible was met de MS-DOS6.
DOS=HIGH,UMB :D

Wat heb ik destijds op veel computers de config.sys en autoexec.bat lopen fixen. En volgens Bill Gates zou 640kb ruim voldoende zijn!
En volgens Bill Gates zou 640kb ruim voldoende zijn!
QUESTION: "I read in a newspaper that in l981 you said '640K of memory should be enough for anybody.' What did you mean when you said this?"

ANSWER: "I've said some stupid things and some wrong things, but not that. No one involved in computers would ever say that a certain amount of memory is enough for all time."

Gates goes on a bit about 16-bit computers and megabytes of logical address space, but the kid's question (will this boy never work at Microsoft?) clearly rankled the billionaire visionary.

"Meanwhile, I keep bumping into that silly quotation attributed to me that says 640K of memory is enough. There's never a citation; the quotation just floats like a rumor, repeated again and again."

Dat is helaas ťťn van de grootste fabeltjes in de computerwereld :P
In in het stenen tijdperk liepen al mijn programma's, inclusief mijn boekhouding, op een CPM machine, waaraan een vast toetsenbord, met slechts 2 x 5-1/4 " floppy drives. Dus geen hard disk en met slechts 64 K Ram memory....
Tezamen met de matrixprinter (^KP) en incl. de programma's kostte het destijds Hfl.25.000,-
Een paar jaar later kwam er ms dos, met een Kaypro 8086 processor (20 MB HD) en vergulde contacten en iets later de Tulip computer met de 80286 (40 MB HD) en zowel MS DOS en de eerste versie van Windows...

[Reactie gewijzigd door The dynamic Fox op 26 maart 2014 15:37]

CPM... Heb ik ook nog mee gewerkt. Copy heette PIP ;)

Het zou mooi zijn als ook MS-DOS 6.22 openbaar werd.
Peripheral Interface Program.
Inderdaad een apart programma omdat er te weinig geheugen was om het in de shell beschikbaar te houden.
Het hele CPM operating system was iets als 8kB memory. Plus een aantal ondersteunende programma's zoals PIP.

[Reactie gewijzigd door Permutor op 26 maart 2014 19:21]

Dat Bill Gates verhaaltje is al zo vaak ontkracht. Dat heeft hij nooit gezegd. Urban Myth die kennelijk in leven gehouden moet worden ;)
Is nooit een uitspraak van Bill Gates geweest.
Zie onder andere het interview met Steve Jobs (die andere grote "dief" van Silicon Valley).
Die incompatibiliteit is destijds bewust gecreŽerd om DR-DOS uit de markt te werken.

Edit: typo

[Reactie gewijzigd door Trashed op 26 maart 2014 17:02]

De incompatibiliteit is ontstaan omdat MS de rechten op bepaalde delen dusdanig vast wist te leggen dat het niet rendabel was voor DR om nog verder te ontwikkelen (ze hadden een emulatie moeten maken dmv reverse engineering, en zo groot was hun markt al niet meer na het marketing offensief van MS-DOS5)
Het was geen incompatibiliteit.
Ms liet software checken op het bestaan van een interne datastructuur die in ms dos gebruikt werd, maar in de dr dos implementatie niet nodig was.
FUD (Fear, Uncertainty and Doubt ) deed de rest.
De code, bekend als de AARD code, was geobfusceerd. Op runtime gedecodeerd naar de juiste machine instructies. En voorzien van anti-debug commando's.

[Reactie gewijzigd door Permutor op 26 maart 2014 19:02]

De AARD-code was een werkende check in bŤta's van Windows 3.1 of MS-DOS werd gebruikt (i.p.v. bijvoorbeeld DR-DOS). Op zich geen vreemde gedachte in een beta (testen op basis van een bestaande "baseline" levert meer consistente resultaten). De RTM-versie bevatte deze code ook, maar was niet geactiveerd en Windows 3.1 RTM draaide dan ook op DR DOS.

Dat de AARD-code "geobfusceerd" was, is door mij niet terug te vinden (en volgens mij ook niet waar). Het hele AARD-verhaal is wellicht ook een vorm van FUD, maar dan geÔnitieerd door de concurrentie?
De AARD-code was geobfusceerd met XOR's. Simpel maar destijds redelijk doeltreffend. De bedoeling was dat je met een un-assembler de code niet kon zien. En op runtime ook niet, vandaar de anti-debugger commando's.
Dit is mij altijd bijgebleven na het lezen van het artikel van Andrew Schulman.
Over de XOR code kun je in het artikel van Geoff Chapel lezen. En dan ga ik er voor het gemak even van uit dat obfuscatie gelijk staat aan encryptie. Bitwise XOR is namelijk niet bepaald moeilijk te kraken. Tevens noemt Geoff's artikel het gebuik van debug handlers en NMI's om het gebruik van debuggers te frustreren.

[Reactie gewijzigd door Permutor op 31 maart 2014 11:50]

Dan moest je eerst geheugen vrij maken, om te kunnen spelen :)
Op een gegeven moment had je natuurlijk om dat te beheren...

Quarterdeck Expanded Memory Manager (QEMM)

http://en.wikipedia.org/wiki/QEMM

Plaatje: http://www.computinghisto...s/large/PRODPIC-12533.jpg

[Reactie gewijzigd door LogiForce op 26 maart 2014 18:05]

En om de schijf te vergroten gebruikte je o.a. Stacker

http://en.wikipedia.org/wiki/Disk_compression

Mooi was die tijd :*)
Mooi was die tijd zeker. Het was allemaal nog basic en je leerde nog echt het systeem onderhuids kennen. Je moest wel zelfs, anders kon je bepaalde programma's niet draaien.

Dan nog maar niet te spreken over IRQ problemen en andere zaken, puur omdat je toen nog geen "Plug&Play" had. Dus had je een geluidskaart en een modem (ook een geluidskaart) in je ISA slot gestoken, en werkte het niet dan moest je jezelf eerst even achter de oren krabben over waar het wel fout ging.
Immers in die tijd hadden we nog geen internet waar we het allemaal op konden zoeken. Je moest gewoon zelfstandig diagnoses stellen en debuggen. Als je mazzel had dan had je nog wel een vrienden kring in het BBS land (Bulletin Board Systems). Maar ook die hoefden niet alles te weten.

Toen vond ik werken met de PC nog leuk en wist ik nog wat mijn PC aan het doen was. Nu is alles uit handen getrokken met Windows en heb je niks meer met het onderliggende van doen (het is er nog wel).
Daarom vind ik Gentoo ook een leuke Linux Distro. Je leert nog aan de onderkant want te knutselen en bent niet steeds in een grafische schil bezig.
Ik heb Quarterdeck nog in originele verpakking. Kon er niet toe komen om het weg te gooien. Met geheugen om in een slot te plaatsen.
En vergeet LIM EMS niet , een wopping total toen van 2MB
voor de prijs van 4MB kon je gewoon een autootje kopen
Ik vond Memmaker (DOS 6.x) eigenlijk ook wel goed. Ik vond het alleen wel heel irritant dat mouse en smartdrv zo veel geheugen gebruikten, waardoor je niet meer alles in je upper memory blocks kon proppen.
dat was pas met 286/386 en verder :p daarvoor was het config.sys en autoexec.bat aanpassen, eventueel middels een zelfgemaakt qbasic menuutje :p
Daarvoor hadden wij thuis een Amiga 2000. Dat werkte wat anders, AmigaDOS. ;)
Ik gebruikte hgcibm
CGA was er eerst, MDA kwam iets later (beiden 1981). Hercules kwam nog later (rond 1983).
En de Trident.
De videokaart was typisch een insteekkaart. Ik heb er later nog geheugen, losse IC's, bijgeprikt om de volle resolutie van de NEC monitor alle kleuren te krijgen!

Op een XT (8088 of 8086) zaten de poorten ook op insteekkaarten.
Eentje voor serieel... de matrixprinter.
En eentje voor parallel... de andere printer en de OPTISCHE DISKDRIVE.

[Reactie gewijzigd door Permutor op 26 maart 2014 19:23]

Veel vroegere XT machines hadden zelfs een insteekkaart voor de muis of zelfs voor de diskette- of floppydrive.
>> Leuk dat ze het openbaar hebben gemaakt!

Zeker! CP/M was al openbaar gemaakt. Nu kunnen DOS en CP/M
theoretich dus eens naast elkaar gelegt worden.
CP/M en DOS startten sneller op dan de gemiddelde windows PC.

Hier een voorbeeld van een puur Nederlandse computer met CP/M: Holborn 6100
http://www.youtube.com/watch?v=H-xoC5zRjjE

Helaas is CP/M in moordend tempo omzeep geholpen door MS-Dos.
En dus belandden deze mooie machines op straat..

[Reactie gewijzigd door Proxxima op 26 maart 2014 09:54]

De vraag is alleen wat wil je gaan exploiten op een single user, single process, geen network system?
Beetje jammer dat het screenshot duidelijk op een te recente machine is gemaakt; het font doet me aan VGA denken oid. Ik kan me niet voorstellen dat DOS 2.0 ooit op een VGA bak heeft gedraaid.
Ik denk dat je je niet moet vergissen in de resolutie van een MDA scherm uit de jaren '80. Die was 720x350 pixel. Bij de standaard console afmeting van 80x25 karakters levert dat nog een best goede letter op. (9*14 px).
De monitoren waren leverbaar in groen, amber, en 'paper-white'. Volgens mij is de screenshot iets te wit voor 'paper-white', maar als die camera een automatische witbalans had, zou het een originele monitor kunnen zijn. (Zij het dat ik bij een monitor van die leeftijd wel wat 'inbrand artifacten' zou verwachten.
Maar je ziet het raster niet. Dat verwacht je wel bij een beeldbuis.
Raster? Als dit een MDA monitor is, is hij monochroom. Die heeft geen raster.
Ja, dat kon. Sommige 16-bit ISA VGA kaarten (volgens mij waren alle VGA kaarten 16-bit) kon je gewoon in een 8-bit ISA slot douwen. Dat werkte ook. Zo kon je VGA graphics op een IBM PC/XT compatible computer draaien. Wellicht zou je een IBM 5150 zelfs kunnen uitrusten met zo'n VGA adapter en aansluiten aan een FullHD scherm. Echter de resolutie zal niet hoger zijn dan 640x480.

[Reactie gewijzigd door Trommelrem op 27 maart 2014 19:25]

Ik denk dat het zelfs op een TFT scherm is gedaan.
Denk toch dat het iets anders is: kijk eens naar de kromming in het screenshot, lijkt me dan toch geen screenshot van een VM, maar een echte foto. Ofwel van een CRT ofwel een serieuze afwijking op de lens.
Word for Windows was niet de eerste Word-versie: die kwam al uit in 1983 voor MS-DOS.
Foei Tweakers. De allereerste Word versie is uitgekomen voor Xenix... Pas paar maanden later voor MS-DOS
Inderdaad. Ze zullen wel WP bedoelen. Oh wait, dat betekent tegenwoordig Windows Phone. Maar dat betekende vroegah Word...Perfect.
WordPerfect.... 5.1.....nog examen in gedaan in 1996....Kende het door en door, maar nu moet je er me niks meer over vragen. Iets met Shift-F7 geloof ik..... Op een Tulip computer.....
Mooie tijd! Als klein ventje midden jaren '90 m'n eerste stukjes programmeersel gemaakt in Basic en later met assembly achtig iets aan de slag gegaan. Zou nog best wel eens een lekkere oude Tulip 8086 willen hebben trouwens :)
Zou nog best wel eens een lekkere oude Tulip 8086 willen hebben trouwens
Is een IBM 5160 ook goed? Asjeblieft
Tulip had ook de PC Compact 2. Dat is wellicht een van de beste XT-compatible machines ooit geweest. Had een snellere NECV20 processor en een 16850 UART ipv de 8250 UART. Ook had die machine 16 interrupts ipv 8, wat op een XT gebruikelijk is. Ook was het een van de weinige XT machines met een CMOS en support voor HD diskettes.
Ha, die goeie ouwe Dos, toen je als automatiseerder nog enige zelfbeschikking had.
Volgens mij heeft deze DOS nog geeneens ondersteuning voor prompt $P$G, zelfs edlin.exe ontbreekt :D
Volgens Wikipedia zat edlin al in MS-Dos 1.0, en dus ook in PC-Dos 2.0. Hoewel ik denk dat dat edlin.com is.
Prompt $P$G is er volgens mij al sinds DOS 2.0. Ik zal het zo eens testen.
DOS 1.0 had dat inderdaad niet, omdat er in DOS 1.0 nog geen support voor directories was en de $P functie ("driveletter:\path\") nog geen nut had.

Sterker nog, het filesystem van DOS 1.0 is niet meer compatible met latere DOS (en Windows versies). Een DOS 2.0 geformatteerde diskette kun je nog wel gewoon benaderen vanuit Windows NT 5.x. NT 6.x weet ik niet.

Vroeger prankte ik weleens mensen door de prompt variabele in te stellen in "A:\>" zodat men dacht dat men op de A-drive zat, ook al typte men 1000x C: in.

-edit-
In IBM DOS 2.10 zat prompt $P$G er in ieder geval wel in: Plaatje. Ik had IBM DOS 2.10 nog ergens in m'n archieven liggen.

[Reactie gewijzigd door Trommelrem op 27 maart 2014 23:39]

MS-DOS bron code *lol*
http://en.wikipedia.org/wiki/PTS-DOS compatible met MS-DOS 6 en je krijgt de source bij.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True