XP-Kurztest
 

SCHON LÄNGER AUF DEM MARKT IST DIE OS-DISTRIBUTION DES HERSTELLERS MICROSOFT, DIE UNTER DEM NAMEN "WINDOWS XP HOME EDITION" VERTRIEBEN WIRD

Der Hersteller bewirbt sein Produkt als modernes PC-Betriebssystem, das robust und für alle Aufgaben gewappnet ist. Bietet der Markt also ernsthafte alternativen zu GNU/Linux?

Zum Praxistest gehört eine Untersuchung der üblichen Vorgänge. Installation auf einem Rechner mit bereits installiertem Betriebssystem, Konfigurationsmöglichkeiten, Ausstattung und die Einbindung in ein lokales Netzwerk.

Wer Windows testen möchte und auf der Web-Seite des Herstellers nach einem ISO_Image zum Download sucht, wird enttäuscht. Zwar finden sich einzelne Update-Pakete im exe-Format, doch ein Download des gesamten Produktes wird nicht angeboten. Soll Windows auf die Platte, ist also der Kauf einer Windows-Distribution notwendig. XP kann nur über den Fachhandel bezogen werden und schlägt mit stolzen 229,- Euro zu Buche. Bootet man von der CD, kommt es zu einer unerwarteten Überraschung: XP erkennt die Linux-Partitionen nicht und schlägt das Löschen des Systems vor. Für die Erfolgreiche Installation ist also eine vorherige Repatitionierung mit anderer Software notwendig - hier hätte ich mir einen Linux-Partitions-Resizer gewünscht: So viel Service darf man für über 200 Euro schon verlangen.

Ist ausreichend Plattenplatz frei, läuft die XP-Installation schmerzlos ab. Leider überschreibt XP dabei ohne Vorwarnung den Installierten Boot-Manager, so dass nach dem Neustart von Diskette gebootet werden muss, um LILO neu zu installieren und damit eine Betriebssystemauswahl zu ermöglichen. Zwar verwendet XP einen eigenen Boot-Manager, der prinzipiell auch Linux-Systeme starten kann, doch wird von dieser Möglichkeit bei der XP-Installation kein Gebrauch gemacht

Alles so bunt hier

Beim ersten XP-Start verschreckt das System mit einer allzu bunten Oberfläche, die offensichtlich dem XP_Theme von KDE nachempfunden wurde. Glücklicherweise lässt sich die Darstellung so anpassen, dass XP das gleiche Look & Feel wie ein älteres fvwm95 bietet.

Die XP-Distribution wird ohne GNU-Tools ausgeliefert - diese müssen erst umständlich von der Web Seite eines Drittanbieters ( http://sources.redhat.com/cywin/ ) nachinstalliert werden. Will man mit Bordmitteln arbeiten, steht nur die sehr rudimentäre cmd-Shell zur Verfügung, die zudem noch unglücklich im Startmenü versteckt ist.

XP weicht vom Standard ab und bindet Datenträger nicht über Mount-Points, sondern über die Zuordnung so genannter "Laufwerksbuchstaben" ein; ausserdem wird als Pfardtrennzeichen der Backslash statt des einfachen Slashs verwendet. Hat man sich an diese Konvention gewöhnt, kann man zumindest durch die Verzeichisse navigieren. Wer es lieber grafisch hat, darf hierfür auch den gelungenen Datei-Manager explorer verwenden, der sich aus der Shell heraus oder über ein Icon aufrufen lässt.

Netzwerk? Nur bedingt

Die Anmeldung an einem lokalen DHCP-Server bereitete keine Probleme - die vom NFS-Server bereitgestellten Home-Verzeichnisse konnten allerdings nicht gemountet werden. Eine Recherche im Internet bestätigte den Verdacht, dass XP das NFS-Protokoll nicht beherrscht.

Fazit

Die XP-Distribution wirkt unausgereift. Für reine Hobby-Anwender mag XP nochmit interessanten Multimedia-Fähigkeiten überzeugen, bei Installation und Netzwerkfähigkeit muss der Hersteller aber nachbessern, wenn XP sich im Linux-Umfeld behaupten soll.


gefunden auf http://www.linux-archiv.org/news/XP-Kurztest.xml

*gack* :lol:

Trotzdem viel Wahres dran ;)

Und genau deshalb habe ich es nicht gekauft! Ich hoffe bloss, dass der Nachfolger nciht auch so wird... (wird aber trotzdem ähnlich sein)

