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 , , 43 reacties
Bron: CRN

Volgens bronnen van CRN is Microsoft in een vergevorderd stadium van onderhandelingen om Softricity, ontwikkelaar van virtualisatiesoftware, over te nemen. De deal zal waarschijnlijk nog voor WinHEC volgende week afgerond zijn. De geruchten houden daar echter niet op, want de verwachting is dat Microsoft volgende week bekend zal maken de ontwikkeling van het virtualisatieproduct met de codenaam 'Viridian' te versnellen en officieel het virtualisatiemanagementplatform Carmine zal aankondigen. Op WinHEC zal volgens bronnen Virtual DLL worden onthuld, een feature van Windows Vista die samen met Softricity is ontwikkeld. Virtual DLL biedt niet hetzelfde als de volledige virtualisatie van applicaties zoals Softricity's SoftGid-platform, maar zal het mogelijk maken om de registerinstellingen van applicaties te virtualiseren. De feature maakt het mogelijk om een virtueel register te hebben in plaats van één register zodat meerdere versies van dll's in het register opgenomen kunnen worden. Hiermee moet de 'DLL hell' voor eens en voor altijd voorbij zijn, aangezien applicaties geen conflicten meer zullen hebben. Zo is het bijvoorbeeld mogelijk om Office 97 tegelijk met Office 2003 te installeren.

SoftricityMicrosofts recente activiteiten op het gebied van virtualisatie, kunnen niet los worden gezien van de aanstaande introductie van ESX Server 3.0 en VirtualCenter 2 door VMware. Naast de introductie van eigen virtualisatiesoftware, poogt Microsoft de acceptatie van VMwares platform te vertragen door de introductie van Veridian te versnellen. Waarschijnlijk zal Veridian in het vierde kwartaal in de vorm van een gesloten bètarelease aan een selecte groep worden voorgesteld. Grote klanten van Microsoft zetten druk op het bedrijf om snel met VMware-achtige oplossingen te komen, omdat zij anders zullen overstappen. Oorspronkelijk stond de opvolger van het standalone Virtual Server-product op het programma voor 2006 of 2007. Inmiddels heeft Microsoft echter bekendgemaakt dat Veridian pas in R2 van Longhorn Server zal worden geïntegreerd en dit duwt de release naar 2009 of 2010. Recent heeft Microsoft bekendgemaakt zijn virtuele-harddiskformaat aan het opensourcebedrijf XenSource te licenseren.

Moderatie-faq Wijzig weergave

Reacties (43)

De feature maakt het mogelijk om een virtueel register te hebben in plaats van één register zodat meerdere versies van dll's in het register opgenomen kunnen worden. Hiermee moet de 'DLL hell' voor eens en voor altijd voorbij zijn,
Toch vreemd hoe microsoft een probleem oplost wat ze zelf gecreerd hebben. Wanneer applicaties gewoon, zoals vroeger in DOS, alle bestanden die ze nodig hadden in hun eigen directory zouden houden dan had je dat hele 'DLL hell' probleem niet eens gehad en hadden we daar nu ook geen virtualisatie voor nodig gehad.

