Silent Mode execution

[aleeksunder]

Not an issue, but a feature request.

Since it very usefull to use iojs as script interpreter, the one feature is missing, and I can suggest that many can vote for it - execute script without console window showing.

I'm not really a programmer, and cannot even say is it possible or not to make console application start without creating a window. But if it is possible I think it may be very usefull to have some command line switch, like --background or --hidden to get this stuff.

Another approach to this can be via another executable, for example windows has wscript.exe and cscript.exe to execute scripts in different modes.

Maybe this was discussed and rejected a lot of time in Node project, but since IOJS is a different project I just want to try again =) I know there is a lot of stuff to get this done like binaries that executes console apps in hidden mode, but this is such a little and such a usefull feature so having it bundled within iojs executable will be really awesome, since we don't need another tool for that.

For example:
I need my JS script to execute some program, wait for it's finish, and do some stuff after that, maybe depend on exit code or something like that, so I can spawn a new process from script and give it a callback. They key here is that I don't want to see any windows, neither spawned process, nor iojs. And I will not see spawned process, but will see iojs window for all the time the spawned process will work. So this is a bit frustrating.

So my question is:
Is this feature can be accepted for consideration by new TC or not?

And if not, can you please provide some info how I can recompile iojs executable to get it run completely silent?

[bnoordhuis]

/cc @piscisaureus - I remember previous discussions about this but I forgot the details.

[dougwilson]

And if not, can you please provide some info how I can recompile iojs executable to get it run completely silent?

You just have to modify the PE header; there are plenty of scripts on the web that can do this, and I already do this for Node.js. https://metacpan.org/source/SREZIC/Tk-804.032/exetype is the source of one such script.

[piscisaureus]

@aleeksunder

Unfortunately due to windows limitations it's not quite possible to build a console/gui "dual mode" application. The only solution I can think of is building two binaries. But I don't think a GUI build of node is useful for the general user base so we won't be shipping binaries for it.

That said, it's not hard to build node as a gui application. You can use @dougwilson's trick, or do it the "official" way, as follows:

• Specify that node is to be built for the "windows" subsystem and not the "console" subsystem. This is specified in common.gypi, although you may want to leave it there and override it only in node.gyp.
• Add a WinMain entry point that gets called when iojs is started; this should go into node_main.cc.
• GUI apps may not have a stdin/stdout/stderr, which may make iojs nonfunctional. I don't know exactly what is to be done, but it can't be hard.

I'd accept pull requests that make GUI builds of node easier.

[rvagg]

Java ships with java and javaw for this reason and may be a model we can follow.

[piscisaureus]

Quoting myself:

But I don't think a GUI build of node is useful for the general user base so we won't be shipping binaries for it.

Maybe I was a bit fast too fast in drawing conclusions. Can I suggest a raise of hands? +1 if you 'd like us to ship two version of node.exe, 0 if you don't care, -1 if you're against.

[rvagg]

-0, this is a Windows-only concern as far as I see it so mostly a call for @seishun and @piscisaureus, though it does also add some build complication.

[dougwilson]

It's interesting to hear that Java ships with java and javaw--ActiveState's Perl ships with perl and guiperl as well for this use-case.

[seishun]

And Python ships with python and pythonw. I'm not too sure if it's really worth the added complexity.

[BenSower]

+1 (even though I am Linux only, that option would be nice for the casual windows development)

[silverwind]

+1, I'd certainly see use of an "GUI" build for simple backgrounding of processes. I'd suggest setting a .js file type association to the gui app through the installer (I think .js to this date still associates with WSH).

[rvagg]

Perhaps this simply comes down to level of difficulty. I have no objections to shipping a nodew.exe in releases. Maybe someone should try a PR for this if they want the feature, if it's not super complicated then it may have a good chance of getting in because you'd mainly just have to convince the Windows collaborators (we only have 2 ATM AFAIK).

[silverwind]

Also, I think it would generally be appreciated by novice users on Windows if they could run a script by double clicking on it (Maybe pointing them to a npm zip before).

[silverwind]

On the other hand, I think a gui app without any visible windows would be quite confusing. A systray icon could solve that, but it's probably quite a bit of work.

[aleeksunder]

Yes, the the complexity is not what we looking for... I don't think that this feature is important enough that you guys drop what you do and implement it, but maybe sometime later, when you have a time for it, just look at the issue.

I've looked for another interpreters ( Perl, Python, etc ) to find out how is it possible to implement this and not to break anything already done... I think the only way here is to compile main binary as .dll-library, so it may be named iojs.dll as a "backend" and provide "frontends" simple .exe-files like "node.exe", "nodew.exe" so them may use .dll in the way they compiled and do not create any symlink on windows ( iojs.exe -> node.exe ), so this can ressurect 100% work on Windows XP and 2003. Finally I think that compile main binary as .dll-library is not too bad idea, since it provides the ability to use IOJS as module in other software with ease. Maybe projects like Node-Webkit ( NW now ) and others similar stuff will be happy to hear about official library. I'm not pretty sure about Mac and Linux, but can suggest that .so file there for exact purpose... So finally this maybe implemented cross-platform.