ich hab home (war mit dabei) hat noch keine probs mit netzwerk oder so gegeben :rolleyes: *gg* *räbähhh will nanderes*!!!
www.mueller-deg.de/ingurum/Linux-Windof.jpg hab ich draufgeklebt, das man nich meint ich hab NUR xp home :D

Jetzt würd ich gerne ein Kommentar von Myers lesen..

ich weiß schon, warum mir XP nicht auf den Rechner kommt... intuitive Abneigung :D

2k ist zwar auch nur ein Windows, aber... immer noch das erträglichste :)

Ich hab's leider nicht... wär's bloss nicht so teuer, sonst hätte ich's auch...

nein. er wird schlimmer :D erste alpha kommt ja bald ;)

ich sag nur eins: .net wird scheisse für jeden der mal eben was programmieren will. dafür wirds stabiler aber extrem inkompatibel.
na ja das netzwerk wird aber 100% wie bei os2 oder linux laufen :)

.net? Hab ich schon gehört, weiss aber nicht, was das ist... :shy:

windows .net wird das nächste windows.

entwickler tools gibts schon (visual studio .net) und auch schon erste kompatibilitätsupdates für die vorgänger von .net.
nur dieses aufgesetzte funktioniert nicht ganz so perfekt ;) wie sollts auch anders sein? :D

jedenfalls basiert das .net system auf frameworking wie java es tut. nach dem sog. sandkastensystem.
eine anwendung wird sozusagen in einen sandkasten gestezt und´kann nur da spielen! wenn es abstürzt macht es nur den sandkasten kaputt aber nicht den ganzen spielplatz :) also läuft alles andere stabil weiter :D und dadurch wird es programmieren nicht grade leichter gemacht auf tiefste systemebene zu stoßen :(
naja gibt dann auch erstmal keine viren dafür :)

SuSE?
Naja immerhin ein anfang. Aber ich kan SuSE nicht leiden.
Dann lieber ein RädHät :)

Kann es dann sein, das .net ähnlich viel Ressourcen wie Java braucht ? Oder hat das andere Gründe?

Ehrlichgesagt hab ich den Bericht zuerst für vollen ernst gehalten :shy:

@Surfer, wieso findest du eigentlich SuSE so schlecht?

Naja das wirst auch du selbst genug früh erfahren.

Es ist halt einfach SuSE einfach nur KomerZ

surfer: jo hast recht! suse ist eben suse. und zwar das suse wies heute ist und nicht war! ;)

dabei kann man sich seine distri so schön einfach selber zusammenstellen! dazu ist linux nun mal opensource und free for all ;)

ausserdem gibts auch noch andere distributoren, die wirklich nicht schlechter sind ;)

allein schon dieses suse getue: suse linux 8 bla dröhn und red hat hängt bei 4 oder so. das macht natürlich schlechteren eindruck auf viele kunden. dabei kommts doch fast nur auf den kernel an. die versionsnummer des kernels ist wichtig und nicht, dass suse grade distri. 8 oder sonstwas rausbringt ;) aber das sehen viele nicht!

was soll andere gründe haben?

Das Java soviele ressourcen frisst. Hängt das mit dem Sandkastensystem zusammen oder hat das eben andere Gründe?

Schön das du zu den Leuten gehörst, die sich eine Distribution selber basteln können ;), ich kann das leider nicht so ganz :shy:

na ja dass ich es kann hab ich nicht gesagt! aber es ist möglich :D
gibt aber genug seiten die anleitung geben!
und ob ichs wirklich kann weiss ich nicht: wenn mans noch nie probiert hat, kann man auch schlecht sagen ob mans kann oder nicht :D :D


und java..?!
na ja siehs so: der quellcode wird zur laufzeit kompiliert. das kostet natürlich n bisschen mehr rechenleistung als bei normalen porgrammen. dadurch resultierend: es ist mega stabil und die cpu verschwendet ihre kraft eher zum kompilieren und ausführen. allen anderen schnick schnack mit irgendwelchen verwaltunssachen und "ziwschen-rechnungen" fallen weg. im endeffekt verbraucht java und auch die .net technik nicht mehr ressourcen als "normale" anwendungen! (eher weniger)

kann natürlich sein, dass du die java-umgebung meinst und nicht das grade ausgeführte programm (den...code) is leider so, dass die engine, die ja bei der technik doch komplex ist, ein wenig mehr speicher klaut.


