stdin/stdout communication between Java program and C program under 64 bit windows 7

Question

I have a C program which gets spawned from a Java program. The C program is mine, while the Java program is third party. The Java program somehow sets things up so that it communicates with my program via stdin/stdout.

The system has been working fine under 32-bit Windows XP for years. I have just purchased a new machine with 64-bit Windows 7. When I ran the Java program (from a "dos" box), it launched my program successfully, and it sent my program a command, which my program successfully acted upon. But when my program went back to its loop with

inputchar = getc(stdin);

the getc(stdin) never returns.

A clue: I know almost nothing about Java and I did have some trouble getting it to run in the first place. It seemed that after installing it from java.com, if I went to a "dos" box and typed "java", I just got an unrecognized command error. I then found a java.exe on windows\sysWOW64 so I typed "windows\sysWOW64 java -jar blah blah..." and then the program looked like it was running (at least up until the getc(stdin) problem).

Any idea what could be going wrong? Do I need a special 64-bit-Windows-7 Java? Is it possible that its just a badly written java program who's bugs only manifest themselves when running on a new OS? Or is it more likely to be me?

EDIT: My C program runs fine on its own (i.e. not spawned from java) on the 64bit windows 7 machine.

EDIT: If I type "\windows\syswow64\java -version", then I get...

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: On the old XP box the java version was 1.6.0_17-b04

EDIT: I did not re-build my C program for the new machine. I just copied the old 32 bit version.

EDIT: the first "command" that the java program sends is a string ending in a "line feed" character (ASCII 10).

Answer 1

Have you tried writing a different Java program and launching your C program from that? Basically, you just need something like:

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

This should launch your program, send it some command, then wait for it to exit. You can also call cPgm.destroy() to terminate your program if it doesn't have an exit command. I just figure it might be easier to analyze the problem if you control both sides of the issue.

Have you compiled your program to create a 64-bit executable? I noticed that your JRE's path has "WOW64" in it, which makes me wonder if it's running under some kind of emulation (WOW used to indicate something that was running in DOS compatability mode, aka "Windows on Windows"). If so, then there may be some kind of inter-process buffering going on, which might explain why your read isn't returning.

Answer 2

Some details to help with the 64-bit issues.

1. There is a 64-bit Java virtual machine. When you install the 32-bit virtual machine, the java.exe gets installed to the "Windows on Windows" compatibility portion of Windows (that is, the 32-bit compatibility portion. If you were to start the 32-bit command prompt (c:\windows\syswow64\cmd.exe), I suspect you would be able to run java.exe and get what you expect. If you install the 64-bit Java virtual machine, you should be able to launch it from a 64-bit command prompt (the default) as you normally would.

   > java -version java version "1.6.0_17" Java(TM) SE Runtime Environment (build 1.6.0_17-b04) Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01, mixed mode)

2. You should be able to execute any 32-bit C process from a 32-bit or 64-bit Java process (it should not matter). The fact that it's getting hung up indicates to me that maybe the bytes aren't being passed as you expect. In the C program, what do you expect getc(stdin) to return when it instead hangs there? It's possible that the getc implementation could be different on Windows 7 versus XP, but that seems unlikely.

Answer 3

Are you running the command from an Administrator's command prompt? If not, I would try that (when launching the command prompt, right-click and select Run As Administrator).

Windows Vista and 7 adds a feature called UAC, which means that even if you are an Administrator, your account is not given Administrator privileges. This effect could be impacting the privileges available to your program or to the Java program or to the Java Virtual Machine.