start.exe - Ein Tool zum Aufruf und zur Fernsteuerung anderer Anwendungen

start.exe

Wie es anfing Wo das Problem liegt Wie es weiterging Was es alles kann Was leider dazu gehört Download

start.exe: Eine kleine, selbstgeschriebene VisualBasic-Anwendung, die durch ein eigene ini-Datei konfiguriert werden kann, um andere Programme zu starten.

Wie es anfing:

Ursprünglich wurde das Tool dazu entwickelt, um eine auf einem Netzwerk-Fileserver liegende Access-Datenbankanwendung auf einheitliche Weise startbar zu machen. Normalerweise hätte sich jeder Benutzer z.B. auf seinem Desktop einen Link erstellen müssen, der dann spezielle Startkommandos für den Aufruf des Access-Runtime-Modules und der dazugehörigen Parameter enthält. Darin sah ich eine potentielle Fehlerquelle, zumal ich eine Dokumentation hätte erstellen müssen. Außerdem wäre irgendeine arme Sau bei dem Kunden mit ständigen Anrufen belästigt worden, wie denn die Anwendung aufzurufen sei etc.

Das Ganze sollte so einfach wie möglich ablaufen.
Die Anwender legen sich jeweils eine Verknüpfung zu start.exe im Projekt-Verzeichnis how2 an.
Völlig unabhängig von wo aus die start.exe-Anwendung gestartet wurde, liest sich das Tool ein paar Anweisungen aus der start.ini ein und bastelt auf dynamische Weise einen korrekten Aufruf-String für das zu startende Microsoft-Access-Runtime-Modul zusammen. So klappte dann das Starten der Access-Anwendung auch wunderbar, unabhängig davon, unter welchem Laufwerksbuchstaben die jeweiligen Anwender das entsprechende Server-Laufwerk in ihr Windows eingebunden hatten. Vereinzelt gab es noch etwas Ärger mit superverschachtelten Verzeichnisstrukturen und so tollen Verzeichnisnamen wie "Meine spannendsten Projektverzeichnisse~88", aber dem konnte mit pädagogischen Maßnahmen begegnet werden.

nach oben

Wo das Problem liegt:

Letztendlich liegt die Problematik, der das Tool entgegentritt, darin, daß die Typen von Microsoft schlicht und ergreifend unfähig sind, innerhalb ihrer selbst entwickelten Anwendungen auf ihren selbst entwickelten Dateisystemen Bezüge nach einem Verfahren herzustellen, daß man "relative Verweise" nennt.
So stellt der html-Verweis "start/index.htm" aus Sicht der download-Übersichtsseite einen relativen Verweis zu dieser Seite her, die selbst "index.htm" heißt und eben im Unterverzeichnis "start" liegt. Mit "../index.htm" verweise ich bei dem stehenden Männchen unten auf die Seite "index.htm" im übergeordneten Verzeichnis.
Diese Verweise heißen "relativ", weil sie keine absolute Verweise a'la "http://www.domain.de/irgendwas/etc" oder wie in der Microsoftwelt üblich etwas wie "C:\Programme\supertolle anwendung\bla.exe" enthalten.
Der Vorteil der relativen Verweise besteht darin, daß die kompletten Strukturen verschoben und irgendwo anders hin kopiert werden können.
Hat man erst mal den Einstieg gefunden, passt alles andere dann eben relativ wieder zusammen.
Das Tool ermittelt entsprechend den für den Anwender gültigen DOS-Pfad und bastelt dann die relativen Pfade für den Aufruf der Access-Runtime, der Access-Datenbank-Anwendung und einer speziellen Access-ini-Datei so zusammen, daß sich ein gültiges Aufrufkommando ergibt.

nach oben

Wie es weiterging:

Im alltäglichen Bürobetrieb im Umgang mit verschiedenen Anwendungen kommt es aus meiner Sicht oft vor, daß in bestimmten Kontexten Programme mit einem bestimmten Dokument oder bestimmten Benutzereingaben gestartet werden müssen und eben diese regelmäßig wiederkehrenden Eingaben ziemlich lästig sind.
So ist z.B. die gerade für Betreiber von Webseiten sehr hilfreiche Anwendung Xenu's Link Sleuth (info & download) in der Lage, komplette Webauftritte auf gültige Verweise aller Art (Links, Grafiken, css und andere verlinkte Dokumente etc.) hin zu überprüfen. So findet man schnell tote bzw. ungültige Links innerhalb der eigenen oder bei externen Webseiten, die man einfach nicht ständig überprüfen kann. Vor dem Starten der Prüfung muß allerdings jedesmal die URL der Webseite angegeben werden (z.B: "http://www.domain.de/irgendwas.htm"), was etwas lästig ist. Ich habe leider keinen Weg gefunden, dem tollen Progrämmchen einen Weg abzutrotzen, ihm das automatisiert abzuringen.
Im Rahmen meiner Access-Datenbankanwendungen hat es sich bewährt, externe Anwendungen kontextgerecht bequem zu starten und evtl. erforderliche Benutzereingaben über einen speziellen SendKeys-Befehl "hinterzuschicken".
Das vorliegende Tool start.exe wurde um diese Fähigkeiten erweitert und kann so z.B. die Linkcheck-Anwendung starten und die Eingabe der Webadresse vornehmen.

nach oben

Was es alles kann:

Wer dem Tool mittels eines Kommandozeilen-Befehles ein "?" als Parameter übergibt, erfährt, daß auch die auszuwertende Konfigurationsdatei angegeben werden kann.
Ohne jegliche Angabe wird versucht, eine start.ini in dem Verzeichnis auszulesen, in dem das Tool steht.
Alternativ können andere Namen wie "app1" bzw. ganze Dateinamen wie "app1.ini" übergeben werden, wenn die benannten Dateien ebenfalls im Tool-Verzeichnis stehen.
Auch kann eine solche ini-Datei an einem ganz anderen Ort stehen. Dann muß eben die vollständige Pfadangabe vorangestellt werden.

Die eigentliche Ansteuerung des Tools erfolgt durch die Einträge der ini-Datei.
Als Beispiel hier ein Link zu einer start.ini-Beispieldatei.
Die Datei ist in Englisch kommentiert, deswegen gebe ich hier nur eine grobe Übersicht über vorhandene Features.

Allgemein:
Grundsätzlich wird die Angabe eines Wertes als Aktivierung eines Features interpretiert.
Die Deaktivierung eines Features erfolgt über das Entfernen des Wertes oder durch Voranstellen eines ";" am Zeilenanfang.

Optionen:
Bei Bedarf kann eine Debug-Meldung ausgegeben, die Zeit, wie lange sich das Tool im Vordergrund aufhält oder gar auf einen Tastendruck warten muß sowie eine Icon- wie auch eine große Bilddatei angegeben werden.

Applikations-bezogene Angaben:
erlauben es, festzulegen, ob aktuelles Laufwerk und Pfad im benutzten Betriebssystem auf den Ort gesetzt werden, in dem das Tool liegt, sowie Pfadangabe und Name der auszuführenden Datei und in welcher Größe das Fenster der zu startenden Anwendung dargestellt werden soll.
Durch die Angabe eines Teiles des Fenstertiteltextes der Zielanwendung kann das Tool auch direkt zu der beabsichtigten Anwendung wechseln, wenn diese bereits geöffnet sein sollte. Durch Nutzen dieses Features dauert der Start nur solange, bis die Anwendung wirklich aktiv ist (das kann bei einer großen Anwendung beim ersten Mal recht lange dauern und geht danach wegen des Cache´-Speichers von Hard- und Software u.U. sehr fix). Ein Timeout-Wert gibt an, wie lange das Tool auf den Start der Zielanwendung warten soll. Allerdings habe ich schon mal ein Windows98-System gesehen, daß bei diesem Feature doch glatt den Dienst verweigern wollte.
Als manchmal sehr hilfreiches Schmankerl können nach dem Start einer Anwendung in 2 Phasen Tastaturanschläge gesendet werden, die auch künstlich verlangsamt werden können, wenn die Zielanwendung sich beim Empfang der automatisierten Anschläge "verschluckt".
Zur Dokumentation der Syntax, mittels der die automatisierten Tastaturanschläge anzugeben sind (typisch für Visual Basic und auch Visual Basic for Applications, wie es z.B. in den Microsoft Office-Programmen Word, Excel, Access etc. enthalten ist), ist dem download eine Textdatei sendkeys.txt beigelegt.

