Hallo@Allerseits,

eine meiner berühmt-berüchtigten Fragen, weil's auch dringend ist, und ich zu keinem für mich verwertbaren Ergebnis komme:

Wenn ich in der Eingabeaufforderung "phoner.exe" oder "phoner" eingebe, dann startet Phoner. Völlig klar, völlig logisch. Das gleich passiert auch, wenn ich in einer DOS-Batch-Datei scripte: "start phoner".

Gibt's das jetzt auch irgendwie umgekehrt?

Also einen Parameter, den ich an "phoner.exe" anhänge könnte (etwa "phoner /Q" oder "phoner /Quit"), damit Phoner auch per ShellScript oder über die Eingabeaufforderung beendet werden kann?

Oder ist das Beenden von Phoner mit einer Brigde unter Verwendung des Commandos "rundll32.exe phoner.exe IrgendEinComArgument" möglich? Ich meine, Phoner hat ja genügend COM-Schnittstellen, nur die für's "Beenden" finde ich leider nicht.

Bisher löse ich das Problem mit einer Fremdsoftware der Orange Lamp Software Solutions  namens "KillProcess". Aber irgendwie ist mir der rabiate Abbruch eines laufendes Prozesses zu Wider, und es wäre besser, könnte man den Prozess von sich alleine aus beenden. Zwar könnte ich auch in Win2003 und XP die "taskkill.exe" benutzen; ich suche jedoch nach einer Lösung, die für alle Windows-Versionen seit 95 machbar ist.

Ausserdem kann der plötzliche Abbruch eines Tasks dazu führen, dass ein Datenverlust auftritt. Beim "natürlichen" Programm-Beenden-Aufruf erfolgt normalerweise die Speicherung aller Daten, bevor der Prozess endet.

Vielen Dank bereits im Voraus
Grüße vom Kai

Moin@Forum Admin Heiko,

triftige Gründe, warum Phoner sich über die Kommandozeile bzw. per Batch-Kommando (ShellScript) schliessen lassen können muss, gibt es nicht.   Wenn es diese Möglichkeit jedoch gäbe, wäre es möglich, per Batch oder Eingabeauffoderung:

- ohne Zusatzprogramme Phoner regulär zu beenden, ohne den Task einfach abzubrechen,
- zudem Phoner ohne die Gefahr eines Datenverlustes zu beenden, und
- Phoner mehr oder weniger "automatisch" zu einem bestimmten Zeitpunkt zu beenden, um ihn auch mehr oder weniger automatisch mit neuen Einstellungen starten zu lassen.

Anwendungsbeispiele (basierend auf Batch-Scripting):

Neuinstallation eines Programmes unter Windows

