Moin.
Man kann mit Hilfe der Registry in Windows 2000/XP bestimmen, mit
welcher Shell Windows starten soll. Normalerweise ist das der Explorer,
es lassen sich aber auch andere Programme angeben.
Der Schlüssel ist unter
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon]
und heisst Shell.
Trägt man dort zB cmd.exe ein, startet Windows nach dem Login nur die
Kommandozeile und zeigt lediglich ein eventuell eingestelltes
Hintergrundbild auf dem Desktop an. Die Taskleiste und alle
Desktopsymbole sind verschwunden. Für meine Anwendung als Kiosksystem
ist das ideal.
Nun möchte ich 2 Java Programme starten und habe mir dafür eine kleine
Launcher exe geschrieben, die so aussieht:
In der Datei programs.ini steht
java -classpath hsqldb.jar org.hsqldb.Server -database.0
file:hsqldb/fabu/fabu -dbname.0 fabu
und in weiteren Zeilen noch mehr, aber zum Testen reicht es. Starte ich
nun das Programm per Kommandozeile oder Doppelklick, wird das Java
Programm con CreateProcess gestartet und ich sehe die
Kommandozeilenausgabe.
Trage ich meine Exe als Shell ein, wird sie auch gestartet, es steht
aber nur "Drücken Sie eine beliebige Taste . . ." (die Wirkung von
system("PAUSE");) und java startet nicht und man sieht demzufolge auch
keine Ausgaben. Ich kann aber sofort im Anschluss die Exe nochmal per
Taskmanager ausführen lassen, dann startet java ganz normal.
Hat jemand ne Idee, was ich machen muss, damit die java Prozesse richtig
erzeugt werden? Die exe liegt auch in demselben Verzeichnis wie die java
Klassen.
Du könntest den "PAUSE"-Murks auch hinter der Zeile mit der
Fehlerausgabe einbauen, dann würdest Du sehen, ob und wenn welche
Fehlermeldung ausgegeben wird.
Wer hsqldb bentuzen muss tut mir leid. Das ist ein schlechtes System von
Bugfaces entwickelt. Wie wärs mit "derby.jar". Das ist performant und es
hält was es verspricht (konform, kleine jar, grosse Datenbestände).
Du könntest dein Java-Programm als Systemdienst starten, dafür gibt es
mehrere fertige Lösungen (Tomcat hat sowas). In diesem Zusammenhang wird
dein Problem auch beschrieben und gelöst.
In Visual C++ einen Systemdienst zu generieren geht einfach via Wizard
("ATL Com Anwendungsassistent... Dienst..."). Natürlich kann man auch
alles zu Fuss machen und ist auch kein grosser Aufwand (s.a.
www.codeguru.com). Dein Problem wird dadurch aber nicht gelöst.
Der Vorteil von Systemdiensten ist, dass sie fensterlos sind und damit
wirst du dann deinen "Hänger" los. Alles dies ist mir noch so ungefähr
in Erinnerung geblieben, liegt aber leider schon zu lange zurück.
Hilfreich in diesem Zusammenhang:
http://netez.com/2xExplorer/shellFAQ/bg_shell.html#idsb_lonts
Gruss
Batch Datei hab ich versucht, funktionierte aber nicht. Es gab zwar
irgendwelche Aktionen, aber das Kommandofenster war schneller weg als
ich schauen konnte.
Das Problem mit dem Code oben ist der Dateizugriff. Der scheint nicht zu
klappen, wenn das Programm von Windows gestartet wird. Vielleicht könnte
man mal schauen, in welchem Verzeichnis man wirklich gestartet wird, für
mein konkretes Problem hab ich es jetzt so gebaut:
1
#include<stdlib.h>
2
#include<stdio.h>
3
#include<windows.h>
4
#include<string>
5
#include"Shlwapi.h"
6
7
usingstd::string;
8
9
intmain(intargc,char*argv[])
10
{
11
charcpath[1024];
12
13
intcount=2;
14
stringpaths[count];
15
stringpathenv="D:\\Eigene Dateien\\FB\\Demo";// no tailing backslash
Ist zwar schleifentechnisch äusserst hässlich, tut aber. Muss nochmal
schauen, ob ich es irgendwie doch so bauen kann, dass die zu startenden
Pfade aus einer externen Textdatei gelesen werden können.
So, und nun hab ich auch noch rausgefunden, warum das fopen nicht
funktionierte: Ganz einfach, wenn Windows die Exe startet, führt sie die
in der Umgebung von c:\ aus. So geht ein fopen ohne komplette Pfadangabe
in die Hose. Man bekommt den kompletten Pfad jedoch an main übergeben,
kann den dann da rausfummeln und zum öffnen der Datei benutzen.
Sieht jetzt also so aus:
War JNI nicht der Weg, um von Java auf nativen Code zugreifen zu können?
Das ist ja dann die falsche Richtung.
So wie oben tut es jetzt genau wie es soll und ist auch noch für andere
Anwendungsfälle geeignet, in denen die zu startenden Programme nicht
Java sind. Als Erweiterung könnte man noch die Umgebungspfade für jedes
Programm explizit setzen.
>War JNI nicht der Weg, um von Java auf nativen Code zugreifen zu können?>Das ist ja dann die falsche Richtung.
JNI ist für beide Richtungen. Man kann damit auch problemlos deine
Richtung beschreiten. Aber wenn jetzt funktioniert => umso besser für
dich!