"Windows 32 bit" 3.3.1

[Flint1b]

(...)
Output folder: C:\Program Files\VASSAL-3.3.1-315-g427241be-32_bit_windows_installer\jre\bin
Extract: api-ms-win-core-processthreads-l1-1-0.dll
Extract: java.exe
Extract: api-ms-win-core-profile-l1-1-0.dll
(...)

Oh my.. Good luck with that, Joel. It will be better for my and the users' nervous system if I stay out of 1st level support.

[jrwatts]

Wow, that is...bizarre. Out of curiosity, what anti-virus are you running? The only thing I can think of is the AV is quarantining java.exe....

Edit: Possibly the following link is relevant: https://superuser.com/questions/732332/something-deleted-java-exe-how-to-find-what-it-was

[uckelman]

Thus spake RobS:
> Output folder: C:\Program
> Files\VASSAL-3.3.1-315-g427241be-32_bit_windows_installer\jre\bin
> Extract: api-ms-win-core-processthreads-l1-1-0.dll
> Extract: java.exe

This bit of the install log shows java.exe being extracted into the
location we expect. We've never had a problem with the installer
failing to write the files that it says it is, so I'm inclined to
believe the log. I also checked the installer on a 64-bit Windows
machine before uploading it, and java.exe was written out succesfully
there. It would be very, very stange for the installer to successfully
unpack every file on 64-bit Windows, but on 32-bit Windows fail to
unpack a single file right in the middle of installation---which it
nonetheless claims that it unpacked.

To recap, we have:

1) A screenshot from the file browser with java.exe missing.
2) An error messsage from Java in VASSAL's errorLog saying it can't find
java.exe.
3) The launcher running the Module Manager using javaw.exe instead.
4) The installer claiming that it installed java.exe in the expected place.

Now that I've checked on what exactly the launcher does, I can say that #3
is normal. #4 is also normal. #2 is what should happen when #1 occurs. I
can't see any reason why #1 should occur.

Do we have anyone else around with a 32-bit Windows machine who can test
this? It would be helpful to know what the most recent test build does on
a different machine.

--
J.

[RobS]

Wow, that is...bizarre. Out of curiosity, what anti-virus are you running? The only thing I can think of is the AV is quarantining java.exe....

Edit: Possibly the following link is relevant: https://superuser.com/questions/732332/something-deleted-java-exe-how-to-find-what-it-was

My AVG anti-virus indeed seems to be the problem.
Firstly, I've noticed that AVG does a quick "15 second" check during every step of the installation process, which I've never seen it do for any other program I've ever installed, but maybe that's just something new that AVG does, I don't know. It even says it sends the Installer file to their "labs", which report back after about 5 minutes that the program is "Clear". Then it does another "15 second" check when I actually run Vassal, and then another check when I load a module. It does all these things the first time around, but not thereafter.
It also runs a quick virus check when I uninstall Vassal.
It does all of these things the first time I go through the process, but not thereafter.

I just went through the process of twice uninstalling Vassal and reinstalling it. After both of these installs, java.exe was where it was supposed to be, in the bin folder:



Since I had already installed this version yesterday for the first time, AVG did not do any of it's checks, except when I try to load a game module, at which point it removes java.exe and quarantines it.



I'm sorry for not realizing this issue earlier, but since the AVG "Lab" said everything was good to go, I ignored this. I've tried reporting it as a False Positive, but the little window that opens up doesn't give me enough time to fill out all the info. I will try again.

When I go into AVG quarantine and tell it to restore java.exe and make it an exception, it doesn't restore it to the Vassal Install folder, but creates another similar folder, right next to the Vassal Install folder in C:\Program Files, and puts java.exe in there.
Edit: When I tell it to restore without making it an exception, it does put it back into the correct bin folder.

I hope all of that made sense.

[RobS]

I've added
VASSAL-3.3.1-315-g427241be-32_bit_windows_installer-windows-32.exe
to my AVG exceptions and Vassal 3.3.1 appears to run fine now. I tried it with 2 game modules and they both loaded okay.
I did have Vassal in my exceptions list before and I don't know why AVG ignored that.

