This is the mail archive of the
mailing list for the Cygwin project.
Re: merging mingw and cygwin
Edward Peschko wrote:
Have you tried to compile an application using -mno-cygwin? Have you tried to run the resulting executable? I have. I created an application using -mno-cygwin and to my surprise it became "Windows" like in that thinks like pathnames had to be specified in Window'ese. So before, in
the Cygwin environment I could:yes, I've tried that, and yes, it points out the redudancy of the two projects. My point(s) are:
a) that it is not a good fit. It does a 'good job'
b) its a big usability issue.
I, like others, think that you are just looking at this sideways. If I
compile a program with MingW it is to produce a Windows only executable
totally unaware of Cygwin, Posix or anything. The only thing I'd expect
it to "understand" is Windows conventions. As such I'd expect that
program to only honor Windows compilant pathnames and if it did see a
/path/to/file I'd expect it to choke - wouldn't you?
$ myapp /path/to/fileThat's what I really don't understand about cygwin and mingw32, both. Why can't they make a mutual convention: to take things of the form /path/to/file and change them to C:/cygwin/path/to/file, things of the form /cygdrive/c/path/to/file and make this C:/path/to/file, and always use the internal form 'C:/path/to/file' to open files?
but now, after -mno-cygwin I must:
$ myapp C:\\path\\to\\file
ie - if programs are running under sh.exe, massage at the *shell* level, not let individual applications manage their arguments.
If I wanted my application to work with Unix'isms and Posix'isms then it
must rely on an emulation layer since Windows at it's core (i.e. the MS
C Runtime) does not do Unix or Posix very well (if at all). So then I
create a Cygwin reliant application (i.e. use Cygwin's runtime emulation
layer - cygwin1.dll) and my consumers would need to install Cygwin.
You seem to want something in the middle (which is understandable but
which, AFAICT, doesn't exist). You want to be able to use a Unix-like
environment and code Unix-like symantics yet produce a pure Windows
executable (i.e. MS C Runtime) and then you want some *magic* to
translate such Posix assumptions into "Windowese". Well that "magic"
has been done before. It is called cygwin1.dll and surprise if you glue
that magic into your "Windows only" application it becomes a non
"Windows only" application with a reliance on cygwin1.dll. So your back
in the same boat needing to get Cygwin's cygwin1.dll on your target
machines and wham you come right smack up against the GPL.
The only way I think you can truly accomplish what you want is to
effectively do all the work that Cygwin has already done, by hand,
recoding it so as not to be stealing, and release your runtime license
free or on the "Artist" license like Perl. You'd still have the
dependency and your target machines would need this "magic" dll but
you'd be freed from the licensing requirements.
Good luck! Let us know when you're finished with the project! :-)
If lawyers are disbarred and clergymen defrocked, doesn't it follow that
electricians can be delighted, musicians denoted, cowboys deranged,
models deposed, tree surgeons debarked, and dry cleaners depressed?
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html