ik denk dat nog meer integratie beter is, simpelweg omdat de huidige aanpak van DLL's juist de zwakke schakel is.
Windows heeft inderdaad het '.dll'-hel probleem, maar ik zie in het artikel nergens staan dat ze geen .dlls meer gaan gebruiken.
Als elk programma zijn eigen geintegreerde aanpak heeft ipv afhankelijk moeten zijn van andermans bugs in andermans DLL's, dan is dat een enorme vooruitgang.
Ook al gebruik je in plaats van .dlls een andere techniek (zoals in .net zit) je bent nog steeds afhankelijk van dat andere component. Of wil je het wiel opnieuw uitvinden voor elk programma? Veroorzaakt veel meer bugs dan componenten (.dll, dat .net ding, ...).
Ook linux met zijn *.so rommel doet het niet goed in dat opzicht. Bij linux hebben we er nog geen last van omdat niet iedereen linux draait en er weinig software geinstalleerd wordt die 'hot' is.
In linux kan je ook statisch compileren (Windows vast ook). Als je dan een bug in een library hebt, dan kan je alles opnieuw compileren. Lijkt me niet handig of snap ik niet wat je bedoelt? Daarnaast, waarom is *.so een rommel? De vele bestanden/symlinks in /lib en /usr/lib (mee eens, maar dat kan je samen met /usr/bin mooi negeren)?
Echter zodra je 2 compilers in linux installeert (gcc + intel c++ bijvoorbeeld) dan ben je al de pineut. Of de een werkt of de andere.
Verschillende gcc versies werkt uit ervaring prima. Intel en gcc kunnen ook gewoon tegelijk geïnstalleerd zijn (hoewel geen persoonlijke ervaring), terwijl ze alletwee blijven werken.
Bij windows zijn al deze DLL problemen al enige jaren vrij duidelijk. Een aanpak die mogelijk het einde betekent van dat soort gezeur zou erg fijn zijn.
De linux *.so werkt niet hetzelfde als .dll, gelukkig. Verder is dat .dll opgelost (zo ver ik weet) met dat .net. Hoe ut precies zit mag iemand anders uitleggen

Windows heeft inderdaad het '.dll'-hel probleem, maar ik zie in het artikel nergens staan dat ze geen .dlls meer gaan gebruiken.
Ze willen nog steeds backwards-compatible zijn, dus helemaal oplossen zullen ze het niet. Ze hebben er in ieder geval sinds Windows 2000 voor gezorgt dat systeem DLLs niet makkelijk overschreven worden.
De linux *.so werkt niet hetzelfde als .dll, gelukkig. Verder is dat .dll opgelost (zo ver ik weet) met dat .net. Hoe ut precies zit mag iemand anders uitleggen.
Een .so is toch gewoon een dynamic library? Oftewel at runtime laad je de library en haal je pointers naar de functies die je nodig hebt daaruit en gebruik je die. Net zoals op Windows. Ze zullen uiteraard allebei verschillend werken, zo kan Windows at load time het geheugen adres waarop de DLL wordt geladen aanpassen en zorgen dat alle functies gewoon blijven werken. Misschien kan Linux dat ook, zo diep is mij Linux kennis niet.
Wat betreft die ".net zooi". Dat noemen ze tegenwoordig 'assemblies'. Het zijn in feite nog steeds gewoon DLLs, maar ze bevatten nu ookj versie informatie. Dus als je een applicatie bouwt die met versie 9.32.4.2345 van een bepaalde DLL werkt, dan zal die applicatie, wanneer je hem opstart, als eerst proberen de DLL met die specifieke versie te laden. Als dit niet lukt pakt hij de volgende hogere versie. Dit houd natuurlijk ook in dat je meerdere dezelfde DLLs op je systeem geinstalleerd kan hebben, ze worden apart gehouden op basis van versie nummers. Als je het .NET framework hebt geinstalleerd moet je maar eens kijken in %WINDIR%\assembly Kijk wel vanuit een DOS venster, want de Explorer zal de informatie anders weergeven.