Kod, o którym mowa, pracował mniej więcej w takiej samej konfiguracji we wcześniejszych wersjach systemu Windows, jednak nie wiadomo, aby działał w systemie Windows 7 YET! Właśnie to muszę teraz rozwiązać.

W skrócie, jakiś kod C wykonuje pewne kontrole konfiguracji i bezpieczeństwa przed uruchomieniem programu java, przekazując pewne dane, które byłyby w pobliżu Java niemożliwe. Java z kolei w odpowiednim czasie uruchamia ten sam kod C, który sam uruchamia inny program Java. Drugie uruchomienie programu musi być całkowicie niezależne (pomyśl nohup) stąd drugie uruchomienie.

Teraz dzieje się tak, że program C uruchamia program Java w zwykły sposób, ale gdy Java próbuje uruchomić program C, to błąd wygląda następująco:

/cygdrive/c/opt/ST/v3.3/bin/ST.exe: błąd podczas ładowania bibliotek współdzielonych:?: nie można otworzyć pliku obiektu współdzielonego: Brak takiego pliku lub katalogu

Ponieważ Windows był takim niedźwiedziem na przestrzeni lat, kod C jest napisany w środowisku posix Cygwina, ale tak naprawdę robi to zwykłe typy C (nic o nim nie jest unikalne dla Cygwina, a nawet w przeszłości). został zbudowany przy użyciu narzędzi programistycznych Microsoftu, ale obecnie środowisko nie jest dostępne). Środowisko Cygwina dodaje wiele innych wspaniałych korzyści, takich jak zarządzanie usługami za pomocą wiersza poleceń (cygrunsrv) i pełne środowisko typu nix (bash itp.). W rzeczywistości, ponieważ system Windows wielokrotnie zmienia sposób uruchamiania programu z Java, Cygwin pomaga w standaryzacji kodu uruchamiania Java. Oto fragment:

<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>

(Tak, jeśli struktura mogłaby być lepiej zoptymalizowana.)

W tym przypadku „Shell” równa się:

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

Ponadto istnieje program testowy, który zapewnia, że ​​powyższy kod i kod pomocniczy działają poprawnie - uruchamia on trochę programu powłoki i zapewnia, że ​​odzyska to, co powinien. To mówi:

Sprawdzanie możliwości uruchomienia programu za pomocą powłoki ... Tak, programy powłoki działają poprawnie.

Ostateczna zawartość cmd wygląda mniej więcej tak:

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

CO PODEJRZAM:

Podejrzewam, że dzieje się tak, że plik Cygwin1.DLL nie jest poprawnie znajdowany. Mieszka w C: /cygwin/bin/cygwin1.dll

UWAGA, ŻE zarówno PATH na poziomie systemu, jak i PATH Cygwin zawierają ścieżkę do plików .dll cygwin. Przeniesienie kopii cygwin1.dll do katalogu bin, w którym nie działa docelowe życie wykonywalne.

Czy LD_LIBRARY_PATH udzieli tutaj pomocy? Jeśli tak, czy masz jakiś pomysł, jak to ustawić?

Inne pomysły?

Dzięki.