Ik heb het systeem van shared/common en system files nooit gesnapt. Zet alles in één directory en je hebt nooit problemen met verschillende versies, deinstallatie en een algeheel vertraagd systeem doordat allelei applicaties vinden dat er een x aantal DLL's bij het opstarten geladen moeten worden omdat hun applicatie dan iets sneller opstart... :'(
Ik heb het systeem van shared/common en system files nooit gesnapt. .

Nou dan zou ik nog maar eens goed nadenken over het voordeel van shared libraries, want ze zijn er natuurlijk niet voor niks...

Bijvoorbeeld... Updates van libraries (security, performance etc), geheugen besparing als meerdere programma's dezelfde functionaliteit nodig hebben, plugins en programma's die met DLL's met dezelfde interface verschillende implementaties van hetzelfde leveren, etc, etc...

Zet alles in één directory en je hebt nooit problemen met verschillende versies, deinstallatie en een algeheel vertraagd systeem doordat allelei applicaties vinden dat er een x aantal DLL's bij het opstarten geladen moeten worden omdat hun applicatie dan iets sneller opstart..

Zet alles in één directory en je krijgt het nooit meer voor elkaar om generieke functionaliteit gebruikt door meerdere applicaties betrouwbaar en beheersbaar te upgraden, en AL je programma's starten langzamer op omdat ze allemaal dezelfde shit als private code gaan laden bij het opstarten.

Shared libraries zijn toch wel een vrij fundamenteel onderdeel van moderne computersystemen en OS-en hoor...

Overigens bewijzen unix systemen dat shared libraries helemaal niet tot DLL hell hoeven te leiden, zelfs (en misschien wel JUIST) door niet met een algmeen register te werken, maar via losse tools (ld, ldconfig) en een consequent versiesysteem. Applicaties kunnen op die manier heel precies kiezen welke versie van een lib ze willen (0.1.4.3), of juist naar 'een versie 0.1.x.y' waarvan zeker is dat deze een bepaalde major versie van een interface support. Op die manier kunnen verschillende versies van libs gewoon netjes naast elkaar leven zonder conflicten etc...
Toegegeven shared libraries zijn er niet voor niets.
Ik heb daar ook niets op tegen maar geef minder om geheugen en harddisk ruimte dan om een stabiel en snel systeem.
Er moeten dus ook wel Shared libraries blijven maar die moeten applicaties gewoon in hun eigen directory zetten en zelf zorgen voor de updates daar op. Alleen Windows(MS) mag algeheel gedeelde bibliotheken aanbieden (mfc etc)
Er moeten dus ook wel Shared libraries blijven maar die moeten applicaties gewoon in hun eigen directory zetten en zelf zorgen voor de updates daar op
Dan kan je dus net zo goed statisch gaan linken, want op die manier is het voordeel van shared libraries dus volledig weg. Het gaat overigens ook niet echt om het geheugengebruik, een library van een paar MB maakt inderdaad niet uit op een harddisk van meerdere gigabytes. Maar stel als je meerdere applicaties hebt die van dezelfde library gebruik maken, dan is het voor een systeembeheerder niet echt feest als alle applicaties los van een update voorzien moeten worden.

Overigens is het redelijk goed in de hand te houden als de ontwikkelaars van die shared libraries zich aan een aantal elementaire regels houden. Dus geen wijziging van methodes en properties, alleenaanvullingen die de huidige werking niet draws zitten.
Lol, jij hebt dan ook geen idee wat shared libs zijn :D. In Linux zit inderdaad een aardig systeem, wat de hell voor een groot deel voorkomt.

Moet trouwens zeggen dat ik er in Windows de laatste tijd ook een stuk minder last van heb. In Vista zou het ook opgelost moeten zijn (wat ik van een MS presentatie begreep).
Vraag ik mij af. Het probleem blijft bestaan zolang er legacy setups blijven bestaan. Microsoft's MSI biedt al grote voordelen op het gebied, maar legacy setup's moeten eerst herpackaged worden voordat er helemaal voordeel uit gehaald kan worden.

Nadeel is dat na herpackagen van een legacy setup, meestal in het register nog de meeste problemen blijven bestaan. Een virtueel register zou dus echt super zijn
Toch vreemd hoe microsoft een probleem oplost wat ze zelf gecreerd hebben
Je vraagt je af wat MS nog eingelijk goed kan doen bij sommigen. Het oplossen van problemen uit vorige versies is ook al niet meer toegestaan kennelijk.

Ik neem aan dat de auteur van dit stukje voorstelt om MS maar aan linus te verkopen of zo?


Nu even inhoudelijk, de DLL hel was een heel goed initiatief juist om het gebruik van bibliotheken te optimaliseren. Helaas bleek dat in de praktijk daar nogal wat haken en ogen aan zaten die vaak veroorzaakt werden door installers van third party software. Het beschermen van system dll om zodoende de syteem versies te beschermen was een eerste stap, deze oplossing lijkt nog fraaier en zal veel mogelijkheden bieden voor het draaien van oude software versies op nieuwe systemen. Vooral dat laatste zal de acceptatie bij bedrijven groot maken.
Wat is het probleem met een deftig versienummer-systeem zoals bij unix en linux? Dat zou IMHO nuttig geweest zijn, de huidige DLL hell is wel degelijk het gevolg van een ontwerpbeslissing bij MS.
Niet geheel. De dll's kunnen perfect versienummers kwijt. Echter hebben sommige softwareontwikkelaars bedacht dat ze van de originele dll wel een klein beetje kunnen veranderen / toevoegen en dat onder dezelfde versie konden uitbrengen (of helemaal geen versienummer meer meegeven) zonder de naam te wijzigen..
Net zoals de meeste problemen onder Windows, wordt ook dit probleem veroorzaakt door incompetente ontwikkelaars en eindgebruikers die eigenwijs zijn om matige werkende applicatie te blijven gebruiken.

Dll-hell is ontstaan doordat sommige inventieve ontwikkelaars lui zijn en ongestructureerd te werk gaan. Ze hebben een goed idee voor een applicatie, maar echt ontwikkellen kunnen ze niet. Doordat het idee van de applicatie goed is, wordt het veel gebruikt, maar onderliggend is het een grote puinhoop.
Je vraagt je af wat MS nog eingelijk goed kan doen bij sommigen. Het oplossen van problemen uit vorige versies is ook al niet meer toegestaan kennelijk.
Het oplossen van problemen wel ja... maar dit is een workaround en nog een smerige ook. Het is alsof je jarenlang iedereen in de familie dezelfde naam hebt gegeven en nu daar een oplossing voor hebt: elke keer als je met meerdere mensen uit de familie bij elkaar bent, zet je ze allemaal in een aparte kamer, zodat het duidelijk is tegen welke "Jan Jansen" je het hebt, terwijl de enige juist oplossing is: iedereen een eigen naam geven.
Sorry hoor SED maar dan ken je mij niet.
MS doet een heleboel goed in mijn ogen en ik ben totaal geen ms basher. Alleen vind ik het jammer dat er nu een workaround wordt gemaakt voor een probleem die niet eens nodig was.

Ik weet zeker dat MS het ook liever anders zou oplossen maar om backwards compatible te blijven en ervoor te zorgen dat een heleboel software nog blijft werken moeten ze nu deze workaround maken.
Het probleem is ontstaan door steeds backwards compatible te blijven.. Als MS zou zeggen "vanaf de volgende release van on OS kun je alle bestaande software over de schutting mikken.." zou iedereen ook boos worden.. Legacy is iets waar je moeilijk vanaf komt, zeker als je software zo "polpulair" is dat het grootste gedeelte van de wereld er van afhankelijk is net als van de software die door derden geschreven is en geinstalleerd op je OS..
Het is niet eenvoudig.. maar ze zijn op de goede weg, steeds ene tuk je minder legacy toelaten welke door "natuurlijk verloop" van nieuwere versies van de derder-partij software minder nodig is..

In deze is de vergelijking *nix/MS niet van toepassing.. Ik bemerk dat ik *nix vaker geacht wordt al je software te updaten (het is tenslotte toch gratis) en dan je OS upgraden en bij Windows is het nou eenmaal zo dat software vaak niet gratis is en dus niet altijd ff geupgrade zal worden..
Dat ligt niet eens aan MS maar aan de derde partijen die ook commercieel denken..
En stel nou dat je een shared file van 50 MB hebt, en je hebt 30 applicaties die die file gebruiken; dan moet je hem 30 keer op je schijf hebben staan? Niet ideaal. Aan de andere kant met de huidig el cheapo harddiskprijzen ook niet problematisch meer hoor, dat is waar.

Maar neem nu een securitybug in zo'n library. Nu is het een kwestie van één keer updaten en al je applicaties zijn weer veilig :). Als elke app z'n eigen kopie had moet je alle applicaties apart gaan updaten; niet handig en niet veilig.

En wat betreft het preloaden van libraries; daarvoor maakt het al of niet geshared zijn natuurlijk helemaal niets uit :)

