This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


$ myapp /path/to/file

but now, after -mno-cygwin I must:

$ myapp C:\\path\\to\\file

That'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?

ie - if programs are running under sh.exe, massage at the *shell* level, not let individual applications manage their arguments.

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?

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:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]