Vista:kostenloser Festplatten Manager

amiga-news.de Forum > Andere Systeme > Vista:kostenloser Festplatten Manager

[ - Search - New posts - Register - Login - ]

1 -2-

[ - Post reply - ]

2008-07-24, 17:06 h

Maja
Posts: 15429
User

Zitat:
Original von Michael_Mann:
Mittlerweile scheint es auch so das der M$ Installer für win, der eigentlich Registry-Änderungen protokolliert, Backups vor Änderungen anlegt u.ä. mehr, Stück für Stück versagt.

Meinst Du .bak Dateien bzw. Schattenkopien? Hm, die Nutzung von Reg-Cleanern ist ja inzwischen recht weit verbreitet und werden gern genutzt, "überflüssige" *.bak zu löschen. Und Schattenkopien (Wiederherstellungspunkte) lassen sich über die Datenträgerbereinigung vom Benutzer beseitigen, um Festplattenplatz frei zu machen. Es ist es vielleicht nicht das Gelbe vom Ei, sich als Programmierer für die Deinstallation eigener Software 100% auf diese Daten zu verlassen.

Zitat:
Unter Vista arbeitet die eingehandelte malware wie auch unter winxp - mit Admin-Rechten.

Natürlich. Aber funktioniert sie auch? Unter Vista hat kein normaler Benutzer Admin-Rechte. Auch wenn da huntermal Administrator unter dem Benutzernamen steht. Der Admin ist in der Standardkonfiguration deaktiviert.

Zitat:
Der eine von Sysinternals, der jetzt bei M$ ist, hatte mal in einem BLOG gesagt das die UAC auch nicht unbedingt das Wahre ist.

Niemand behauptet, die UAC wäre "das Wahre". Das ist sie schon desewegen nicht, weil man einfach auf "Fortsetzen" klicken oder sie ganz abschalten kann. Was ja auch nicht ohne Sinn und Zweck ist. Zu restriktiv kann so etwas auch nicht aufgezogen werden. Die UAC gibt dem Benutzer Hinweise. Entscheiden muss er dann selbst. Mehr will das auch nicht sein.

Zitat:
Diese WHQL-Zertifizierung kostet die Hersteller auch einige EUR, Neu-Anmeldung meist mehrere tausend, Änderungen meist mehrere 100 bis mehrere tausend EUR.

Sorry, aber das ist ein Argument für die Tonne. Die Zertifizierung betrifft nur Kernel-Mode-Treiber. Diese bedauernswerten Hersteller wollen mit ihrer Hardware an der Existenz diese Betriebssystems mitverdienen, haben sich in der Vergangenheit aber leider häufig als unwillig/unfähig erwiesen, durchweg systemkonforme, stabile Treiber zu liefern. Hast Du schon vergessen, was für ein Krampf das früher war? Hardwarekauf war wie Lotterie spielen. Läuft der Treiber oder läuft er nicht? Hätten sich mehr Hardwarehersteller mehr Mühe mit den Treibern gegeben, es würde gar kein WHQL geben. Wenn aber ein OS-Hersteller über Jahre hohe Supportkosten wegen - sorry - schrottiger Treiber von Drittherstellern hat, dann darf man sich nicht wundern, wenn der irgendwann den Spieß umdreht und - wie lange im Voraus angekündigt - tatsächlich die Schotten dicht macht.

Zitat:
Nicht berücksichtigt ist bei win 64bit auch das Problem wenn ein mittlerweile verblichener Hersteller einen nicht zertifizierten Treiber anbietet.

WHQL gibt es seit Win2000. Mit XP wurde 2001 das Projekt der Öffentlichkeit (den Benutzern) vorgestellt. Die Treibersignatur kann unter einem 32-Bit System vom Benutzer umgangen werden. Es wurde von Microsoft nie ein Hehl daraus gemacht, dass das unter einem 64-Bit System nicht mehr der Fall sein wird. Und XP 64-Bit gibt es nun auch nicht erst seit gestern. Somit hatten Herstellern von Hardware seit nunmehr rund 7 Jahren vermutlich genug Zeit, sich auf die veränderten Vorausetzung vorzubereiten und ausgiebig zu Testen. Dass das nicht alle Hardwarehersteller verschlafen haben, zeigt wohl die Tatsache, dass es durchaus mehrere Jahre alte Hardware gibt, die sehr wohl über WHQL-zertifizierte Treiber für Vista 64-Bit verfügt.

Zitat:
Warum die Hersteller erst jetzt mit dieser Assign-Abart anfangen?

