Komfortabler Dateimanager mit vielen Funktionen

Produkte

SpeedCommander 10.5

By Sven on 20.09.2005 - 12:45 in SpeedCommander 10 with 5 Kommentare

Kurz vor der ersten öffentlichen Betaversion von SpeedCommander 11 habe ich noch eine 10.5-Version eingeschoben. Damit ist die aktuelle Version packertechnisch auf dem gleichen Stand wie Squeez 5 und der kommende SpeedCommander 11. Alle drei benutzen nun für die Packroutinen und für die Such- und Syncfunktionen die gleiche Quellcodebasis. Somit können spätere Fehlerbehebungen auch ohne großen Aufwand noch in den SpeedCommander 10 einfließen.

Schöner testen

By Sven on 24.08.2005 - 16:50 in SpeedCommander 11 with 21 Kommentare

In den letzten beiden Tagen habe ich den Dialog, der beim Programmstart auf die 60-Tage-Testversion hinweist, ein wenig runderneuert. Alexandra hatte wieder einmal eine tolle Idee, wie man diesen Dialog etwas frischer und moderner gestalten kann. Zusätzlich zu der Fortschrittsanzeige mit den ablaufenden Tagen zeigt nun auch ein passender Farbverlauf, dass die Testzeit langsam zu Ende geht.

Erstes Drittel

Nach dem ersten Drittel erscheint das Fenster nun in einem Gelbton.

Zweites Drittel

Das letzte Drittel der Testzeit wird dann rötlich dargestellt.

Letztes Drittel

AddIns in SpeedCommander 11 (Teil 1)

By Sven on 14.06.2005 - 19:13 in SpeedCommander 11 with 11 Kommentare

Seit einigen Jahren wünschen sich die Anwender immer wieder eine Pluginschnittstelle im SpeedCommander. Bisher hatte ich mich immer etwas dagegen gesperrt, weil ich vom Pluginkonzept anderer Anwendungen nicht ganz überzeugt war. Ein Plugin muss sich in die Anwendung integrieren können, es muss Befehle zur Verfügung stellen und es muss auch die Möglichkeit bestehen, diese Befehle aus Menüs und Symbolleisten aufzurufen. Die Konfiguration sollte möglichst einfach gehalten werden und nicht über viele Dialoge verstreut sein.

Nach vielen Überlegungen bin ich auf das AddIn-Konzept von Microsoft gestoßen, das unter anderem in den Office-Produkten und in Visual Studio eingesetzt wird. Diese AddIns können mit jeder Sprache entwickelt werden, mit der sich COM-Objekte erzeugen lassen. Dies ist ein großer Vorteil gegenüber dem klassischen Dll-Konzept mit einem Satz von exportierten Funktionen, da sich auch mit Visual Basic und dem .NET-Framework COM-Objekte programmieren lassen. Beim klassischen Dll-Konzept bleiben Visual Basic und .NET nämlich außen vor.

Ein AddIn ist ein COM-Objekt und bietet verschiedene Schnittstellen an. Zwingend erforderlich ist lediglich die Schnittstelle IDTExtensibility2, welche aus fünf Methoden besteht:

  • OnConnection
  • OnStartupComplete
  • OnBeginShutdown
  • OnDisconnection
  • OnAddInsUpdate

OnConnection wird aufgerufen, wenn das AddIn geladen wird. Das AddIn erhält jeweils einen Zeiger auf das Application-Interface von SpeedCommander und auf das Interface des AddIn-Objektes. Dazu bekommt es noch die Information, wie das AddIn geladen wurde. Dies kann einerseits gleich beim Starten von SpeedCommander geschehen oder später durch nachträgliche Installation oder Aktivierung des AddIns. Über das Application-Interface kann das AddIn später auf das umfangreiche Objektmodell von SpeedCommander zugreifen und z.B. neue Befehle oder eigene Symbolleisten erzeugen.

Wenn SpeedCommander komplett initialisiert wurde, wird bei allen geladenen AddIns die Methode OnStartupComplete aufgerufen. Hier kann das AddIn Funktionen aufrufen, die bei der Initialisierung eine Interaktion mit dem Benutzer erfordern. OnBeginShutdown wird aufgerufen, bevor SpeedCommander beendet wird. Das AddIn kann an dieser Stelle z.B. seine Einstellungen speichern.

