[Plug'n'Play] Wat is het eigenlijk?

[Trommelrem]

Windows 95 was Microsoft's eerste Plug and Play OS. Nooit meer gedoe met hardware installeren. Je hoefde het slechts in te pluggen en het zou feilloos werken.

Vanaf Windows 98 was dit voor USB geluidskaarten ook wel het geval. Je plugde het in en het werkte. Geen gedoe meer met drivers. Het was weliswaar wel een standaarddriver en met de driver van de fabrikant had je doorgaans meer functionaliteit, maar het werkte wel als Plug and Play. Vanaf Windows ME/2000 gold dit ook voor USB mass storage. One-driver-for-all.

Maar elk ander apparaat bleef om een driverdiskette vragen. Wellicht dat het daarom ook wel Plug and Pray heet? Er is bijvoorbeeld nog steeds geen standaard mass storage controller driver of standaard netwerkcontrollerdriver.

Anyway, Windows NT 4.0 zou niet Plug and Play zijn. Echter tijdens de Textmode setup wordt wel degelijk de HAL en de mass storage controller gedetecteerd en geinstalleerd. Tijdens de GUI mode wordt zelfs de netwerkkaart gedetecteerd en geinstalleerd. Je kon zelfs een service installeren zodat apparaten wel werden gedetecteerd, zoals in Windows 95. Geen Plug and Play, maar toch ook weer wel?

Wat heeft Plug and Play ons dan gebracht? Nu onder Windows NT 5.x en NT 6.x (Vista en 7) is er nog steeds geen standaarddriver voor de mass storage controller. Voor nieuwe ICH/AHCI controllers moet alsnog een driver worden geintegreerd omdat het OS anders niet eens opstart. Hardwaredetectie en installatie bestaat al decennia lang. In het DOS tijdperk waren er zelfs spellen die zelf de geluidskaart konden detecteren. Ik ben confused. Wat is er zo Plug and Play aan apparatuur sinds Windows 95?

[Admiral Freebee]

Plug & Play mag je niet zo letterlijk nemen. Het is eerder om aan te geven dat het eenvoudiger is om de hardware te installeren. Zo herkent het OS dat er een nieuw apparaat is, en heb je een mooie wizard die je helpt bij de juiste drivers te zoeken. Het apparaat vertelt het OS namelijk wat het is, en daarmee kan het OS op je computer naar een passende driver zoeken. Meer is het dus niet.

[RaZ]

Vroeger moest je bij al je hardware de jumpers goed zetten. Op welk IRQ die moest komen, en andere I/O settings.

Die spellen detecteerde niets, omdat het in de autoexec.bat envirment variabele stond, net zoals je nu het pad waar windows moet zoeken gewoon in %PATH% staat. Dat was met geluidskaarten, gamepoorten, en zelfs de losse controllers. Ja vroeger had je geen onboard, en was het meeste gewoon met een insteek kaart. En echt alles moest je met jumpers instellen.

Plug'n'Play heeft dit dus verholpen.

Kortweg antwoord op je vraag: Jumpers!

[Trommelrem]

Pas in het Pentium 3 tijdperk kwamen de eerste jumperless moederborden. Maar dan moest je alsnog vanalles in het BIOS instellen. Maar als ik het goed begrijp dan is een OS sowieso nooit Plug and Play maar is het BIOS en de apparatuur Plug and Play.

[Trommelrem]

Admiral Freebee schreef op zondag 11 oktober 2009 @ 11:34:
Het apparaat vertelt het OS namelijk wat het is, en daarmee kan het OS op je computer naar een passende driver zoeken. Meer is het dus niet.

Ok, dus bij de opkomst van een universele driver voor alle apparatuur krijgen we Plug and Play 1.1?
Psst: liever niet twee keer achter elkaar posten. Gebruik liever de edit-knop om je eerste bericht te wijzigen. Je kunt prima (meerdere) berichten quoten etc. vanuit de edit-scherm

[ Voor 21% gewijzigd door dion_b op 11-10-2009 20:18 ]

[RaZ]

Ik heb het niet over jumperless mobo's, maar over jumperless insteekkaarten.

Als je je nieuwe soundblaster AWE32 niet instelde met jumpers, kon je er niets mee, omdat je drivers niet wisten op welk adres die zat. Heeft 0,0 met het mobo te maken. Maar meer dat de software anders de hardware niet kon vinden.