Microsoft Access:
Hierin lag die urspüngliche Aufgabe des Utilities, um Befehlszeilen-Kommandos zum Start einer Access-Runtime-Anwendung dynamisch zusammenzubauen und die Beschränkung dieses Runtime-Modules, nur 181 Zeichen entgegenzunehmen, möglichst effektiv auszunutzen.

Ab der Version 3.1 kann eine start.exe verschiedene ini-Dateien, deren Namen als Parameter übergeben wurden, auslesen, oder auch gleich vollends an die Stelle einer Windows-Verknüpfung treten.

Gerade bei Bosch-Rexroth kam es immer wieder zu Problemen, wenn z.B Access-Datenbankanwendungen per Windows-Verknüpfungen (Links) gestartet wurden, aber diverse Standorte das Laufwerk, auf dem die Verknüpfungen liegen, mittels verschiedener Laufwerksbuchstaben einbinden. Da relative Referenzierung für Microsoft selbst im Jahre 2005 weitgehend unbekannt ist, stoßen wir hier immer wieder auf ärgerliche Probleme.
Gruß an die Programmiererfraktion aus Redmond, Seattle: Schaut Euch doch mal an, wie man sowas in den 70ern unter UNIX oder in den 80ern sogar unter MS-DOS hingekriegt hat. Ohne relative Referenzierung von Dateien und Verzeichnissen würde es Webseiten kaum geben können.
Im vorliegenden Falle wurden alle Windows-Verknüpfungen durch Kopien einer 3.1-Version von start.exe ersetzt.
Beim Start einer derart umbenannten Anwendung (ohne jegliche Parameter) sucht start.exe, ob es in einem Unterverzeichnis "start" eine namensgleiche ini-Datei findet und liest diese dann aus. Laufwerksbuchstaben werden client-bezogen ermittelt und alle erforderlichen Angaben zusammengebaut.

nach oben

Was leider dazu gehört:

Verdutzt mußte ich bei einem privaten Einsatz feststellen, daß das Tool beim Start eine fehlende dll-Datei namens "msvbvm60.dll" anmeckerte.
Mein erster Verdacht bestätigte sich schnell, daß es sich dabei um eine Dynamic-Link-Library handelt, ohne die die in VisualBasic 6 erstellte Anwendung gar nicht laufen wollte. Die Microsoft-Dokumentation erwähnt nur lapidar, daß diese Datei nun mal eben zum Lieferumfang gehöre, wenn man jemandem eine in VisualBasic programmierte Anwendung geben wolle. Dieser hirnverbrannte Krampf erzwingt den download von "msvbvm60.dll" (per Google, gepackt 800kB), was den Umfang des nur 48kB großen Progrämmchens um 1,3MB vergrößert. Ich kann mich an QuickBasic-Zeiten erinnern, in denen man wählen konnte, ob die zu erstellende Anwendung möglichst klein sein (und dann eine Basic-Laufzeitumgebung benötigte), oder eben selbständig laufen sollte (und dann halt ein wenig größer war). Damals wurde die Anwendung auch noch automatisiert durch einen Compiler sowie einen Linker geschickt; wenn dann nicht so viele Funktionen implementiert wurden, wurde auch nicht so viel Code in die exe-Datei gemostet. Daß das ausgerechnet im 32Bit-Zeitalter nicht mehr möglich ist, halte ich für ein sehr trauriges Zeichen.
Ach ja, bevor ich's vergesse: die blöde dll-Datei steht normalerweise im Unterverzeichnis "system32" des Verzeichnisses, indem Windows installiert wurde. Wer die Datei ansonsten nicht braucht und seine Windows-Verzeichnisse nicht auch noch manuell zumüllen möchte, kann die Datei auch dort platzieren, wo das Tool start.exe steht.

nach oben

Download:

• start.zip (18 kB, enthält start.exe, start.ico, start.ini und sendkeys.txt)
• und leider den download von "msvbvm60.dll" (per Google, gepackt 800kB, wenn nicht bereits auf dem System vorhanden)
• evtl. ist auch noch der download von "vb6de.dll" vonnöten (per Google, ca. 100kB, wenn nicht bereits auf dem System vorhanden)

nach oben