"Assign-Abart"?

Zitat:
Da müßte ich mich mal schlau machen.

Was gibts da schlau zu machen? Sie haben 7 Jahre gepennt oder gehofft, es würde "schon schief gehen" und kaum jemand würde sich je für ein 64-Bit Windows interessieren.

Obwohl, so dramatisch schlecht wie einige es darstellen wollen ist die Treibersituation bei Vista 64-Bit jetzt, 1,5 Jahre nach Erscheinen des OS, längst nicht mehr. Was nicht bedeutet, dass es nicht noch besser werden dürfte. Man kann aber wohl kaum erwarten, dass Hersteller jetzt noch großangelegt zertifizierte 64-Bit-Treiber für Geräte nachliefern, die 4 Jahre oder älter sind. Manche tun es. Andere nicht. Das Entscheidet jeder Hersteller selbst. Es gibt keinen Rechtsanspruch auf Treiber für ein Betriebssystem, das bei Erscheinen des Gerätes nicht in der Liste der Systemanforderungen erscheint. Wer heute Vista hat und unbesehen etwas kauft, auf dem maximal XP SP2 angegeben ist, der geht ein Risiko ein. Besonders dann, wenn sein Vista 64-Bit ist. Dann sollte ausdrücklich Vista 64-Bit auf der Verpackung stehen.

Zitat:
Zum Teil dürfte es Schlamperei der Programmierer selbst sein, es ist halt einfacher alles in einen definierten Suchpfad reinzukippen (meist System-Ordner).

Probleme die im Betriebssystem selbst begründet liegen, werden meist relativ schnell behoben. Vorausgesetzt der Hersteller arbeitete mit dem OS-Hersteller zusammen und hofft nicht einfach mal auf ein Wunder. Immerhin sind sowohl OS-Hersteller als auch die Hersteller von Hardware und Software für dieses OS gleichermaßen von der Funktionsfähigikeit ihrer Produkte miteinander gegenseitig abhängig.

Zitat:
Oder, was auch möglich ist, aus dem Entwicklungspaket Systemdateien mit einbinden und nicht die Option der Benutzung der in win vorhandenen dlls benutzt.

Vorausgesetzt das führt nicht dazu, dass Systemdateien neueren Datums mit alten Versionen (vom Benutzer umbemerkt) überschrieben werden, was wieder nur dazu führen würde, dass etwas anderes nicht mehr funktioniert. Und Vorausgesetzt, das Programm funktioniert auch mit aktuellen Versionen benötigter Komponenten. Meldungen wie, ".NET 2.0 nicht gefunden. Die Installation wird abgebrochen", sollten einem auf einem OS, das .NET 3.0 installiert hat, nun wirklich nicht begegnen. Auch ein ungefragtes Installieren von .NET 2.0 auf diesem OS mag ich nicht sehen wollen. Das ist keine saubere Vorgehensweise.

Zitat:
Diese msvcrt.dll dürfte dehalb per assign eingebunden sein weil die in der Vergangenheit schon immer Anlaß zu Problemen bot.

Wie z. B. das? http://support.microsoft.com/kb/324762/de
Siehe oben. Bei einem Betriebssystem, dass einer ständigen Weiterentwicklung unterliegt, sollten Programmierer Systemdateien nicht zum festen Bestandteil ihres Installationspaketes machen. Oder halt dafür sorgen, dass neue nicht mit alten Dateien überschrieben werden.

Zitat:
Vermutlich wäre es um win besser bestellt wenn die Programmierer nur auf die in win vorhandenen system-dlls zugreifen dürften

Vielleicht würde es schon reichen, wenn weniger versucht wurde sich selbst was zu backen statt Vorhandenes zu nutzen. Damit könnten auch die Konflikte ein Ende haben, die manche Programme mit anderen Programmen oder mit Systemfunktionen auslösen. Es müsste doch möglich sein, das auf die Reihe zu bekommen, ohne dass der OS-Hersteller erneut starre Regelungen wie mit WHQL einführen muss?

Zitat:
und eventuell ein ein gescheiter Registry-Assistent existieren würde (z.B. das Programm soll als Codec eingebunden werden, das dann die Fragespielchen dazu führen das der Assistent die jeweiligen Einträge selbst ermittelt).

Mag sein. IMHO wäre das aber wieder nur ein Workaround mit dem zudem auch nicht jeder wird umgehen können. Optimal wäre es doch, wenn man gar keinen Registry-Assistenten (oder -Cleaner) brauchen würde, um einmal Installiertes wieder vollständig los zu werden. Es kann doch eigentlich nicht so schwer sein, sich mit der Deinstallationsroutine genauso viel Mühe zu machen wie mit der Installtion, oder? Einige beweisen doch, dass es geht.