edit:
Okee, volgende keer eerst maar weer F5 voor ik zo'n verhaal ophang :P
En stel nou dat je een shared file van 50 MB hebt, en je hebt 30 applicaties die die file gebruiken; dan moet je hem 30 keer op je schijf hebben staan? Niet ideaal.
En hoe lang denk jij dat het gaat werken wanneer die 30 applicaties voorzien worden van updates en verschillende versies van die DLL eisen?
Een security update brengt vrijwel nooit een ABI wijziging met zich mee, en applicaties zullen dus zonder wijzigingen met beide versies werken. Net zoals onder unix securty updates geen nieuwe .so versie dragen.
Leg dat maar eens uit aan HP. HP-UX security patches kunnen van tijd tot tijd wel eens applicaties breken ;)
Microsoft houdt er toch een rare denkwijze op na...

Langs de ene kant verwijten ze OSS dat er geen uniforme ontwikkeling achter zit en dat dit (volgens MS dan) vroeg of laat 'een probleem' kan vormen voor de veiligheid.

Maar langs de andere kant breiden ze zelf hun collectie tools/programma's/features constant uit met software die ze van elders gehaald hebben en dus ook 'niet uniform ontwikkeld' is...

Want je gaat mij niet vertellen dat de MS programmeurs op korte tijd erin slagen de code van een third party volledig te doorgronden...
Je hebt gelijk. En dit is overigens al de tweede overname in 3 DAGEN! Je zou bijna denken dat geld verdienen met software tegenwoordig alleen nog maar kan door je bedrijf te laten opkopen door MS.
Als MS zo licht gaat over opkopen van bedrijven, dan maak ik mij toch ernstige zorgen. Enkel monopolisten kunnen IMHO zo makkelijk anderen opkopen.
Enkel monopolisten kunnen IMHO zo makkelijk anderen opkopen
Volgens mij heeft dit veel meer te maken met beschikbare middelen dan met monopoliepositie.
Bovendien zal je het als monopolist juist moeilijker hebben, omdat overnames binnen je "monopoliesector" sneller geblokkeerd zullen worden door commissies die instaan voor concurrentiële handel (sorry, kan ff niet op de exacte naam komen).
Daarnaast zullen veel bedrijven sneller geneigd zijn in te stemmen met een overname als het niet gebeurt door een monopolist (kwestie van afkerigheid t.o.v. machtsconcentraties ... door een ander wel te verstaan :Y) )
In Europe misschien. In amerika is je bedrijfsvrijheid proptioneel gelijk aan je bijdrage aan de partij-kas van het huidige regenten dat aan de touwtjes trekt. En dan gaan we er voor het gemak maar even vanuit dat uberhaupt geen van deze regenten aandelen heeft (en dus financieel afhankelijk is) van je bedrijf.