p.s.: mah *volldurcheinanderbin* scheiss müdigkeit... geh pennen :p

Hatte ich erwähnt daß wir auf dem Server Debian fahren? :D

etwa 30% der deutschen SuSE-User sind innerhalb der letzten paar Monate auf debian umgestiegen, weil SuSE 8.0 so schrecklich ist. Naja, ich kanns nicht bestätigen, ich bin schon seit langem bei debian. Bis Version 6.0 war SuSE noch ok, aber alles danach? *urks*

Naja der Artikel wirkt, als wär er entweder von einem Win95 Fan, einem Windows-Hasser oder jemandem, der neuerungen hasst geschreiben.


Is halt Home-Edition.

Debian kenn ich nicht, Aber zuhaust benutzen wir SuSE, ich glaub V7.0

auch w2k Advanced Server, XP Professional oder Windows.net können kein NFS lesen

Bin SuSE 7.3 User und habs (fast) gratis in einem PC Heft dabeigehabt. Debian kenn ich net.

¨gibbet ein debian logo? wills auf meinen pc kleben

Ich hab bloß nen RedHat-Aufkleber...und ICh bin froh, dass er noch nicht auf meinem PC klebt.

www.debian.org - viel spaß beim suchen ;)

Auch wenn es etwas OT ist:

@myers
Ich finde Programmierung mit .net wesentlich angenehmer. Alleine schon, daß man aus dieser verflixten DLL-Hölle rauskommt.

Es ist supernervig, wenn Du beispielsweise zwei VB-Projekte änderst, die je 10 DLLs aufrufen und Du hast die zu ändernden Projekte bei Dir auf dem Rechner, dann liegen die noch auf 2 Test-Servern, auf einem Integrations-Server und dann auf 20 produktiven WTS-Servern.

Im zweiten Projekt wird eine neuere Version von DLL 5 benutzt, da Projekt 1 noch nicht umgestellt werden konnte, im ersten Projekt allerdings eine neuere DLL von DLL 7, da Projekt 1 das Pilotprojekt dafür war.
Da bist Du nur noch DLLs am "unregistern" und wieder neu am registrieren (regsvr32), am Suchen, ob Du die richtigen Verweise im Projekt hast, etc. !

Also DLL-Hölle ade !

wo hast du dieses Problem? Mit COM und IDL gibts das eigentlich schon laaaaaaaaaaange nicht mehr....

Ich meine das neue ist zwar recht .nett - aber mich hauts nicht vom hocker, ich bleib da lieber bei meinem c++ mit gcc

:confused:
COM ist der eigentliche Verursacher der sogenannten DLL-Hölle.

COM (Component Object Model) stellt eine Infrastruktur bereit, mit Hilfe derer Programme ihre Klassen und Schnittstellen anderen Programmen zur Verfügung stellen können. Dabei spielt immer ein Programm den Server und ein anderes den Client. Damit ein Programm oder eine DLL als Server fungieren kann, muß es und seine Klassen in der Registry unter einer sogenannten GUID (Weltweit eindeutige Nummer) registriert werden. Das Clientprogramm fragt dann immer explizit nach diesen Nummern, die sind da fest drin verdrahtet und das funktioniert auch immer, solange der Server richtig registriert ist und in der richtigen Version vorliegt. Nun stell Dir aber folgende Situation vor:

Programm A braucht DLL D in der Version 1.
Programm B braucht DLL D in der Version 2.
Beide Programme kommen mit der jeweils anderen Version nicht klar.

Welche Version soll man nun registrieren? COM kann nur eine Version registrieren, nicht zwei, also bist Du in der Zwickmühle.

Außerdem verlangt dieses System vom Entwickler einiges an Vorsicht und verursacht ihm einige Probleme, da jede Änderung an einer bereits registrierten DLL die Einhaltung der sogenannten Binärkompatibilität erfordert, was mitunter an sich schon eine Hölle ist, weil man bestehende Schnittstellen nicht verändern darf. Brichst Du die Binärkompatibilität, mußt Du alle Programme ändern, die Deine DLL aufrufen, brichst Du sie nicht, bist Du verdammt eingeschränkt.

Dazu kommt noch das Problem, daß manche Software einfach System-DLLs überschreibt, die dann mit anderen Programmen (oder auch mal einer anderen Version des Systems) dann nicht mehr funktionieren.

Das alles nennt man DLL-Hölle und das löst COM nicht, sondern verursacht es (zumindest den ersten Teil, den ich beschrieb).

