Just to make sure that this work does not fall through the cracks. The last update while useable, could do with some additional changes - Two patches, one updates the nsis script itself, the other updates how the main makefile passes information to it: http://www.ghostscript.com/~hintak/patchset/gs-patches/0018-Passing-zip-name-and-gs-version-to-nsis-to-name-the-.patch http://www.ghostscript.com/~hintak/patchset/gs-patches/0019-Many-enhancements-to-the-nsis-script.patch The main changes are: --------------------- Passing zipfile name and gs version to nsis to name the output file and also some internal information of the installer, rather than requiring some separate manual editing of the file name and gs version. The script itself has been updated with the usual artifex copyright boiler plate, some 64-bit related changes and auto-detection from the "zip name" passed in from the main makefile, some comments documenting notable differences with the winzipse-base installer, safer uninstall, and some general re-indentation for readability.
Ray said he was going to try the 64-bit windows installer so it is probably appropriate for him to take this on. BTW, Patch #21 http://www.ghostscript.com/~hintak/patchset/gs-patches/0021-The-zip-target-should-depends-on-some-the-files-to-b.patch (The zip target should depend on the files being zipp'ed) make it possible to do "make -f psi/msvc32.mak zip" (and the archive target, which depends on the zip target) without doing "make -f psi/msvc32.mak" first to build the windows binaries. It might be useful before the 9.0 release. It is a convenient thing to have anyway.
Just uploaded patch #23: http://www.ghostscript.com/~hintak/patchset/gs-patches/0023-implement-start-menu-folder-selection-not-sure-about.patch Patch #23 is to be applied on top of #19 to make start-menu creation both optional and location user-configurable.and http://www.ghostscript.com/~hintak/r11640/ has been built with that.
Patch 24, 25 and new binaries: http://www.ghostscript.com/~hintak/patchset/gs-patches/0024-moving-cjk-to-the-finish-menu.patch http://www.ghostscript.com/~hintak/patchset/gs-patches/0025-no-need-to-copy-and-del-if-use-NOCD-option.patch http://www.ghostscript.com/~hintak/r11657/ Patch 24 rearranges the user option for start menu before the file copying (feels more "natural" that way), and have the CJK font cidfmap generation as a checkbox in the finish page rather than a pop-up message box; also it optionally launches doc\Readme.htm in IE at the end, if the user so chooses. Patch 25 simplifies the makefile slightly and the corresponding comments in the script about how it should be run. Patch 18,19,21,23,24,25. One of the user options - whether to have the start menu addition for "user" or for "all" - in the winzipse-based installer is not going to be implemented. I don't see the value of it, also, it is the reason why the winzipse-based installer does not clean those up on uninstall (which the nsis-installer does). Any chance of somebody trying the 64-bit windows installer yet?
I have uploaded another set of builds: http://www.ghostscript.com/~hintak/r11747/ There is a small cosmetic change (would be patch #26?). A combined patch is probably in order, when I get round to do it. BTW, the official 9.00 64-bit windows release seems to be both incomplete and a bit of a hack: it consists of only the dll's and export libraries (without the executables and documentation) as well as having them named *64.{dll,lib,exp} rather than the legacy-but-wrong *32.*. The build system has not been updated to do the renaming, so it seems to be renamed by hand (and the omission of *.exe to hide that?)? Anyhow, congrats on the long-awaited new release.
Thanks for the updates to the nsis files. Now that 9.00 is out, I will be having a look at all of this and get it working properly, with other fixes/ changes to the 32-bit and 64-bit build/install process on Windows. The renaming of the 64-bit build files to gsdll64.* was intentional, but we did do that 'manually' by doing a build with WIN64=1 on the nmake command line, which generated the 64-bit executables and DLL as gswin32*.exe and gsdll32.* The decision to not distribute the gswin64*.exe files was also intentional to discourage use of the 64-bit version. Artifex has tested the 64-bit version of Ghostscript and while it passes all of our QA testing, it runs slower on Windows than the 32-bit binary. Note that the 32-bit binary will support file I/O for files larger than 2Gb using the Windows 64-bit file I/O calls. The 64-bit DLL is provided as a convenience for our users that need to link Ghostscript with their own 64-bit application. Also note that the 64-bit DLL is now named gsdll64.dll to avoid confusion with the 32-bit gsdll32.dll so that both can exist in the same path (e.g. bin). We recommend using the 32-bit Ghostscript whenever possible.
Patch 26: http://www.ghostscript.com/~hintak/patchset/gs-patches/0026-remove-remove-only.patch It affects only the uninstaller and also only has effect only on some version of windows. This uninstaller does not allow "repair" or "modify", and this change simply make it obvious to the user - where the window version supports it - by not offering the repair/modify option when unistall. Yes, even on x86-64 linux, it is known that many 32-bit apps runs better than their 64-bit counterpart, and it is my experience (about 10% speed) as well, possibly just from memory latency. However, many still prefer to run a "pure" 64-bit system despite the small penalty, for e.g. 32-bit versions of system libraries need to be loaded (consuming memory) and present (consuming disk space). This is probably less true for the wow64 sub-system of 64-bit windows, but I am just presenting one possible reason why somebody might prefer to run a pure 64-bit system. (I think wow64 is also optional for 64-bit windows, but very few windows user choose not to install it). Anyhow, naming the dll' as *64.* is the proper way to go forward.
I've reviewed and included most of Hintak's changes for nsis (still a couple do to), so I'll take this enhancement on (for now at least). I did forget to credit Hintak in the commit message (sorry!) but I correct that omission in the repository.
(In reply to comment #7) Thanks - much appreciated. I noticed that Ray has done some 32/62-bit windows related changes recently, so some additional adjustment might be needed - hopefully not much.
Hopefully the final piece of the puzzle to get equivalent functionality between the old installer and the nsis one is in place - revision 12375. It was a problem with, I think, filenameforall (used in mkcidfm.ps) not liking the path to the Windows font directory using the Windows style back slash directory delimiters. The nsis script now replaces those back slashes with forward slashes, and it works. The remaining enhancement I'd like is to make the Start Menu shortcuts optional. Hin-Tak, your suggested method of doing that works, but breaks the uninstaller (it can't remove the Start Menu short cuts, if you opt to have them, for some reason). More investigation needed on that one...... at some point.
(In reply to comment #9) > The remaining enhancement I'd like is to make the Start Menu shortcuts > optional. > > Hin-Tak, your suggested method of doing that works, but breaks the uninstaller > (it can't remove the Start Menu short cuts, if you opt to have them, for some > reason). > > More investigation needed on that one...... at some point. Start Menu shortcuts is a tricky business - they can be installed 'for everybody' (the shellcontext variable thing) or for the current user, and likewise needed to be uninstalled the same way. I think the only sensible way to do it is to install for 'all users' (and likewise uninstalled from 'all users'), otherwise you need to keep track of which user had the short cut. I thought I did have the uninstall working at some point? Russell's installer/uninstaller never tries to clean up start up menu's on uninstall, so whatever you can do, is an improvement :-).
(In reply to comment #10) > > Start Menu shortcuts is a tricky business - they can be installed 'for > everybody' (the shellcontext variable thing) or for the current user, and > likewise needed to be uninstalled the same way. I think the only sensible way > to do it is to install for 'all users' (and likewise uninstalled from 'all > users'), otherwise you need to keep track of which user had the short cut. > > I thought I did have the uninstall working at some point? > > Russell's installer/uninstaller never tries to clean up start up menu's on > uninstall, so whatever you can do, is an improvement :-). The changes you suggested for this included updating the uninstall's deletion of the Start Menu links, but for some reason it just didn't appear to work for me. As it's just my own prejudice that makes me want it, and it is strictly against the MS UI guidelines, I didn't investigate further - I felt it was more important to get at the least the same capabilities as the zip-based installer before worrying about enhancements! I'll poke at it some more before the next "proper" release.
The issues with the start menu uninstall are long resolved. I feel this bug is just stale, now, so I'm closing it.