[ - Answer - Quote - Direct link - ]

2008-07-25, 10:26 h

Holger
Posts: 8116
User

Zitat:
Original von Michael_Mann:
M$ hält bis heute an dem seit 1995 bestehenden Eigengeächs namens Registry fest ohne diese Datenbank jemals gründlich entrümpelt zu haben.

Den Satz verstehe ich nicht.
Es sind doch die Programme von Drittherstellern, die eventuell die Registry vollmüllen und das natürlich erst nach der Installation von Windows.

Ich habe noch nie davon gehört, dass User ihre registry an Microsoft zurückgeschickt hätten, damit diese wieder in andere Windows-Installationen eingepflegt werden könnte.

Also, wie soll Microsoft "diese Datenbank entrümpeln"?

Zitat:
Zaghaft beginnt M$ bzw. die Programmierer mittlerweile mit einer Art Assign - bei der c++ Klassenbibliothek, die mittlerweile in den jeweiligen Programm-Ordnern verbleibt. Schon gibts weniger Probleme allgemein.

Häh?
DLLs konnten schon immer im eigenen Programmordner abgelegt werden. Dazu braucht's auch keinerlei "Art Assign", dort wird sogar (und wurde schon immer) zuerst gesucht.

Zitat:
Fehlt nur noch das die Registry so umgebaut wird das win-Einträge strikt gesperrt bleiben und die Installer für die jeweilige Software (Treiber nicht) unter einem jeweiligen Schlüssel alles konzentriert anlegen.

Die Registry besitzt genauso Zugriffsrechte wie z.B. das NTFS-Dateisystem. Ohne entsprechende Rechte kannst Du System-Einträge nicht verändern. Blöd nur, wenn a) der Nutzer mit Administratorrechten unterwegs ist und/oder b) das Programm nunmal tatsächlich eine Systemeinstellung ändern muss.

Zitat:
Original von Maja:
Mal abgesehen von Einträgen ins Startmenü brauchten Anwednungen und Spiele genau genommen noch nie Einträge in die Registry vorzunehmen.

Auch für das Startmenü braucht man keine Registry-Einträge. Das Startmenü ist ein Verzeichnis, in dem Verknüpfungen angelegt werden. Deshalb kannst Du auch auf "Programme" mit der rechten Maustaste klicken und den zugehörigen Ordner (bzw. einen der beiden) öffnen.

Zitat:
Warum sollte Microsoft Systemeinstellungen über die ganze Festplatte verteilen, statt dafür die Registry zu nutzen? Schließlich ist die Registry geanu dafür gedacht und diese Vorgehensweise hat neben den bekannten Nachteilen durchaus auch seine Vorteile.

Richtig.
Unterm Strich ist es auch völlig egal, ob schlecht geschriebene Programme eine Datenbank oder ein Dateisystem zumüllen. Allerdings leidet bei der Registry-Datenbank nicht die Performance darunter.

Zitat:
Optimal wäre es doch, wenn man gar keinen Registry-Assistenten (oder -Cleaner) brauchen würde, um einmal Installiertes wieder vollständig los zu werden. Es kann doch eigentlich nicht so schwer sein, sich mit der Deinstallationsroutine genauso viel Mühe zu machen wie mit der Installtion, oder? Einige beweisen doch, dass es geht.

Programmierer schreiben gerne Programme. Was sie nicht gerne tun, ist

Dokumentieren

(Ordentlich) Testen

Schreiben von Installationroutinen

Schreiben von Deinstallationroutinen

Und wenn der Chef/der Geldgeber zufrieden ist, sobald etwas installierbares vorhanden ist, dass augenscheinlich irgendetwas tut, dann ist klar, was auf der Strecke bleibt. Viele Geldgeber sehen auch gar nicht ein, in Dinge zu investieren, die keine sichtbaren Veränderungen an dem installierbaren, das augenscheinlich irgendetwas tut, herbeiführt.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]

2008-07-25, 13:56 h

Michael_Mann
Posts: 1012
User

Hupps,

bei den beiden umfangreichen Postings hoffe ich mal nichts übersehen zu haben...