IDL (IDL (Interface Definition Language) ist quasi ein Teil von COM (bzw. OLE)) steht für Interface und taugt nur dazu, mit Hilfe des dazugehörigen Compilers MIDL eine Typbibliothek für COM-Komponenten zu erstellen. die DLL-Hölle löst das aber gar nicht.
Zudem brauchen es eigentlich nur Leute, die COM-Komponenten mit C++ und MFC entwickeln (und wir entwickeln auf der Firma nunmal viel in VB) und die IDL hat ohne COM keine Existenzberechtigung, also wird sie auch nicht gegen die DLL-Hölle helfen.

Seit W2K gibt es zwar ein paar Tricks, die da abhelfen können (man kann zum Beispiel Dateien überwachen lassen, so daß W2K das Überschreiben von System-DLLs verhindert und man kann mit einer leeren Datei Programm.exe.local im Verzeichnis von Programm A sagen, daß Programm A nicht die registrierte DLL D in der Version 2 sondern die lokale richtige DLL D in Version 1 nutzen soll), das ist aber eher Gefrickel und kein offizieller Weg, soweit ich weiß.

.net löst dieses Problem nun, indem es die zentrale Registrierung von Komponenten um das Feature der Versionierung erweitert. Das Programm A kann nun also seine DLL D in der Version 1 anfordern, kriegt die auch, während Programm B nach Version 2 fragt und diese ebenfalls von der zentralen Registrierung kriegt.

thx :thx:

Goil, ein Thema, bei dem ich nur Fleischwarenfachverkäufer versteh! :D
Ist immer lustig, so Fachsimpeleien zu lesen, wenn man absolut keinen Schimemr hat, worum's geht. :gf:

HALT! Das Problem liegt bei den Komponenten. Wenn du eine DLL der Version irgendwas.x brauchst, so sind die Interfaces dieser Version bei allen Subversionen von irgendwas gleich - sofern der Programmierer weiß was er tut. Und verschiedene Major-Versionen der DLL kannst du sehr wohl registrieren. Mal abgesehen davon, das du die DLL nicht unbedingt mit deren GUID laden musst (wie das mit den windoof CreateInstance & Co Funktionen geht). Außerdem kannst du die DLL auch registrieren bevor du die verwendest, und nachher wieder die ursprüngliche. Das funktioniert zwar nicht so einfach, aber es geht.

Ahja, das ist aber wohl klar. Und mal ehrlich, wie oft änderst du Schnittstellen einer Komponente? Doch wohl wenn dann nur in der Entwicklung, und da kriegst du sowieso stündlich eine neue. Bei einer release-Version ist für die Komplette Major-Version die Schnittstelle eingefroren. Und wer vor dem Programmieren überlegt, die Deklaration schreibt und so ist klar im Vorteil. Schließlich basiert die ganze Komponente auf den Schnittstellen und die zu modifizieren ist eine sch**** hackn.

Soweit ich mich erinnern kann gabs DLLs auch schon vor COM - mit den gleichen Problemen. COM ist ein Schritt diese zu vermindern (zum Beispiel mit den GUIDs).

HAAAAAAAAAALT! Also ich kann IDL auch für CORBA, C++ @Linux und Java verwenden.

Nun, gibts für irgendwelche m$-probleme OFFIZIELLE wege? Nein, nur Pfusch.

Hier stimm ich dir zu, das geht mit .net um einiges einfacher als mit COM. Aber durch kompetente Programmierung hast du diese Probleme sowieso nicht. Und unter Linux schon gar nicht ;)

@Com Subvie
Erstmal nur zum Thema "Schnittstellen einer Komponente" ändern, zum Rest später, weil mir momentan etwas die Zeit für eine komplette Antwort fehlt:

In unserer Firma wird fast ausschließlich firmeneigene Software und kaum Standardsoftware eingesetzt (wenn man mal von SAP für REWE absieht, ich spreche jetzt natürlich nicht von Textverarbeitung, etc.). Wir haben etwa 200 Programmierer, es gibt etwa 50 verschiedene DLLs, die wahrscheinlich von etwa 10 verschiedenen Teams entwickelt wurden und gewartet werden, darunter solche "Kernkomponenten", wie Security-Prüfungen, Datumsmodule, Schreibroutinen mit RPC-Aufrufen, etc. !

