Please release a new set of binaries on
http://sourceforge.net/projects/winrun4j/files/winrun4j/

Thanks

This is a great option but I cannot use it for 32bit systems, because if the users machine has a lot of memory it can lead to -Xmx being set to greater than 2gb causing the javaVm to fail. So I think either it should automatically prevent it being set to > 2gb for 32bit systems or we should allow setting vm.heapsize.preferred as well and this should make winrun4j use the percentage setting unless it is greater than the preferred setting, in whihc case use the preferred setting

So for the moment I can only use it for 64bit installations

"java.library.path.N" and "classpath.N" are very similar in nature but they are not treated the same in WinRun4J: "classpath.N" performs path expansion while "java.library.path.N" does not and we have to use the "%INIDIR%" workaround to get a similar behavior.

I suggest defining a [Main] section of the WinRun4J ini file. The actual name is not as important as some name being defined. This section would contain the ini entries that are currently defined without a section from "working.directory" to "ini.override".

The reason for my request is that I had an issue deploying the WinRun4J ini file using Windows Installer (Wix specifically). Windows Installer has an error "Error 2109: Section missing for INI action" when attempting to write an ini value without a section defined or empty (http://msdn.microsoft.com/en-us/library/windows/desktop/aa372835(v=vs.85).aspx). I was trying to write the WinRun4J ini file using Wix's IniFile Element (http://wix.sourceforge.net/manual-wix3/wix_xsd_inifile.htm). Wix's IniFile element is in short a wrapper around Windows Installers IniFile Table (http://msdn.microsoft.com/library/aa369282.aspx).

For this change the Ini keys may be defined like:

// Ini keys

define WORKING_DIR "Main:working.directory"

define LOG_FILE "Main:log"

define LOG_LEVEL "Main:log.level"

define CLASS_PATH "Main:classpath"

define VM_ARG "Main:vmarg"

define PROG_ARG "Main:arg"

define MAIN_CLASS "Main:main.class"

define SERVICE_CLASS "Main:service.class"

My app includes a folder with 317 jar files which are added from a subfolder with the * pattern. The new behavior is that my app does not start. Caused by several "class not found" exceptions.
Starting the app manually with java.exe and the classpath reference to the lib/* causes no problem and the app starts as expected.

Is there an issue with the extended files and foldernames and the command shell input length?

Currently, if I have DDE enabled and there are multiple users logged into a system (i.e. user switching) and both want to have an instance of our application running, they can't. Only the user who opened our application first will get an instance; the second user will get nothing.

this is the ini:
dde.enabled=true
dde.class=edu.wustl.cse.lookingglass.ide.WindowsFileHandler
single.instance=dde

However, if I change the ini to this:
dde.enabled=true
dde.class=edu.wustl.cse.lookingglass.ide.WindowsFileHandler
single.instance=window

any number of users can launch our application. However, the second ini breaks the file associations.

How can I use winrun4j to behave like the second config with multiple users and still make file associations work?

With the new 0.4.5 release, people are going to look for information on how to use the new features (or how to disable them). There are 2 major places:
http://winrun4j.sourceforge.net/
https://github.com/poidasmith/winrun4j

Both these places are not yet up to date. Also note that the first link contains the change log which stopped at 0.4.3.

I launch a non-console exe from a DOS shell, which generates errors (actually bubbling up and killing the main but I don't think this is relevant). These errors show up in the middle of other things I was doing in that shell.

If I am not mistaken, output and error streams should not be shown at all when launched from a shell using a GUI application since that application is able to show modal dialog boxes with error reporting and so on.

I tried to block the error stream with "log.level=none" but this seems to only affect events from WinRun4J itself.

How can I detect from a running program whether it is run via WinRun4j or not?

The JNI threads that call serviceRequest/serviceMain do not have a context classloader setup (i.e. Thread.currentThread().getContextClassLoader() == null). Allthough this probably isn't wrong persé, it is a situation that a lot of code out there (including Java's own SPI/ServiceLoader classes) don't account for.

I suggest you initialize the context classloader from your JNI calling code to the same contextclassloader that is used to create the service class. If that's not an option, you might want to call Thread.currentThread().setContextClassLoader(getClass().getClassLoader()) as a first thing in the serviceMain/serviceRequest of e.g. ServiceMain, AbstractService, ...

That will solve a lot of weird issues of code breaking when using winrun4j as a service, while the same code works when using winrun4j as an executable, e.g.: http://sourceforge.net/projects/winrun4j/forums/forum/693148/topic/5334049

If you're computer only has a JDK installed, WinRun4J won't detect the java installation. According to my research, the problem is related to the registry search. WinRun4J only look for java installation in HKLM\Software\JavaSoft\Java Runtime Environment. When a JDK is installed, it create registry entry Software\JavaSoft\Java Development Kit.

Step to reproduce:

1. Uninstall any JRE / JDK
2. Install only a JDK
3. Start WinRun4J.

Behavior:
4. A JVM is not found

Expected behavior:
5. WinRun4J is using the JDK.

Our old custom exes had version information and the new WinRun4J doesn't. This caused us many problems because of MSI which was not installing the new exe files during an upgrade (probably because unversioned file is considered older than versioned file).
Is there a way to set version information using RCEdit.exe? If not, could this be added?

Note that for 32 bit I found verpatch.exe:
http://www.codeproject.com/Articles/37133/Simple-Version-Resource-Tool-for-Windows
which we use with a command like:
verpatch.exe /va my.exe "1.4.0.0" /s desc myDesc /s company myCompany /pv "4.8.0.0"

I am not sure this can work with 64bit exes, and having to use different tools is not very nice if it can be avoided. The syntax of verpatch is convenient and allows to specify any string property so this could serve as a model.

Feedback requested on whether this feature should be enabled by default or not.

It would be convenient to also be able to start a service by simply calling the exe on the command line rather than having to register it and use the Windows services interface. Is it possible?

I am thinking of calling the exe directly on the command line, but if for technical reasons a no-param call cannot be done then why not a "--WinRun4J:RunService".
The service would then run until you "ctrl+C" (sending a stop or shutdown signal).

This would simplify testing real service execution (we can see out and err streams) and would allow new ways of launching the service during development as well as in production when operations do not want to allow service registration.

When a service ends using System.exit(), such as in the MainService class, the services control reports Error 1053: The service did not respond to the start or control request in a timely fashion. If I replace this with just returning from main then everything works file.

This is an issue for me because I'd like to just use my normal main entry point, as I utilise Runtime shutdown handlers to cleanup (which also run correctly, despite the service handler freaking out).

I have recently ported a standalone command line Java tool to be run as a service with others but it has a very large classpath (130+ jars) . I am getting strange results that are likely the fault of the underlying platform and code I have not been able to fix yet, but I wanted to know if there is an upper limit on the size of the classpath that can be generated for a service wrapper, in it's ini file.

Note the existing command line version runs fine using a batch file to set and clear the classpath for the module.

I am using the ini file to specify a number of jars, plus one entry that references a folder containing the large jar collection. This results in the standard out showing all classes enumerated correctly (159 lines of "Expanding Classpath: ..." then a single line showing the generated classpath to be truncated at 3995 characters.

Is this a feature of the logging, or does it show a limitation in the maximum size of the generated classpath?

Thanks for any help.

Using the windows build of winrun4j 0.4.5 I can embed an ini into the 64 bit launcher (the one without a console) using:

rcedit64 /N foo64.exe bar.ini

This works OK.

But when I use this on the 32 bit launcher:

rcedit /N foo32.exe bar.ini

The resulting launcher crashes immediately upon execution. No log file is generated.
If i do not modify the launcher (by including a foo32.ini file) or only set an icon using /I, everything works OK.

Windows 8 Pro 64-bit
Intel i7-3770

Thanks

What is the right way to find out the path to the .exe file in a Windows Service?

My constraints:

• The exe must not override the default directory.
• The JVM, class path and library path must refer to subfolders.

It seems the relative path of "classpath.1" and "vm.location" are expanded properly, but "vmarg.1=-Djava.library.path=relative\path" does not perform expansion.

Unless I am missing something, I couldn't find any other way to define the library path (like "library.1") and I did not find any way to reference the exe path which I could prepend ("vmarg.1=-Djava.library.path=%EXE_DIR%\relative\path")

On windows ; is used as the path seperator for the java.library.path, however, the current ini parser treats all ; as starting a comment so you can never have more than 1 entry in your library path.

Either there should be a method of escaping the ; to prevent a comment from being started or the library path should be specified in the same manner as the classpath ( ie java.library.path.1=...)

Please upload the WinRun4J.jar to the central Maven repository

I have a trivial console application.
It's just a test part of a larger application. I'd like to specify the "exit code" of my console app.
How do I do this?
Using System.exit(17) sets no errorlevel 17.

I am running an agent as a windows service through winrun4j. I am unable to run multiple agents. I am looking for a way where winrun4j can spawn multiple jvms and each agent run in it's own jvm and yet I want to be able to start/stop the service.

I'am looking for a possibility to override values via a commandline, which are set or not set in the inifile.

Consider the following usecase:

Usually i omit setting the ini value 'vm.location=' and let winrun4j detect the suitable vm. This works fine.

In some situations my users would like to set 'vm.location=' to a dedicated location (or even another key to another value). They have to preprocess and modify
the ini file. But thats no solution.

My approach would be to introduce something like
--WinRun4J:SetIniParam::vm.location=C:\whatever

Are there better solutions than patching WinRun4J.cpp ?

When loading native library for JNI, the DLL required to be in search path. Whould be nice to privode a way to override the PATH environment variable.

e.g.: PATH='../my_path/lib/;%PATH%'

Otherwise, a batch script is required.

Need to add a signal hook on VM creation to detect a System.exit from java code. On exit call the service control manager.

I.e. when doing something like:

working.directory=../..
ini.override=true
ini.file.location=settings.ini

This settings.ini will be resolved from the working directory during service registration (--WinRun4J:RegisterService). But when actually starting the service, the settings.ini file won't be found/loaded. The only way to make ini.file.location work consistently (i.e. same settings loaded during registration and starting of service) seems to set an absolute path.

(On a sidenote: an invalid ini.file.location will not result in any messages. That might be by design, but for debugging purposes it would be nice if there was at least an info message that the ini.file.location was not found.)

In Native.java, you check for "amd64" and that is then 64 bit. It would be better to replace this line with:

   public static final boolean IS_64 = System.getProperty("os.arch").contains("64");

The OSGi maintains a list of all seen processors. See http://www.osgi.org/Specifications/Reference

I am having this really weird issue. My code needs to read a value from the registry (from under the Software\Microsoft\Windows\CurrentVersion\Run key).
When I launch the code via Eclipse or simply as java -jar my.jar, everything works fine. As soon as I try to launch the code via WinRun4j, the value is always reported as missing.

I have tried three different registry access libraries (JNA, WinRun4j-own and some strange Properties-based class you can find on stackoverflow), and all behave consistently. Run with java - get your value. Launch under WinRun4j - pretend the value is not there.

What could WinRun4j do to prevent registry access this way?

I'm using Windows7, Java 1.6.0_21, latest WinRun4j.

The last lines in my .ini files did not have a trailing end of line characters. When the ini's were loaded in to the console exe (with rcedit /n) the resulting exes would just crash. After playing around for a while and determined that it was the lack of end of line characters on the last line, I updated all my ini's and they seem to

Request 954232 is closed and stated that embedding xp theme manifest is possible in version 0.4.2 using -m option:
https://sourceforge.net/tracker/?func=detail&aid=3001911&group_id=195634&atid=954232

It seems that there is still problems with embedding. I used -m option to add SWT 64 .exe.manifest resource into my amd64 manifest file. Now I'm facing this error:
The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.

Usually windows doesn't allow unicode on the commandline. However if the program is assigned to a file type, if you double click one of those file, the path passed to the program allows unicode parts.

Can WinRun4J support passing of unicode command line parameters to java programs?

When I run the exe, I see this in the console:
[info] Registering natives for Native class
[warn] Could not find Native class

I found that between the info and warn message I have to wait for about 2 seconds. Since I don't seem to need the Native class, is there a way to switch this lookup off in the ini file to not lose those 2 seconds and avoid this log warning?

Having a no-arg constructor for the service class makes sense. That being said, we lost several hours trying to understand why a service would not start. The reason was that the class had some parameters to its constructor and there as no other no-arg constructor.

It would be very helpful that if the service class does not have a no-arg constructor an error be added to the log.

I have a service that takes longer than the default 30 seconds to shutdown. From http://bytes.com/topic/c-sharp/answers/274008-service-stop-timeout-setting it looks like you can send SetServiceStatus(...) (http://msdn.microsoft.com/en-us/library/windows/desktop/ms686241(v=vs.85).aspx) with a value of SERVICE_STOP_PENDING to reset the 30 second counter.

I have only the JDK installed, not the JRE. In my environment, I have set the JAVA_HOME to point to the root of the JDK installation directory:
c:\Program Files\Java\jdk1.7.0

The java bin directory is also in my path:
c:\Program Files\Java\jdk1.7.0\bin\

Other java launchers don't seem to have any issues location and running java , maybe because they use java.exe instead of jvm DLL.

The current/working directory should default to the location of the INI/exe file for services.

I am using the pre-compiled binaries for version 0.42 - I dont have the capability to build my own with the current source.

I seems that any single character argument has a space prefixed on the front. I have a number of console based apps that take numeric argumentss (e.g. number of threads) as well as other single character arguments, and I am getting problems on these if I just try to parse without trimming first. As a test, I am using the Java code:

package winrun4jtest;

public class WinRun4JTest
{
    public static void main(String[] args)
    {
        for (String arg : args)
        {
            System.out.println("." + arg + ".");
        }
    }

    private WinRun4JTest()
    {
    }
}

When I run it within a Winrun4j console exe, with command line arguments of:

a b c ab 1 11

I get the following results:
.a.
. b.
. c.
.ab.
. 1.
.11.

All single character arguments have a space on the front.

This may be related to the other issues relating to parsing, and may already be fixed. If so, are you planning to do a binary release soon?

Thanks,
Mike

Currently, it seems we can only specify the class path and main class combination.

In my case, I have an executable JAR file with a classpath defining all the dependencies (about 100 JAR files). Thus, my INI is:
classpath.1=MyExecutableJar.jar
main.class=com.xx.xx.Main

It would be simpler and more refactoring-friendly to be able to define something like:
classpath=MyExecutableJar.jar

ini files which are embedded using the /N option are truncated at byte 1024.

You can reproduce this issue by creating an ini file with many classpath entries (make sure the classpath entries break the 1024 byte mark). Embed the ini file using the /N option. Now launch your program... notice that the info messages you should see a classpath entry that is halfway complete... for example this should read "lib/tools.jar"

[info] Expanding Classpath: lib/too

This will result in your application failing to have a complete classpath, and therefore should crash.

You can workaround this issue by not embedding your ini file. ini files located at the same location as the exe works fine!

What is the status of/plans for Excel 2007 support?

My understanding is that the SDK has changed to support addressing larger worksheets. XLW version 3.0 included a number of changes to accomodate this (http://xlw.sourceforge.net/refman/a00007.html)

-jason

It seems that using environment variables in override ini files doesn't work. E.g. I can use

log=%MYDIR%\logs\log.log

in the embedded ini file, but if I use the same setting in the override ini it doesn't work. If I use a full path without environment variable there, that does work.

Hello,

I obtain a NoClassDefFoundError "IllegalName" with Winrun4j 0.4.5.
Please find below, the whole draft configuration.

Regards,
Guillaume

TEST.ini:

working.directory=.
main.class=com.Test
vm.heapsize.preferred=512
single.instance=process
process.priority=above_normal
vmarg.1=-XX:+UseConcMarkSweepGC
vmarg.2=-XX:+CMSClassUnloadingEnabled
vmarg.3=-XX:+CMSPermGenSweepingEnabled
vm.version.min=1.6.0_43
vm.version.max=1.6.0_45

Linkage:

RCEDIT64.exe /C TEST64.exe
RCEDIT64.exe /N TEST64.exe TEST.ini
RCEDIT64.exe /I TEST64.exe TEST.ico
RCEDIT64.exe /J TEST64.exe test.jar

• The test.jar contains a main class: com/Test.class

Output:

C:\Program Files\Test>TEST64.exe
C:\Program Files\Test>[info] Module Name: C:\Program Files\Test\TEST64.exe
[info] Module INI: C:\Program Files\Test\TEST64.ini
[info] Module Dir: C:\Program Files\Test
[info] INI Dir: C:\Program Files\Test
[info] Working directory set to: C:\Program Files\Test
[info] Configured vm.location: (null)
[info] Found VM: C:\Program Files\Java\jre6\bin\server\jvm.dll
[info] Generated Classpath:
[info] VM Args:
[info] vmarg.0=-XX:+UseConcMarkSweepGC
[info] vmarg.1=-XX:+CMSClassUnloadingEnabled
[info] vmarg.2=-XX:+CMSPermGenSweepingEnabled
[info] vmarg.3=-Djava.class.path=
[info] vmarg.4=-Xmx512m
[info] Registering natives for Native class
[warn] Could not find Native class
[err] Could not find or initialize main class
java.lang.NoClassDefFoundError: IllegalName: com/Test
at java.lang.ClassLoader.preDefineClass(Unknown Source)
at java.lang.ClassLoader.defineClassCond(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at org.boris.winrun4j.classloader.EmbeddedClassLoader.findClass(Embedded
ClassLoader.java:98)

Hi,
I am trying hands on winrun4j 64 bit wrapper for my java service. Facing a couple of issues -

1. Have a .properties file in the same folder where .ini / .exe and .jar files are placed. But I am not able to read properties file.
   .ini file -

service.class=com.datamigration.services.AggDataProducerService
service.id=AggDataProducer
service.name=AggregationDataProducer
service.description=Dumps customers data

classpath.1=*.jar
working.directory=.
vmarg.1=-Xdebug
vmarg.2=-Xnoagent
vmarg.3=-Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n

2. able to register the service but once it starts, the behavior is unpredictable.
3. I am unable to stop the service nor can I unregister it (goes in disabled state)

Is there any chance that WinRun4J could be dual-licensed under a more popular commercial-friendly license such as BSD, Apache, or MIT? The CPL is uncommon outside of the Eclipse ecosystem.

Will you be updating the plug-in soon? Can't use the export feature in Juno (Java 7 & Win 7), though the run-as does, The generated .exe file size is the same as that of the WinRun4J.exe in the launcher folder.

Thanks in advance

After cloning the Git repo and opening the solution in Visual Studio, what is the preferred/recommended way of configuring the location of "jni.h"? Is there a variable somewhere?
Any other advice?

I could not find any mechanism to pass VM parameters at the time of calling the exe (rather than adding it to an ini file).

Generally, VM launchers support adding/overriding VM parameters using a magic prefix, for example: -J-Dmysysprop=xxx -J-Xmx1024m

If there is no such feature already, maybe you should consider adding it to WinRun4J. The ini could have a key that tells which prefix to use, and when set would activate that VM parameter handling.
For example, if I want my prefix to be "--vmarg:", I could specify:
vmparam.prefix=--vmarg:

A Service (with your Service-EXE) registered in Windows, which is configured to restart if an error happens, does not restart. I am using the current Version 0.4.5.

I tried it in different ways in the serviceMain-Method:

1. returning a result smaller or bigger than zero
2. System.exit(1)
3. Throwing a ServiceException

None of the above worked.
But I do know that at one point it worked. So I tried to find the version of WinRun4J, which allowed the service to restart.

The Version 0.4.2 did work. I only tried it with System.exit(1) in that Version, so I don't know what else would work.

It would be nice, if you could find out why it doesn't work anymore and fix the issue.

Thank you.

The website says: "Any JARs added to the executable will automatically be added to the classpath"

I have a service that obviously implements the Service class from WinRun4J. I tried to add the "WinRun4J.jar" file to the exe but then the service fails to start.

Listing the content of my exe:
RCEDIT.exe /L xxx.exe
Icon 0001
Icon 0002
Icon 0003
Icon 0004
Icon 0005
Group Icon 0001
INI File
JAR File WinRun4J.jar

Note that if the JAR is outside the exe and specified in the classpath, then the service does start.