Re: [go-nuts] Re: Windows Binaries and stdout

[Jason D]

It should be doable with just go code and the windows package..
CreateFile can do the same work that freopen is doing.

The *CreateFile* 

 function 
enables a process to get a handle to its console's input buffer and active 
screen buffer, even if STDIN and STDOUT have been redirected. To open a 
handle to a console's input buffer, specify the CONIN$ value in a call to 
*CreateFile*. Specify the CONOUT$ value in a call to *CreateFile* to open a 
handle to a console's active screen buffer. *CreateFile* enables you to 
specify the read/write access of the handle that it return.

On Thursday, May 5, 2022 at 1:56:43 AM UTC-4 stephen.t@gmail.com wrote:

> The blog is very interesting. However, I can't see how to re-implement 
> this in Go with only the syscall package or the golang.org/x/sys/windows 
> package. It needs the functionality of C++ freopen(), which as far as I can 
> tell is not possible with the WinAPI - From what I can gather,  ReOpen() 
> only works with file handles and not console handles returned by 
> GetStdHandle().
>
> On Monday, May 2, 2022 at 2:34:03 PM UTC+1:
>
>>
>> https://www.tillett.info/2013/05/13/how-to-create-a-windows-program-that-works-as-both-as-a-gui-and-console-application/
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a32a24f0-fa45-44e9-b364-ac5fdc73620cn%40googlegroups.com.

Re: [go-nuts] Re: Windows Binaries and stdout

[stephen.t....@gmail.com]

The blog is very interesting. However, I can't see how to re-implement this 
in Go with only the syscall package or the golang.org/x/sys/windows 
package. It needs the functionality of C++ freopen(), which as far as I can 
tell is not possible with the WinAPI - From what I can gather,  ReOpen() 
only works with file handles and not console handles returned by 
GetStdHandle().

On Monday, May 2, 2022 at 2:34:03 PM UTC+1:

>
> https://www.tillett.info/2013/05/13/how-to-create-a-windows-program-that-works-as-both-as-a-gui-and-console-application/
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/27aad81a-9eb9-47e9-8fcb-f494bfd10038n%40googlegroups.com.

Re: [go-nuts] Re: Windows Binaries and stdout

[stephen.t....@gmail.com]

Yes. Logging to a file is probably the simplest option for this particular 
use case.
On Monday, May 2, 2022 at 2:27:22 PM UTC+1 anderson...@elastic.co wrote:

> You could log to a file. If you're willing to take in a -log flag, you 
> could take a path as well and log to this file. That way you don't need 2 
> binaries, however you'd need to tail the file, which seems to me better 
> than 2 binaries.
>
> Best, 
> Anderson
>
>
> On Friday, April 29, 2022 at 2:47:06 PM UTC+2 stephen.t@gmail.com 
> wrote:
>
>> You're right, it is a Windows issue. I can see that now. I bought up the 
>> issue originally because I was unsure if there was something in addition to 
>> -H=windows or -H=windowsgui that I could make use of. My understanding of 
>> Windows is now exhausted.
>>
>> The alternative way is to have two binaries for the Windows version.
>> On Friday, April 29, 2022 at 1:22:45 PM UTC+1 jake...@gmail.com wrote:
>>
>>> This is really a Windows issue, and not related to Go. According to this 
>>> very old post: 
>>> https://stackoverflow.com/questions/493536/can-one-executable-be-both-a-console-and-gui-application
>>>  
>>> it is technically possible to do that, but the technique has flaws, foibles 
>>> and limitations. 
>>>
>>> This sounds like a 'rabbit hole' to me. I would suggest going back to 
>>> what you actually want to accomplish, and thinking about alternative ways 
>>> of achieving it.  
>>>
>>> On Friday, April 29, 2022 at 4:46:19 AM UTC-4 stephen.t@gmail.com 
>>> wrote:
>>>
 Hello Alex. Thanks for your response.

 On Fri, Apr 29, 2022 at 9:34 AM brainman  wrote:

> Once windows executable is built, go has no control over how this 
> program executes.
>
> When command line program is executed by clicking in explorer window 
> Windows automatically starts a new console window and the console is used 
> for stdout output (I did not check that). If command line program is 
> started from existing cmd.exe console, new process just uses the same 
> console.
>
> When you click on GUI executable in Windows explorer, no console 
> windows is started (I did not check that). Same for GUI executable 
> started 
> from cmd.exe console - new GUI process is not attached to parent console 
> (I 
> did not check that).
>

 Right. So I have a GUI executable that might be launched from a console 
 but it will not be "attached" to that parent console.

 Is there a way to attach the GUI executable to the parent console, 
 perhaps using a Windows system call?



-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/36b12b14-4fb7-4b6c-a5e9-82d0155c3924n%40googlegroups.com.

Re: [go-nuts] Re: Windows Binaries and stdout

[Robert Engels]

https://www.tillett.info/2013/05/13/how-to-create-a-windows-program-that-works-as-both-as-a-gui-and-console-application/

> On May 2, 2022, at 8:27 AM, 'Anderson Queiroz' via golang-nuts 
>  wrote:
> 
> You could log to a file. If you're willing to take in a -log flag, you could 
> take a path as well and log to this file. That way you don't need 2 binaries, 
> however you'd need to tail the file, which seems to me better than 2 binaries.
> 
> Best, 
> Anderson
> 
>> On Friday, April 29, 2022 at 2:47:06 PM UTC+2 stephen.t@gmail.com wrote:
>> You're right, it is a Windows issue. I can see that now. I bought up the 
>> issue originally because I was unsure if there was something in addition to 
>> -H=windows or -H=windowsgui that I could make use of. My understanding of 
>> Windows is now exhausted.
>> 
>> The alternative way is to have two binaries for the Windows version.
>>> On Friday, April 29, 2022 at 1:22:45 PM UTC+1 jake...@gmail.com wrote:
>>> This is really a Windows issue, and not related to Go. According to this 
>>> very old post: 
>>> https://stackoverflow.com/questions/493536/can-one-executable-be-both-a-console-and-gui-application
>>>  it is technically possible to do that, but the technique has flaws, 
>>> foibles and limitations. 
>>> 
>>> This sounds like a 'rabbit hole' to me. I would suggest going back to what 
>>> you actually want to accomplish, and thinking about alternative ways of 
>>> achieving it.  
>>> 
 On Friday, April 29, 2022 at 4:46:19 AM UTC-4 stephen.t@gmail.com 
 wrote:
 Hello Alex. Thanks for your response.
 
> On Fri, Apr 29, 2022 at 9:34 AM brainman  wrote:
 
> Once windows executable is built, go has no control over how this program 
> executes.
> 
> When command line program is executed by clicking in explorer window 
> Windows automatically starts a new console window and the console is used 
> for stdout output (I did not check that). If command line program is 
> started from existing cmd.exe console, new process just uses the same 
> console.
> 
> When you click on GUI executable in Windows explorer, no console windows 
> is started (I did not check that). Same for GUI executable started from 
> cmd.exe console - new GUI process is not attached to parent console (I 
> did not check that).
 
 Right. So I have a GUI executable that might be launched from a console 
 but it will not be "attached" to that parent console.
 
 Is there a way to attach the GUI executable to the parent console, perhaps 
 using a Windows system call?
 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/95689cc2-ec6b-466f-ba3b-72a41756b328n%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0614C0D2-7A18-4C0F-8BB8-C97BDA088969%40ix.netcom.com.

Re: [go-nuts] Re: Windows Binaries and stdout

['Anderson Queiroz' via golang-nuts]

You could log to a file. If you're willing to take in a -log flag, you 
could take a path as well and log to this file. That way you don't need 2 
binaries, however you'd need to tail the file, which seems to me better 
than 2 binaries.

Best, 
Anderson