Ich weiß nicht, ob Du Dir vorstellen kannst, wie schnell sich DLLs ändern, weil Team A eine Weiterentwicklung benötigt, Team Z aber die Änderung nicht in Programm XY aus irgendwelchen Gründen nicht mitpflegen kann, gleichzeitig aber das Programm ABC des gleichen Teams ebenfalls die neue Version dieser Kernkomponente benötigt ?
Da ist nichts mit einer gleichzeitigen Anpassung aller betroffenen Systeme, vor allem nicht in einem Betrieb von über 30.000 Mitarbeitern, wo ich leider schonmal auf die Bedürfnisse von Direktor Gedöhnsrat reagieren muß, auch wenn die Planung anders aussah. ;)

Zum Rest später etwas, möglicherweise erst morgen.

klingt nach schlechter bis sehr schlechter organisation. naja, bei meinen maximal-10-leute teams hab ich die probleme nicht...

Ich weiß ja nicht, in welcher Branche Du tätig bist, wie groß Deine Firma ist, etc. und kann deshalb nicht sagen, wie einfach Deine Organisation zu halten ist, oder nicht.

Aber ich kann Dir mal ein paar Beispiele von uns nennen. Z.B gab es zwei Kern-DLLs, die in allen Systemen gleich gehalten werden konnten.
Urplötzlich (vom einen auf den anderen Tag) wurde vom Vorstand des Mutterkonzerns bekanntgegeben, daß ein Unternehmen im europäischen Ausland aufgekauft wird, die Verhandlungen mehr oder minder abgeschlossen sind und bestimmte Systeme "direkt" nach Belgien übernommen werden sollen, um eine einheitliche Logistikstruktur zu bekommen. Dazu gehört nicht nur eine 1:1-Portierung, sondern eine Übersetzung ins englische, flämische und wallonische (OK, das hat nicht viel mit dem eigentlichen Problem zu tun, sondern soll nur mal verdeutlichen, was plötzlich organisatorisch umgeworfen werden kann) und es müssen aber auch Dinge geändert werden, weil nunmal bestimmte Sachen nach belgischem Recht ganz anders laufen.
Und da gehst Du weder zum Vorstandschef vom eigenen Konzern mit 30000 MA, noch zum Chef des Mutterkonzerns mit etwa 55000 MA und erzählst ihm etwas von Versionsproblemen von DLLs aufgrund dessen die geplante Firmenübernahme mit den angedachten Prozeßen erstmal etwas warten soll, um auch alle Syteme anpassen zu können. Sorry, aber der lacht mich aus und sagt, daß ihn solche Kleinigkeiten nicht interessieren, sondern nur, daß er seinen Jahresumsatz von 45 Milliarden Euro wie geplant um 10 % steigern will.
Ein weiteres "einigermaßen" aktuelles Beispiel war die Änderung des Rabattgesetzes in Deutschland, die sich zwar schon etwas längerfristig ankündigte, aber dennoch Planungen umwarf. Das ist etwas anderes, als vielleicht einen reinen Softwarebetrieb zu führen, in dem man abgeschlossene Produkte nach draußen verkauft.


Nun aber zu meiner eigentlichen Antwort, die ich noch geben wollte:

