El código en cuestión ha funcionado en más o menos exactamente la misma configuración en versiones anteriores de Windows, sin embargo, no se sabe que se haya ejecutado en Windows 7 YET! Eso es lo que necesito resolver ahora.

Brevemente, algunos códigos C realizan algunas comprobaciones de configuración y seguridad antes de iniciar un programa java, y pasan algunos datos que serían casi imposibles de realizar en Java. Java a su vez, en el momento adecuado lanza el mismo código C que a su vez lanza un programa Java diferente. El segundo lanzamiento del programa debe ser completamente independiente, (piense nohup) por lo tanto, el segundo lanzamiento.

Lo que está sucediendo ahora es que el programa C lanza el programa Java de la forma habitual, pero cuando Java intenta iniciar el programa C, se produce un error de este modo:

/cygdrive/c/opt/ST/v3.3/bin/ST.exe: error al cargar bibliotecas compartidas:?: no se puede abrir el archivo de objeto compartido: no existe tal archivo o directorio

Debido a que Windows ha sido un oso tan fuerte a lo largo de los años, el código C está escrito en el entorno posix de Cygwin, pero todo lo que realmente hace es un tipo de cosas C ordinario (nada de esto es exclusivo de Cygwin y, de hecho, en el pasado ha sido construido con las herramientas de desarrollo de Microsoft, pero ese entorno no está disponible en la actualidad). El entorno Cygwin agrega muchos otros grandes beneficios, como la gestión de servicios en línea de comandos (cygrunsrv) y un entorno completo similar a nix (bash, etc.). De hecho, como Windows ha cambiado la forma en que se inicia un programa desde Java tantas veces, Cygwin ayuda a estandarizar el código de inicio de Java. Aquí hay un extracto:

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

(Sí, la estructura if podría optimizarse mejor).

En este caso, "Shell" es igual a:

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

Y, hay un programa de prueba para garantizar que el código anterior y el código de soporte funcionen bien: ejecuta un poco de programa shell y garantiza que recupere lo que pensaba que debería. Dice:

Verificando la capacidad de ejecutar un programa usando un shell ... Sí, los programas de shell funcionan bien.

El contenido final de cmd es algo así:

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

LO QUE ESPERO:

Sospecho que lo que está sucediendo es que el archivo Cygwin1.DLL no se encuentra correctamente. Vive en C: /cygwin/bin/cygwin1.dll

TENGA EN CUENTA QUE tanto el PATH a nivel del sistema como el Cygwin PATH incluyen la ruta a los archivos .gll de cygwin. Mover una copia de cygwin1.dll al directorio bin donde las vidas del ejecutable de destino tampoco funcionó.

¿LD_LIBRARY_PATH prestaría ayuda aquí? Si es así, ¿alguna idea de cómo se va a configurar?

¿Otras ideas?

Gracias.