How do I read real-time text from a DOS window?

[Brent4518]

I'm calling an executable which downloads a file to flash memory.  This program displays real time status information such as percent complete in a DOS window.   It also reports the CRC of the file it downloads.  I'm currently redirecting the output from the DOS window to a text log file.  This works fine for obtaining the CRC when the file is done downloading but the operator looses the visibilty of the percent download status.  Is there a way to read the text information in a DOS window real time with my LabWindows/CVI application?

[ebalci]

Hi Brent,

I haven't heard of any such function or library. But if both applications' code is available to you I would recommend you to use some form of inter-application communication.

There are some methods of this. Best ones I know are DataSocket (replaced by Network Variables in later CVI versions) and DDE.

I have previously coded an application with DDE and got satisfying results. So I am recommending it where applicable. Code a DDE server into the flash loading application and create a DDE client in the gui application.

Then request data from the server using DDE calls. In this case this data will be the percent completed.

I've not yet tried it but DataSocket is also looks like a good approach.

Maybe others come up with better ideas. 

Hope this helps. 

[Brent4518]

S. Eren BALCI,

Thank you for your suggestion.  I have no doubt the Datasocket or Network Variable libraries would work for what I'm trying to do.  Unfortunately, I don't have access to the source code of the flash programmer.

[LuisG · Accepted solution]

Hi Brent,

If you redirect all output from the first application to a log file, wouldn't you be able to read the contents of the file continuously from your second application, and whenever the content changes (such as the percent download value), couldn't you display that information immediately with the second application, into a DOS window or some other GUI?

Luis

[Brent4518]

Luis,

Sorry if this reply comes through twice, I thought I replied earlier but it didn't show up on the message board.  I had thought of doing what you suggest but was not sure if I could open a file handle on a file which was already in use by another application.  If I open the file as read only, will I be able to see the updates the flash programming application is making as it writes to the file? 

[LuisG]

Hi Brent,

I tested that scenario just now, and it seems to work okay. I wrote a small console app that writes to stdout continuously, which I run with output redirection:

c:\testwrite.exe > testdat.txt

testwrite.c:

int main (int argc, char *argv[])
{
    int    i = 0;

    SetStdioWindowOptions (100, 0, 0);
    while (!KeyHit())
        printf ("%d\n", i++);
   
    return 0;
}

While the first app was running, I ran a second app that continuously reads the contents of testdat.txt. I stepped through it and saw that it was reading the file succesfully:

testread.c:

int main (int argc, char *argv[])
{
    FILE    *fp;
    char    c;
   
    fp = fopen ("testdat.txt", "r");
   
    while (1)
    {
        c = fgetc (fp);
    }
   
    fclose (fp);
   
    return 0;
}
 

The one caveat is that since we're using the OS to redirect the output of the first app to the file, the first app is not really in control of when the output buffer is flushed to the physical file and thus made available to the second app. When it's the app that writes to the file directly, it has some control of when to flush, but in this case it's the OS doing it, and I don't know the specifics of when the output buffer is flushed. So there's a possibility that the read operation might be a tad behind, which might be an issue if output is very infrequent.

Luis

[Brent4518]

Luis,

I implemented a read routine which opens the same file the flash loader is writing.  I've experienced some issues with reaching the EOF before the file is updated with the writes.  Probably the OS buffer dump you mentioned.  I can live with a few delays in the status update.  Thanks for the help!

[dummy_decoy]

did you consider programatically redirecting the output of the upload application ?

you should be able from your application, using windows SDK functions, to spawn the upload application and redirect the standard output. this would allow you to be poll the output, avoiding the EOF since the redirected output will be valid until closed, as well as avoiding the flushing problem since the output will not be buffered by the OS. now you only have to display what you read to the user and write it to a log file.

also, redirecting the standard output is generally done using pipes, and this should allow you to use an efficient wait instead of a brute-force resource-consuming polling.

here is a MSDN example of redirection through a pipe:

Creating a Child Process with Redirected Input and Output