Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
X-Injected-Via-Gmane: http://gmane.org/
To: cygwin AT cygwin DOT com
From: Andrew DeFaria <ADeFaria AT Salira DOT com>
Subject: Re: merging mingw and cygwin
Date: Mon, 13 Oct 2003 13:06:54 -0700
Lines: 62
Message-ID: <bmf0hl$fvb$1@sea.gmane.org>
References: <20031011001648 DOT GG2659 AT mdssirds DOT comp DOT pge DOT com> <6 DOT 0 DOT 0 DOT 22 DOT 0 DOT 20031012123242 DOT 01d10978 AT mail DOT chariot DOT net DOT au> <20031012052757 DOT GB12191 AT mdssirds DOT comp DOT pge DOT com> <1065936902 DOT 844 DOT 19 DOT camel AT localhost> <20031012062347 DOT GA12677 AT mdssirds DOT comp DOT pge DOT com> <bmeida$gnh$1 AT sea DOT gmane DOT org> <20031013190000 DOT GB20245 AT mdssirds DOT comp DOT pge DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet AT sea DOT gmane DOT org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
In-Reply-To: <20031013190000.GB20245@mdssirds.comp.pge.com>

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.
>
[snip]

>>$ 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:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/