Ich gebe zu, daß COM die DLL-Hölle nicht allein verursacht hat. Ich gehe auch darin mit überein, daß wenn man in einer abgeschotteten Welt lebt, in der nur man ganz allein DLLs kompiliert, es für den Entwickler kein Problem darstellt, eine komplett neue Version seiner DLL zu registrieren.
Was aber, wenn andere auch auf die DLL zugreifen können sollen und zwar auf die aktuelle Version und ohne Entwicklungsaufwand (also ohne die neuen GUIDs verwenden zu müssen)? Und wenn noch dazu gefordert ist, daß auf zentral im System registrierte DLLs zugegriffen werden soll (es gibt ja gute Gründe für sowas) und eben kein Wildwuchs mit vielen Versionen in verschiedensten Anwendungsverzeichnissen getrieben werden soll ?
Wenn im Unternehmen nur mit VB programmiert werden soll (wo mir beim besten Willen kein trivialer Weg einfällt, eine DLL ohne GUID zu laden) ?
Wer meint, er könne seine Schnittstellen immer so universell planen, daß ihre Rückwärtskompatibilität niemals gebrochen werden müßte, der ist entweder ein Hellseher oder extrem naiv (bitte nicht persönlich nehmen, ich nehme einfach an, wir arbeiten nicht in den gleichen Welten). Und da kommt die (Er-)Lösung eben erst mit dem GAC-Konzept des .Net-Frameworks, das die Vorteile einer zentralen Registrierung von Komponenten mit der Möglichkeit einer Versionierung verbindet, was auch den Konfigurationsaufwand beträchtlich reduziert.
Wenn man die Perspektive nun noch etwas erweitert und bedenkt, daß moderne Unternehmenssoftware auch oft auf Komponenten von Drittanbietern angewiesen sein kann, kommt man eigentlich erst richtig ins Schwitzen, denn diese sind quasi immer zentral registriert und unterscheiden sich eben oft auch zwischen Versionen mit gleicher Schnittstelle in ihrem Verhalten. Warum sonst sollte der Drittanbieter die "Zwischenversion" herausgebracht haben? In einer idealen Welt würde man nun immer dafür sorgen, daß auf allen Maschinen, auf denen Software zu installieren ist, immer der genau gleiche Stand an Komponentenversionen herrscht. Genau darauf zielen natürlich auch unsere Konfigurationskonzepte ab.
Nun leben wir allerdings nicht in einer idealen Welt und so ist schon die relativ überschaubare Landschaft wie die unseres Unternehmens mit nur einigen hundert relevanten Servern (und einigen Tausend Citrix-Clients) auch bei den größten Anstrengungen nur sehr bedingt immer auf dem gleichen Stand zu halten. Der Standardfehler, der immer wieder auftritt, ist zum Beispiel der, daß die Datenzugriffskomponenten auf der Entwicklermaschine und der Produktionsmaschine sich in kleinen Details unterscheiden, was dann oft auch zu Programmabstürzen führt, die auf der Entwicklermaschine nicht passiert sind. Eine zentrale Registrierung mit Versionierung löst dieses Problem äußerst elegant, indem eben einfach immer alle theoretisch benötigten Versionen zentral abrufbar sind. Man kann sich als Entwickler darauf verlassen, daß die richtige Version da ist. Und wenn eine sehr neue Version dann eben doch noch nicht auf allen Produktionsmaschinen installiert ist, kann man sie sofort, ohne Entwicklungsaufwand und ohne Auswirkungen auf andere installierte Software einfach dazu installieren. Das geht mit COM nun beim besten Willen nicht, sondern höchstens ansatzweise mit dem Workaround mit der anwendung.exe.local - Datei, was aber erhöhten Konfigurationsaufwand nach sich zieht.

Um mal auf die Eingangsfrage zurückzukommen:
Die DLL-Hölle mag schon vor COM bestanden haben, ich kann allerdings nicht erkennen, inwiefern COM und die IDL dazu beigetragen haben sollten, sie zu lindern. Eher das Gegenteil ist der Fall.

Nun noch ein paar spezielle Aspekte:
Das würde mich ja mal interessieren. Ich möchte mich hier nicht als COM-Experten aufschwingen, aber mit CoCreateInstance oder einer ClassFactory kann man meines Wissens keine Klasse aus einer DLL laden ohne CLSID (was ja auch eine GUID ist). Wenn Du einen anderen Weg meintest, würde mich dieser wirklich sehr interessieren!


Das kann es ja wohl nicht sein. Denn was passiert bei einer solchen Lösung, wenn zur Laufzeit ein anderes Programm die ursprünglich registrierte DLL benötigt? Das ist riskantes Gefrickel.


C++ hatte ich ja bereits aufgeführt und dies sollte nun wirklich keine absolute Vollständigkeit beanspruchen, denn dafür kenne ich nunmal einfach nicht alle Programmiersprachen dieser Welt.

Naja, ich gebe zu, ich sehe das mehr als "Einzelprojekt-Programmierer", da wird die DLL nur von einem Entwicklerteam benötigt, und von sonst niemandem. Und erst wenn die released ist - und damit die Schnittstellen eingefroren sind - können sich andere damit beschäftigen. Mal abgesehen davon das ich DLLs sowieso nicht mag ;)

naja, wenn wir uns zum beispiel mal DirectX ansehen, so kann ich auch bei der aktuellen Version nachwievor die Schnittstellen der Version 3 verwenden. Soweit ist hier also binärkompatibilität gegeben. Ob ich alte und neue Interfaces gleichzeitig verwenden kann weiß ich allerdings nicht.

Ich hab gemeint, es gibt einen anderen Weg als CoCreateInstance auch, aber frag mich jetzt auf nicht wie das ging, ich hab das früher mal mit C verwendet, ob das in C++ noch immer geht? Keine Ahnung....