latest version of buildtools can not run after checkout

[hn3000]

If this is a question about how to use NVM4W, please use stackoverflow instead.

If this is an issue regarding antivirus, make sure you search the existing issues first.

My Environment

• Windows 10

I'm using NVM4W version:

• OTHER (Please Specify)
  trying to build from github

I have already...

• read the README to be aware of npm gotchas & antivirus issues.
• reviewed the wiki to make sure my issue hasn't already been resolved.
• verified I'm using an account with administrative privileges.
• searched the issues (open and closed) to make sure this isn't a duplicate.
• made sure this isn't a question about how to use NVM for Windows, since gitter is used for questions and comments.

My issue is related to (check only those which apply):

building from source

Expected Behavior

Running build.bat (after the other steps outlined in README.md) should build an installer.

Actual Behavior

A popup tells me that the binaries in buildtools are not designed for windows:

*Unsupported 16-Bit Application*

 The program or feature "\??\C:\Users\...\nvm-windows\buildtools\zip.exe" cannot start
 or run due to incompatibity with 64-bit versions of Windows.
 Please contact the software vendor to ask if a 64-bit Windows compatible
 version is available.

 [OK]

Steps to reproduce the problem:

git clone git@github.com:coreybutler/nvm-windows
cd nvm-windows
build.bat

(i.e., fetching the go dependencies is not required to reproduce, it doesn't fix the problem, either)

Additional information / Ohter things tried

Reverting to the previous commit b87de53 allows the tools to run.

Another symptom is that git thinks the tools are modified immediately after checkout.

Adding the following to .gitattributes allows the tools to be checked out without modification, but still doesn't allow to tools to run:

*.exe binary
*.dll binary
*.e32 binary

(Since the WIndows git installer lets the user to control some settings on installation we might have different global git settings, I am not completely sure what option I selected for those. But I feel the projects .gitattributes should make sure that checkout does not rely on those global settings.)

[jonbride]

I have what I think is the same issue with Windows 7 64-bit, and the error message is similar, running e.g. buildtools\zip.exe:

[Content]
The version of this file is not compatible with the version of Windows you're running. Check your computer's system information to see whether you need an x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher.

[OK]

[coreybutler]

Well that's funky and unexpected. If you want to submit a PR with the .gitattributes, I'll merge it. I can do it myself if you prefer, but I like to give people a chance to add a contribution if they like.

The build tools did recently change, but it was updating the tools to support 32 and 64 bit environments... the 16 bit message is what feels funky. I'm marking this for investigation and will revert the tools if necessary.

[hn3000]

I think you'll have to re-commit the binaries after checking out the .gitattributes ... the 16-bit message just says that the actual PE structure inside the binary is not valid, without it Windows thinks it's an old .com executable.

[TheSpartaPT]

so, any news on this issue ? this is preventing me to build the app myself to be able to use the commits made on August 3rd that fixed the issue #41 because there isn't any prebuilt version with this fix implemented, if there's any way around this issue, even if it requires me to create a VM just to build the app on a different windows version, i'm up for suggestions, i just really want to have a build with that issue fixed (preferebly a way that also lets me build a 64bit version of it, but that's not really a major problem)

[d7d6]

I got a working amd64 build on win10 64bit using following steps:

1. replacing all files in buildtools:
   • zip.exe from ftp://ftp.info-zip.org/pub/infozip/win32/zip300xn-x64.zip
   • all other files from an installation of Inno Setup Compiler (I used the version 5.6.1)
2. commented lines 16 and 17 in nvm.iss
   • ;SignTool=MsSign $f
   • ;SignedUninstaller=yes

[gartha1]

this issue still exists
https://i.imgur.com/sssVL8y.png
also gives that error for iscc.zip

Perhaps d7d6's suggestion could be incorporated into the actual project?

[gartha1]

• zip.exe from ftp://ftp.info-zip.org/pub/infozip/win32/zip300xn-x64.zip
• all other files from an installation of version 5.6.1

version 5.6.1 of what program? The zip program is 3.0 and nvm is 1.1.7 so I can't see what program you mean?
Thanks

[d7d6]

• zip.exe from ftp://ftp.info-zip.org/pub/infozip/win32/zip300xn-x64.zip
• all other files from an installation of version 5.6.1

version 5.6.1 of what program? The zip program is 3.0 and nvm is 1.1.7 so I can't see what program you mean?
Thanks

You right. I just corrected the post. The software where I picked the files was the Inno Setup Compiler.
I just try the latest version (at the moment 6.0.4) and it works as the 5.6.1

[danieljin]

Came across this same issue today. Hopefully @coreybutler can add a new release to https://github.com/coreybutler/nvm-windows/releases. The last one is from over 2 years ago.

The new release fixes issues with spaces in user name folder and using git bash with the weird error popup for "this file does not have an app associated with it for performing this action." For the latter, I can just make sure nodejs and nvm get installed some where the user has permissions for symlinks due to the changes in #511.

I will take a look at creating a PR with 64 bit compatibility if I have time.

[coreybutler]

The build tools have been update in the latest release (https://github.com/coreybutler/nvm-windows/releases/tag/1.1.8).