Der fragliche Code hat in früheren Versionen von Windows in etwa in der gleichen Konfiguration funktioniert, es ist jedoch nicht bekannt, dass er noch unter Windows 7 ausgeführt wurde! Das ist es, was ich jetzt lösen muss.

Kurz gesagt, ein Teil des C-Codes führt vor dem Start eines Java-Programms einige Konfigurations- und Sicherheitsprüfungen durch. Dabei werden einige Daten übergeben, die in Java so gut wie unmöglich sind. Das Java startet wiederum zum richtigen Zeitpunkt denselben C-Code, der dann selbst ein anderes Java-Programm startet. Der zweite Programmstart muss völlig unabhängig sein (think nohup), daher der zweite Start.

Was jetzt passiert ist, dass das C-Programm das Java-Programm auf gewöhnliche Weise startet, aber wenn das Java versucht, das C-Programm zu starten, kommt es zu einer Fehlermeldung:

/cygdrive/c/opt/ST/v3.3/bin/ST.exe: Fehler beim Laden der gemeinsam genutzten Bibliotheken:?: Datei mit gemeinsam genutzten Objekten kann nicht geöffnet werden: Keine solche Datei oder kein solches Verzeichnis

Weil Windows über die Jahre so ein Bär war, ist der C-Code in der Posix-Umgebung von Cygwin geschrieben, aber alles, was es wirklich tut, sind gewöhnliche C-Arten von Dingen (nichts daran ist einzigartig für Cygwin und in der Tat in der Vergangenheit) wurde mit den Entwicklungstools von Microsoft erstellt, diese Umgebung ist jedoch derzeit nicht verfügbar. Die Cygwin-Umgebung bietet viele weitere Vorteile, wie die Befehlszeilenverwaltung von Diensten (cygrunsrv) und eine vollständige Nix-ähnliche Umgebung (bash usw.). In der Tat hilft Cygwin, den Java-Startcode zu standardisieren, da Windows so oft geändert hat, wie ein Programm von Java aus gestartet wird. Hier ist ein Auszug:

<code>  if (ClientOS.indexOf("Windows") != -1)
  {
     if (ClientOS.equals("Windows 95"))
     {
        cmd = "command.com /C ";
     } else if (ClientOS.equals("Windows 98"))
     {
        cmd = "command.com /C ";
        //cmd = "cmd.exe /C ";
     } else if (ClientOS.equals("Windows NT"))
     {
        cmd = "cmd.exe /C ";
     } else if (ClientOS.equals("Windows 2000"))
     {
        cmd = "cmd.exe /C ";
     } else if (ClientOS.equals("Windows XP"))
     {
        cmd = "cmd.exe /C ";
     } else {
        cmd = "cmd.exe /C ";
     }
     if (cygwin)
     {
        cmd += Shell+" '"+Command+"'";
     } else {
        cmd += Command;
     }
  } else {
     cmd = Command;
  }
</code>

(Ja, die if-Struktur könnte besser optimiert werden.)

In diesem Fall entspricht "Shell":

<code>Shell=C:/cygwin/bin/bash -c
</code>

Und es gibt ein Testprogramm, das sicherstellt, dass der obige und der unterstützende Code in Ordnung sind - es führt ein bisschen Shell-Programm aus und stellt sicher, dass es zurückkommt, was es gedacht hat. Es sagt:

Überprüfung der Fähigkeit, ein Programm mit einer Shell auszuführen ... Ja, Shell-Programme funktionieren einwandfrei.

Der endgültige Inhalt von cmd sieht ungefähr so ​​aus:

cmd.exe / C C: / cygwin / bin / bash -c '/cygdrive/c/opt/ST/v3.3/bin/ST.exe'

Was ich vermute:

Ich vermute, was los ist, dass die Cygwin1.DLL-Datei nicht richtig gefunden wird. Es lebt in C: /cygwin/bin/cygwin1.dll

BEACHTEN SIE, DASS Sowohl der Pfad auf Systemebene als auch der Cygwin-Pfad enthalten den Pfad zu den Cygwin-DLL-Dateien. Das Verschieben einer Kopie von cygwin1.dll in das bin-Verzeichnis, in dem sich die ausführbare Zieldatei befindet, hat ebenfalls nicht funktioniert.

Würde LD_LIBRARY_PATH hier Abhilfe schaffen? Wenn ja, eine Idee, wie es eingestellt werden soll?

Andere Ideen?

Vielen Dank.