Der wininstaller von M$ ist so eine Art "Paketverwaltung" für Software & Registry. Der legt z.B. beim Installieren von Software backups von geänderten Registry-Werten an und spielt die wieder zurück wenn das Programm deinstalliert werden soll.
Daneben sollte er auch überflüssige Einträge löschen, blockierte Dateien/Ordner zum Deinstallieren freigeben und der Dinge mehr.
In meinem Stammforum gibt es vermehrt Hinweise das diese Funktionen mittlerweile nicht mehr oder nicht mehr richtig funktionieren.
Die Firma meines Forums selbst achtet sehr penibel darauf das eine Deinstallation auch eine vollständige ist - weil alles andere ist schlecht für den Ruf des Produkts (so wie es Symantec, ähem, vormacht)...

Wenn man ein Programm hat das in seinem Installations-Ordner eine c++-dll beherbergt findet man in der Registry einen Verweis auf diese dll a la: Software -> Pfad -> *.dll, also so eine Art Quasi-Assign wie man es von Amiga her kennt.

Arbeitende malware funktioniert unter win vista und arbeitet auch wie es die malware-Autoren vorgesehen haben. Da gibt es keinen Unterschied zu winxp.

Hmm zur Registry:
Da kippen mal Schreibrechte um oder die Registry hält unbeirrt an etwas fest. Warum ist unbekannt. Deshalb hat der Softwareanbieter meines Forums auch einen Registry-Cleaner gebaut.
Besser organisiert wäre die Registry sicherlich wenn es einen Zweig nur für win, einen weiteren nur für die systemweiten Treiber und einen für die installierte Anwender-Software gäbe wo dann alles in dem jeweiligen Zweig enthalten ist (also z.B. alle Assigns, Programm-Module, Sheel-Externsions pp in dem jeweiligen Zweig eingetragen ist). Damit würde es reichen nach einer Deinstallation einfach diesen Zweig mit seinen Einträgen zu löschen (analog zu den Einträgen in der User-Startup). Leider gibt es so eine Untergliederung in der Registry nicht.
Dumm auch das es bei den win-Installern keine LOG-Funktion gibt.

Das mit der whql-Zertifizierung - akzeptiert, das Produkt in meinem Stammforum hat Treiber. Man hört das es von M$ bereits ein herunterladbares Zubehör gibt das diese Treiber-Programmierung vereinfacht. Eventuell werden dann in win eine Art Devices installiert damit die Treiber-Autoren weniger selbst zu programmieren brauchen.

Nun, wenn win zunächst im Installationsverzeichnis nach Programm-Modulen sucht - warum kippen aber dann so viele Programm-Hersteller immer noch alles in system32 hinein?

Michael

[ - Answer - Quote - Direct link - ]

2008-07-25, 15:57 h

Maja
Posts: 15429
User

Zitat:
Original von Holger:
Auch für das Startmenü braucht man keine Registry-Einträge. Das Startmenü ist ein Verzeichnis, in dem Verknüpfungen angelegt werden. Deshalb kannst Du auch auf "Programme" mit der rechten Maustaste klicken und den zugehörigen Ordner (bzw. einen der beiden) öffnen.

Uups, stimmt. Hatte mich wohl verrant. Dann danke für das "Nebelhorn".

Zitat:
Unterm Strich ist es auch völlig egal, ob schlecht geschriebene Programme eine Datenbank oder ein Dateisystem zumüllen. Allerdings leidet bei der Registry-Datenbank nicht die Performance darunter.

Auch richtig. Gilt aber nur so lange der (Rest)Müll nicht zu Problemen mit anderen Programmen oder sogar dem Betriebssystem selbst führt.

Zitat:
Programmierer schreiben gerne Programme. Was sie nicht gerne tun, ist

Dokumentieren

(Ordentlich) Testen

Schreiben von Installationroutinen

Schreiben von Deinstallationroutinen

Und wenn der Chef/der Geldgeber zufrieden ist, sobald etwas installierbares vorhanden ist, dass augenscheinlich irgendetwas tut, dann ist klar, was auf der Strecke bleibt. Viele Geldgeber sehen auch gar nicht ein, in Dinge zu investieren, die keine sichtbaren Veränderungen an dem installierbaren, das augenscheinlich irgendetwas tut, herbeiführt.

Vor diesem Hintergrund braucht man sich über WHQL nicht mehr wundern. Die Installation von Geräte-Treibern ist wohl so ziemlich das Einzige bei dem Eingriffe in die Registry und Änderungen an Systemeinsellungen unumgänglich sind. Und Geräte-Treiber sind das Einzige, was im Kernel-Mode läuft (laufen muss), im Betrieb also nicht vom OS kontrolliert wird. Daher müssen Geräte-Treiber besonders zuverlässig und vertrauenswürdig sein. Die Vergangenheit hat leider auch hierbei gezeigt; Vertrauen ist gut, Kontrolle ist besser.

