✔ Probleme mit UAC und Windows 7...

[mccae]

Hallo,

@mccae:
Der Vorteil der Variante mit cmd.exe ist, dass er bei Fehlern nur Exceptions wirft oder ggf. einfach nur nicht das ausführt, was du willst.
Die Variante über JNI kann bei Fehlern im C-Code (die werden ganz sicher in den Windows-DLLs auftreten) dein Programm zum Absturz bringt. Das ist also riskanter.

Dem kann ich leider nicht zustimmen.
Anscheinend gibt es hier ein Missverständnis was "ShellExecute" angeht.
C oder C++ sind nicht so böse wie ihr immer glaubt

ShellExecute liefert ein "HRESULT" welches sich in ein "INT_PTR" casten lässt und über Erfolg oder Misserfolg bescheid gibt.

Ein Wert > 32 steht für Erfolg, alle anderen Werte für einen ganz bestimmten Fehler.
Von diesen Fehlern gibt es einen ganzen Haufen, sei es ein OutOfMemory Error oder ein Fehler weil die ausführbare Datei gar keine ist! (was ja bei cmd.exe nicht rauszufinden ist).

Diesen int Wert caste ich wiederum in ein jint (die Version des Java Integers in C aus jni.h), gebe es zurück und interpretiere es dann auf der Java Seite wo dann entsprechende Exceptions geworfen werden.
Auch ein direktes Werfen von Java Exceptions von der C Seite aus ist möglich.

Ich verstehe nicht was da etwas zum Absturz bringen kann.
Wenn "ShellExecute" erfolgreich war, wirken sich spätere Programmfehler nicht auf die JVM aus da die Prozesse nicht gekoppelt sind.

Mit freundlichen Grüßen,
Martin C.

 

[genodeftest]

Hallo,
Dem kann ich leider nicht zustimmen.
Anscheinend gibt es hier ein Missverständnis was "ShellExecute" angeht.
C oder C++ sind nicht so böse wie ihr immer glaubt

Es geht mir nicht darum, dass C/C++ böse ist, habe ich nicht behauptet (C programmiere ich selber - ein bisschen), sondern darum, dass häufig nativer Code die JVM zum Absturz bringt, was nicht erwünscht ist. Es gibt verschiedene Sicherungsmechanismen, um dies zu verhindern, aber die werden meist nur unzureichend genutzt.

Bestes Beispiel: die nativen Biblotheken von SWT.
Ich weiß nicht, warum diese Schutzmechanismen dort nicht aktiv sind, aber ich habe bereits mit verschiedenen Konfigurationen (XP und Ubuntu) allein durch vorgesehene Einstellungen im jeweiligen graphischen Toolkit Situationen erzeugt, die regelmäßig zum Absturz aller SWT-basierten Anwendungen führen. Und kein Absturz mir Eintrag ins Logfile oder Exceptions innerhalb des Programmes, sondern Abstürze der JVM selbst, weil diese nativen Bibliotheken Fehler verursacht haben.
Gegenbeispiel: mit JNA (Java Native Access, https://secure.wikimedia.org/wikipedia/en/wiki/Java_Native_Access ) ist es möglich, diese Abstürze zu verhindern.

// EDIT:
Anderes Beispiel:
Ein Segmentation Fault im nativen Code einer eingebundenen Biblothek nimmt die JVM meiner Anwendung mit ins Grab. Dagegen stört mich ein Segmentation Fault in einem von mir erzeugten Subprozess wenig bis gar nicht – und führt auf keinen Fall zum Absturz meines Programmes.

 

[mccae]

Huhu,

Was du schilderst mag in der Tat zutreffen, jedoch reden wir hier nicht über Monster wie SWT und dergleichen sondern über einen simplen, harmlosen und sicheren Call auf "ShellExecute" mit anschließender Rückgabe des HRESULTs.

Solange auf der C Seite alles sauber und sicher programmiert ist (es lassen sich auch debug mechanismen einbauen - Fehler lasse ich mir zum Beispiel ganz einfach auf STDERR ausgeben) müsste auch alles passen (Ich weiß, darauf sollte man sich trotzdem nicht verlassen).

Was diesen Fall also angeht, kann ich zumindest die JNI Variante bedenkenlos empfehlen.

mfg,
Martin