[Trommelrem]

Ok, grappig. Ik kan me niet herinneren dat ik op mijn Soundblaster Pro in mijn 80286 systeem jumpers moest instellen. Maar dat was al zo lang geleden. Ik weet wel 100% zeker dat een EGA of VGA kaart direct werd herkend. Geen jumpers voor nodig. Maar ik denk dat ik het idee wel begrijp. Wel een misleidende term is Plug and Play dus. Zelfs Windows 3.1 en NT 3.1 zijn dus in feite Plug and Play capable.

[ Voor 23% gewijzigd door Trommelrem op 11-10-2009 11:51 ]

[Admiral Freebee]

Nee, maar vaak moest je in je BIOS dan nog wel wat instellen, aangezien je anders conflicten kon krijgen.

[Trommelrem]

Dus dat zijn de Plug and Play conflicten als je teveel PnP hardware in een moederbord plugde. Daarna moest je dus alsnog IRQ's handmatig toewijzen. Plug and Play was dus wel een verbetering, maar wel een kleine.

[RaZ]

Windows is nooit een OS geweest, pas vanaf de NT serie. En dan ook geen NT 3.51, en 4 ook nog niet echt hoor.

Dus alle consumenten Windows versies, t/m ME, waren niet meer dan een grafische schil over DOS heen.

Aangezien DOS geen P'n'P OS is, kan Windows dat ook nooit geweest zijn.

Het is dat ik geen 386'ers meer heb, anders had ik wel een autoexec.bat en een config.sys kunnen posten waar dat allemaal ingesteld stond.

Vroeger had je voor SoundBlaster eigen settings: SET BLASTER = xxxxx
En voor de Gravis Ultrsound had je weer andere.. Games keken gewoon naar die settings, en konden op die manier dus 'concluderen' dat er een soundcard was.

[Trommelrem]

RaZ schreef op zondag 11 oktober 2009 @ 12:01:
Windows is nooit een OS geweest, pas vanaf de NT serie. En dan ook geen NT 3.51, en 4 ook nog niet echt hoor.

Windows NT 3.1, NT 3.5 en NT 3.51 waren niet gewoon een grafische schil hoor. Het waren een volwaardige OSs zonder DOS afhankelijkheid.

code:

SET SOUND=C:\PROGRA~1\CREATIVE\CTSND
SET BLASTER=A220 I5 D1 H5 P330 E620 T6

Dit bedoel je?
Zit t/m Windows ME nog steeds in de AUTOEXEC.BAT, wellicht voor legacy doeleinden.

[ Voor 8% gewijzigd door Trommelrem op 11-10-2009 12:14 ]

[RaZ]

Windows NT 3.1 en 3.11 for workgroup (beide consumenten Windows) draaide ENKEL EN ALLEEN op MS-DOS. Als je PC-DOS had, weigerde het simpelweg te installeren.

Je startte, na DOS geladen was. Win.exe

NT Begon pas bij 3.51

[Trommelrem]

Windows NT 3.1 start uit zichzelf en heeft geen DOS afhankelijkheid. Het had dezelfde interface als Windows for Workgroups 3.1 maar de kernel was volledig verschillend.

Ik heb hier nog ergens de installatiediskettes liggen. Zal eens een screenshot voor je maken

[Herko_ter_Horst]

Windows 3.1 en 3.11 (zonder NT, en al dan niet "for Workgroups") waren inderdaad consumenten/SMB Windows versies die als een grafische schil vanuit DOS werden opgestart.

Windows NT 3.1 was echter wel degelijk de eerste NT versie: een geheel 32bits OS, zonder DOS ondergrond.

[ Voor 27% gewijzigd door Herko_ter_Horst op 11-10-2009 12:24 ]

[RaZ]

Ruk, ik tik vanalles verkeerd door elkaar.

De windows 3.1 en 3.11 for workgroups (consumenten versie), dus niet de NT serie, draaide niet zonder dat er MS-DOS was.

De NT versies waren inderdaad wel zelfstandige OS'en.

[Trommelrem]

Alsjeblieft. Antiek OS
Met hardwaredetectie tijdens de Textmode setup

[CodeCaster]

Er is dus een verschil tussen hardwareherkenning en hardwareaansturing. Dat heel gedoe met jumpers om IRQ / DMA in te stellen hoeft niet meer dankzij Plug&Play.