However, I think other people might run into the problem I described in my previous post, wherein AVG quarantines java.exe. when they try to run a module.

[uckelman]

Wow, that is crazy-making, having your AV software swipe an executable you need right when you try to run it...

Good work spotting that. I wonder what we can do to prevent this from happening?

[RobS]

Wow, that is crazy-making, having your AV software swipe an executable you need right when you try to run it...

Good work spotting that. I wonder what we can do to prevent this from happening?

If I can be of any more "help", let me know.

[Flint1b]

I wonder what we can do to prevent this from happening?

Some search results talk about signing the executable that is created with launch4j, there is apparently an extra tool for this in the launch4j distribution. But then there are also reports that even the signed versions are detected as false positives by some AVs. It looks like there was/is some windows virus or malware that can be distributed inside a modified java binary, and some AVs just go nuts when they see an application bring their own JVM.

What we can do..
- try to sign the releases
- tell users to stop using AVG as it's a malware and security vulnerability in itself https://en.wikipedia.org/wiki/AVG_AntiVirus#Controversy
- tell users to stop using AVs in general as they are usually worse than the viruses they are supposed to protect from
- learn from the best and write a list of "Known Incompatible Software" like minecraft does: https://minecraftirc.net/support-articl ... -software/ - oh look, AVG is first on that list, but only due to being first in alphabetical order, the rest of the list is made up of almost all other AVs, who would have thought that
- send letters to AV manufacturers and ask them how to get Vassal binaries onto their whitelists
- tell users to install to some place other than "C:\Program Files" to not get any issues with windows UAC
- tell users to download Java and "Vassal other" distro, unzip and run the .bat file

Also:
- produce a live-usb linux with Vassal preinstalled, and an instruction how to copy that onto an USB drive and boot from that
- or a virtualbox VM
- or a docker image

[RobS]

If I can be of any more help, send me a private message because this is not a forum I normally read.

[uckelman]

Thus spake RobS:
> If I can be of any more help, send me a private message because this is
> not a forum I normally read.

As we've verified that the 32-bit build works when nothing is stealing it's
kidneys and leaving it in a bathtub full of ice, I think we're sorted.

Thanks very much for your persistence in helping us troubleshoot.

--
J.

[uckelman]

Thus spake Flint1b:
>
> "uckelman" wrote:
> > I wonder what we can do to prevent this from happening?
>
>
> Some search results talk about signing the executable that is created
> with launch4j, there is apparently an extra tool for this in the
> launch4j distribution.

I see the source code for sign4j, but I'm not sure what good it would
do. AVG isn't complaining about VASSAL.exe, which is what launch4j
produces.

> But then there are also reports that even the
> signed versions are detected as false positives by some AVs. It looks
> like there was/is some windows virus or malware that can be distributed
> inside a modified java binary, and some AVs just go nuts when they see
> an application bring their own JVM.

The java.exe we're distributing comes straight out of the JDK I'm using
for bundling. It's not modified.

> What we can do..
> - try to sign the releases

