github
/
winsw
mirror of https://github.com/winsw/winsw
1
0
Fork 0
Code Issues Releases Wiki Activity

Make the document less personalized

pull/129/head
Oleg Nenashev 2016-11-26 01:19:05 +03:00
parent 4ec9984c1f
commit b60756b8c5
4 changed files with 14 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
README.md
View File

@ -2,18 +2,19 @@ winsw: Windows service wrapper in less restrictive license
=========================
### Why?
<!--TODO: I => something-->
Now, I think the first question that people would ask is, why another, when there's [Java Service Wrapper project](http://wrapper.tanukisoftware.org/doc/english/download.jsp) already available.
Here is a cite from [Kohsuke Kawaguchi](https://github.com/kohsuke/), who is the original author of this project:
> Now, I think the first question that people would ask is, why another, when there's [Java Service Wrapper project](http://wrapper.tanukisoftware.org/doc/english/download.jsp) already available.
The main reason for writing my own was the license — Java Service Wrapper project is in GPL (so that they can sell their commercial version in a different license), and that made it difficult for [Jenkins](http://jenkins-ci.org/) (which is under the MIT license) to use it.
Functionality-wise, there's really not much that's worth noting; the problem of wrapping a process as a Windows service is so well defined that there aren't really any room for substantial innovation.
> Functionality-wise, there's really not much that's worth noting; the problem of wrapping a process as a Windows service is so well defined that there aren't really any room for substantial innovation.
You basically write a configuration file specifying how you'd like your process to be launched, and we provide programmatic means to install/uninstall/start/stop services.
Another notable difference is that winsw can host any executable, whereas Java Service Wrapper can only host Java apps.
<!--TODO: I-->
Whether you like this or not depends on your taste, so I wouldn't claim mine is better.
It's just different.
As the name implies, this is for Windows only.
> As the name implies, this is for Windows only.
Unix systems have their own conventions for daemons, so a good behaving Unix daemon should just be using `launchd/upstart/SMF/etc`, instead of custom service wrapper.
### Download

3
doc/deferredFileOperations.md
View File

@ -13,8 +13,7 @@ To perform file operations, write a text file (in the UTF-8 encoding) at `myapp.
The success or failure of these operations will be recorded in the event log.
Note that it is apparently possible to [rename executables even when it's running](http://superuser.com/questions/488127/why-can-i-rename-a-running-executable-but-not-delete-it), which makes sense if you think about file handles.
<!--TODO: fix "I"-->
I have failed to find any authoritative source of information about this, but experimentally this even works on Windows XP and presumably on all the later Windows versions.
Kohsuke has failed to find any authoritative source of information about this, but experimentally this even works on Windows XP and presumably on all the later Windows versions.
This behavior can be used to update `winsw.exe` itself.
Also see `WINSW_EXECUTABLE` environment variable.

5
doc/installation.md
View File

@ -91,10 +91,9 @@ One way to deal with this is to ensure that `.NET 2.0` runtime is installed thro
</configuration>
```
The way the runtime finds this file is by naming convention, so don't forget to rename a file based on your actual executable name.
The way the runtime finds this file is by naming convention, so don't forget to rename a file based on your actual executable name (e.g. `myapp.exe`).
See [this post](http://www.davidmoore.info/2010/12/17/running-net-2-runtime-applications-under-the-net-4-runtime/) for more about this.
<!--TODO: Modify the text-->
To our knowledge, none of the other flags are needed.
None of the other flags are needed.
#### WinSW Offline mode and Authenticode

7
doc/xmlConfigFile.md
View File

@ -35,9 +35,8 @@ Since this is an environment variable by itself, this value can be also accessed
### id
Specifies the ID that Windows uses internally to identify the service.
<!--TODO: "have not verified" is confusing-->
This has to be unique among all the services installed in a system,
and (while I haven't verified this) this must consist entirely out of alpha-numeric characters.
and it should consist entirely out of alpha-numeric characters.
### name
Short display name of the service, which can contain spaces and other characters.
@ -205,13 +204,17 @@ If set to `true`, will automatically set the "Allow Log On As A Service" right t
Some services need to run with a working directory specified.
To do this, specify a `<workingdirectory>` element like this:
```
<workingdirectory>C:\application</workingdirectory>
```
### priority
Optionally specify the scheduling priority of the service process (equivalent of Unix nice)
Possible values are `idle`, `belownormal`, `normal`, `abovenormal`, `high`, `realtime` (case insensitive.)
```
<priority>idle</priority>
```
Specifying a priority higher than normal has unintended consequences.
See the MSDN article [ProcessPriorityClass Enumeration](http://msdn.microsoft.com/en-us/library/system.diagnostics.processpriorityclass%28v=vs.110%29.aspx) for details.