Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: "Robert McNulty Junior" <bmj2001 AT bellsouth DOT net>
Cc: <cygwin AT cygwin DOT com>
Subject: RE: merging mingw and cygwin
Date: Mon, 13 Oct 2003 16:30:48 -0500
Message-ID: <000001c391d1$44b54a70$6701a8c0@bobbyjunior>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20031013203527.GA25036@mdssirds.comp.pge.com>
Importance: Normal

Ed, mingw is a bunch of library files used with Mingw.
I notice, though, that I can create a Windows based GUI with the mingw
and w32api from Sourceforge better than I could with Cygwin.
When I want a Unix program compiled, I turn to Cygwin.
I also have Visual Studio, but it ain't great for Cygwin or Mingw.
Earnie Boyd just came out with a new Mingw runtime. Works better and
better all the time.
Enough out of me as this is off-topic and hush-hush.
Robert McNulty Junior

-----Original Message-----
From: cygwin-owner AT cygwin DOT com [mailto:cygwin-owner AT cygwin DOT com] On Behalf
Of Edward Peschko
Sent: Monday, October 13, 2003 3:35 PM
To: Andrew DeFaria
Cc: cygwin AT cygwin DOT com
Subject: Re: merging mingw and cygwin

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

well, I'd expect to see the mingw application choke if I ran it through
cmd.exe 
this way..

I don't see why it would have to choke if it ran through *SH.EXE* this
way.
sh.exe - in either the mingw32 world or the the cygwin world - could
handle
the arguments. And that way, interoperate a lot better with Win32.

And I don't care if cygwin sh.exe links with cyg*.dll. The whole point
of this 
is to make the final product - be it end-user application or third party
API - 
be able to not use the cygwin1.dll if it doesn't want to. I set MINGW ==
1 or 
NO_CYGWIN == 1, use cyg*.dll to do the development, and my final
executable is 
true, blue mingw32.

In fact, that's the whole point behind -mno-cygwin. 
Witness http://www.delorie.com/howto/cygwin/mno-cygwin-howto.html:

"The reason behind implementing the -mno-cygwin option is quite simple:
since you
already have the Cygwin development tools loaded, wouldn't it be nice
to be able to create Mingw executables using the same compiler and tools
instead
of having to load yet another set of Mingw-specific development tools?"

Its my contention that -mno-cygwin is fundamentally broken; and to make
it truly
work cygwin needs to incorporate the mingw32 patches and the tools have
to take
the 'flavor' of mingw32 when MINGW is set or NO_CYGWIN is set. My
ultimate goal
would be to build everything from scratch

> 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".  

As I said before, that "magic" would be nice to use whilst developing..
I don't
need the magic in my final executable. In some cases its a nice thing to
have
(ie: cross-platform unix/win32) but it need not be there all the time.
Its a 
hindrance, not a help to force it there.

> 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.

or, basically take all the patches that mingw32 has done, and
reintegrate them
into cygwin under a MINGW or NO_CYGWIN flavor.

Ed

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/