[dion_b]

Trommelrem schreef op zondag 11 oktober 2009 @ 13:03:
[afbeelding]

Alsjeblieft. Antiek OS
Met hardwaredetectie tijdens de Textmode setup

offtopic:
Hee, dat lijkt verdraaid veel op de UI van OS/2 2.0

CodeCaster schreef op zondag 11 oktober 2009 @ 14:56:
Er is dus een verschil tussen hardwareherkenning en hardwareaansturing. Dat heel gedoe met jumpers om IRQ / DMA in te stellen hoeft niet meer dankzij Plug&Play.

Het is maar wat je "gedoe" noemt. Jumpers vereisen handmatig ingrijpen, maar het is - zodra je de jumpers voor je hebt - altijd volledig duidelijk welke mogelijkheden er zijn en welke gekozen is. PnP deed het automatisch, maar zeker de eerste 5 jaar ging het lang niet altijd ook automatisch goed. Zelfs nu nog krijg je nog gedoe met IRQ routing tabellen in BIOS die niet doen wat ze moeten.

* dion_b heeft vaak heimwee naar de tijd dat je resources gewoon met jumpers instelde

[Trommelrem]

dion_b schreef op zondag 11 oktober 2009 @ 20:21:
[...]

offtopic:
Hee, dat lijkt verdraaid veel op de UI van OS/2 2.0

Ik heb ooit de diskettes van OS/2 weten te bemachtigen, maar helaas zijn die niet goed meer
Sommige NT versies (ik dacht NT 3.1 t/m 5.0) hadden zelfs nog 16-bit OS/2 support.

Wel heb ik nog (werkend) zowel Workstation, Server en Advanced Server van NT 3.1, NT 3.5, NT 3.51 en natuurlijk NT 4.0. Ik heb zelfs nog ergens NT 4.0 Terminal Server in een productie omgeving voor een bepaalde (hele oude) applicatie. Grappig om te zien dat de huidige RDP-client nog steeds compatible is met NT 4.0 Terminal Server.

Het is maar wat je "gedoe" noemt. Jumpers vereisen handmatig ingrijpen, maar het is - zodra je de jumpers voor je hebt - altijd volledig duidelijk welke mogelijkheden er zijn en welke gekozen is. PnP deed het automatisch, maar zeker de eerste 5 jaar ging het lang niet altijd ook automatisch goed. Zelfs nu nog krijg je nog gedoe met IRQ routing tabellen in BIOS die niet doen wat ze moeten.

* dion_b heeft vaak heimwee naar de tijd dat je resources gewoon met jumpers instelde

Tegenwoordig komt het zelfs vaak voor dat de PnP-settings zichzelf automatisch wijzigen. Op Pentium 4 systemen heb ik nog vaak genoeg hardwareconflicten gehad, maar PnP stond niet toe dat je zelf bepaalde settings maakte. Vaak vraag ik me af wat PnP nou voor de eindgebruiker heeft betekend. Bepaalde problemen zijn opgelost, maar er zijn ook problemen bij gekomen die men prima had kunnen oplossen.

[the_stickie]