On Friday, April 29, 2022 at 2:47:06 PM UTC+2 stephen.t@gmail.com wrote:

> You're right, it is a Windows issue. I can see that now. I bought up the 
> issue originally because I was unsure if there was something in addition to 
> -H=windows or -H=windowsgui that I could make use of. My understanding of 
> Windows is now exhausted.
>
> The alternative way is to have two binaries for the Windows version.
> On Friday, April 29, 2022 at 1:22:45 PM UTC+1 jake...@gmail.com wrote:
>
>> This is really a Windows issue, and not related to Go. According to this 
>> very old post: 
>> https://stackoverflow.com/questions/493536/can-one-executable-be-both-a-console-and-gui-application
>>  
>> it is technically possible to do that, but the technique has flaws, foibles 
>> and limitations. 
>>
>> This sounds like a 'rabbit hole' to me. I would suggest going back to 
>> what you actually want to accomplish, and thinking about alternative ways 
>> of achieving it.  
>>
>> On Friday, April 29, 2022 at 4:46:19 AM UTC-4 stephen.t@gmail.com 
>> wrote:
>>
>>> Hello Alex. Thanks for your response.
>>>
>>> On Fri, Apr 29, 2022 at 9:34 AM brainman  wrote:
>>>
 Once windows executable is built, go has no control over how this 
 program executes.

 When command line program is executed by clicking in explorer window 
 Windows automatically starts a new console window and the console is used 
 for stdout output (I did not check that). If command line program is 
 started from existing cmd.exe console, new process just uses the same 
 console.

 When you click on GUI executable in Windows explorer, no console 
 windows is started (I did not check that). Same for GUI executable started 
 from cmd.exe console - new GUI process is not attached to parent console 
 (I 
 did not check that).

>>>
>>> Right. So I have a GUI executable that might be launched from a console 
>>> but it will not be "attached" to that parent console.
>>>
>>> Is there a way to attach the GUI executable to the parent console, 
>>> perhaps using a Windows system call?
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/95689cc2-ec6b-466f-ba3b-72a41756b328n%40googlegroups.com.

Re: [go-nuts] Re: Windows Binaries and stdout

[stephen.t....@gmail.com]

You're right, it is a Windows issue. I can see that now. I bought up the 
issue originally because I was unsure if there was something in addition to 
-H=windows or -H=windowsgui that I could make use of. My understanding of 
Windows is now exhausted.

The alternative way is to have two binaries for the Windows version.
On Friday, April 29, 2022 at 1:22:45 PM UTC+1 jake...@gmail.com wrote:

> This is really a Windows issue, and not related to Go. According to this 
> very old post: 
> https://stackoverflow.com/questions/493536/can-one-executable-be-both-a-console-and-gui-application
>  
> it is technically possible to do that, but the technique has flaws, foibles 
> and limitations. 
>
> This sounds like a 'rabbit hole' to me. I would suggest going back to what 
> you actually want to accomplish, and thinking about alternative ways of 
> achieving it.  
>
> On Friday, April 29, 2022 at 4:46:19 AM UTC-4 stephen.t@gmail.com 
> wrote:
>
>> Hello Alex. Thanks for your response.
>>
>> On Fri, Apr 29, 2022 at 9:34 AM brainman  wrote:
>>
>>> Once windows executable is built, go has no control over how this 
>>> program executes.
>>>
>>> When command line program is executed by clicking in explorer window 
>>> Windows automatically starts a new console window and the console is used 
>>> for stdout output (I did not check that). If command line program is 
>>> started from existing cmd.exe console, new process just uses the same 
>>> console.
>>>
>>> When you click on GUI executable in Windows explorer, no console windows 
>>> is started (I did not check that). Same for GUI executable started from 
>>> cmd.exe console - new GUI process is not attached to parent console (I did 
>>> not check that).
>>>
>>
>> Right. So I have a GUI executable that might be launched from a console 
>> but it will not be "attached" to that parent console.
>>
>> Is there a way to attach the GUI executable to the parent console, 
>> perhaps using a Windows system call?
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c8b4a749-3c1a-4823-b37b-8573165accafn%40googlegroups.com.