Über die Höhe der Kosten für die Zertifizierung kursieren zum Teil abenteuerliche Angaben. Bis hin zu mehreren 10.000 USD für jedes neue Gerät. Wobei die Frage, an wen diese Gelder fließen, unbeantwortet bleibt. Ohne Möglichkeit selbst hinter die Kulissen zu blicken, kann man alles als "gottgegeben" hinnehmen oder sich fragen, ob es nicht auch anders und auf lange Sicht günstiger ginge. Das WHQL-Programm hat ein "Sub-Unternehmertum" auf den Plan gerufen; Unternehmen die für Hardware-Hersteller die vorgeschriebenen Testreihen durchführen, gegen Gebühr natürlich. Vermutlich liegt da der Hund begragen, wenn über immense Kosten "durch" die WHQL-Zertifizierung von Geräte-Treibern geklagt wird. Wenn dem so ist, darf ich mich auch fragen, ob einzelne Hersteller nicht besser darin investieren sollten die Testreihen selbst durchführen zu können, statt ihr Geld auf Dauer "Trittbrettfahrern" zu geben.

Wie läuft das überhaupt mit dem WHQL?
http://www.microsoft.com/whdc/winlogo/drvsign/kmsigning.mspx
http://www.microsoft.com/whdc/winlogo/drvsign/kmcs_walkthrough.mspx
http://www.microsoft.com/whdc/winlogo/drvsign/crosscert.mspx

[ - Answer - Quote - Direct link - ]

2008-07-25, 19:12 h

Maja
Posts: 15429
User

Zitat:
Original von Michael_Mann:
Der wininstaller von M$ ist so eine Art "Paketverwaltung" für Software & Registry. Der legt z.B. beim Installieren von Software backups von geänderten Registry-Werten an und spielt die wieder zurück wenn das Programm deinstalliert werden soll.

Nochmal. Demnach greift die Deinstallation mancher Programme auf Daten zurück, die vom Benutzer, wie oben beschrieben, längst gelöscht worden sein könnten. Übrigens können auch Registry-Cleaner zur Löschung solcher Daten verwendet werden. Diese Tools sind keineswegs nur ein Segen.

Zitat:
Daneben sollte er auch überflüssige Einträge löschen, blockierte Dateien/Ordner zum Deinstallieren freigeben und der Dinge mehr.

Dateien sind gemeinhin blockiert, wenn sie gerade benutzt werden. Ordner in denen benutzte Datei enthalten sind, können ebenfalls nicht gelöscht werden (alles andere wäre wohl auch Unsinn). Also ist entweder ein Neustart zur Entfernung erforderlich oder es werden erst mal alle relevanten Prozesse beendet. Aber das ist alles Sache des Programmierers, dafür Sorge zu tragen. Auch hierfür gibt es wieder Hersteller die beweisen, dass das durchaus sauber möglich ist.

Zitat:
In meinem Stammforum gibt es vermehrt Hinweise das diese Funktionen mittlerweile nicht mehr oder nicht mehr richtig funktionieren.

Darf man wissen, welches Forum das ist? Dann könnte man dort mal selbst nach diesen Hinweisen suchen. Oder gib halt mal einen Link auf einen entprechenden Thread dort.

Zitat:
Die Firma meines Forums selbst achtet sehr penibel darauf das eine Deinstallation auch eine vollständige ist - weil alles andere ist schlecht für den Ruf des Produkts

So sollte es sein.

Zitat:
Wenn man ein Programm hat das in seinem Installations-Ordner eine c++-dll beherbergt findet man in der Registry einen Verweis auf diese dll a la: Software -> Pfad -> *.dll, also so eine Art Quasi-Assign wie man es von Amiga her kennt.

Wenn "installiert" wird und der Programmierer es so wollte. Beim Aufruf wurde und wird ohne Pfadangabe in der Reg zuerst an dem Ort gesucht, von dem aus das Programm gestartet wurde. Eine einfache Pfadangabe ist allerdings kein Assign. Mit Assigns sind vielleicht Hard-/Softlinks entfernt vergleichbar.

Zitat:
Arbeitende malware funktioniert unter win vista und arbeitet auch wie es die malware-Autoren vorgesehen haben. Da gibt es keinen Unterschied zu winxp.