How would we do that? (I suspect it won't matter in this case, however.)

> - tell users to stop using AVG as it's a malware and security
> vulnerability in itself
> https://en.wikipedia.org/wiki/AVG_AntiVirus#Controversy[1]
> - tell users to stop using AVs in general as they are usually worse than
> the viruses they are supposed to protect from
> - learn from the best and write a list of "Known Incompatible Software"
> like minecraft does: https://minecraftirc.net/support-articl ...
> -software/[2] - oh look, AVG is first on that list, but only due to
> being first in alphabetical order, the rest of the list is made up of
> almost all other AVs, who would have thought that :D

These will let us say "we told you so", but that's about it.

> - send letters to AV manufacturers and ask them how to get Vassal
> binaries onto their whitelists

Want to head that up? (In the past, I've complained to Norton about
listing our files as malware...)

> - tell users to install to some place other than "C:\Program Files" to
> not get any issues with windows UAC
> - tell users to download Java and "Vassal other" distro, unzip and run
> the .bat file
> Also:
> - produce a live-usb linux with Vassal preinstalled, and an instruction
> how to copy that onto an USB drive and boot from that
> - or a virtualbox VM
> - or a docker image

All of these will technically work, but have about zero uptake from
users.

--
J.

[uckelman]

Thus spake Flint1b:
>
> If you're already messing with the build script, you could automate it
> so it downloads and unzips the necessary JDKs automatically, of course
> only if they are not downloaded and unzipped yet. Adopt even has a REST
> API for this: https://api.adoptopenjdk.net/[1]

That's done in HEAD, as we needed a different JDK for Macs due to Bug
13176.

> Another option would be to automate the whole build so that it can run
> on a "naked" ubuntu machine, install all requirements first then build
> all 4 distributions.

There might be a package for nsis? Building dmg and launch4j isn't
very hard, and they're all small. The less convenient thing is that
the three JDK tarballs are 562MB collectively... Downloading half a
gig of stuff on every build on a CI system is not ideal.

--
J.

[Flint1b]

On the AV topic,

some of my ideas were in the ironic sense.

You already tried writing to Norton, let me guess how good that worked.

These AVs are the worst viruses of them all, they infect more computers and use up more resources than all viruses combined. And since they have the knowledge and the financial incentive, I am pretty sure that they themselves are responsible for creating most viruses and the media hype about how dangerous it is on the internet. It's classical racketeering only with computers.

The one thing that we could do which would most definitely work is paying money to the AV mafia for getting on their whitelists.


About automated builds,

yes nsis is just an "apt install nsis" on ubuntu.

If we can get dmg and launch4j to download and build from a script, would be cool.

The JDKs, yes it would be too much for every CI build but we could configure a special release build, something like "if the commit is from release branch then do the full release build else do the regular compile+test". Travis has some options to configure a build right in their .travis.yml file, and if that is not enough we could still write our own build script in bash which looks at the branch name and does what we need.

[uckelman]

Thus spake Flint1b:
> On the AV topic,
>
> some of my ideas were in the ironic sense.
>
> You already tried writing to Norton, let me guess how good that worked.

Actually, it did work, but I had to do it for a while after every single
release, so it was rather tedious. That was the only one where we got
a lot of reports of problems, and it was some years back.

> The one thing that we could do which would most definitely work is
> paying money to the AV mafia for getting on their whitelists.

Yeah, no.

> About automated builds,
>
> yes nsis is just an "apt install nsis" on ubuntu.
>
> If we can get dmg and launch4j to download and build from a script,
> would be cool.

I'm sure I could do that. I'll look into it.

> The JDKs, yes it would be too much for every CI build but we could
> configure a special release build, something like "if the commit is from
> release branch then do the full release build else do the regular
> compile+test". Travis has some options to configure a build right in
> their .travis.yml file, and if that is not enough we could still write
> our own build script in bash which looks at the branch name and does
> what we need.

If we could have something like a docker image which was pre-populated
with the JDKs, that would help a lot. (Also, it's too bad AdoptOpenJDK
doesn't let you rsync, or provide binary diffs to apply from version
to version... That would cut our downloads to almost nil.)

--
J.

[Flint1b]

If we could have something like a docker image which was pre-populated
with the JDKs, that would help a lot. (Also, it's too bad AdoptOpenJDK
doesn't let you rsync, or provide binary diffs to apply from version
to version... That would cut our downloads to almost nil.)

I think this is not such a big issue, we are an opensource project after all and Travis does offer us its features and its bandwidth for free.

Here is a project that downloads several (9 different) JDKs in every build: https://github.com/sormuras/bach
And it uses travis to build 1x daily per cron job, in addition to the regular commits: https://travis-ci.org/github/sormuras/s ... .io/builds

And we wouldn't even need to download that much, we would just need to download the JDKs when we do a full or beta release, that's 4 JDKs once or twice a month, this is less than this sormuras bach project does per day. Also the travis guys are probably smart enough to use some kind of caching mechanism and it's likely that our JDKs would come from this cache instead of all the way from the adopt/zulu/graal/whateverjdk servers.

Another idea I just got - if we automate this whole thing anyways, it's going to be very easy to add additional Vassal distributions with alternative VMs like GraalVM and/or with alternative JIT compilers like OpenJ9 which "might" improve performance for some users.