I compiled a Windows GUI application with haskell-gi. Everything seems to be working fine. However, every time I double click on the executable in Windows Explorer to execute the program, Windows also creates a console window (i.e. a terminal) along with the main window of my application. Is it possible to ask Windows to not create the console window, which is how typical Windows GUI apps behave?
As per the ghc user guide, you can build a GUI-only application by adding the -optl-mwindows flag to your build.
Notice the warning in the link that says that in this mode using standard IO functions (putStrLn, getLine, or anything that reads from stdin or writes to stdout/stderr) will fail with an IOException on Windows.
Related
I have a small warp server project on Windows that listen to a particular port and do something whenever I send a command to it by REST (for example: POST http://10.10.10.1:5000/print). It's a small client for printing PDF / receipt directly from another computer.
It works. But my problem is when I had to package the whole project, the Rust compiler give me an executable file (.exe). The application displays a terminal window when I run it. I want this terminal to be hidden somehow.
I try to run the program as a windows service (by using NSSM). It doesn't work for me since I had to access the printer. Windows doesn't allow my app to access any devices or any other executable as a windows service. (The reasons are explained here: How can I run an EXE program from a Windows Service using C#?)
So I plan to run my app as a tray-icon application so user can control or close the app. (https://github.com/olback/tray-item-rs)
Unfortunately, I still cannot hide the app's terminal window.
Another solution that I found is hstart (https://www.ntwind.com/software/hstart.html). But I would like to use this as "the last resort" solution since many antivirus/windows defender mark it as a malware.
Do anyone know how to hide or get rid of it ?
After lot of searching, It turns out to be easier than I thought. Just add
#![windows_subsystem = "windows"]
on top of your main.rs file. (for rust > 1.18) and the terminal is gone.
These control the /SUBSYSTEM flag in the linker. For now, only
"console" and "windows" are supported.
When is this useful? In the simplest terms, if you're developing a
graphical application, and do not specify "windows", a console window
would flash up upon your application's start. With this flag, it
won't.
https://doc.rust-lang.org/reference/runtime.html#the-windows_subsystem-attribute
https://blog.rust-lang.org/2017/06/08/Rust-1.18.html
https://learn.microsoft.com/en-us/cpp/build/reference/subsystem-specify-subsystem?view=msvc-170
I try to run an windows 10 application inside a windows servercore container.
The app can run without user input via COM-Interface (and without visible GUI), but it seems that it needs to load a hidden window in the background. When I start it on docker, the application log file indicates that it's stuck on starting this window.
Is there a way to make the app assume it successfully loaded the window?
All information I found so far was about users who want to see the GUI or about Linux/Windows combinations. None of that helped me.
If I create a new console application (.NET Framework 4.5.2) and enter the following lines as the complete contents of the Main method:
Console.WriteLine("A");
Console.ReadLine();
When I hit run (F5), VS enters debugging mode and shows the memory usage graph but does not show any console window. This same problem is seen on every console application I try to use in VS2017. While not universally the case, in the app I described above, running this by double-clicking the .exe file does produce a console window.
Does anyone know how to get VS2017 to show a console window?
This appears to be to do with 32-bit applications.
Unticking the prefer 32-bit option in the build options solves the problem.
Edit: Further investigation showed this to be a problem with an extension used within my company. Disabling this extension let my console windows appear again.
Why doesn't -Dinstall4j.debug=true -Dinstall4j.logToStderr=true on windows result in messages in the console while it does on linux?
My cross platform installer runs as a normal user on linux and elevates on windows so it can install a service.
Linux
myinstaller.sh -Dinstall4j.debug=true -Dinstall4j.logToStderr=true
Console window fills with useful information
Windows
myinstaller.exe -Dinstall4j.debug=true -Dinstall4j.logToStderr=true
console window empty - I suspect the elevation, which seems to require a relaunch, is the cause.
If I run my installer from an Admin window I don't get my error case and don't see the console logging either.
GUI applications cannot write to the console under Windows, because they have no associated console.
If you select the "Windows console executable" property for the installer node on the Installer->Screens & Actions tab, you will see console output.
We have a java application that uses Launch4j to create a windows .exe. We achieve this using the org.bluestemsoftware.open.maven.plugin, which works great. I have one inquiry however. Recently I added cmd line functionality, and found that using the GUI header didn't pass arguments when run from the .exe. OK, that makes sense.
Using the Console Header works as intended (arguments are passed). However, now when we run it in GUI mode, I get the command window in the background, no pretty splash screen, and my window name is lost. Again, this makes sense, its a CONSOLE header now. But i need both functionalities.
Is there a way to support BOTH headers in one .exe?