Managed hosting door True

De kijk van Van Eijk: Terug naar school

 

"Pap, wil je deze cd-rom nog even voor me installeren? Moet ik morgen een proef over doen", vroeg mijn dochter vorige week. Eitje, dacht ik. Maar bij het gebruik van de software crashte die acuut, met een foutmelding die me bekend voorkwam.

De volgende dag meldde de helpdesk dat ik de eerste was met dit probleem. Vreemd, want de halve klas had de proef gemist omdat de software niet op Vista van Microsoft aan de gang was te krijgen. Dat liet ik niet op me zitten, en ik ontdekte vervolgens dat deze software onder XP wel werkt, maar alleen als de gebruiker administratieve rechten heeft. Bij gebruikers met beperkte rechten geeft het dezelfde foutmelding als onder Vista.

Toen werd ik boos. In mijn woordenboek is dit slordig programmeren. Er is geen enkele functionele of beheernoodzaak om administratieve rechten te hebben bij het draaien van dit programma. Wat ik niet begrijp is hoe professionele softwareontwikkelaars zulke elementaire zaken over het hoofd kunnen zien.

Naar mijn mening is er voor ouders van scholieren een belangrijke taak in verantwoordelijk computergebruik. Windows geeft vanaf XP eindelijk mogelijkheden om op thuiscomputers de rechten van gebruikers in te perken. Gelukkig maar, want ik wil om verschillende redenen niet dat mijn kinderen ongezien software installeren.

Ik begrijp dat niet alle ouders deze taak aankunnen. Dat is jammer. Maar het feit dat de meeste ouders geen autorijles kunnen geven, leidt er nog niet toe dat we kinderen maar zelf laten uitproberen wat de verkeersregels zijn.

Ook in het bedrijfsleven kom ik te vaak software tegen die een loopje neemt met elementaire beveiligingsprincipes. De projectleider drukt dan vaak de uitrol toch door. Het resultaat? Veiligheidsrisico's ter grootte van een hangardeur, problemen met draaien in gevirtualiseerde omgevingen, en duur beheer. Is dit kwade opzet? Meestal niet, eerder incompetentie. Het antwoord? Terug naar school met die programmeurs.

Peter van Eijk is onafhankelijk adviseur (http://www.digitalinfrastructures.nl/).

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/2719921). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

De IT-wereld is erin geslaagd om zaken zo ingewikkeld te maken dat je tegenwoordig voor de ontwikkeling van zelfs het kleinste systeem eigenlijk een heel team van specialisten nodig hebt. Dat is het echte probleem en dat los je niet op door net te doen alsof het een kwestie is van onvoldoende geschoolde programmeurs.

De beschukdigende vinger in deze 'kijk van van Eijk' doet me een beetje denken aan de kano vol stuurmannen die de enige roeier in het team verwijten dat hij zich onvoldoende inspant.

Ik kan me nog een interview met Peter Molyneux herinneren. (voorheen de directeur van Bullfrog)

Die vertelde dat hij een C++ programmeerboek hekelde, waarin hij een opmerking tegenkwam van een programmeur die zei: "De beste manier voor het optimaliseren van je computer is een snellere computer kopen."

Dat valt ook onder slordig programmeren.

"Optimaliseren van je programma" bedoelde ik natuurlijk ;)

"Terug naar school met die programmeurs."
Hier ben ik helemaal niet mee eens Peter.
Je uitspraak zou in mijn ogen moeten zijn
"Back to the drawingboard met dat OPERATING SYSTEM!"

1. Waar is de OPEN SOURCE van het Windows Kernel en de rest van het besturings-systeem?

2. Waarom is dat **** windows zo complex GEMAAKT dat je eerst tien jaar MSDN-er moet zijn, om het fatsoenlijk te kunnen programmeren?? en dan nog heb je het gevoel dat er iets ($hidden$) gemaakt is???

3. Waar is de complete documentatie van dit windows platform?
SDK's, DDK's, Whitepapers geven nog steeds niet 100% weer wat je ermee kunt? Waarom duiken er op internet nog steeds artikelen op over "undocumented!!! win32 api calls???"

4. Waar zijn de mooie, duidelijke voorbeelden die je als - aanstand micro$oft programmeur - laten zien hoe ALLES werkelijk werkt? Principele voorbeelden die in detail laten zien what's going on under the hood?
Zelf Microsoft's eigen "bla bla bla msce, msdn, resourcekit tools" verbergen zaken die onder de windows motorkap draaien!


Nu heb je een setje vage, slecht gedocumenteerde win32 api calls, bosje dot_net aanroepen, hoopje COM en COM+ componenten (zonder diepte inzicht), geen gedetaileerde architectuur overzicht "under the hood" en daar moet je het maar mee doen als welwillend programmeur..??

Vind je het gek dat er dan af en toe wat crasht;
- als de leverancier van je platform geen 100% inzicht / toegang wil geven tot de kelders van je operating system
- als je geen 100% documentatie hebt van alle patches, security breaches, updates servicepacks
- als je buiten Redmond meer info over hun eigen produkten kan vinden dan op de webserverfarm achter www.micro$oft.com??


