Communication stdin/stdout entre programme Java et programme C sous Windows 64 bits 7

Question

J'ai un programme C généré par un programme Java. Le programme C est à moi, tandis que le programme Java est un tiers. Le programme Java configure les choses de telle sorte qu'il communique avec mon programme via stdin/stdout.

Le système fonctionne correctement sous Windows XP 32 bits depuis des années. Je viens d'acheter une nouvelle machine avec Windows 7 64 bits. Lorsque j'ai lancé le programme Java (à partir d'une boîte «DOS»), mon programme a été lancé avec succès et mon programme a reçu une commande que mon programme a exécutée avec succès. Mais quand mon programme est retourné à sa boucle avec

inputchar = getc(stdin); 

le getc (stdin) ne retourne jamais.

Un indice: Je ne sais presque rien sur Java et j'ai eu quelques difficultés à obtenir à courir en premier lieu. Il m'a semblé qu'après l'avoir installé depuis java.com, si je suis allé dans une boîte "dos" et que j'ai tapé "java", j'ai juste une erreur de commande non reconnue. J'ai alors trouvé un java.exe sur windows \ sysWOW64 donc j'ai tapé "windows \ sysWOW64 java -jar bla bla ..." et alors le programme a semblé qu'il fonctionnait (au moins jusqu'au problème de getc (stdin)).

Une idée de ce qui pourrait mal se passer? Ai-je besoin d'un Java 64-bit-Windows-7 spécial? Est-il possible que ce soit juste un programme java mal écrit dont les bugs ne se manifestent que lors de l'exécution sur un nouveau système d'exploitation? Ou est-ce plus susceptible d'être moi?

EDIT: Mon programme C fonctionne bien sur son propre (à savoir pas donné naissance à de Java) sur les fenêtres 64bit machine 7.

EDIT: Si je tape "\ windows \ SysWOW64 \ java -version", je reçois ...

java version "1.6.0_18" 
Java(TM) SE Runtime Environment (build 1.6.0_18-b07) 
Java HotSpot(TM) Client VM (build 16.0-b13, mixed mode, sharing) 

EDIT: Sur la vieille boîte XP la version java était 1.6.0_17-b04

EDIT: Je n'ai pas reconstruit mon programme C pour la nouvelle machine. Je viens de copier l'ancienne version 32 bits.

EDIT: le premier caractère « commande » que le programme java envoie est une chaîne se terminant par un « saut de ligne » (ASCII 10).

Answer 1

Avez-vous essayé d'écrire un programme Java différent et le lancement de votre programme C de cela? En gros, vous avez juste besoin de quelque chose comme:

Process cPgm = Runtime.exec("your-C-program"); 
OutputStream stdin = cPgm.getOutputStream(); 
stdin.write("some-command".getBytes()); 
stdin.flush(); 
cPgm.waitFor(); 

Cela devrait lancer votre programme, envoyez une commande, puis attendez qu'il quitter. Vous pouvez également appeler le cPgm.destroy() pour terminer votre programme s'il n'a pas de commande de sortie. Je me dis simplement qu'il pourrait être plus facile d'analyser le problème si vous contrôlez les deux côtés du problème.

Avez-vous compilé votre programme pour créer un exécutable 64 bits? J'ai remarqué que le chemin de votre JRE a "WOW64" dedans, ce qui me fait me demander s'il fonctionne sous une sorte d'émulation (WOW utilisé pour indiquer quelque chose qui fonctionnait en mode de compatibilité DOS, alias "Windows on Windows"). Si tel est le cas, il peut y avoir une sorte de mise en mémoire tampon inter-processus, ce qui pourrait expliquer pourquoi votre lecture ne revient pas.

Answer 2

Quelques détails pour résoudre les problèmes 64 bits.

1. Il existe une machine virtuelle Java 64 bits. Lorsque vous installez la machine virtuelle 32 bits, le Java.exe est installé sur la partie de compatibilité "Windows sur Windows" de Windows (c'est-à-dire la partie de compatibilité 32 bits.) Si vous deviez démarrer l'invite de commande 32 bits (c: \ windows \ syswow64 \ cmd.exe), Si vous installez la machine virtuelle Java 64 bits, vous devriez pouvoir la lancer à partir d'une invite de commande 64 bits (la valeur par défaut) comme vous le feriez normalement.

   > java -version java version "1.6.0_17" Java (TM) SE Runtime Environment (build 1.6.0_17-b04) Java HotSpot (TM) 64 bits serveur VM (build 14.3-B01, mixte mode)

2. Vous devriez être en mesure d'exécuter n'importe quel processus C 32 bits à partir d'un 32 bits ou Processus Java 64 bits (cela ne devrait pas avoir d'importance). Le fait qu'il se bloque m'indique que les octets ne sont peut-être pas transmis comme prévu. Dans le programme C, qu'est-ce que vous attendez que getc (stdin) retourne quand il se bloque à la place? Il est possible que l'implémentation de getc soit différente sur Windows 7 par rapport à XP, mais cela semble peu probable.

Answer 3

Exécutez-vous la commande à partir de l'invite de commande d'un administrateur? Si ce n'est pas le cas, j'essayerais cela (au lancement de l'invite de commande, faites un clic droit et sélectionnez Exécuter en tant qu'administrateur).

Windows Vista et 7 ajoute une fonctionnalité appelée UAC, ce qui signifie que même si vous êtes administrateur, votre compte ne dispose pas des privilèges d'administrateur. Cet effet peut avoir un impact sur les privilèges disponibles pour votre programme ou pour le programme Java ou la machine virtuelle Java.