Bevor das AddIn entladen wird, ruft SpeedCommander die Methode OnDisconnection auf. Dem AddIn wird hier auch der Grund des Entladens mitgeteilt. Das AddIn kann somit erkennen, ob es z.B. vom Anwender deinstalliert wurde und somit seine Einstellungsdaten löschen kann.

Die fünfte Methode OnAddInsUpdate wird aufgerufen, wenn ein anderes AddIn geladen wird. Wenn z.B. die AddIns A und B bereits geladen sind und später das AddIn C geladen wird, dann ruft SpeedCommander die Methode OnAddInsUpdate von AddIn A und B auf. Ist z.B. ein AddIn abhängig von einem anderen, so kann das AddIn hier prüfen, ob das andere AddIn geladen oder entladen wird.

fsc.exe und die angebliche Fernwartung

By Sven on 02.05.2005 - 15:02 in SpeedCommander 10 with 2 Kommentare

Es gibt gewisse Anwendergruppen, welche kommerzielle Software gerne ohne Bezahlung nutzen. Diese treffen sich dann unter anderem im Forum des Community Leaders Founders Cosmo Connor und diskutieren darüber, wie man mit den Tücken der Software zurechtkommt, die sich gegen eine unberechtigte Nutzung zur Wehr setzt.

So schreibt Elektrospeedy dort zum Beispiel:

Hi, ich möchte Euch aber ans Herz legen, die Datei fsc.exe vor der Installation von SC umzubenennen oder zu löschen. Die Installation funktioniert trotzdem und auch SC selber greift nicht direkt darauf zu. Googelt aber mal nach fsc.exe. und Ihr werdet verstehen, warum man mistrauisch sein sollte. Irgendwie arbeitet es auch mit Netframework zusammen und verbindet sich mit einem Sever im Internet. Ich bin damals beim SC10 stutzig geworden, als bei installiertem Netframework plötzlich fsc.exe ins Netz wollte (die Firewall hat es aber unterbunden).

Wenn man dann in Google einmal nach „fsc.exe“ sucht, dann gibt es in der Tat interessante Ergebnise. Über den ersten Beitrag findet man zur Seite Pflege von Webseiten und Verzeichnissen mit dem „FileServer Commander“ und hier heißt es:

Der Fileserver Commander FSC.EXE ist das ultimative Werkzeug zur Fernwartung eines Fileservers von Clients aus, die sich im Netz befinden, deshalb wurde für diese Software die Kurzbezeichnung „Fileserver Commander“ gewählt.

Einige Einträge später kommt dann auch das .NET-Framework mit ins Spiel. fsc.exe ist nämlich zufällig auch die Abkürzung für den F#-Compiler:

The compiler fsc.exe is a traditional command line compiler with a set of command line switches similar to both the OCaml compiler and the C# compiler.

Elektrospeedy zieht daraus nun folgende Schlussfolgerungen:

Ich denke mal, das hing auch mit diesem KG zusammen und der basierte ja auf Netframework. Der sucht sich auf der HD diese Datei und versucht sie zu nutzen.

Aber bitte, mal einige Schlagzeilen aus Google:
Der Fileserver Commander FSC.EXE ist das ultimative Werkzeug

NET framework – not inculded the zip; Requires F#/AbsIL – not inculded the zip; Requires the Fsc.exe and csc.exe compilers to be on the path

utils/winnt: (among other things). rtpudpsvc.exe – rtp server; fsc.exe – Field Setup Controller; nci.exe – Network Control Interface

ive been infected by a bloody trojan or the like….help! – Tech … – [ Diese Seite übersetzen ]… O4 – HKLM..Run: [Kec] C:\WINDOWS\System32\Fsc.exe O4 – HKLM..Run: [Gvv] C:\WINDOWS\System32\Urm.exe O4 – HKLM..Run: [Rqh] C:\WINDOWS\System32\Qsr.

File: c:\windows\fsc.exe Positive identification: TrojanClicker.Win32.Spywad.a File: c:\windows\rmp.exe Positive identification: TrojanClicker.Win32. …

Ich habe die Links zwar nicht im weiteren Verfolgt, doch das mahnt schon zur Vorsicht, zumal fsc.exe im Hintergrund ohne sichtliche Meldungen abzulaufen vermag. Wie schon gesagt, durch deaktivierung habe ich noch kein Fehlverhalten des SC feststellen können.