In mijn woordenboek heet dit:
- Rijk worden door gebrek aan documentatie over de rug van je klanten
- Bewust afhankelijkheid creeeren.
- Een verrot operating system, bad by design

Tot slot:
"Dont kill the developer / programmer please!"
Zij/Hij zitten in hetzelfde schuitje als jij (klant van Microsoft) Zij zijn ook gehandicapt door gebrekkige tools en gebrek aan goede programmeer voorbeelden en complete 100% documentatie!

"Smash your windows and switch to Open Source"
Dan kan de programmeur zelf de source code lezen (en verbeteren) van het platform waar ie tegenaan programmeert.

(en dan maar hopen dat je compiler fabrikant niet stiekum iets in je code injecteert ;-)

Aan de basis van het probleem ligt de nogal gammele implementatie van gebruikersrollen in het Windows platform. Het is heel onduidelijk welke zaken er mogen worden uitgevoerd door de diverse gebruikers. Installeren is iets wat een gebruiker normaalgesproken niet mag doen, maar soms wel. Het is heel onduidelijk omdat bij installatie van een applicatie er soms zaken worden toegevoegd of gewijzigd in het OS en dat is weer het gevolg van een gammele architectuur. In andere OSsen wordt dit beter geregeld: een installatie wijzigt nooit iets in het OS of 'legt' er een laagje bovenop, maar in het laatste geval is er een hogere 'macht' nodig om dit voor elkaar te krijgen.

In Windows is het vaak niet mogelijk om een applicatie te ontwikkelen zonder zaken te wijzigen in het OS (bijv. registry wijzigingen) of eraan toe te voegen (.dll files in system32) en dat is wat er fout gaat. Het kan ook luiheid zijn van de ontwikkelaars, in elk geval het simpelweg de schuld leggen bij de ontwikkelaars is wat kort door de bocht.

@Ronald Vermeij

Leuk commentaar tegen Windows die kant noch wal raakt. Waarom zijn er andere programmeurs op het Windows platform wel instaat om die problemen zoals Peter van Eijk ze meldt wel af te vangen? Dat kunnen ze alleen maar als ze weten waar ze mee bezig zijn.

@Cpt
[quote]In Windows is het vaak niet mogelijk om een applicatie te ontwikkelen zonder zaken te wijzigen in het OS (bijv. registry wijzigingen) of eraan toe te voegen (.dll files in system32) en dat is wat er fout gaat. Het kan ook luiheid zijn van de ontwikkelaars, in elk geval het simpelweg de schuld leggen bij de ontwikkelaars is wat kort door de bocht.[/quote]

Ook dit is dus klinkklare onzin. Als een applicatie wijzigingen in de Registry moet doen waar het niet zou mogen, dan kom je dergelijke problemen tegen. Wijzigingen die een applicatie doet tbv van de gebruiker moet men dan ook op de juiste locatie in de Registry doen, dwz HKEY_Current_User.

Indien een applicatie andere dll's nodig heeft, moet men deze plaatsen op de locatie waar de applicatie wordt ge?nstalleerd. Een applicatie hoort niets te plaatsen in de System32-folder. De naamgeving geeft al aan dat dit voor het besturingssysteem zelf is.

De wijze van programmeren zoals de vermelde applicatie is gemaakt, is jaren geleden al in de ban gedaan. Het is dan ook een fout van de programmeur die hiermee geen rekening houdt en per direct op een opfriscursus moet.

En zoals uit al het commentaar hier blijkt schort er niet op een enkele plaats wat aan maar over de gehele linie. Wie doet wat, wanneer en in hoeverre? Afgebakende taken maar ook goed omschreven mogelijkheden behoren bij een (duur) OS. Het boekje dat bij XP of Vista zit weleens bekeken? Dit geld natuurlijk ook voor programmeurs die andere programma's of tools ontwikkelen die op een dergelijke OS moeten draaien en dit ook zonder deugdelijke documentatie de markt op gooien.

Terug naar DOS! ;-)

@Jachra...
Wat was er ook al weer mis met .ini-files?
Lekker simpel, lekker makkelijk gewoon in de folder waar je applicatie executabel staat.

Waarom allemaal zo moeilijk op dat Windows-platform??
Waarom gerommel in een registry? Die niet eens goed gedocumenteerd is?

@Ronald Vermeij

Het is niet zo moeilijk op het Windows Platform. Immers kan men ook nog steeds kiezen voor een INI-bestand in de eigen folder. Men hoeft niets te doen met de Registry, maar het kan wel.

De Registry is op nagenoeg goed gedocumenteerd. Immers dient alles wat een gebruiker aan instellingen heeft te worden opgeslagen in HKEY_CURRENT_USER en niet in de andere hives.

Het feit dat dergelijke programmeurs het niet weten en niet om kunnen gaan met het schrijven van software voor een systeem waarbij een gebruiker geen lokale administrator rechten heeft, vereist dat ze per direct op een spoed cursus worden gezet.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×