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.)

[vlad-shatskyi]

Thanks to @ForNeVeR it should now run on Windows. Please note that Windows is still not officially supported, though.

[ForNeVeR]

@vshatskyi I understand and appreciate your position on "official" thing. What else could we do to advance towards the "official" or at least "semi-official" support? Should we enable unit-testing on Windows, for example?

Everyone else in the thread: please, guys, help us to find and fix the remaining issues on Windows. I bet somebody wants alternate shell support (e.g. many people on Windows are using bash or PowerShell), somebody could find a bug etc.

[vlad-shatskyi]

So, the current plan is to avoid using external shells and write our own. If that's what's going to happen, then it doesn't make sense to support cmd.exe.

I guess gathering a list of differences between platforms would help, but don't expect it to be implemented any time soon.

[ForNeVeR]

Understood. So, ideally we shouldn't implement any new features in the meantime. Small feature requests and bug fixes are okay, but major changes are undesired at the moment.

Also, good news, everyone! I should mention that PowerShell already works with all its' nice features (PsReadLine, oh-my-posh) in the current state:

You should just start powershell from the initial upterm session, and everything seem to be okay.

[Cka3]

So, are we posting bugs for unofficial windows support or...? Here is what I got when I tried to do npm install

npm ERR! Windows_NT 10.0.14393
npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "install"
npm ERR! node v6.10.2
npm ERR! npm  v3.10.10
npm ERR! code ELIFECYCLE

npm ERR! node-pty@0.6.6 install: `node scripts/install.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the node-pty@0.6.6 install script 'node scripts/install.js'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the node-pty package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node scripts/install.js
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs node-pty
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls node-pty
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     D:\Projects\upterm\upterm-0.2.157\npm-debug.log

npm version

npm@3.10.10 C:\Program Files\nodejs\node_modules\npm
PS D:\Projects\upterm\upterm-0.2.157> npm version
{ upterm: '0.2.157',
  npm: '3.10.10',
  ares: '1.10.1-DEV',
  http_parser: '2.7.0',
  icu: '58.2',
  modules: '48',
  node: '6.10.2',
  openssl: '1.0.2k',
  uv: '1.9.1',
  v8: '5.1.281.98',
  zlib: '1.2.11' }

Also where can I find installation guide? Is it the same as for linux?

[christianwico]

I've always wanted to bring up this Windows Building issue as well. Can't help if you can't even get the app running. The wiki article on Windows installation is absolute garbage.

[ForNeVeR]

Could you, guys, please post any additional logs you're getting from npm? I think you need Visual Studio 2017 installed and added to environment to build some of native deps.

[christianwico]

I had Visual Studio 2013, 2015, and 2017 installed. I also installed python 2.x (I think it was 2.7...).

I'll post my logs when I get home...

[christianwico]

Here's the gist...

I have:

• Microsoft Windows v10.0.14393 (Pro x64)
• Microsoft Visual Studio 2013 (Community)
• Microsoft Visual Studio 2015 (Community)
• Microsoft Visual Studio 2017 (Community)
• Python 2.7.11
• NodeJS v6.10.3
• Node Package Manager v3.10.10

[ForNeVeR]

Sorry, but I can't reproduce that. I have VS2017, Nodejs 8.0 and Python 2.7.11 installed. npm install works on my machine (I've just checked with a clean checkout of upterm sources).

[christianwico]

I could try it on another machine. I was planning on setting up an older PC to use Windows 7. I'll try to reproduce your Windows environment from a clean install. (Were you using Windows 10?)

[ForNeVeR]

(Were you using Windows 10?)

Yes, I'm using Windows 10 x64 Pro 10.0.14393.

[weaversam8]

I can confirm it installs for me on Windows 10 x64 Pro. I think I've got VS 2015.

[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.