Ich kann Elektrospeedy aber beruhigen. SpeedCommander und natürlich auch alle anderen von mir veröffentlichten Anwendungen enthalten keinerlei Funktionen, um remote (ohne Wissen des Anwenders) auf andere Rechner zuzugreifen und sie senden auch keine Informationen „nach Hause“. Die Datei „fsc.exe“ heißt so, weil fsc einfach nur die Abkürzung für FileSync Command Line ist. Durch das Löschen dieser Datei wird SpeedCommander nur um die Programmfunktion zum Synchronisieren von Ordnern via Kommandozeile beraubt, nicht mehr und nicht weniger.

Aufbruch in das XML-Land

By Sven on 20.03.2005 - 15:22 in SpeedCommander 11 with 3 Kommentare

Das Speichern der Programmeinstellungen in der Registrationsdatenbank hat sich zwar mittlerweile durchgesetzt, doch für mobile Anwendungen entstehen damit auch einige Nachteile. Beim Start auf fremden Systemen sieht z.B. SpeedCommander so jungfräulich frisch aus wie nach einer Neuinstallation. Man kann als Parameter zwar einen vorher exportierten Registrationsauszug übergeben, den SpeedCommander beim Start in die hiesige Registrationsdatenbank einträgt und nach dem Beenden selbständig wieder löscht. Allerdings verfallen hier wieder alle während des Betriebes geänderten Einstellungen. Auch bei einer Neuinstallation von Windows bzw. dem Zurückspielen eines Images sind alle davor geänderten Einstellungen wieder weg.

Mit dem Update des Xtreme Toolkit Pro auf die Version 9.60 führte Codejock ein cleveres System zur Speicherung von Einstellungen ein. Die Basis ist eine Klasse CXTPPropExchange, die alle grundlegenden Funktionen zum Lesen und Schreiben von Daten unterschiedlicher Typen enthält. Zur Umsetzung auf den jeweiligen Ausgabetyp sind davon dann die Klassen

  • CXTPPropExchangeArchive
  • CXTPPropExchangeRegistry
  • CXTPPropExchangeXMLNode
  • CXTPPropExchangeIniFile

abgeleitet. Sämtliche Objekte speichern ihre Daten über die Klasse CXTPPropExchange, ihnen ist es egal, ob die Serialisierung nun in eine binäre Datei, in die Registry, in eine INI-Datei oder in eine XML-Datei geschieht. Die Entscheidung dafür liegt dann in der Hand des Anwendungsprogrammierers.

Diese Idee hat mich so begeistert, dass ich für SpeedCommander 11 und Squeez 5 nun endlich einmal die Umstellung auf XML in Angriff genommen und nach einer Woche auch erfolgreich zum Abschluss gebracht habe. Fast alle Einstellungsdaten werden nun leserlich in eine XML-Datei geschrieben. Übrig bleiben nur noch die Tastenkürzel und die Einstellungen für das Menü und die Symbolleisten, die in binäre Dateien gespeichert werden. Zwar ist hier eine Umstellung auf XML auch möglich, allerdings ist es doch ein wenig Overkill, angepasste Symbole mit Base64 zu kodieren und in einer XML-Datei abzulegen.

Einstellungssache

By Sven on 18.02.2005 - 17:19 in SpeedCommander 11 with 3 Kommentare

In der letzten Zeit war ich sehr mit dem Redesign der Einstellungsdialoge von SpeedCommander beschäftigt. Man denkt eigentlich, dass es doch gar nicht so schwer ist, ein paar Dialogelemente im Fenster zu verteilen, aber da steckt einiges an Arbeit drin.

Ein Nachteil der bisherigen Implementation ist, dass die Einstellungen in einzelne Dialoge aufgeteilt sind und der Anwender somit viel zu viel mit dem Öffnen und Schließen der Dialogfenster beschäftigt ist. Ein guter Freund überzeugte mich auch, dass die derzeitige Anordnung eher so aufgebaut ist, wie es der Programmierer sieht; aber nicht so, wie es der Anwender gerne hätte. Er erklärte sich bereit, mit mir zusammen die ganze Sache einmal auf neue Füße zu stellen.

Wir haben die einzelnen Einstellungen nach dem Muster Aussehen, Verhalten und Erweitert aufgeteilt und dann in zusammengehörige Gruppen sortiert. Die zeitintensivste Arbeit war dann aber das Dialogdesign selbst. Die Dialoge sollen schließlich gut zu bedienen sein, schick aussehen und sich auch an den Styleguide von Microsoft halten.

Top