RunProgram() and get its output data

[Fred]

Ha, you just have to wait until the buffer gets flushed and it works (about 15 secs here). You have to move the mouse over the window as you used WaitWindowEvent().

[Trond]

I've waited for five minutes now and still no ouput. And if you didn't notice there is a 10 millisecond timeout in my WaitWindowEvent().

[Fred]

Weird, it definitely print the numbers here . Can anyone else confirm ? (using the Project2.exe file above).

[Psychophanta]

Weird, it definitely print the numbers here . Can anyone else confirm ? (using the Project2.exe file above).

Here DOES NOT print anything , using the Project2.exe file above neither using quickbasic piper.exe
Plain PB4.0 B11 (without any newer lib)

[freak]

The reason that the command is line-based is for ease of use. Most console
output is line-based, so it makes more sense to read it in that manner as well.
To prevent this, ReadProgramData() can be used.

1. Hmm, what does the Ln in WriteLn() mean?
2. ReadProgramData() does not fix the problem.

Stop talking to me like i do not know what i am doing.
I really don't like that, so maybe that is not the best approact to report a bug or request a feature.



Ok, lets clear these things up:

1. Why your PB code (with WriteConsole()) does not work:

Both WriteConsole and WriteFile can be used for console I/O. While WriteConsole supports writing Unicode characters to a console screen buffer, WriteFile does not. However, WriteConsole fails if it is used with a standard handle that is redirected to a file.

So here you have the reason. The writer of the program is responsible to write it in the correct way
(which is to try WriteConsole() first and use ReadFile() as a fallback, like PB does)
If a program does not do that, its not our problem.

2. Why the QB program does not work:

I did not test this any further, but i would simply guess that communication
with real dos programs using the Win32 pipe mechanism is not working.
I don't think that this is worth investigating any further.

3. Why the Delphi program has problems:

It turns out that delphi does use WriteFile() for the output, but it buffers the output (so not 1 write per line)
Thats why you do not get the numbers in real time.

See this code:

Code: Select all

OpenWindow(0, 0, 0, 512, 384, "", #PB_Window_ScreenCentered | #PB_Window_SystemMenu)
CreateGadgetList(WindowID(0))
EditorGadget(0, 10, 10, 492, 364)

Pid = RunProgram("b:\project2.exe", "", "", #PB_Program_Open | #PB_Program_Read)

Repeat
  Select WaitWindowEvent(10)
    Case #PB_Event_CloseWindow
      Break
  EndSelect
  size = AvailableProgramOutput(Pid)
  If size > 0    
    *buffer = AllocateMemory(size)
    If *buffer
      readsize = ReadProgramData(Pid, *Buffer, size)
      String$ = ReplaceString(PeekS(*Buffer, readsize), Chr(13), "#"+Chr(13))
      AddGadgetItem(0, -1, String$)
      FreeMemory(*buffer)
    EndIf
  EndIf
ForEver

KillProgram(Pid)
CloseProgram(Pid)

As you can see, multiple lines are outputed at once, and the last one does not contain a newline.
Also the gui does not lock up as you can see.

This tells us the following:

1) Delphi does buffer the output when redirected, which explains the much output at once.
2) As part of this buffering, it outputs an incomplete line (no newline) at the end of the data,
which makes ReadProgramString() wait for the newline just as i said in the earlier post, which makes the GUI lock up.
3) ReadProgramData() does fix the lockup problem (just as i said above)
4) You could have just saved your smartass comments above and waited for me to check the stuff out, because what you said was just wrong.


The conclusion:

There is no bug. PB does the stuff correctly. (In fact, more correct than most Win32 programs
out there, as i did quite some research on this topic)
Delphi is the buggy thing here by having a WriteLn() command that delays
the output and also writes lines without a newline.

[Psychophanta]

2. Why the QB program does not work:

I did not test this any further, but i would simply guess that communication
with real dos programs using the Win32 pipe mechanism is not working.
I don't think that this is worth investigating any further.

The conclusion:

There is no bug. PB does the stuff correctly. (In fact, more correct than most Win32 programs
out there, as i did quite some research on this topic)

No bug? You say that communication with real dos programs using the Win32 pipe mechanism is not working, and you add "there is no bug"?
Well, so, then please add to the help (in the RunProgram() command) something like this line:

communication with real dos programs using the Win32 pipe mechanism is not working.

And then you can freely say: "There is no bug", but not before.

Or am i wrong?!

EDIT:
And Damn! Who the hell moved this thread from General Discussion (where it was originally posted) to this section!!??
If can we know...

[thefool]

project2.exe prints numbers on new lines and in a correct delay.
so i confirm the delphi program works on winxp pro sp2.

[freak]

project2.exe prints numbers on new lines and in a correct delay.
so i confirm the delphi program works on winxp pro sp2.

Thats just the console output. It is different from what is sent on the pipe.
Read above about the WriteConsole()/WriteFile() difference.

Psychophanta:

Dos programs do not even run anymore on WinXP, and nobody calls that a bug either...

[thefool]

Many dos programs runs fine!
i've used qbasic some time, and it works just fine.

however; i get no output from the delphi program now that i ran it trough piper.

[Psychophanta]

Dos programs do not even run anymore on WinXP...

That's not a total true, because as you know, WinXP includes a built-in
DOS emulator, and for example everybody can test on WinXP SP2 the QB made 'piper.exe' i refer above. It works perfectly on winxp, and lost of MSDOS stuff works properly under XP SP2.

EDIT:
If don't believe me, please check these:
http://www.penguinbyte.com/apps/pbwebst ... oolsUI.zip <- it is a frontend made using PB and 3 MSDOS external programs.
http://www.penguinbyte.com/apps/pbwebst ... HD-COPY.7z <- utility for floppy disks.

And if you want more info, the piper.exe file was created with QuickBasic 4.5 under winxp SP2.
QuickBasic 4.5 under winxp SP2 works absolutely fine.
Here it is complete for those who want it (no need install, simply put it in a folder inside program files dir.
http://www.penguinbyte.com/apps/pbwebst ... talado.zip
BTW, to see a MSDOS prgram at full screen (i.e. like the original) press LALT+ENTER.

[freak]

I know there is a dos emulator, but it does not do a very good job on many programs.
There are quite many that have problems.

But thats not really the point. Does it say anywhere in the Help that PB actually IS compatible
with Dos programs ? No, so why should it be a bug then?

But if that is so important to you, we can also put an extra note for you in the help...

[Psychophanta]

Well, that's right.
The matter is that console programs (from which the data output can be read using PB) are usually in DOS, win16 (i.e 3.11), drdos, ...

[Fred]

Well, that's right.
The matter is that console programs (from which the data output can be read using PB) are usually in DOS, win16 (i.e 3.11), drdos, ...

Are you sure of that ? Aren't the vast majority of console programs in the Win32/Console format ?

[Psychophanta]

Uffh! dunno, but i'd say that most are DOS.

[Fred]

Uffh! dunno, but i'd say that most are DOS.

I tough you knew . So if you want my guess, i would say than 99% of the console programs are now Win32/Console based (because no compilers since Win95 produce a DOS program anymore).