Re: [go-nuts] Re: Windows Binaries and stdout

[jake...@gmail.com]

 This is really a Windows issue, and not related to Go. According to this 
very old post: 
https://stackoverflow.com/questions/493536/can-one-executable-be-both-a-console-and-gui-application
 
it is technically possible to do that, but the technique has flaws, foibles 
and limitations. 

This sounds like a 'rabbit hole' to me. I would suggest going back to what 
you actually want to accomplish, and thinking about alternative ways of 
achieving it.  

On Friday, April 29, 2022 at 4:46:19 AM UTC-4 stephen.t@gmail.com wrote:

> Hello Alex. Thanks for your response.
>
> On Fri, Apr 29, 2022 at 9:34 AM brainman  wrote:
>
>> Once windows executable is built, go has no control over how this program 
>> executes.
>>
>> When command line program is executed by clicking in explorer window 
>> Windows automatically starts a new console window and the console is used 
>> for stdout output (I did not check that). If command line program is 
>> started from existing cmd.exe console, new process just uses the same 
>> console.
>>
>> When you click on GUI executable in Windows explorer, no console windows 
>> is started (I did not check that). Same for GUI executable started from 
>> cmd.exe console - new GUI process is not attached to parent console (I did 
>> not check that).
>>
>
> Right. So I have a GUI executable that might be launched from a console 
> but it will not be "attached" to that parent console.
>
> Is there a way to attach the GUI executable to the parent console, perhaps 
> using a Windows system call?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a20dab65-79a4-4111-9cd4-44450109ba4cn%40googlegroups.com.

Re: [go-nuts] Re: Windows Binaries and stdout

[Stephen Illingworth]

Hello Alex. Thanks for your response.

On Fri, Apr 29, 2022 at 9:34 AM brainman  wrote:

> Once windows executable is built, go has no control over how this program
> executes.
>
> When command line program is executed by clicking in explorer window
> Windows automatically starts a new console window and the console is used
> for stdout output (I did not check that). If command line program is
> started from existing cmd.exe console, new process just uses the same
> console.
>
> When you click on GUI executable in Windows explorer, no console windows
> is started (I did not check that). Same for GUI executable started from
> cmd.exe console - new GUI process is not attached to parent console (I did
> not check that).
>

Right. So I have a GUI executable that might be launched from a console but
it will not be "attached" to that parent console.

Is there a way to attach the GUI executable to the parent console, perhaps
using a Windows system call?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAPmHGLNS1QMVKqHrjoLskEy1SFhCYXc_Ra%2BnEiysHoA%3DV7Fw2A%40mail.gmail.com.

[go-nuts] Re: Windows Binaries and stdout

[brainman]

Hello Stephen,

Windows uses special flag in every executable binary to determine if 
executable is a GUI or command line program.

go program uses "-H windows" linker flag to set that flag. See 
debug/pe.TestBuildingWindowsGUI for details.

Once windows executable is built, go has no control over how this program 
executes.

When command line program is executed by clicking in explorer window 
Windows automatically starts a new console window and the console is used 
for stdout output (I did not check that). If command line program is 
started from existing cmd.exe console, new process just uses the same 
console.

When you click on GUI executable in Windows explorer, no console windows is 
started (I did not check that). Same for GUI executable started from 
cmd.exe console - new GUI process is not attached to parent console (I did 
not check that).

If you want GUI with console window, you have to create console window in 
your code.

Alex 


On Friday, 29 April 2022 at 17:34:29 UTC+10 stephen.t@gmail.com wrote:

