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

Discussion in 'C Programming' started by spammenotplui31@yahoo.ca, Mar 29, 2007.

  1. Guest

    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?
     
    , Mar 29, 2007
    #1
    1. Advertising

  2. Stan Milam Guest

    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.
    =============================================================
     
    Stan Milam, Mar 29, 2007
    #2
    1. Advertising

  3. Guest

    On Mar 28, 11:18 pm, Stan Milam <> wrote:
    > 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! :)
     
    , Mar 29, 2007
    #3
  4. llothar Guest

    On 29 Mrz., 04:58, wrote:
    > On Mar 28, 11:18 pm, Stan Milam <> wrote:
    >
    >
    >
    > > 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.
     
    llothar, Mar 29, 2007
    #4
  5. Tim Prince Guest

    llothar wrote:
    > On 29 Mrz., 04:58, wrote:
    >> On Mar 28, 11:18 pm, Stan Milam <> wrote:
    >>
    >>
    >>
    >>> 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....)?
     
    Tim Prince, Mar 30, 2007
    #5
  6. Guest

    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.
     
    , Apr 2, 2007
    #6
  7. santosh Guest

    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?
     
    santosh, Apr 2, 2007
    #7
  8. Guest

    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!
     
    , Apr 2, 2007
    #8
  9. >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.
     
    Gordon Burditt, Apr 3, 2007
    #9
  10. 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.
     
    Richard Heathfield, Apr 3, 2007
    #10
  11. 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.
     
    Gordon Burditt, Apr 8, 2007
    #11
  12. (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) <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"
     
    Keith Thompson, Apr 8, 2007
    #12
  13. 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.
     
    Richard Heathfield, Apr 8, 2007
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Fangs
    Replies:
    3
    Views:
    9,953
    darshana
    Oct 26, 2008
  2. Replies:
    0
    Views:
    597
  3. Replies:
    3
    Views:
    1,865
    Timothy Bendfelt
    Jan 19, 2007
  4. Replies:
    9
    Views:
    1,062
    Juha Nieminen
    Aug 22, 2007
  5. Jeff.M
    Replies:
    6
    Views:
    207
    Lasse Reichstein Nielsen
    May 4, 2009
Loading...

Share This Page