.exe magic

Eric Blake ebb9@byu.net
Tue Apr 17 23:17:00 GMT 2007

Larry Hall (Cygwin <reply-to-list-only-lh <at> cygwin.com> writes:

> Here's a naive thought.  See if it makes any sense.  We have lots of
> complicated logic to try to transparently handle ".exe" extensions.
> We have ".exe" extensions because Windows 9x/Me requires it to execute
> binaries.  For the upcoming Cygwin 1.7 release (date TBD), we're dropping
> support for Windows 9x/Me.  Does it follow that complex ".exe" logic
> could be dropped from 1.7 as a result?

Interesting thought.  But it is more than just cygwin 1.7.0 that would have to 
be changed; we would also need a new release of gcc that no longer added an 
automatic .exe to files as they are compiled.  And there might be some severe 
repurcussions in automake/autoconf where they currently are coded to handle 
$(EXEEXT) all over the place, if they do it based on hostname rather than on 
what the default gcc output is.  I would have to remove some of the .exe magic 
I've added in coreutils (but it would mean I'm closer to an upstream image).

> I realize this would be a hard break with the 1.5 Cygwin series since it
> would force all Cygwin packages to remove the ".exe" extensions, thereby
> excluding 9x/Me users from these package updates - assuming they would
> otherwise be compatible - even though the Cygwin package would not be.  But
> there has to be something worse about it than just this.  I'm mean, this
> has to be a real stupid idea...

I think it has merit.  But there are some caveats.  It will BREAK libtool, 
which currently RELIES on having ./foo and ./foo.exe in the same directory, 
where ./foo.exe is a binary that satisfies the make dependency for foo$(EXEEXT) 
and invokes ./foo, and where ./foo is a script that invokes the 
real ./.libs/foo.exe with the correct environment variables set.  And you are 
correct that if we made the no-.exe extension for cygwin-created executables 
mandatory, that every packager with binaries would have to update their package 
to the new 1.7.0 scheme.

On the other hand, this would be a good idea to prune away any unmaintained 
packages.  And if we go this way, we could introduce any other binary 
incompatible change that makes cygwin1.dll more efficient but requires the 
recompile (such as the change from 1.3.x to 1.5.0 to introduce 64-bit file 

I don't know how likely it is to happen though; I'll let cgf and Corinna 
comment on that.

Eric Blake

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/

More information about the Cygwin mailing list