> I've read through my post again. I'll try to simplify my question:
>
> Where is stdout for a Windows "GUI binary"? (see -H option)
>
> https://pkg.go.dev/cmd/link
>
> If I run from the command prompt I would have thought that stdout is the 
> console I'm running from but if the executable is a "GUI binary" this does 
> not seem to be the case.
>
> If I create a "console binary" then stdout is indeed the console I'm 
> running from. But this means that when I run the binary from a desktop 
> icon, Windows will open up a console window, even if there is nothing to 
> output.
>
> Context for this is an application that has a GUI by default and 
> optionally, a terminal interface (using stdout).
>
> I'm not a Windows person and I'm sorry if this is a dumb question but this 
> is a complete mystery to me. Do I really need two separate binaries?
>
> On Monday, April 25, 2022 at 9:48:18 AM UTC+1 stephen.t@gmail.com 
> wrote:
>
>> Hello,
>>
>> I'm cross-compiling my Go application to Windows and I'm having 
>> difficulty understanding how Windows interacts with stdout.
>>
>> I'm compiling the Windows binary with the "-H=windowsgui" LD flag. This 
>> works great but I've found that the program will never print to stdout, 
>> even if the program is launched from the command prompt
>>
>> The alternative LD flag "-H=windows" will print to stdout but with the 
>> downside that a "DOS" window will always open, even if the program is 
>> launched from the desktop icon and even when there is no stdout activity.
>>
>> For the most part, compiling with "-H=windowsgui" is fine but 
>> occasionally it's useful for users to run with the program's -log option, 
>> which outputs to stdout.
>>
>> My solution for now is to have two Windows binaries. One for regular use 
>> and another for diagnosing problems. This is a poor solution.
>>
>> What I require is a single binary that can:
>>
>> 1) Launch from the desktop icon without a "DOS" window opening.
>> 2) To launch from a command prompt and for stdout to be echoed to the 
>> command prompt window.
>>
>> Is there a Go compilation option that I've missed. Or is the solution 
>> more complex?
>>
>> Regards
>>
>> Stephen
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ea7da703-d5e6-464e-add7-f741cdf12464n%40googlegroups.com.

[go-nuts] Re: Windows Binaries and stdout

[stephen.t....@gmail.com]

I've read through my post again. I'll try to simplify my question:

Where is stdout for a Windows "GUI binary"? (see -H option)

https://pkg.go.dev/cmd/link

If I run from the command prompt I would have thought that stdout is the 
console I'm running from but if the executable is a "GUI binary" this does 
not seem to be the case.

If I create a "console binary" then stdout is indeed the console I'm 
running from. But this means that when I run the binary from a desktop 
icon, Windows will open up a console window, even if there is nothing to 
output.

Context for this is an application that has a GUI by default and 
optionally, a terminal interface (using stdout).

I'm not a Windows person and I'm sorry if this is a dumb question but this 
is a complete mystery to me. Do I really need two separate binaries?

On Monday, April 25, 2022 at 9:48:18 AM UTC+1 stephen.t@gmail.com wrote:

> Hello,
>
> I'm cross-compiling my Go application to Windows and I'm having difficulty 
> understanding how Windows interacts with stdout.
>
> I'm compiling the Windows binary with the "-H=windowsgui" LD flag. This 
> works great but I've found that the program will never print to stdout, 
> even if the program is launched from the command prompt
>
> The alternative LD flag "-H=windows" will print to stdout but with the 
> downside that a "DOS" window will always open, even if the program is 
> launched from the desktop icon and even when there is no stdout activity.
>
> For the most part, compiling with "-H=windowsgui" is fine but occasionally 
> it's useful for users to run with the program's -log option, which outputs 
> to stdout.
>
> My solution for now is to have two Windows binaries. One for regular use 
> and another for diagnosing problems. This is a poor solution.
>
> What I require is a single binary that can:
>
> 1) Launch from the desktop icon without a "DOS" window opening.
> 2) To launch from a command prompt and for stdout to be echoed to the 
> command prompt window.
>
> Is there a Go compilation option that I've missed. Or is the solution more 
> complex?
>
> Regards
>
> Stephen
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/84d95a6c-441e-4b83-b1e2-abc59838bf7cn%40googlegroups.com.