MinimServer Forum

(17-02-2017 19:02)simoncn Wrote: [ -> ]You could copy the real javaw.exe into C:\ProgramData\Oracle\Java\javapath, overwriting the symbolic link. You would need to do this every time you install a Java update but this might perhaps be easier than updating firewall rules.

Interesting idea. If I could discover the path of the current version within a batch file, I would copy the current version of (the real) javaw.exe to the javapath folder, before starting up Minimserver. Have to think about that. Seems strange that java is designed this way, since it must affect every windows java application?

(17-02-2017 19:02)simoncn Wrote: [ -> ]You could copy the real javaw.exe into C:\ProgramData\Oracle\Java\javapath, overwriting the symbolic link. You would need to do this every time you install a Java update but this might perhaps be easier than updating firewall rules.

My apologies to Simon and MarmiteSandwich for giving duff information here. I thought I'd correctly checked that the image name for Javaw depended on which you way launch it. Although update 101 uses symlinks in C:\ProgramData\Oracle\Java\javapath, update 121 doesn't, and I assume (but haven't tested this) uses hard links. So, I'm puzzled. If that's the case, I can't see how overwriting javaw.exe would help. In any case, that's the kind of action that really is best avoided because it's too hard to understand what's going on.

As to MarmiteSandwich's issue, the most obvious option, if you don't mind an extra step is to script the firewall change. I think that this can be done with netsh advfirewall commands, but I haven't checked.

Alternatively, I think you could use an executable launcher for Java programs, provided that it runs the java DLLs directly, rather than via javaw.exe. This is what winrun4j does. winrun4j is used by BubbleUPNPServer (in service configuration) If you use Bubble UPNPServer, you may know whether it needs firewall rules of its own - which would show that it does what you need.

You'd need to copy the appropriate version (32 or 64 bit, console or GUI) to your MinimServer directory, rename it, and put the required ini file in place. The ini file needs to know the class path to execute. There's a correct way of finding this out (with an appropriate java program), but it's probably what it says in the manifest file in mserver.jar:
Main-Class: com.minimserver.launch.LaunchServer
I don't think you'd need to know anything else, but I haven't tested this. (The option to run as a service wouldn't be appropriate here, because that assumes that the application is designed to do this.)

This also depends on Simon not changing the main class path; he has no reason to do this that I can think of, but nothing else would break if he did.

The one (tiny) advantage of using a private launcher, is that you wouldn't be giving permission for any Java program to work through the firewall, which is what we're doing at the moment.

Many thanks for suggestions.
I think I will probably just put up with this and look out for firewall prompts when they happen.
Cheers,
MS

I wrote:

(17-02-2017 01:29)skeptic Mike Wrote: [ -> ]Oracle have a rather strange way of organising Java on Windows so that you can run Java programs reasonably easily. If you run Java by starting a jar file through the file association, then you start Java in the directory in which it's installed, e.g. you actually run C:\Program Files (x86)\Java\jre1.8.0_121\bin\javaw.exe, if you start it from the command line by just typing e.g. javaw -jarfile myprogram.jar, then it starts the version in the path. Since Java 8 was released, this has been the javaw.exe file in c:\ProgramData\Oracle\Javapath, which is in the system path. Normally this makes no difference to anything, but if you have a firewall exception for any executable file such as javaw.exe, then windows uses the full path name to identify it.

As MarmiteSandwich found out, this isn't right. So, I've actually tested this on a newly install 64 bit Win 10 Pro. I installed 64bit Java Runtime using the standard Oracle off-line installer, and MinimServer using the .exe file downloaded today from the website. I ran MinimServer by the standard shortcut, and by launching explicitly using a javaw -jar command line. Then I waited for the Windows Security warning to see what firewall exception it suggested.


The results are:

Conventional launch: C:\program files\java\jre.1.8.0_121\bin\javaw.exe

via javaw -jar: C:\programdata\oracle\java\javapath_target_359687\javaw.exe

I was surprised by the last one. It turns out that the folder C:\programdata\oracle\java\javapath is a junction point, which points to the real folder C:\programdata\oracle\java\javapath_target_359687. I haven't the enthusiasm for redoing the whole thing with the previous update 101 of Java, but that version didn't create the junction point, but used symlinks in the C:\programdata\oracle\java\javapath folder to the real executables in the program files folder. Update 121 doesn't use symlinks, but copies or hard links (I don't know which, but they look the same)

So, although you can start MinimServer using javaw -jar, don't do it. It looks as though it will be more confusing than the conventional way. I did try winrun4j, as I've suggested elsewhere in this thread, and that did work as I thought it would.

Thanks for trying this and reporting the results.

If I understand correctly what winrun4j does, it works at present with MinimServer and Java 8 but it won't work with MinimServer and Java 9 because the Java 9 support in MinimServer will require MinimServer to be launched as an executable jar file.