package for Windows

[efa]

hi, I want try to create a package for Windows, with all the dependancies. Is not much difficult using the very old version from Cygwin, but I want to generate your version.

At first I want try native compile using MSYS2, then try to crosscompile using MXE. Some one has already tryed to do that? In case, any hints? thank you

[efa]

just a note: Solaris make support Bourne shell if syntax: https://docs.oracle.com/cd/E19253-01/816-5165/6mbb0m9l0/index.html

[unixwork]

The problem is, all make implementations have a different syntax for conditionals. I have used implementation specific features in the platform specific makefiles, but not in the main Makefile.

I think the ultimate goal for cygwin/Windows should be to provide a simple binary installation package (.msi or .exe).

[efa]

good as you done as now. Thinking well, maybe the call to 'xnedit_pkg' is better in a named 'dist-bin' target like 'dist-cygwin' instead of 'install-cygwin', not sure, maybe dist-* is the setup.exe on Windows platform?

About a binary installation package for Windows, as now the 'resources/cygwin/xnedit.nsi' con be "compiled" by NSIS in a 'setup.exe' and I tested it on Win10 64 bit and work installation, create start menù entry, Send To menù, and de-installation link.

Do you accept a PR for the binary blob in a 'bin' sub directory generated for tag v1.3.3 ?

[unixwork]

Not a big fan of binary packages in the repository.

I would also prefer a dist-cygwin (currently the target is named cygwin-install), because that would allow people to make a normal installation in a cygwin environment with make install (just putting the binaries in the cygwin bin directory).

My plan is to provide binary packages with the next minor release v1.4 (sometime in September or October). Until then we can decide how to transfer the files. I could also create the install package myself.

Btw, the project is also on Sourceforge, where I also want to publish the binary files.

[efa]

understood.

Give it a try or generate by NSIS yourself: XNEdit1.3.3win64_setup.exe.zip

I only changed 'xnedit.nsi' as so:

- OutFile "XNEdit1.3.2win_setup.exe"
+ OutFile "XNEdit1.3.3win64_setup.exe"

on a next version I will add auto version name getting the XNEdit version from sources. From 'help_data.h:5806' I think

[efa]

done with: https://github.com/unixwork/xnedit/pull/52 the XNedit version is used as prefix in the name of setup.exe file

Note: The content of the generated setup.exe(.zip) remain identical

[efa]

As now 'xnedit_pkg' support both 64 and 32 bit Cygwin, but .nsi file is for 64 bit only. Here on holiday I have no Cygwin @32bit, when back home I will add some little modifications to generate also an NSIS package at 32 bit.

[efa]

done in: https://github.com/unixwork/xnedit/pull/53

[efa]

here the two new '*_setup.exe' zipped files: XNEdit1.3.3win64_setup.exe.zip XNEdit1.3.3win32_setup.exe.zip

[efa]

I found an old WinXP 32-bit installation in VirtualBox, then updated Cygwin to a current (unofficial) repository. There installed dependencies and try a build of current git and work. xnedit_pkg required some little fix to support XP and that old Cygwin version too, follow a PR. To create the setup.exe I had to install NSIS 3.07 that support Unicode, and work.

[efa]

done in https://github.com/unixwork/xnedit/pull/60

[efa]

about WinXP, we should not consider supporting it a must, but a nice to have.

script installation in: C:\Program Files\xnedit_32bit left directory and file permission set (Posix mode) as unwanted by Windows, as Cygwin do also outside its hierarchy, and WinXP miss: icacls /reset and takeown that was added from Vista, to fix that. So XNEdit do not start by double click (file acces error), I had to use the command.com as in the attached image.

As now the only solution I found to fix file permissions on WinXP is to use: subinacl and cscript XCACLS.vbs but those are not part of WinXP and license probably is not compatible with GPL, so users has to do themself. Maybe I will find a solution to set Windows file permissions by Cygwin tools only.

Fortunately the NSIS setup.exe package install file correctly and work by GUI too.

[efa]

OT: on that old Cygwin 2.5/WinXP, I tested also the packaged Nedit: 5.5-6 work 5.6-1 give always error:

$ nedit
NEdit: Converting .nedit file to 5.6 version.
    To keep, use Preferences -> Save Defaults
Segmentation fault (core dumped)

do you have an idea of how to solve that? thank you

[unixwork]

do you have an idea of how to solve that? thank you

No, I don't know where it crashes. Does this also happen, when you don't have any existing config files?

[efa]

Does this also happen, when you don't have any existing config files?

yes, it happen also without .nedit directory before start it, stack dump after it has created .nedit and left empty. Happer also with a .nedit/nedit.rc copyed from my linux home that has 5.7

[efa]