Oft sieht man während der Programm-Installation die Aufforderung, alle laufenden Programme zu beenden, bevor man "das neue" installiert. Dies hat den Grund, dass Programmdateien oder zentrale Bibliotheken (DLL's), die gerade durch ein Programm "gebraucht" werden, nicht durch neuere Versionen ersetzt werden können. Per Batch kann man nun bequem alle laufenden Programme beenden, die Installation starten, und anschliessend nacheinander alle Programme erneut starten (da unter XP nicht immer ein Neustart erforderlich ist). Zugegeben, wenn eine Installation gleichzeitig auf 100 Rechnern oder mehr erfolgt, ist so ein Script eine wesentliche Erleichterung   .

Virenüberprüfung

Ein Programm, das permanent gestartet ist, läßt sich nicht vollständig auf Viren überprüfen. Es kommt zu einem I/O-Fehler, den jedoch die meisten Virenschutzprogramme übergehen (so auch dass bekannte, jedoch kaum geeignete Symantec-Antivirus). Erst wenn vor dem Start einer Virenprüfung ein Programm beendet wurde (z. B. durch Batch), kommt dieser Fehler nicht mehr vor. Das Batchkommando "START /W Irgendeinevirenprüfung" kann nach dem Durchlauf der Prüfung genutzt werden, alle benötigten Programme wieder zu starten.

Starten von Phoner mit unterschiedlichen Einstellungen

Mein eigentliches "Problem", wie ich zugeben muss. Weil's immer öfter hier im Forum gefragt wurde, und ich auch einen nützlichen Zweck hierin erkannt habe, sitze ich an einer fast fertigen Batch-Lösung, um Phoner mit einer Zeitsteuerung in Verbindung zu bringen.

Da ich selber (bzw. meine Scripte) keine Änderungen an einer bereits konfigurierten Phoner.ini eines beliebigen Benutzers vornehmen möchte, bleibt das dem Anwender selber überlassen. Jedoch sieht meine Planung vor, dass der Benutzer verschiedene Einstellungen konfigurieren kann, die automatisch über ein Batch-Script durch den Task-Planer aufgerufen werden.

Ist Phoner einmal in einer Instanz gestartet, können per Batch keine "neuen" Einstellungen an der bestehenden phoner.ini vorgenommen werden, die dann Gültigkeit für den bereits laufende Phoner haben. D. h. Phoner muss beendet, die Phoner.ini ausgetauscht und dann Phoner erneut gestartet werden - alles über ein Script, dass durch den Taskplaner ausgeführt wird.

Bisher habe ich mir mit dem zusätzlichen Programm "KillProcess" zu helfen gewußt. Das finde ich jedoch aus bereits genannten Gründen "suspekt", da damit nicht der einem (gut programmierten) Programm ureigene Mechanismus ausgelöst wird, alle (auch ausgelagerten) Daten vor Beendigung zu speichern.

Hierfür habe ich ein nettes Beispiel für ein "schlecht gemachtes" Programm: Den Powerarchiver. Startet man dieses Programm, und bricht den Task im Task-Manager ab, "zerschiesst" man sich förmlich die Benutzer-Oberfläche. Das passiert dadurch, dass der jeweillige Skin geladen wird, und - weil man die Einstellungen hierzu auch verändern kann - die Benutzeroberfläche komplett "ausgelagert" wird, entweder in den Speicher oder die Auslagerungsdatei. Bricht der Task ab, so kann selbstverständlich nichts mehr gespeichert werden - und beim nächsten Start ist mit 50-%-iger Wahrscheinlichkeit die GUI kaputt, und läßt sich auch nicht wieder herstellen.

Um ein Programm per Batch oder Eingabeaufforderung zu beenden, gäbe es mehrere Möglichkeiten:

a) Das Programm ist ein "Dienst" oder als "Dienst" registriert.

Dann kann man per Batch seit NT festlegen: NET START "Dienst.exe" oder NET STOP "Dienst.exe".

b) Das Programm hat eine Schnittstelle, die seit Windows 98 mit "rundll32.exe" angesprochen werden kann.

In diesem Fall kann man per Script und Befehl "RUNDLL32 [DLLoderProgrammExe], [Parameter]" auch ein Programm beenden, wenn es eine Schnittstelle hierzu bietet, und der Parameter für "Speichern und Ende" definiert wurde.

c) Das Programm kann mit dem Aufruf "ProgrammName.exe /ParameterFürQuit" beendet werden.

Wenn Du mich also fragst: Für diese Funktion gibt es den guten Grund, dass auch eine automatische Kontrolle oder Steuerung kompfortabel gelöst werden kann - und das unter allen Windows-Versionen, auf denen Phoner auch lauffähig ist.  

D. h. jetzt nicht zwangsläufig, dass Du Dich dazu gedrängt fühlen musst, das jetzt einzubauen - ich wollte nur mit meiner Anfrage in Erfahrung bringen, ob's dass schon gibt   .

Oh... gewohnt schnelle Antwort   Danke!

Ich weiss nicht, ob Du meinen nachstehenden Gedanken brauchbar findest.

