Windows Support

[ghost]

Hi,

Please bring support for Windows including a downloadable installer

[drew-gross]

Happy to accept help :) I don't think any of the current core contributors use Windows so don't expect this to be high priority for them.

[gyurisc]

I would like to help bringing black-screen to windows, but I am not sure where to start.

[minecrawler]

@gyurisc

start by downloading the source, installing all dependencies and running it. Just getting it started without errors is your first hurdle ;)

Once it runs, decide on a basic feature set you think has to work no matter what. Then see if those features work. If they don't, debug the application and fix them in a way which does not prevent them from working on other platforms.

As soon as all core features work, you should make a PR with your fixes, package Electron and the application into a binary bundle (ZIP file should be enough for now, I would leave the decision which installer to use etc. for the core team). Then you can send the ZIP archive to the core team and have them include it with the release you based it on (just add it as a binary file in the RELEASE section)

You might want to ask them to add a direct link to the file to the README, so people will find it more easily.

From there on, you will have to make sure all subsequent releases work on Windows. Also try to add more working features.

[jsphpl]

Duplicate of #302

[mrcbax]

I find it annoying that "just because our contributors don't use it we shouldn't support it" is your response. You should aim for cross platform from the start. Also, look at the percentage of the world population that actually owns a Mac. It's JavaScript guys c'mon, it's been cross platform since around '98 has it not?

[weaversam8]

Indeed, it is annoying, but part of maintaining open source software is the fact that people are volunteering their own time and resources to make it. Those things are limited, and while I personally love Windows and despise Macs, if the contributors have everything they need then it may not be high on their priorities. That being said, this is open source after all, and you're welcome to try and make the port yourself. @minecrawler provided some great ideas on how to start.

[drew-gross]

Well put @weaversam8. I do think we should support Windows, but I have typically 2-3 hours a week to work on black-screen, and I'm going to put those hours towards things that are important to me, first and foremost.

Also, I think it should already pretty much work on Windows, maybe with some small updates to the build system, but I don't have a Windows machine, and it's not easy to test Windows in CI. If someone who does have Windows and knows a little about Electron tried to add support I doubt it would be too hard.

[weaversam8]

Yeah, with my limited experience with Electron, I'd say it's probably pretty straightforward. I'd work on it myself if I had decent time, but you know how that is.

[ShadowRZ]

I just talked about a failed build of winpty on #920 ,it's the naitve dep of pty.js. Should I file a new issue for that?
@vshatskyi @weaversam8

[ShadowRZ]

Check what I found!
chjj/pty.js#178

[ForNeVeR]

@ShadowRZ, thanks a lot!

Your comment has been very useful: I have been able to compile and execute black-screen on Windows with pty.js being replaced with node-pty. The overall experience is still messy as hell, but hey — it works!

I'll slap things together and prepare a pull request; ETA: 2 hours.

[ForNeVeR]