I had tested Cygnal (substitute Cygwin DLL), executable may work well, but got a lot of incompatibility with the bash script. So as now remain so, maybe I will update 'xnc.sh' to support both DLL.

Cygnal should have the advantage of stripping out the /cygdrive/c from the file path, so Windows users will see something like: C:\path which they should be accustomed to

[efa]

maybe you can add Cygwin to the list of 'Available configurations' in README.md ?

[unixwork]

Yes, I forgot that. It is now listed in the readme file.

[efa]

I found a trouble with Cygwin version, similar to the one we spoke on July 9. I cannot input non ASCII chars in Search&Replace dialog, while work for main editor. This happen both inside Cygwin and with XNEdit packaged via xnedit_pkg and NSIS.

[efa]

Here the characters that works with Italian keyboard:

\1234567890'
   qwertyuiop+
asdfghjkl
<zxcvbnm,.-

SHIFTed: |!"$%&/()=?^
QWERTYUIOP*{}
ASDFGHJKL
>ZXCVBNM;:_

so miss at least:
£ìèéçò°ù§€
and other AltGr[+shift] sequences

[unixwork]

Try to compile with -DXNE_TEXTFIELD added to the cflags. This replaces the motif textfield in the Search/Replace dialogs with a custom textfield, that fixes some input problems and also has better unicode support.

[efa]

work well.

Will add a PR for adding the option in xnedit/makefiles/Makefile.cygwin

[efa]

done, on Cygwin it is necessary that option:

https://github.com/unixwork/xnedit/pull/82

[efa]

I'm facing a new issue on Windows. It happen on both native Nedit 5.6 in Cygwin and XNedit 1.4 compiled in Cygwin, so I'm quite sure is related to an update in cygwin DLL (or the X server I'm using), but mybe you can help me before open a ticket on unresponsive cygwin (on Xming) list.

For clipboard compatibility between Xserver and WinClipboard, on Cygwin is used to call: nedit.rc: clip = remove_cr(shell_command("getclip", ""))\n\ where remove_cr() is defined in "~/.nedit/cygspecial.nm" and getclip() seems a Cygwin provided function.

From some days, when I do paste in Nedit and XNEdit I got this error:

/bin/bash: getclip: command not found

I tryed to change the X server from Xming to VcXsrv and native CygwinX, but same result. So everything lead to a Cygwin update I recently do.

Do you know something about getclip() ?

thank you in advance

UPDATE: solved, getclip was moved to optional package "cygutils-extra", installing that solve the issue. I have to update the package script to include the external binary, or maybe switch to use /dev/clipboard that is the new suggested method to access xclip

[unixwork]

shell_command("getclip", "") looks like an external program getclip is called, which doesn't exist anymore (or is not in PATH). I haven't found any program with that name in my older cygwin installation.

Do you really need a workaround for the clipboard? I think with VcXsrv the clipboard works out of the box.

[efa]

no, I'm not sure. This was necessary with Nedit5.6+Xming and old Cygwin not supporting UTF-8, but I had to make some test on XNEdit and other Xservers on new Cygwin supporting clipbord with UTF-8. Will do.

[unixwork]

The current windows installer package has one problem, it uses C:\Program Files\xnedit\.xnedit as xnedit config directory for all users. Also the directory is by default not writable by normal users, therefore in XNEdit Preferences -> Save Defaults doesn't work.

I think XNEDIT_HOME should point to $HOME/.xnedit or maybe $HOME/AppData/local/xnedit. The xnc.sh script should check if the directory exists and copy the necessary .nm files, if needed.

[efa]

as soon as I have some time I'll fix it, thanks for the test

[efa]

I looked into this. I have HOME defined to "C:\Users\username" and "HOMEPATH=\Users\username", but I have Cygwin and minGW/MSYS2 installed, I'm not completely sure in a standard Windows installation all users have HOME env var defined, maybe it is something from "unix" world. And as now 'xnc.sh" depend on $HOME, if HOME is not defined, use $USERPROFILE so "C:\Users\username". We need another tester

Looking to Win env vars, I see: USERPROFILE=C:\Users\username APPDATA=C:\Users\username\AppData\Roaming LOCALAPPDATA=C:\Users\username\AppData\Local the first one is used by many unix application to store configurations. The second one when logging via domain auth, the last one for other cases.

I just checked Windows can create and rename directory starting with a dot, so will go for .xnedit instead of xnedit

So using %USERPROFILE%\.xnedit (or %LOCALAPPDATA%\.xnedit) in Windows and $USERPROFILE\.xnedit (or $LOCALAPPDATA/.xnedit) in Cygwin should point to the right place.

[efa]

done in https://github.com/unixwork/xnedit/pull/120

[efa]

but shouldn't I be listed among other XNEdit contributors in about dialog?

[unixwork]

You are absolutely right. I've added your name to the contributions list.