> >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. > > > How (and why) should sh.exe convert anything for the program it's about > to exec? To do that it would have to be cognizant that this is a MingW > executable and therefore needs conversion of such things as pathnames. > How would it know that the underlying executable did not want > "Date/Time" as a string as opposed to some sort of filename? The shell > shouldn't been guessing and converting things like this because it just > doesn't know enough to guess right.
touche.. although you could use a mechanism like 'complete' in tcsh to enforce the conversion (complete recognizes things like paths, ip addresses, email addresses, etc.) and enforces conversion by this mechanism. This would work in 95-99% of the cases. > Really? How so? 'Cause I'm still able to use -mno-cygwin and produce > Windows only executables. Are you not able to do this? If not then why? Like I said, try: mingw > gcc -dM -e -xc /dev/null cygwin > gcc -mno-cygwin -dM -E -xc /dev/null cygwin makes 73 defines, mingw makes 38. If a large project uses any of the cygwin defines, it will behave differently than if compiled with native mingw. As I said, this is just the tip of the iceberg - who knows what patches that mingw has made to gcc, ld, make, etc. which could affect the building and running of large win32 packages. If the large packages built in mingw are tested via mingw, then mingw is the only real way to a 'proper' win32 executable. And the only way to truly emulate mingw32 would be by merging it. > Maybe the MingW package in Cygwin needs to be updated, however, I fail > to see the need for a MINGW or NO_CYGWIN flavor aside from what > currently exists (i.e. -mno-cygwin). Because gcc is not the only place that has MINGW-isms in it; msys departs from the cygwin standard and handles certain things differently. In order to build MinGW packages right, the underlying tools have to work the same as well. MINGW and/or NO_CYGWIN simply wrap all of this up in a nice user friendly package. 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/