Zelfs in Europa zal een 'monopolist' niet snel aangepakt worden als ze zo veel geld jouw land in sluizen. Of zijn er mensen die echt denken dat dit soort regels een ideaal en niet de gelegenheid behoren te dienen?
Enkel monopolisten kunnen IMHO zo makkelijk anderen opkopen
Volgens mij heeft dit veel meer te maken met beschikbare middelen dan met monopoliepositie.
De ruim voorhanden beschikbare middelen vloeien (zoals bij MS) voort uit hun monopoliepositie.
1. Begin een bedrijfje met iets dat een nieuwe betadienst van Google beconcurreert
2. Laat MS snuffelen
3. Laat je overnemen
4. Begin weer bij 1, herhaal dit een paar keer, ga door naar 5
5. Koop een Porsche Carrera GT, voordat ze niet meer te koop zijn :P
Nou het is wel duidelijk dat Microsoft de nieuwsberichten op Tweakers.net goed leest :+
of van infoworld.com

kijk maar naar de bron die is van infoworld mischien hebben ze dat wel gelezen (iets logischer) :+ :+
Microsoft kan natuurlijk niet achterblijven nu ook concurrent Altiris al een paar maanden geleden "Software Virtualization Solution" (SVS) heeft geïntroduceerd. Als je een idee wil krijgen wat software virtualisatie inhoud, moet je zeker eens gaan spelen met SVS van Altiris. Het is gratis voor persoonlijk gebruik en er is al een levendige community voor actief: http://juice.altiris.com/svs
Kan iemand hier misschien een link plaatsen naar informatie over wat het nu precies betekent in deze context (dll) en andere voordelen / practische toepassingen ?

Als ik het zo allemaal lees krijg ik het idee alsof de techniek enkel in wordt gezet om als oplossing te fungeren voor de beruchte dll-collisions, of vergis ik me ?

Je kunt dan wel verschillende versies van applicaties draaien, maar in de pratkijk zal dat weinig voorkomen lijkt me.

En zijn er bv verder nog overeenkomsten / verschillen met Apple's Disk Image (dmg), of is dat een compleet andere techniek ?

Anyway, alvast bedankt ;)
De oplossing voor dll-hell is maar een klein onderdeel van het Soft-Grid platform van Softricity.

Ik heb er een keer mee mogen werken en het is een geniaal platform, alleen erg duur.

Wat softricity doet is installatie packages beheren en, wanneer nodig, streamen naar de client en deze draaien in een hybride, gevirtualiseerde omgeving. Het registry, filesystem etc is een mix van je PC en de wijzigingen in het package. Zo ziet je registry er in AutoCad heel anders uit dan wanneer je het bekijkt vanuit Windows rechtstreeks.
Applicaties worden klaargemaakt voor distributie en toegekend aan gebruikers. Applicaties worden niet echt geinstalleerd op de PC, wanneer een gebruiker de applicatie start, worden de benodigde gedeeltes van de applicatie gestreamd naar de PC en uitgevoerd. De client cached de gestreamde onderdelen overigens wel, zodat de volgende keer starten van de applicatie nog sneller gaat.
Itt gebruikelijke application deployment systemen, is de applicatie na publicatie meteen bruikbaar voor de eindgebruikers.