I have no idea how external library will affect performance of IOJS, and how is it difficult to get this all done, and just write some thoughts about this...

[rvagg]

that approach would also probably solve #751, which would be handy

[artur-railwaymen]

Is there any progress or anything new in this matter?

[Fishrock123]

@artur-railwaymen Nope, but it seems like there is some info above that would make this fairly reasonable for someone to pick up and start working on. :)

[whitlockjc]

I don't mind picking this up. It would be nice to have an agreed upon "this is what we should do" but I can read through the comments and settle the rest in PR review.

[poiru]

@piscisaureus @bnoordhuis I have working patches, but I'm not sure how we want to expose this. How about this:

• Add --dest-windows-subsystem={console,windows} configure option (and vcbuild.bat equivalent)
• Create dummy stdio streams when console is not available
• Make node.exe --interactive always show a console regardless of the subsystem (--dest-windows-subsystem=windows builds wouldn't show any UI by default)

[bnoordhuis]

I don't really have a stake in this. I defer to @piscisaureus.

[Fishrock123]

I don't think --interactive needs to do anything from this "silent mode".

[raub]

+1
I use OpenGL window, and if I were to release any kind of product based on it, I'd rather prefere to hide an ugly black console from the end-user

[StefanScherer]

Some people helped themselves with a custom built node.exe -> https://stackoverflow.com/questions/22653010/prevent-console-window-from-being-created-in-custom-node-js-build/22653825#22653825

[poiru]

I've been maintaining a patch to do this for our custom Node build. Here is an up-to-date patch for Node 8.9.x: https://gist.github.com/poiru/d7cedb2c3c4c7aca9dce29d439597cca

[ukoloff]

Custom build is too complex desision for me. It's the matter of patching node.exe, changing one byte of exe-file from 03 to 02. Et voila!

[StefanScherer]

Thanks @ukoloff for the tip, I've dockerized the generation of nodew.exe with StefanScherer/dockerfiles-windows#275

[s-h-a-d-o-w]

Since I also had a need for this in one of my projects, I ported @ukoloff's solution (Thank you very much for posting it!) to node and released it as a standalone solution that offers both CLI and API:
https://www.npmjs.com/package/create-nodew-exe

[ryzokuken]

Closing this because there's a solution available in the userland (thanks, @s-h-a-d-o-w). Feel free to reopen this.

[s-h-a-d-o-w]

@ryzokuken

Uhm, thanks but I was actually hoping for an official solution at some point because the solution implemented by @ukoloff and me is a pretty dirty hack, as is noticeable by the fact that when you start an app using such a modified .exe, the mouse cursor will switch to "busy" state for like 5-6 seconds.

Which obviously makes for questionable UX, as the user will rightfully ask themselves "What the hell is that thing doing?", as node doesn't actually take 5-6 seconds to start up.

[poiru]

@s-h-a-d-o-w FWIW, the node_main.cc patch in my earlier comment addresses the feedback cursor as well.

[s-h-a-d-o-w]

Yeah I saw that but... as that can't be automated (at least I don't think so, as the code base may change, so you always need to check manually?), I find it too much of a hassle to deal with especially for small personal projects.

If you work at a company where you're free to spend an hour here or there building silent executables for every node version that is being used, it's different. Still annoying I imagine but... at least you get paid to do it. 😉

[ryzokuken]

@poiru @s-h-a-d-o-w please feel free to discuss this and reach consensus, and feel free to reopen this if you feel it should be. I just closed this because it's technically resolved and there was no activity. You'd also want to ask someone to work on this, or submit a PR yourself. We cannot just keep it open.

[develar]

It is also required for Proton Native and other NodeJS libui-based frameworks. The main concern is not technical issue, but increased maintenance costs — on Linux and macOS electron-builder can use officially provided NodeJS executables, but on Windows we need to maintain LaunchUI and build it for each NodeJS version. Even if appveyor offers free build service for everyone to build custom, it is not convenient for users.

[bittu]

Can anyone help to achieve same for macos?

[ukoloff]

@bittu I always thought that MacOS is like Linux in this respect. Linux need no nodew (as well as javaw, pythonw, rubyw etc), so does MaxOS.

[yoavain]

You can use this module:
create-windowless-app

This module:

1. Create a "hello world" project structure (javascript or typescript) that compiles into an exe file (using nexe, with configurable nodejs version)
2. Compiles a c# launcher (with an option to provide an icon) that can start the project exe in a silent mode. (source included)

[yoavain]

You can use this module:
create-windowless-app

This module:

1. Create a "hello world" project structure (javascript or typescript) that compiles into an exe file (using nexe, with configurable nodejs version)
2. Compiles a c# launcher (with an option to provide an icon) that can start the project exe in a silent mode. (source included)

I just created a template repository from this module (if you prefer not to run it yourself)

[Niek]

Quite crazy that this is not a solved problem. For now I rely on cmd /c start /min node.exe file.js but that's far from ideal.