Beim Aufruf (bisher ohne Paramter) erzeugt Phoner doch bestimmt eine PID (ProcessID).

Da diese ID bestimmt Variabel ist (man will ja nicht unbedingt mit einem anderen laufenden Prozess kollidieren), könnte man Phoner beim Aufruf diese PID irgendwo speichern lassen. Im seltensten Falle wird man eine "statische" PID erzeugen, wenn der Zugriff auf einen Prozess (Programm, DLL o. ä.) durch andere Prozesse nicht ausdrücklich erlaubt sein soll (Anwendungsbeispiel: Apache Webserver, schneller Zugriff auf die statische PHP-Implementation)

Problem: Wenn ich das richtig verstehe, kann Phoner mittlerweile in drei Instanzen betrieben werden: Jeweils eine für den CAPI-, SIP-, und TAPI-Modus. D. h. es existierten drei unterschiedliche PID's.

Um diese zu "killen" müßte der Parameter-Aufruf eines vierten Phoners wahrscheinlich variabel sein, etwa: "phoner.exe /quitcapi /quittapi /quitsip".

Beim Empfang dieser Parameter würden alle drei laufenden Instanzen, so wie ich sie oben beschrieben habe, beendet, da jeder Instanz eine PID zugewiesen wurde, die man lediglich noch dem Phoner in einer bestimmten Betriebsart zuordnen müßte...

Im Falle von drei laufenden Instanzen, jedoch beim gewollten beenden des CAPI-Phoners, müssten die Parameter (bzw. der Parameter) folgendermaßen abgearbeitet werden:

"phoner.exe /quitcapi" - d. h. die Phoner-Instanz mit der gültigen PID im CAPI-Modus wird beendet.

Als allumfassende Möglichkeit wäre natürlich eine rigorose Option "phoner.exe /quitall" zusätzlich möglich; jedoch liesse sich ja - ausgehend vom Parameter - eine Prüfung "nach unten hin" realisieren. D. h. bei

"phoner.exe /quitcapi" würde geprüft: Gibt's 'nen CAPI-Modus-Phoner in der PID-Liste, wenn ja, mach' den platt, wenn nein: Laß die anderen Instanzen laufen, und terminiere Dich selbst.

Phoner startet Deiner Aussage gemäß zukünftig  in einer weiteren Instanz, und terminiert dann bei entsprechendem Parameter den laufenden Prozess und alle anderen?

Demnach könnte - so denke ich es mir - vor dem Laden der phoner.ini geprüft werden, ob ein Parameter übergeben wurde. Phoner "fährt" nicht komplett hoch, nur um sich und andere Instanzen zu terminieren, sondern prüft - so wie oben beschrieben - ersteinmal, ob existierende Phoner-PID's vorhanden sind, und welche dieser PID's den verschiedenen Betriebsmodi zugeordnet sind.

Am einfachsten lösbar wird es wahrscheinlich sein, wenn's ein zusätzliches kleines Command-Tool gäbe; etwa "TerminatePhoner", dass die entsprechenden Funktionen zum "Speichern und Beenden" im Phoner auslösen würde, ohne den Prozess "phoner.exe" á la "KillProcess" zu killen.

Ich hoffe, Du konntest etwas aus dieser wirren Darlegung meiner Idee für Dich verwerten - und Danke bereits für Deine neuerlichen Mühen...

Grüße vom Kai

Also:
Es gibt in der aktuellen Beta von heute zwei neue Kommandozeilenparameter:

• /kill: Beendet eine evtl. laufende Version von Phoner aus dem gleichen Verzeichnis
• /killall: Beendet alle laufenden Phoner-Instanzen

Funktionierts denn auch?

Doch 'n klitzekleines Dingen ist mir aufgefallen, was jetzt aber nicht unmittelbar ein Problem darstellt, oder einer Lösung bedarf. Fühle mich halt als Tester, und gebe Dir für Deine tolle Freeware gerne Rückmeldung  

