New run version with patches for Windows 7

Charles Wilson cygwin@cwilson.fastmail.fm
Mon Aug 10 13:19:00 GMT 2009


Corinna Vinschen wrote:
> Ok, so Alexander replied (thanks!) and would like to drop maintainership
> so if you like to take it back, feel free.

OK.

> We need run working for W7 asap, but in the long run, why not have both
> capabilites in one single "run" application?

Mainly to allow for continued mingw support by the simpler one.  Here's
what the README for run2 says:

------------------
Non-Cygwin (native win32/mingw) ports
=============================================================================
run2.exe currently requires cygwin, but a more limited version (which
supported only the Global::Target mode of operation) could easily be
ported to native win32.

[ed: or a full-featured MinGW port with the use of win32-pthreads and a
native port of libxml; this approach would avoid SOME of the issues
described below -- but what algorithm would mingw-run2 use to locate
libXll.dll for dynamic loading/LoadLibrary?]

While Patches are Thoughtfully Considered (PTC),
I believe that such a modified version would require very ugly changes
not only to the code, but also to the build machinery.  This will only
get worse once cygwin-1.7 specific features like support for (really)
long filenames, Unicode/wide char XML contents, and wide char filenames,
are added.  Therefore, I believe -- and encourage -- a native-win32/
mingw-specific port to be implemented as a cooperative fork, or branch
in the existing repository, rather than cluttering the code and build
machinery with more #ifdefs and AM_CONDITIONALS.
------------------

So, creating a version of run2 that implemented strictly the
functionality of the original run application -- or implementing a
specific mode in run2 that exactly mimicked the operation of the
original run application -- would be fairly straightforward.

However, making that version/mode compilable under MinGW would not be;
and in fact, I'd already given /that/ some thought, and decided that (1)
it would require changes to the run2 that are Too Ugly For Words, and
(2) that a fork of run2 for that purpose would be better.

So...how many versions of run DO you want me to maintain <g>?

Basically, supporting a native version of run2 myself -- in any form --
is not in my mission plan for run2 [*].  But, I believe it is part of
the implied contract for the original run. So...

Now, "in the long run", since a lot of the functionality is shared
between run and run2, I could see merging development between them.

Either by creating an API and (static) library containing most of the
common functionality (e.g. the actual launch-target code, and some of
the utility code, but not run's "magic guess-the-target-name from
argv[0]" stuff nor run2's parse xml and probe for Xserver stuff).

Or, explicitly sharing that code in source form a la' gnulib.

In fact, it was with a view to these two possiblities that I said I
"have a few ideas for refactoring" run.

But, in whatever form, I think it best if run and run2 remain logically
 distinct, even long term.

--
Chuck

[*] Here's an idea for "long term" -- do the "fork" of run2 "for MinGW"
as described originally -- one that would never "switch" between two
targets nor probe for an Xserver by LoadLibrarying libXll.dll. It would
still need mingw-libxml, tho.  Then, add the "magic
guess-the-target-name from argv[0]" from run.  This "mingw" run2 fork,
when compiled on cygwin, would basically then be a drop-in replacement
for run, but with a (relatively) common source code, plus
set-env-var-before-launching-target and xml-config support.  This could
be combined with the library/gnulib-style code sharing idea above (only,
even more code would be common between the "original" run2 and the
mingw/run-mimick version).



More information about the Cygwin-apps mailing list