natuurlijk is het wel dankzij PnP dat een normale eindegbruiekr nu ene upgrade aan z'n pc kan doen. In het verleden moest je a) weten welk slot werkt met welke IRQ b) de IRQ en DMA met jumpers instellen op de uitbreidingskaart c) de driver oproepen in config.sys/autoexec.bat al naargelang het device (als dat al lukte omdat je niet mmor over genoeg van het juiste "soort" ramgeheugen beschikte) en dan in elke applicatie nogmaals gaan opgeven op welke irq en dma een device te verwachten viel. Bovendien is het ljstje IRQ's beperkt en grotendeels ingenomen door syteemdevices.
PnP zou dat allemaal veranderen: de bios detecteerd een nieuw device, kijkt welke IRQ en DMA beschikbaar zijn en vertelt het OS dat er een nieuw apparaat gevonden is met die IRQ en DMA en een bepald apparaatID. Maar dan begint de miserie pas. . Ten eerste krijgt het OS een bepaalde vrijheid om in overleg met het BIOS een anderre IRQ en DMA te kiezen.Ten tweede zijn er nog altijd te weinig IRQ's beschikbaar en si beslotten dat door in de drivers van apparaten er rekening mee te houden, IRQ's gedeeld moesten kunnen worden tussen verschillende apparaten. Een hele uitdaging blijkbaar voor de devvers, want dit avontuur bezorgde de technologie ook bijnamen als Plug'n Pray of Plug'n Pay. Door een slecht driver voor een of ander apparaat kon een ander apparaat dienst weigeren, of erger nog de al-zo-stabiele windows kernel zwaar op zijn bek gaan (bsod). Bovendien wezen hardwarefabrikanten alsmaar naar mekaar of bleven halstarrig vasthouden aan hun oude standaarden (zelfs recente soundblasters vragen nog steeds dezelfde irq's en weigeren soms dienst als die gedeeld wordt.)
Nog een extra leukigheidje is dat niet elk slot in je pc bedraad is om elke IRQ te gebruiken: een paar kaarten van plek wissel wordt dan de oplossing voor een hardnekkig sowftareprobleem...

Gelukkig zijn we vele jaren verder en werkt alles nu veel eenvoudiger. Dankzij bijvoorbeeld het certifiëringsprogramma dat Microsoft hanteert voor zijn drivers, maar ook betere ontwikkelaars met nog betere tools, werkt Plug'n Play nu zoals het ooit bedoelt was... maar je moet nog steeds zelf op zoek naar je driver

[Trommelrem]

the_stickie schreef op zondag 11 oktober 2009 @ 23:02:
Nog een extra leukigheidje is dat niet elk slot in je pc bedraad is om elke IRQ te gebruiken: een paar kaarten van plek wissel wordt dan de oplossing voor een hardnekkig sowftareprobleem...

Dat was heel irritant ja. Bepaalde PCI sloten kregen gewoon hardnekkig bepaalde IRQ's toegewezen.

Met de juiste hardware, alles op handmatig en WHQL drivers moet bijvoorbeeld zelfs Windows ME stabiel te krijgen zijn.

Gelukkig zijn we vele jaren verder en werkt alles nu veel eenvoudiger. Dankzij bijvoorbeeld het certifiëringsprogramma dat Microsoft hanteert voor zijn drivers, maar ook betere ontwikkelaars met nog betere tools, werkt Plug'n Play nu zoals het ooit bedoelt was... maar je moet nog steeds zelf op zoek naar je driver

En dat met die drivers meot toch op te lossen zijn?

Zo is er al sinds Windows 98 een universele USB-audiodriver en sinds Windows ME een universele USB-massstoragedriver. Een universele netwerkkaartdriver zou ook mogelijk moeten zijn (PXE-boot werkt bijv. met een universele hardware-ingebakken-driver). Helaas is men ook afgestapt van de universele mass-storage driver. T/m ICH7 werkt gewoon nog op de "Standard IDE"-driver, maar vanaf ICH8 moet je de AHCI driver hebben en hoe hoger je ICH, hoe nieuwer je driver moet zijn. Waarom kan het niet compatible zijn met de standaard driver? Ik snap dat er dan een performance verlies is, maar met bijvoorbeeld een werkende netwerkkaart en mass storage controller kun je in ieder geval wel de drivers downloaden.

[ Voor 3% gewijzigd door Trommelrem op 12-10-2009 00:13 ]

[Jazzper]

SET BLASTER=A220 I5 D1 H5 P330 E620 T6

sweet memories! adress, irq en dma waren standaard meestal al goed. Soms konden spellen het ook detecteren (of kwam het je op een vastloper te staan). AdLib had je ook nog. Je moest met jumpers in de weer en tevens goed kijken of je niet conflicteerde met je videokaart of andere ISA kaart. Daarom waren grote moederborden ook ideaal. Kon je een beetje variereren met hoogtes

[the_stickie]

Trommelrem schreef op maandag 12 oktober 2009 @ 00:12:
[...]


En dat met die drivers meot toch op te lossen zijn?

Z

is grotendeels opgelost: voor drivers die niet meegeleverd zijn kan online gezocht worden in de WHQL drivers. Dat daar vaak niks te vinden is, is alleen aan de HW-fabrikant te wijten.
Een andere technologie is het inbouwen van flashgeheugen in het device met daarop de driver. Maar dat is imho ook gene oplossing: de HW bevat dan slecht drivers voor een bepaald aantal systemen en veroudert dus heel snel. om die driver te updaten moet je weer aan de slag met een download etc (been there done that voor zo'n vodafone usb-krel)