Und zwar liegt es wahrscheinlich daran, dass Du die jeweilige Phoner-Instanz anhand der Pfadagaben des Ordners der gestarteten Instanz identifizierst... Denk ich mir mal so:

Wenn ich Phoner unter Win2003 z. B. über Autostart oder über Doppelklick starte, dann startet Phoner aus einem Verzeichnis, welches auf der Basis des jeweils benutzten Betriebssystemes (bei mir XP und W2003)  mit langen Datei- und Ordnernamen gespeichert bzw. identifiziert wird.

Beispiel: C:\Dokumente und Einstellungen\Benutzer001\Desktop\Phoner\phoner.exe

Wenn ich per Script oder Eingabeaufforderung in der CMD-Konsole (DOS-Befehlserweiterung) den Phoner "kille", dann endet wie gewünscht die Instanz.

Beispiel: C:\Dokumente und Einstellungen\Benutzer001\Desktop\Phoner\phoner.exe /kill

Wen ich per Script oder Eingabeaufforderung in der COMMAND-Konsole (DOS-Shell der "alten" command.com, abwärtskompatibel) einen Phoner zum Terminieren bringen will, der vorher über CMD oder den Explorer (Autostart, Doppelklick etc.) ab Windows 98 bis Windows 2003 gestartet wurde, dann passiert mit dem Parameter "kill" nichts.

Beispiel: C:\DOKUME~1\BENUTZ~1\DESKTOP\PHONER\phoner.exe /kill

Erst wenn ich Phoner aus der COMMAND-Konsole starte, 

also: START C:\DOKUME~1\BENUTZ~1\DESKTOP\PHONER\phoner.exe

läßt sich Phoner mit dem Parameter "kill" beenden. Gleiches gilt, wenn ich in der CMD-Konsole kurze Ordnernamen zum Start von Phoner benutze.

Der Parameter "killall" bewirkt dagegen, egal auf welcher Konsole ich mich befinde, oder unter welcher BetriebsSystemVersion, dass ein - egal wo und wie gestarteter Phoner - beendet wird. Daraus schliesse ich, dass Du die Suche nach dem zu terminierenden Programm generell auf Prozesse mit dem Namen "phoner.exe" begrenzt hast, ohne auf eine bestimmte Verzeichnisbezeichnung einzugrenzen.  

Darf ich folgendes vorschlagen?

Um Phoner "generell" unter allen Konsolen terminierbar zu machen, müsste lediglich die Suche oder Rückmeldung einer gestarteten Phoner-Instanz, in zwei Arten möglich sein, anhand derer man eine Instanz eindeutig identifizieren kann:

Einmal: (juchu, ich bin der Phoner  , und ich wurde aus dem Verzeichnis) c:\dokumente und einstellungen\benutzer001\desktop\phoner\ (gestartet), und zum anderen:

(Damit mich auch Steinzeitliebhaber wie die COMMAND.COM verstehen:) c:\dokume~1\benutz~1\desktop\phoner\

Das derzeitige Verhalten von Phoner ist jedoch absolut unproblematisch, da - je nach BetriebsSystemVersion - der interne Pfad ohnehin aufgrund der primär genutzten Konsole gesetzt wird. Also Windows 95 würde immer kurze Datei- und Verzeichnisnamen für interne Prozesse rückmelden, während seit Windows 98 erstmal auch lange Datei- und Verzeichnisnamen für die interne Verarbeitung benutzt werden können.

Danke nochmals und viele Grüße vom Kai

P. S.: Dir 'nen sonnigen Vatertag noch!

Klar, es tut's doch auch so 

Ich sehe auch warum: Die neue 1.72 ist da - ich stürz mich derweil mal da drauf

Danke und CU

Dann hast du das von mir am meist gehasste Feature eingeschaltet: "Minimieren statt Beenden".
Wer sowas aktiviert hat, der gehört auch bestraft