A 64-bit binary returning a value to a 32-bit binary?

[spammenotplui31]

I have a program that needs to be compiled as 64bit. I have another
program that needs to be compiled as 32bit and will call that 64-bit
binary. Is there a way for the 64-bit binary to return a string to
the 32-bit? If so, how?

The only way I could think of is to have the 32-bit binary call the 64-
bit binary, then it writes to a text file and finally have the 32-bit
binary read it off.

Is there a better way to do this?

[Stan Milam]

sp*************@yahoo.ca wrote:

I have a program that needs to be compiled as 64bit. I have another
program that needs to be compiled as 32bit and will call that 64-bit
binary. Is there a way for the 64-bit binary to return a string to
the 32-bit? If so, how?

The only way I could think of is to have the 32-bit binary call the 64-
bit binary, then it writes to a text file and finally have the 32-bit
binary read it off.

Is there a better way to do this?

Does the 32 bit binary support long long? If not you may have to do as
you wrote, or use some non-portable means such as popen(), or invoke the
64 bit via a socket and read back the string from its standard output.
But of course all of that stuff is off-topic :-).

--
Regards,
Stan Milam
================================================== ===========
Charter Member of The Society for Mediocre Guitar Playing on
Expensive Instruments, Ltd.
================================================== ===========

[spammenotplui31]

On Mar 28, 11:18 pm, Stan Milam <[e-mail]:

[e-mail] wrote:

I have a program that needs to be compiled as 64bit. I have another
program that needs to be compiled as 32bit and will call that 64-bit
binary. Is there a way for the 64-bit binary to return a string to
the 32-bit? If so, how?

The only way I could think of is to have the 32-bit binary call the 64-
bit binary, then it writes to a text file and finally have the 32-bit
binary read it off.

Is there a better way to do this?

Does the 32 bit binary support long long? If not you may have to do as
you wrote, or use some non-portable means such as popen(), or invoke the
64 bit via a socket and read back the string from its standard output.
But of course all of that stuff is off-topic :-).

--
Regards,
Stan Milam
================================================== ===========
Charter Member of The Society for Mediocre Guitar Playing on
Expensive Instruments, Ltd.
================================================== ===========

Hi Stan,

I'm not good in C. What if it supports long long? What would be the
more efficient way of doing it? What sort of functions would I use
for the second method you suggested with invoking a socket?

Thanks! :)

[llothar]

On 29 Mrz., 04:58, [e-mail] wrote:

On Mar 28, 11:18 pm, Stan Milam <[e-mail]:

[e-mail] wrote:

I have a program that needs to be compiled as 64bit. I have another
program that needs to be compiled as 32bit and will call that 64-bit
binary. Is there a way for the 64-bit binary to return a string to
the 32-bit? If so, how?

The only way I could think of is to have the 32-bit binary call the 64-
bit binary, then it writes to a text file and finally have the 32-bit
binary read it off.

Is there a better way to do this?

Does the 32 bit binary support long long? If not you may have to do as
you wrote, or use some non-portable means such as popen(), or invoke the
64 bit via a socket and read back the string from its standard output.
But of course all of that stuff is off-topic :-).

--
Regards,
Stan Milam
================================================== ===========
Charter Member of The Society for Mediocre Guitar Playing on
Expensive Instruments, Ltd.
================================================== ===========

Hi Stan,

I'm not good in C. What if it supports long long? What would be the
more efficient way of doing it? What sort of functions would I use
for the second method you suggested with invoking a socket?

Thanks! :)

Google for IPC, sockets are IMHO the best. Open a socket with port 0
and
pass the given port number to the callee. But you need to learn about
IPC
first to understand the sentence above.

[Tim Prince]

llothar wrote:

On 29 Mrz., 04:58, [e-mail] wrote:

>On Mar 28, 11:18 pm, Stan Milam <[e-mail]:

>>[e-mail] wrote:
I have a program that needs to be compiled as 64bit. I have another
program that needs to be compiled as 32bit and will call that 64-bit
binary. Is there a way for the 64-bit binary to return a string to
the 32-bit? If so, how?
The only way I could think of is to have the 32-bit binary call the 64-
bit binary, then it writes to a text file and finally have the 32-bit
binary read it off.
Is there a better way to do this?
Does the 32 bit binary support long long? If not you may have to do as
you wrote, or use some non-portable means such as popen(), or invoke the
64 bit via a socket and read back the string from its standard output.
But of course all of that stuff is off-topic :-).
--
Regards,
Stan Milam
================================================== ===========
Charter Member of The Society for Mediocre Guitar Playing on
Expensive Instruments, Ltd.
================================================== ===========

Hi Stan,

I'm not good in C. What if it supports long long? What would be the
more efficient way of doing it? What sort of functions would I use
for the second method you suggested with invoking a socket?

Thanks! :)

Google for IPC, sockets are IMHO the best. Open a socket with port 0
and
pass the given port number to the callee. But you need to learn about
IPC
first to understand the sentence above.

Having figured out all this stuff for your current platform, do you
expect the next person who maintains your application to spend the time
to come to the right conclusion? What if she is forced to come to the
conclusion mentioned above (not good in C....)?

