On 9/14/2010 1:56 AM, Andy Koppe wrote:
> On 14 September 2010 06:05, Charles Wilson wrote:
>> Since I don't see (a) happening anytime soon (the most likely course of
>> affairs is a "reboot" of msys-2.0, re-forking from cygwin-NOW rather
>> than cygwin-2003
> ... and hopefully maintaining it as a patchset rather than an outright
> fork, so the same situation doesn't arise again later.
That would be ideal, yes. IIRC, there were seven major differences (and
probably a lot of minor differences) between cygwin-2003 and the
original MSYS fork:
1) encoding of the $GLOBAL namespace object names so that multiple
"MSYS" installations could coexist (*) -- although applications in one
MSYS instance could not communicate with apps in a different MSYS
instance. Contemporaneous cygwin allowed all cygwin apps in any
instance to communicate with each other -- but if there were version
mismatches between those cygwin instances...boom!
(*) not to mention so that an msys installation could coexist with a
"real" cygwin one.
2) automatic detection of the installation root, and the use of
/etc/fstab (where C:\dos\path\to\etc was part of that autodetection) to
implement the mount table. Contemporaneous cygwin used the registry for
this purpose, including explicit specification of the installation root.
3) automatic mounting of attached hard drives, as C: -> /c, D: -> /d,
etc. Contemporaneous cygwin auto-mounted hard drives as /cygdrive/c,
4) magic path translation and heuristics when calling exec() or spawn()
with a "native" application.
5) uname(2) returned either MINGW32-blah-blah or MSYS-blah-blah,
depending on the value of the environment variable $MSYSTEM. Also, lots
of mechanical CYGWIN -> MSYS changes.
6) Very simple permissions modeling: chmod(2)/chown(2) have practically
no effect. No real use of /etc/passwd or /etc/group. umask(2) does
nothing. New files created with Full Control access for Everybody.
Msys-stat() and access() queries basically return 666 for all files, and
777 for all ".exe's" and directories -- unless the DOS "Read Only"
attribute was set.
7) symlink(2) implementation modified
so that "file" symlinks were implemented as hardlinks if on the same
device, and copies otherwise; "directory" symlinks implemented as
recursive copies (with files "below" the directory treated as individual
link(2): hardlink if on same device, copies otherwise).
As it happens, modern cygwin versions now do #1:
by default (to get "old" cygwin behavior, you have to run 'cygcheck
although the format of cygwin-1.7's fstab and msys's fstab are quite
Also, #3 is easily implemented, by adding the following to /etc/fstab
(or #ifdef'ing in a different default cygdrive prefix, for MSYS):
none / cygdrive binary 0 0
#4 effects are localized to only two or three .cpp files
#5 affects a single .cpp file
#6 ... I dunno, this one is probably pretty pervasive. cygwin-1.7 made a
LOT of changes in the permissions and ownership handling, so it might be
difficult to "turn it off" in all the places it needs to be.
#7 Again, only affects one or two .cpp files
Then, there are the all the "new things" introduced in cygwin since
2003; some of which may be fine as they are, but others may need to be
modified in some way for better "MSYS-ness". Stuff like exactly HOW
i18n and wide chars are supported in new cygwin, especially with regards
to path-names. Even cygwin has not yet nailed all of this down yet;
they are currently trying to figure out the best way to handle REALLY
long file names (>4K, up to 32K chars).
cygwin-1.7 has no problems with them, but there IS a problem if a cygwin
program (say, bash) calls a win32 API function while the current working
directory is set to a really long path -- because the win32 subsystem
itself doesn't really support them. One such problematic win32 api
function is CreateProcess (which, unfortunately, is called
under-the-hood by exec() and spawn() when the target is a native app)!
This is an even bigger issue for MSYS than for cygwin, because while you
are "in" cygwin it is possible you might almost ALWAYS launch only other
cygwin apps. But, the whole POINT of MSYS is to launch *native* apps --
like MinGW gcc -- via a unix-like shell (which uses fork/exec()
semantics to launch commands). Thus, an MSYS bash is *often* used to
launch a native app (ultimately) via CreateProcess. If new-MSYS
supports really long paths, then you will have problems if CWD is a
really-long-path, and you try to run MinGW gcc...
So, in some ways forking msys-2.0 from current cygwin will be easier to
maintain, because many of the most intrusive *existing* differences are
no longer needed. But in other ways, it may be just as difficult as
before, because we aren't yet sure how the new cygwin capabilities
should be "translated" for a smooth "MSYS"-like experience.
Alternatively, we could take a long, hard look at some of the decisions
made in the early MSYS days, and consider if, in this new era of
somewhat improved native win32 security (**), whether we need ALL of
these differences from cygwin? Maybe #4, #5, and #7 are all we *really*
(**) That is, all current versions of windows are now based on the NT
kernel, and support some modicum of security; back in the old days we
still had to worry about win9x and its zero-security model. New-cygwin
no longer supports win9x at all (and neither does microsoft); should we
worry about it any longer, for msys-2.0?) The downside here is that you
would no longer be able to use any-old-win32 tool to "unpack" msys
packages, because the unpacker would have to "know" how to set the
correct ACLs on the unpacked files; kinda like cygwin's setup.exe does.
However, we still want to be able to use any-old-unpacker for the MinGW
packages...so msys itself would need to be able to "deal" with that...
In any case, I really do think it would be easier to maintain any such
msys-2.0 using a git mirror of cygwin's repo, and putting msys on a git
branch. That way, merges from "upstream" would be a lot simpler;
branches are SO much easier to work with in git...
But, to even THINK about that, *we* need to distribute an actual msys
port of git (and not rely *directly* on the msysgit version, which IIUC
is actually a MinGW version bundled *with* msys). And that needs, I
*think*, a newer perl implementation than 5.6.1... (not sure why, but
msysgit went thru the effort of porting 5.8.8 for SOME reason.)
And higher priority than ANY of that, is to get mingw-get (CUI) support
for package removal and package upgrades, instead of the current
install-only behavior. And then some sort of "real" GUI, instead of the
goofy InnoSetup "wrapper" we have right now.
One thing at a time...