Door de applicatie in een gevirtualiseerde omgeving te draaien is het mogelijk om conflicterende applicaties (bv: verschillende versies van dll's die dezelfde bestandsnaam gebruiken), probleemloos langs mekaar te draaien. Zo is het ook mogelijk om applicaties die eigenlijk niet onder Terminal Service werken, toch werkend te krijgen binnen Soft-Grid onder een Terminal Server session.
tja shared libraries in je eigen dir houden betekent dat ze niet meer shared zijn he. en dan ben je weer terug bij af wat betreft de voordelen van shared libraries.

verder denk ik dat dit juist een goeie oplossing is voor een probleem dat ooit is ontstaan doordat iedereen maar gebruik / misbruik mag maken van shared libraries, en veel 3rd party software dat niet goed doet, of niet goed uitbreid. laat die 3rd party software eens wel gewoon de laatst beschikbare ;library ondersteunen, en je hebt geen tig versies van dezelfde librarie nodig.

het is dus wel heel genereus dat microsoft die rotzooi nu een beetje aanpakt.

3rd party software overneemn, betekent vaak ook dat de mensen van dat bedrijf opeens MS programeurs worden, en die zijn meteen al specialist in die software. willen de andereMS programeurs dar iets mee doen, dan kunnen ze het nu gewoon an die collega vragen, ipv het 3rd party bedrijf te verzoeken om informatie, en zo dus bureaucratie voorkomen.

ook hebben alle programeurs vanaf dan een zelfde doel voor ogen en krigen ze te maken met dezelfde planning van boven af, waardoor hun werkzaamheden aan zullen sluiten, ipv twee verschillende ontwikkelpaden zijn.
Ooh, die goede oude .ini tijd. Waarom moesten nou alle settings in een warrige, gigantische, bijenkorf gestopt worden.
Hier baal ik nou dus van, ik werk al zolang met Softgrid, geweldig product en nu wordt het weer door MS overgenomen ;(

Dikke tegenvaller dit :(
dus eigenlijk komt het er op neer dat het hen niet lukt een deftige virtualizatie in te bouwen in vista en kopen ze maar een bedrijf op dat er in gespecialiseerd is?
Daar begint het toch serieus op te lijken met al dat uitstellen en opkopen van de laatste tijd... .
Je kan zuchten ja, maar er zit helaas wel een vorm van waarheid in.

MS moet zowat bij de top van de bedrijven horen die beschikken over verschrikkelijk veel resources en know-how en programmeurs om iets te maken.

En toch is het net dit bedrijf dat te pas en te onpas software van andere bedrijven overneemt.

Dan heb je 2 mogelijkheden :

- het is om bedrijf X uit de markt te halen.

of

- het is omdat het over iets gaat waar ze zelf niet in slagen om het te ontwikkelen.
Het overnemen van kleine bedrijven die een speciale techniek hebben ontwikkeld is al decennia volkomen normaal.

Sterker nog, veel kleinere bedrijven in de technologie hoek worden speciaal opgezet om later verkocht te kunnen worden aan grotere bedrijven. Externe innovatie heet dat en is zeker rond Amerikaanse Universiteiten een gebruikelijke manier van innovatie.
Een paar studenten ontwikkeld een theorie of techniek, na afstuderen richten ze een bedrijfje op om dit tot een werkend iets of eventueel een prototype te ontwikkelen om daarna het bedrijf inclusief techniek en patenten te verkopen aan een grote club. Oprichters blij want die hoeven nooit meer te werken, groot bedrijf blij want die hebben niet het innovatierisico gelopen en hebben een bewezen technologie in huis.

Grotere bedrijven die alles zelf ontwikkelingen bestaan al sinds de vroege jaren '80 bijna niet meer of staan daardoor op de rand van faillisement.
beter goed gekocht dan slecht verzonnen
Nu weet ik niet veel van DLL's etc af, maar het moet toch mogelijk zijn om de dll's samen te voegen ipv vervangen of meerdere kopieën ervan te hebben.

In mijn redenatie, zou je dan het programma dan naar specifieke regels of een bepaalde sectie in een DLL kunnen laten verwijzen. (of gebeurd dit nu al??)

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