[spammenotplui31]

Thanks for all the replies. I've opted to use p2open which will allow
the 32bit executable to write to stdout to 64bit's stdin. The 64bit
executable will then write to stdout and the 32bit will read it.

I want to make a small tweak though. I would like the 32bit to keep
the pipe open and the 64bit will constantly check to see if there's
anything new written to its stdin. Prior to attempting to modify
this, I was using fprintf and fgets in both programs to write and read
from stdout/stdin. My attempt to do the tweak was to put the entire
64bit program inside a "while (fgets(input, sizeof(input), stdin) !=
NULL)" loop. It doesn't work though. I don't think it is reading the
value. Before the while loop i opened a log file and inside the loop,
I would write the input to the log file. The log file is created but
there's nothing in the log.

Is there anything wrong with my approach? Thanks.

[santosh]

sp*************@yahoo.ca wrote:

Thanks for all the replies. I've opted to use p2open which will allow
the 32bit executable to write to stdout to 64bit's stdin. The 64bit
executable will then write to stdout and the 32bit will read it.

The data generated by one program may not make sense to the other.

I want to make a small tweak though. I would like the 32bit to keep
the pipe open and the 64bit will constantly check to see if there's
anything new written to its stdin. Prior to attempting to modify
this, I was using fprintf and fgets in both programs to write and read
from stdout/stdin. My attempt to do the tweak was to put the entire
64bit program inside a "while (fgets(input, sizeof(input), stdin) !=
NULL)" loop. It doesn't work though. I don't think it is reading the
value.

fgets attempts to either read in a complete line or input-1 characters
and append a null character. If a newline occurs it is retained.
Excessive characters are simply left in the stream's buffers and later
calls to fgets can pick them up.

Try using fgetc or getc.

Before the while loop i opened a log file and inside the loop,
I would write the input to the log file. The log file is created but
there's nothing in the log.

Is there anything wrong with my approach? Thanks.

How can we asses that when there's no code?

[spammenotplui31]

Thanks santosh. What I was missing was actually a \n on the 64 bit
side when I do a fprintf to stdout. The 32 bit program hangs at fgets
because it was waiting for something and reading your post reminded me
to check if it's returning a newline character on the 64 bit side.

Thanks!

[Gordon Burditt]

>Thanks for all the replies. I've opted to use p2open which will allow

>the 32bit executable to write to stdout to 64bit's stdin. The 64bit
executable will then write to stdout and the 32bit will read it.

Beware of deadlock. Buffering makes it worse, and some systems will
*NOT* flush the buffer when a newline is output when writing to a pipe.
Use of fflush() is recommended. Also, you need to know when you've
read all of the result *without* attempting to read more.

>I want to make a small tweak though. I would like the 32bit to keep
the pipe open and the 64bit will constantly check to see if there's
anything new written to its stdin.

ANSI C has no non-blocking I/O. If you call fgets() to read a line,
it keeps waiting until it gets (a) a full line, (b) a full buffer,
or (c) end of file. It will *not* return with "no input yet".

>Prior to attempting to modify
this, I was using fprintf and fgets in both programs to write and read
from stdout/stdin. My attempt to do the tweak was to put the entire
64bit program inside a "while (fgets(input, sizeof(input), stdin) !=
NULL)" loop. It doesn't work though. I don't think it is reading the
value. Before the while loop i opened a log file and inside the loop,
I would write the input to the log file. The log file is created but
there's nothing in the log.

Is there anything wrong with my approach? Thanks.

[Richard Heathfield]

Gordon Burditt said:

>>Thanks for all the replies. I've opted to use p2open which will allow
the 32bit executable to write to stdout to 64bit's stdin. The 64bit
executable will then write to stdout and the 32bit will read it.

Beware of deadlock.

Gordon, when are you going to learn to ascribe quotes?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Gordon Burditt]

When will certain posters stop posting articles that don't add
anything about C? Top-posting, Google, topicality, attributions,
and calling other posters names are off-topic. If you (and you
know who you are) must do that, how about talking about C also?

If your system allows you to compile to binaries of different types,
like 64-bit vs. 32-bit, you probably want to transfer text between
them over pipes. Raw images of structures probably won't have the
same size, alignment, or whatever in both binaries.

[Keith Thompson]

go***********@burditt.org (Gordon Burditt) writes:

When will certain posters stop posting articles that don't add
anything about C? Top-posting, Google, topicality, attributions,
and calling other posters names are off-topic. If you (and you
know who you are) must do that, how about talking about C also?

Gordon, when are you going to learn to ascribe quotes?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Gordon Burditt said:

When will certain posters stop posting articles that don't add
anything about C? Top-posting, Google, topicality, attributions,
and calling other posters names are off-topic.

Wrong. Discussions about topicality are, alas, always topical. And your
apparent desire to stop people complaining about your continual failure
to ascribe quoted text would be most easily satisfied if you were to
ascribe the text that you quote.

If you (and you
know who you are) must do that, how about talking about C also?

That'd be nice, yes.

If your system allows you to compile to binaries of different types,
like 64-bit vs. 32-bit, you probably want to transfer text between
them over pipes.

Well, we're hardly talking about C now, are we?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.