(i personally think that pspad on windows may be much stronger than a lot of these editors considering the install size / functionality trade off).
edit: also a nano-2.2.6 build is available at the bottom.
i wanted to try nano for win32, so basically i went to http://www.nano-editor.org/download.php and i've downloaded the latest windows build 'nano-2.2.6.zip'.
running it however spat out a nasty message 'redirection is not supported'. after some investigation (installing / compiling / running / disassembling / testing stuff and sending emails...) i've put together a older version package of nano - 2.2.5 that runs ok on my system.
here is a fuller story in the README.txt:
this is the gnu-nano-2.2.5 from cygwin (dll 1.7.7-1), stripped down with just
the cygwin terminal information and the basic needed dlls.
the reason that i created this package is that on my desktop pc running
windows xp sp2 i've got the message "redirection is not supported" and the
program did not work.
some disassembly debug on the included dll / exe's in the official
package revealed that the message is related to cygwin1.dll.
i've installed the latest cygwin, got the pdcurses for windows and compiled
them. unlike compiling pdcurses with mingw, with the gcc-cygwin i've got
"redirection is not supported" for all new test executables - which ment
that something is wrong with cygwin/pdcurses, but not exactly sure what
specifically.
unfortunately none of the people related to this issue which i've tried
contacting replied so i've quickly decided to redistribute this
'gnu-nano-2.2.5-winxp-fix.zip' package from my website.
so instead of persisting on this and eventually patching cygwin dll's (and wasting a lot of time in the process), which wouldn't actually be the greatest and of moral things to do, i'm redistributing the one compiled for the cygwin project with the appropriate license information from both parties.
here is a bug report that i've set to gnu-nano @ savannah:
https://savannah.gnu.org/bugs/?32077
here is the DOWNLOAD of the package:
gnu-nano-2.2.5-winxp-fix.zip
i still have no idea what the cause for this is, but i can confirm that the official nano-2.2.6 works ok on other people's windows installations.
**** UPDATE ****
i was able to compile 2.2.6 with ncurses under cygwin. here is a working snapshot, download this version instead of the one above if you would prefer:
gnu-nano-2.2.6-ncurses-5.7.18.zip
06052012: here is a native (but buggy) windows build attempt, explained in comments 4-5 bellow:
gnu_nano_2.2.6_pdcruses_win32_native.zip
lubomir
Posts
Thanks for fixing the bug. Can you convince the nano-devel folks to adopt your fix?
In the mean time, I wrapped your working binary in a simple MSI (automatically adds nano to PATH, etc.).
http://downloads.yellosoft.us/apps/nano-2.2.5.msi
i didn't hear from the nano developers and haven't tried a native build (no cygwin) myself, since some things in there don't make sense for mingw/win32 (e.g. pwd.h) and some mods has to be done. on the other hand the 2.2.6 solution with ncurses from cygwin is working fine for me a.t.m.
--
Recently tried to build some other pdcurses based programs on Cygwin and got the same redirection error. Seem to remember issues with this always happening with msys as well (which is based on Cygwin). pdcurses doesn't work well with the console programs like rxvt. pdcurses also builds in X and SDL mode, so I rebuilt pdcurses in SDL mode on Cygwin and I'm not getting the redirection error. However, one would need to run it with an X server (like Cygwin or XMing). I did not notice any issues or redirection warnings when I ran via cmd.com outside of Cygwin. Worked fine as long as I had all the Cygwin dlls it used in the path.
Have been thinking about looking into a native Windows port of nano. Things like pwd.h shouldn't be a big issue to port, but if the code has a lot of forks and other Unix specific commands, it may be too much of a nuisance to be worth it. Would be nice to have a native version though.
unfortunately nano is _quite_ dependent on posix (i.e. the developers did not have of non-posix systems in mind for the simplest of operations). the biggest hint i can give is use the gnuwin32 libraries and headers.
here is a test build i did this morning:
http://sites.google.com/site/neolit123/Home/gnu_nano_2.2.6_pdcruses_win32_native.zip
it crashes when nano performs file read/write operations (which suggests bugs/compat. issues in files.c), but otherwise the curses gui is functional. if someone is interested in porting i have provided more detailed info in the README file. i'm currently busy with other projects, but might get back to this eventually.
--
just made a couple of fixes in the above build. it leaks memory now, but opening and closing files works at least (not the file browser though).
--
I've tried using some of the gnuwin32 libraries when porting applications. Usually it's overkill and buggy. Pieces of it work fine, but not usually the whole glibc library. Just for fun, tried #ifdef'ing out the non-compatible POSIX stuff and/or #ifdef'ing Windows equivalents when possible. Was able to get Nano-Tiny to build. Didn't try saving files, but opening, searching, cutting and pasting worked fine. Going to see if I can pull in more of the code (not set to Nano Tiny) and replace some of the fork and exec calls with spawns. Not sure how it'll work, but might be worth a try to get spell-checking and execution to cmd.exe possibly working. I'll have to work on this when I have more time though. Would be interested to take a look at your code and see how similar it is to the changes I made. I think it's just going to be a matter of going through and debugging parts. I was experimenting with ncurses hexedit (using pdcurses) before trying nano. The results appear to be working fine now on Windows. The code between the two seems somewhat similar, although pico has a lot more functionality than hexedit.
I pulled down the source for 2.2.6 from the Debian site. Noticed at the nano web site, they're on 2.3.1 as latest unstable release. Would it be worth looking at porting 2.3.1 instead of 2.2.6?
yes, nano-tiny was less demanding.
as mentioned, my approach was not very clear, since i did some compiler modifications to begin with (i.e. POSIX extensions for MINGW), so i don't think this is worth of any public attention. i believe, your approach is the correct one (i.e. step by step branching and porting features). i do heavily question though, the use of specific POSIX features in the code. i think they non-intentionally bound the editor a little bit more than necessary.
i can see that the project's last release update is 2011-05-10 and also they have a twitter account...would be interesting to get their opinion on the native windows port, even if they don't get involved with the task. with tools like git nowadays, merging and keeping upstream will be much easier, in comparison to bare SVN.
reading the changelog, versions up from 2.2.6 are mostly deprecating internals and making bugfixes, but i still think that porting the upstream version is a better choice (i.e. latest one).
sadly, i cannot promise involvement on my part ATM (at least). perhaps later on.
lubomir
--