The last binary for Windows was beta1 in 2015. Sure I could setup a build environment, but I doubt most Windows users of Icecast build their own Icecast server (myself included).
A windows binary was also desired by Rick Keniuk on the mailing list.
win32 is not a prime port of Icecast. Creating a proper build consumes quite a lot of time. That's why I didn't bother.
There is considerable work to be done for it to reach a presentable state. We can consider this, if someone from outside the core team is willing to commit time to actually help solve issues like:
proper log storage location (last few times I tried it failed to log as it wanted to write to the program directory)
It is a lot harder to create a MSI than a NSIS installer, unless you have an actual Windows machine to create it. And even then the format is really complex and hard to understand.
proper log storage location (last few times I tried it failed to log as it wanted to write to the program directory)
There are Windows APIs to get the Documents folder or the local folder and so on. Once this is dome properly this should be consistent. Windows 10/8/8.1 does have different APIs than Windows 7/Vista/XP/2K. Question is how old a Windows do you wish to support?
Using feature detection (load dll, check if the function is there) it's relatively trivial to support Windows 7 API and Windows 10 API. My suggestion would be x86 Windows 7 for "legacy" and x64 Windows 10 for current, that way there are only two Windows builds to worry about.
windows service setup, native
This can be a bit finicky, the API is simple enough. But making sure one remembers to check system messages about powerdowns (due to patching or restarts) and such can be annoying to get right. Been a while since I've done a service so I don't know if you can do admin (system) or usermode services (starting with Vista and later).
documentation
A tiny .txt file or section under "install" in the manual is probably fine for a beta.
possibly reworking the installer from NSIS to MSI
I'd advise against that.
Heck a installer may not be needed at all. For a beta a zip (or 7zip) is probably fine, have it extract as a Icecast2.5b2 folder.
Should be enough to test, if anybody are crazy enough to use a beta as a service they can use service tools (many free or open source too) that let you run (almost) any program as a service.
Unpacking into a folder also solves the log issue temporarily as the user obviously has full write permissions there.
A proper Icecast 2.5 for Windows could probably wait until after the release of Icecast 2.5 final based on the amount of interest (downloads, feedback). You never know, someone just might want to run Icecast on Microsoft Azure or a Amazon virtual Windows OS on a cloud host or something.
Although hobbyists and small stations are more likely to want a Icecast for Windows though.
As far as I'm concerned, as long as it runs when clicking the .exe (and a proper config obviously) without crashing then that's good enough for a beta in my eyes.
But if it's a lot of work/time to setup the compiler to a x86 or x64 Windows build I do understand if you don't want to do it, just would be nice that's all.
I first need to take care of the 2.4.4 release, including win32. Then I can look into this too.
Yes, I know there are APIs and such, but we would need to get things working properly to consider a 2.5 final release for win32 that we wouldn't have to be ashamed of. One thing I'd be curious to know and you could help exploring would be if the "%magic%" windows paths already work when used in the config file. Specifically local app-data. Creating the necessary directories in local-appdata would then be needed to add to the installer.
Do you mean the nsis script?
Looking at that I see you use HKCU (current user registry) which is fine.
But you do use RequestExecutionLevel admin
This should be RequestExecutionLevel user
This will mean that a admin has to run the installer manually as elevated, but for a normal user (or admin that do not wish/need to install it as a admin) can then install it without the elevation prompt.
This also eliminates the issue with writing to the Icecast program folder as the user has access to the Icecast folder.
If you mean some other config script I can't find any magic paths, you'd need to point me to the right source file.
I'd advise against making folders in local appdata from the install script, this is better done from Icecast itself. Minimize the script to basically just extract and copy the files to the right place, and when uninstalling just delete the same.
Attached is the NSIS 3 script I use for a program I maintain. It uses a custom version touch tool that creates a version file that is included (so that the installer exe file has the proper version number). In the case of Icecast this can be done by the existing build system instead. Other than that the programid and other info needs to be changed, the rest should require minimal to no edits. The programid is used for a mutex, which is not needed for Icecast I assume.
I've attached the NSIS 3 script, consider it under CC0 license, use/steal the parts that are of interest.Example_Installer.nsi
Looking at Icecast 2.4.3 I see the install is very simple, the default config is in the icecast folder. If a usermode install is done there should be no issues. Adapting my script should not be that difficult. I could convert my script and base it on the 2.4.3 install (which uses NSIS 2 ?), let me know if this is of interest.