(Just a little announcement for the ones who're interested in Windows support: there's a PR #1033 and I think I'll finish it in the nearest couple of days.)

[christianwico]

Trial 1

I tried it on another machine running a clean install of Windows 10 x64. I installed NodeJS 8.1.0, Python 2.7.11, and Microsoft Visual Studio 2017 (Community).

Except for dates and times, the err logs from both of them are more or less 100% identical.

Trial 2

I clean installed Windows 7 x64 on the same machine. Installed everything else the same. Now, it's not only the dates and times that are different, but some version numbers as well. But nonetheless. Almost 100% identical. Same number of lines.

I guess that's it for me and Windows. I'll just have to stick with my Arch Linux until I get my hands on a Mac...

[OvermindDL1]

Same issue and same log as @christianwico on Windows 10 x64 Creator's Update.

[ForNeVeR]

Hey, guys! I've built upterm in my clean virtual environment, and I can confirm that there're indeed some… issues. That manual should help you to solve them.

Here's what I've done on my fresh Hyper-V instance:

1. Install Windows 10 version 1511 (10586.713 whatever that means)
2. Install Visual Studio 2017 Community edition
   • Make sure to choose the right install workloads; see below
     
     (please forgive me for the screenshot in Russian, but I don't know how to change the installer language to English; the selected workload should be Classic C++ application development or something similar in English version)
   • Install Visual C++ 2015.3 Build Tools; see below
     
3. Install Chocolatey
4. Install Python 2: choco install python2 → Python 2.7.13
5. Install Node.js: choco install nodejs → Node.js v8.1.3; npm 5.0.3
6. npm config set msvs_version 2015 (yes really! 2015!)
7. Due to a recent known bug with npm 5 and fsevents, you'll need to disable optional dependencies: npm config set optional false (I hope it will be fixed in some future version of npm)
8. Clone upterm repository; npm install → no errors reported
9. Open "Developer Command Prompt for VS 2017"; execute all the next commands there
10. npm start → no errors reported; upterm started successfully

[Antony-Jones]

Is there any chance we can get a windows 10 build of Upterm attached to this thread? I cant get a VM set up for building it right now.

[OvermindDL1]

Is there any chance we can get a windows 10 build of Upterm attached to this thread? I cant get a VM set up for building it right now.

I'm interested as well, not able to easily install python2 or MSVS 2015 due to other reasons (I'd have to do a lot of path fiddling and other stuff that would take a lot of time... >.>

/me wishes it supported mingw builds straight-out

[weaversam8]

I managed to get this to compile on my own system a while ago, not sure how up to date it is. The one I have here on my system is 0.2.153.

I had no problems getting it to run and create the installer.

GitHub didn't let me upload the file here since it was too big, so I created a repository on my account (weaversam8/upterm-download-0.2.153), you can download by clicking this link.

[r4zzz4k]

Just FYI, there is a package on npm called windows-build-tools -- I never actually came to testing it because my Windows has VS2017 installed and I didn't setup CI for my project yet, but I know it exists exactly for setting up environment with VC++ and Python 2 to support building packages dependent on node-gyp on Windows.

[Rezrazi]

Why not use clink as interpreter for windows version of the terminal ?

[ForNeVeR]

@Rezrazi I think it should work if you run it within upterm.

[jacson-junior]

Is it possible to utilize bash as the default shell on windows? I mean, can I change the shell enviroment variable to bash and get upterm to run over it?

[christianwico]

Finally got this running on my Windows 10 x64. #1141 is waiting. (Petty...)

[ghost]

Nice @christianwico - hopefully there will be a simple installer for the rest of us 😄

[christianwico]

@blacksky86 Looking forward to that day, too. Still waiting for my next vacant period to continue working on my PRs.

[resir014]

Hey there, any progress with this? It would be great if we could finally have official support for Windows machines.

I have a W10 machine at my disposal so I could volunteer with building + testing, etc. Is there anything I could do to help?

[ForNeVeR]

@resir014,

⚠ Disclaimer: I am not one of upterm's maintainers, but I still believe in cross-platform software and willing to help.

To run the upterm on Windows, ideally you should have some experience in Windows development (you don't necessarily need to be an expert though), and have set up the necessary tools (Visual Studio 2017, Python 2, Node.js for sure).

Just clone the repository and try to build the sources. It could be tricky, but shouldn't be very hard. I expect some new build issues to pile up, but all of them should be easy to fix. Please report the progress or issues you've encountered. Refer to my post above for some detailed (but possibly slightly outdated) instructions.

After you built the upterm, you could

1. Test the upterm and report any (positive or negative) experiences

2. Send the PR that'll fix any build or whatever issues you encounter

3. Ping the active maintainer and ask for further directions: if the program is stable enough, then we could make the Windows support official

4. Probably we should set up the automated test suite?

   FYI, https://ci.appveyor.com/ offers free Windows CI servers for open-source software (like Travis, but running on Windows). I am not affiliated with them in any way, I just really think that's a good (the only?) choice for public free testing on Windows machines.

5. Probably we should migrate my little build guide into the repository? E.g. add the document building-on-windows.md? (I'd also appreciate if somebody could replace my screenshots with the English ones.)

6. Maybe we should automate publishing of the installer for people to try upterm on their machines? I have no experience in preparing the Windows installers for node.js software, but it should be possible, and it'll be very convenient for people. Or at least publish the binary archives to chocolatey.org or scoop.sh?

I could offer you help with every item in this list, but I'm short on spare time right now, so please make your questions and issues as concrete as possible if you need any help.

Best regards, Friedrich.

[resir014]

@ForNeVeR

4) I think we should do that, yeah

6) For packaging/installation, there are so many options to do it on Windows, but electron-builder seems to be the one that's currently gaining some traction. It supports cross-platform builds for Linux, macOS, and Windows, as well as support for generating installers in either Squirrel or NSIS format.

I currently can only dedicate a very tiny amount of time a week to debug upterm on Windows, but by this weekend I should be able to start debugging and help you figure out packaging and stuff.

At least I managed to get it run on my machine, that's a start!

[Riebart]

So I've got it building (with a couple changes to the above process) after building a new icon file (the existing 32x32 one is too low resolution for modern Windows).

That said, only supporting cmd for a Windows shell is woefully inadequate given that Powershell has officially replaced cmd.exe as the official shell (and WSL's bash is pretty great). I'll put together a PR with the changes, as well as instructions for building and packaging, but the utter lack of comments in the source code, and the widespread explicit assumptions that cmd is the only Windows shell make modifying it to support a modern shell natively tricky.

Looks like a great terminal, as soon as we can get it running Powershell or WSL-bash.

[ForNeVeR]

When adding cmd as default shell in Windows' variant of upterm, I've taken a look at the API and I think that we could easily add a PowerShell as an alternate shell. Although, that'll probably require some additional refactoring (custom scripts to retrieve shell aliases) and decision making (e.g. whether we still want to execute cmd.exe for some additional purposes such as environment variable enumeration). That's totally doable and won't require big changes.

And for WSL bash — I am not sure but I think that it should almost completely share the settings and code with ordinary bash — we should just use bash.exe instead of /usr/bin/bash (or whatever) and it should work.

@Riebart also please note that it actually could run PowerShell almost without problems as shown on my screenshot above.

[Riebart]

@ForNeVeR Yeah, I took a stab at adding the new-style WSL bash access as well as powershell as a first-level terminal process (not run as a command from cmd.exe), but bumped into issues where the env call was being made with extra /d /s /c switches and didn't know where they were coming from.

For Powershell, yes I realize you can run it as a process from the cmd.exe terminal, but you lose a lot of the benefits that upterm offers. In the same way, running ubuntu from the cmd.exe terminal in upterm launches the WSL bash (for Ubuntu), but again is missing lots of the important bits.

On the topic of my alternate shells not working, this is the error I'm getting from the Electron debug shell when Upterm starts. Any thoughts?

Uncaught (in promise) Error: Command failed: powershell.exe -Command "gci $Env
/d : The term '/d' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the 
spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ /d /s /c powershell.exe -Command gci $Env
+ ~~
    + CategoryInfo          : ObjectNotFound: (/d:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException
 


 

    at ChildProcess.exithandler (child_process.js:217:12)
    at emitTwo (events.js:106:13)
    at ChildProcess.emit (events.js:194:7)
    at maybeClose (internal/child_process.js:899:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:226:5)

Edit: Ah ha! Found it in the child_process.js file's normalizeSpawnArguments() function, which makes an assumption that cmd.exe is in use, and causes all manner of problems when attempting to run another root shell process on Windows platforms (I'm on NodeJS 8.7.0).

...
    if (process.platform === 'win32') {
      file = typeof options.shell === 'string' ? options.shell :
              process.env.comspec || 'cmd.exe';
      args = ['/d', '/s', '/c', '"' + command + '"'];
...

[Riebart]

I made some progress, but now I'm stuck at a different place. For those curious, I've included the necessary updated icon and some notes in the WINDOWS.md file in my fork.

[Riebart]

@formatme Unfortunately it isn't that simple. My attempts to get WSL working (which, by the way, is no longer just replacing cmd.exe with bash.exe with the new install-from-Microsoft-Store method) have been met with... complexities. For one, there is path translation being done on the source files, in many places (as well as const values mapping home directories) that condition only on whether or not the platform is win32. This causes a problem because we need to maintain the Linux-style paths in a win32 environment, conditionally on the shell being used (if it is a WSL shell, either Ubuntu, Suse, or OpenSuse, use the Linux paths).

There are also other issues where debugging things gets hard because some of the issues I'm getting are from the C winpty code, and not the nodejs of Upterm. The one that stumped me with WSL was winpty (I think) throwing a TLS error as it tried to establish a socket connection with the shell process... Or something.

Supporting non-cmd.exe shells on Windows is definitely a nontrivial exercise, but one I think is well worth the effort.

On the bright side, the packaging and setup generation portions of the build process are pretty much flawless, so once we get other shells working, adding an official Windows release is simply a matter of getting a Windows build environment provisioned.

[Riebart]

@formatme You requested a build of the current version of Upterm for Windows, so here you go. I've published it as a release on my fork.

[dougmaitelli]

@Riebart, about your comment from October on WSL not being bash.exe anymore. In the last windows WSL the executable is wsl.exe instead of bash.exe.

[Riebart]

@dougmaitelli Are you referring to stable releases, or insider builds? Part of the issue is that you can install multiple distributions, so a single insertion point doesn't make semantic sense anymore (Ubuntu is Ubuntu.exe, Suse is another, and they are all buried in the %USERHOME%\AppData tree).

[dougmaitelli]

@Riebart, I am talking about the stable 1709 actually. But you are right, when you have multiple installations this will probably not work, but in my local machine I can start Ubuntu WSL running wsl.exe. I've been using hyper terminal with this approach with no problems.

[gregoriobenatti]

About windows, I just build from source and the basics are working... I will try for a couple of days and see if I found some problem.
I also interested to contribute, dunno if I will have time but I will take a look on the source code and do some small changes to get closer to my terminal+bash profile configs.
Btw, I didnt search for that yet but... Is it possible to use the bash_profile file with black-screen?
Cheers.

[SimonMeskens]

So has anyone gotten this to work with WSL yet?