Welche sind das?
Wird die Funktion aufrgrund der bloßen Existenz vermutet oder wurde sie nachgewiesen?
Wie wurde Vista installiert (stand-alone oder als Upgrade eines vorhandenen XP)?
Sind UAC und Defender aktiv?

Zitat:
Da kippen mal Schreibrechte um oder die Registry hält unbeirrt an etwas fest. Warum ist unbekannt.

Wenn eine Deinstallation geschützte Reg-Keys ändern/löschen will, hält die Registry natürlich unbeirrt an den ursprünglichen Einstellungen fest, eben weil der Key vor Zugriff geschützt ist. Wenn Reg-Keys geschützt sind, hat es der Programmierer entweder so gewollt oder es handelt sich um eine sensible Systemeinstellung, an der er eigentlich nichts zu suchen hat. Ansonsten ist das dasgleiche Thema wie geschützte Dateien und Ordner.

Zitat:
Besser organisiert wäre die Registry sicherlich wenn es einen Zweig nur für win, einen weiteren nur für die systemweiten Treiber und einen für die installierte Anwender-Software gäbe wo dann alles in dem jeweiligen Zweig enthalten ist (also z.B. alle Assigns, Programm-Module, Sheel-Externsions pp in dem jeweiligen Zweig eingetragen ist).

Es gibt:
HKLM/Software/
HKCU/Software/

Wer oder was hindert Programmierer daran, genau so vorzugehen? Was nur die Software selbst benötigt, muss doch nicht global eingetragen werden. Mal abgesehen von Dingen wie das Kontextmenü oder die Zuweisung von Dateitypen. Wohl gemerkt, Software (Anwendungen, Spiele). Geräte-Treiber sind ein anderes Thema.

Zitat:
Dumm auch das es bei den win-Installern keine LOG-Funktion gibt.

Ich frage mich, wo bei einigen Programmen das "Uninstall.log" im Programmverzeichnis herkommt.

Fall es noch nicht mit einem Reg-Cleaner gelöscht wurde, weil *.log ist ja "überflüssig" wie *.bak.

Nix für ungut. Ich verwende so ein Tool auch. Allerdings nur im "Notfall" und dann auch nur mit allergrößter Vorsicht. Trotzdem hats mir auch schon Probleme gebracht weil ich etwas habe löschen lassen, was noch gebraucht wurde.

Zitat:
Das mit der whql-Zertifizierung - akzeptiert, das Produkt in meinem Stammforum hat Treiber. Man hört das es von M$ bereits ein herunterladbares Zubehör gibt das diese Treiber-Programmierung vereinfacht.

Unterstüzende Tools für die Signierung werden schon länger angeboten. Was bei der Treiber-Programmierung für Windows zu beachten ist, ist seit Jahren umfangreich dokumentiert. Alles zum kostenlosen Download.

Zitat:
Eventuell werden dann in win eine Art Devices installiert damit die Treiber-Autoren weniger selbst zu programmieren brauchen.

Gibt es.

Zitat:
Nun, wenn win zunächst im Installationsverzeichnis nach Programm-Modulen sucht - warum kippen aber dann so viele Programm-Hersteller immer noch alles in system32 hinein?

Weil ihnen irgendwer mal erzhält hat, dass unter Windows alles "installiert", über die ganze Festplatte und Registry verteilt werden "muss" und sie im Traum nicht auf die Idee kommen, es könnte auch anders gehen? "Haben wir immer so gemacht."?

Eine Ankedote aus dem realen Leben. Gothic 3 auf externe Festplatte installiert und irgendwann dort "vergessen". XP platt gemacht. Vista installiert. Drei Wochen später beim Stöbern Gothic 3 wieder gefunden. In einem Anfall von Forscherdrang gothic.exe aus dem Programmverzeichnis aufgerufen. Spiel läuft einwandfrei. Und jetzt kommts. Wird dieses Spiel unter Vista installiert, macht es erst mal Probleme und muss gepatcht werden oder lässt sich gar nicht installieren. Ist doch interessant, oder?

[ - Answer - Quote - Direct link - ]

2008-07-26, 08:23 h

Andreas_B
Posts: 3121
User

@Maja:
> Darf man wissen, welches Forum das ist?

Ich tippe mal, er meint das Forum von AntiVir.

Ciao,
Andreas.

[ - Answer - Quote - Direct link - ]

1 -2-

[ - Post reply - ]

amiga-news.de Forum > Andere Systeme > Vista:kostenloser Festplatten Manager

[ - Search - New posts - Register - Login - ]