T3XT4
Beißer
|
Nachdem es hier um ein Tool geht, mit dem jeder mögliche Ballast von Windows entfernt werden soll, ist IMHO die Installation einer Laufzeitumgebung für den Endbenutzer unzumutbar. Damit fällt Java aus meiner Sicht schon mal aus.
Wenn wir mal davon ausgehen, dass WinXP irrelevant ist, dann bietet sich .NET 2.0 an. Das ist seit Vista beim OS dabei und recht bequem zu programmieren, gerade für solche GUI-Spielereien mit ein bisserl Systemintegration.
Eine reine C++-Variante als kleines handliches EXE ohne zusätzliche Libraries wäre auch ganz nett, ist aber *wesentlich* mehr Aufwand. Also ich würde euch daher C# empfehlen. Und z.B. Github als Host.
Ich werde aber nicht anfangen, das muss schon einer von euch machen. Für alles unter 1000 Zeilen braucht man keine UML-Diagramme (ein grundlegender Plan kann aber nicht schaden) und auch keine Architektur, sondern erstmal einen funktionierenden Prototypen. völlig korrekt, bis auf die korrektur auf 3.0, wenn ich richtig informiert bin. (dann können wirs ja fancy mit wpf machen :P)
|
userohnenamen
leider kein name
|
ja, 3.0 bei vista und 3.5 bei 7
|
GATTO
Here to stay
|
So grad noch was gefunden...
falls jemand die Shark Windows 7 Codecs hernimmt und fleißig updated: Man sehe mal unter Programdata/Win7Codecs nach... siehe da: auch dieses Codecpack speichert alle installationsdateien von allen bisherigen Installationen und da die teilweise alle 2 Wochen upgedated werden warens bei mir ganze 22 Stück a 25 Mb...
edit: Ach ja und die ganzen Beispielbilder/Musikdateien/Video im Benutzer/Öffentlich Ordner braucht man auch nicht wirklich...
Bearbeitet von GATTO am 29.01.2011, 07:27
|
GATTO
Here to stay
|
Is es nicht eigentlich egar auf welcher Basis das alles läuft?? Mit VMWare ThinApp http://www.vmware.com/products/thinapp/könnte man auch auf Net.Framework Basis eine Exe daraus machen ohne das net.framework auf dem Zielrechner installiert sein muss oder??? Sorry für den Doppelpost...
|
that
ModeratorHoffnungsloser Optimist
|
Is es nicht eigentlich egar auf welcher Basis das alles läuft?? Nein. Mit VMWare ThinApp http://www.vmware.com/products/thinapp/ könnte man auch auf Net.Framework Basis eine Exe daraus machen ohne das net.framework auf dem Zielrechner installiert sein muss oder??? Hast du die von dir verlinkte Seite gelesen? The packaged applications have awareness of each other but execute independently and make no changes to the underlying operating system Wäre etwas unpraktisch für ein Tool, das Teile von Windows löschen soll. Aber wie schon erwähnt, ist das Framework sowieso bei Windows dabei.
|
mat
AdministratorLegends never die
|
Auweh, da haben wir uns ja wieder mal das richtige Command-Line-Tool ausgesucht. pnputil.exe schreibt wegen einem Fehler nicht auf den Standard Output Stream, weshalb der Inhalt nicht so einfach abgelesen werden kann. Dafür muss man die Console per Fake Copy&Paste auslesen. Mehr dazu hier. Hab mir auch kurz die dazupassenden Funktionen im WDK angeschaut. Leider scheint es keine Funktion zu geben, die den Driver Store ausliest. Das macht pnputil.exe vielleicht auch via File Access. Der Driver Store wird ja relativ unproblematisch in C:\Windows\System32\DriverStore gelistet.
|
mat
AdministratorLegends never die
|
Nachdem ich mir noch ein bisschen Gedanken zu der Sache gemacht habe, will ich diese auch hier teilen. So wie es ausschaut, legt das Betriebssystem die Third Party Driver im Driver Store tatsächlich unter oem1.inf - oemXXX.inf ab. Wenn ein Driver wieder deinstalliert wird, dann fehlt der natürlich. Eine Liste dieser Third Party Driver konnte ich leider nirgendwo finden, weder im der Festplatte im Driver Store (wo alle Driver enthalten sind), noch in der Registry. Wie man die Sache dennoch lösen könnte, ist durch einen Brute-Force-Ansatz. Man könnte annehmen, dass es Hausnummer 100 Driver gibt (Grenze einstellbar im Tool - bzw. könnten auch immer 50 Positionen durchsucht werden und falls dann kein Driver mehr auftaucht, nach dem 50 aufhören) und diese werden dann gesucht und aufgelistet. Für die Informationen zu dem Driver kann man die Funktionen aus dem DIFx-Framework von Microsoft importieren ... das wäre nicht das Problem. Schön ist die Lösung halt leider nicht. Was denkt ihr?
|
Hansmaulwurf
u wot m8?
|
Sind alle in Windows/inf drin ?
Wir wärs mit letztem Namen(höchste Nummer) Auslesen, Nummer speichern. Dann checkt man bis zu der Nummer. Bzw sollt c# doch eh Datei-Namen in einem Ordner bekommen können ? Wenn es existiert wird es geöffnet, geparsed. Wenn wer löschen will, einfach console aufrufen mit dem Namen als Argument.
Oder hab ich grad was falsch verstanden ?
|
mat
AdministratorLegends never die
|
Die Existenz kann man wahrscheinlich besser mit DriverPackageGetPath() überprüfen. Sollte das nicht schnell genug funktionieren, dann könnte man natürlich einen Filecheck im Inf-Verzeichnis machen.
|
GATTO
Here to stay
|
Ähm Jungs also beim auslesen kann ich behilflich sein: im cmd einfach: Dism /online /get-drivers /format:table >c:\drivers2.txt
eingeben und schon hat man eine schöne liste mit allen nötigen Infos in einem hoffentlich brauchbaren Format... Hoffe das hilft.
edit: wenn man den parameter /all noch dazu gibt wirft er einem auch alle standardmäßig mitgelieferten aus... die kann man zwar auch mit pnputil löschen aber erst wenn man die rechte dafür übernommen hat... würde man z.B. alle HP Treiber so killen wärens auch wieder 100MB weniger...
Bearbeitet von GATTO am 01.02.2011, 20:36
|
mat
AdministratorLegends never die
|
Mhmm ... ich hab das Tool nicht bei meinem Vista Business dabei. Wie kann man es beziehen?
|
GATTO
Here to stay
|
Bearbeitet von GATTO am 01.02.2011, 22:11
|
mat
AdministratorLegends never die
|
Ahh, so geht's: driverquery /SI | find "oem"
So werden alle oem*.inf Files aufgelistet. Kann das jemand in Windows 7 gegenchecken bitte.
|
userohnenamen
leider kein name
|
ich hab damit jetzt 24 ergebnisse ausgeliefert bekommen
|
mat
AdministratorLegends never die
|
Passt, dann machen wir es so.
|