No text output to console on Windows

[vidavidorra]

Originates from #15. When using the program from the command line no output is shown on the console, where on OS X for example the output of --help is shown.

Command run (on Windows 10):

BullyCPP-0.8.1-win32.exe --no-gui --help

Does not show anyting

Command run (on OSX):

BullyCPP.app/Contents/MacOS/BullyCPP --no-gui --help

Does show the following output.

Usage: BullyCPP.app/Contents/MacOS/BullyCPP [options] [hexfile]
Flashes code to PIC devices running the Bully Bootloader.

Options:
  -h, --help             Displays this help.
  -r, --mclr             Assert MCLR (RTS/DTR line) before programming target
  -c, --configbits       Program config bits
  -D, --device <device>  Serial device to use
  -b, --baud <baud>      Serial port speed
  --piclist <piclist>    PIC device file to read
  --no-gui               Do not show GUI

Arguments:
  hexfile                The Intel hex file to send (required with --no-gui)

[vidavidorra]

Just found out that when I redirect the output from the command line to a text or log file the output of BullyCPP is shown in that file. So the output is definitely out there somewhere just not showing on the cmd output.

The following command, for example outputs the same help that I showed in the previous comment in the file log2.txt.

"C:\Program Files (x86)\BullyCPP\BullyCPP-0.8.1-win32.exe" --baud 115200 --no-gui --device COM4 --mclr --help >> log2.txt

[thirtythreeforty]

I can reproduce this on both Windows 7 and 10.

It look like other people have run into this before. Unfortunately, Windows has a distinction between a "console program" and a "GUI program." GUI programs immediately fork from the command prompt they're called from and don't print back to it. Console programs don't, but they always display a console.

I will continue to look into this.

[thirtythreeforty]

Seems like the standard solution to this is to create a second "console program" that forwards its arguments to the "GUI program," then redirects the GUI program's standard input and output streams to its own. There are some methods to attach to the parent process's console, but these don't change the underlying behavior of the system... The program still forks, and the console can continue to execute other programs while the "console" program is running.

[vidavidorra]

Thanks for looking into it! It's not a big problem for me anymore, since I am using it in combination with MPLABX. Now I have MPLABX execute the command line argument

"C:\Program Files (x86)\BullyCPP\BullyCPP-0.8.1-win32.exe" --baud 115200 --no-gui --device COM4 --mclr C:/Users/jdebruijn/Drive/Programming/MPLABX/LedCube.X/dist/debug/production/LedCube.X.production.hex

and the output of that is shown in MPLABX' output window. So it seems that the output is redirected in that case.

But of course it is still not showing the output when just run from the command prompt.

[thirtythreeforty]

Alright, finally nailed this down. Basically I add a wrapper around the main executable and forward all its output back to the console. This stub program will be installed on Windows only; sane platforms only need the main executable.

This will be released with the next release, probably v1.0, after I get everything ready. Sounds like you have a working solution in the meantime.

[vidavidorra]

Thanks! Looking forward to it!