MC for Win32 revival

[Zdzislaw Sliwinski]

I would like to add my 2c to what Pavel already said.

Graphical shells are very well known in the DOS and Windows world with the 
most prominent Norton Commander in the lead (and I think that it isn't a 
coincidence that MC stands for Midnight Commander). 

Another one (IMO much better than NC) is FAR (File ARchiver).

Whoever then comes out with the idea of graphical shell for DOS/Windows 
should be aware of the existance of at least those two products.


A question to Pavel. Back in 1990-91 I've been working with QNX very often 
with the help from some graphical shell. Could it be MC?

dishlav


On Monday 29 October 2001 17:11, you wrote:
> Hello, Miguel!
>
> > > 1. Who else is interrested (or even active) in reviving the Win32 Port
> > > ? 1a. Any interrest in building mc with M$-VC++ or Borland C++
> > > (otherwise I will only support mingw-gcc )
> >
> > I would like to see MC running on Windows.  Although I am wondering if
> > it is not just trivial to port it using Cygwin?
>
> Not only is it trivial, but I even tested MC on Cygwin days before
> releasing 4.5.55 and it compiled with very minor fixes that I committed
> before the release.
>
> MC works quite well on Cygwin, but it sees the system from the UNIX
> standpoint.  It doesn't know about drives and represents permissions in
> the UNIX form.
>
> Another more technical problem was that both editor and the viewer
> displayed some useless warnings and required some tricks to be used.
> This may have been a problem with the regex implementation in Cygwin.  It
> could also be caused by the interference between the system regex and the
> regex implementation included with MC (src/regex.c).
>
> The "native" port (as opposed to the trivial Cygwin port) addresses the
> issues of the drives and the permissions.  It also uses the native S-Lang
> support for the host OS instead of relying on the escape sequences.  It
> supports Win32 and OS/2.  Open-sourced EMX and mingw are among the
> supported compilers.
>
> The problem is that the native port is broken and doesn't compile.  The
> makefiles don't know anything about glib.  Also the file lists in the
> makefiles need to be updated.
>
> Unfortunately, there has been no interest to the native PC port from the
> developers ("YES!!!!! Thank you thank you" doesn't count).  If I had a
> working Win32 or OS/2 system around I would probably fix it, but it's not
> the case.
>
> A word of caution.  Windows users have a different mentality and don't
> generally understand the idea of free software.  Whoever works on the port
> may be a subject of spiteful personal e-mail ("you $%$#% program doesn't
> work") and shameless support requests ("where do I get the fixed binary").
>
> I've had enough of such e-mail just for merging some OS/2 and Win32 code,
> rewriting the makefiles and minor changes to the code.  It is not a big
> deal if you are prepared, but please _be_ prepared.