Open dmik opened 4 years ago
It has been this way since ever. The file without extension is starting the real exe file, or at least it used to work so.
Ah that. Ok, but this makes no sense to me as if there is a foo.exe
, calling exec("foo")
will find it anyway due to extension probing in LIBC (so this covers all POSIX shells and all other programs using kLIBC to start programs). CMD.EXE behaves the same way (by probing .EXE).
The only case where it does make some sense is starting such a program with DosExecPgm
. But doing that per se makes no sense as it's not clear why anyone would do such a thing. It's pure OS/2 API where .EXE is always a must.
Perhaps it was needed back in the days where DosExecPgm
was somehow used for executables gotten from the Unix environment. But it's surely not the case now so I will eventually remove it. It's misleading after all. I.e. if you remove foo.exe
but leave foo
, there won't be any meaningful diagnostic why the program fails, nothing like "File not found". Bad design.
The reason for -Zexe is for *nix makefiles that don't know about .exe and target foo. This way foo and foo.exe are created, the makefile is happy that foo is there and foo.exe actually works. Originally foo was empty but with PGCC 2.9.x AZ fixed it so that if foo was executed by sh or such, it would execute foo.exe. Generally there is no reason anymore to use -Zexe but recently I compiled an ancient program using the included makefile and had to add -Zexe to get it to work as it was easier then reworking the makefile. Why I see people using -Zexe, I don't know but may be related to Jun Sawatasha's build environment that Paul learned on. Please don't fix -Zexe by changing it as it works exactly as it is meant to.
Makefiles, ok, I see. Thanks for this historical background. Interestingly enough, Silvan hit this very issue just today (with giflib). The makefile there relies on the default make rules (https://www.gnu.org/software/make/manual/html_node/Catalogue-of-Rules.html) that can create executables out of .c files and these rules of course expect executables to have no extension. But even in this particular scenario it's far more correct to fix our GNU Make port to expect .EXE for these default rules. Together with shells being no longer an issue here, this would make -Zexe completely redundant.
I will leave it open until the final decision. Not to happen before GNU make receives an appropriate fix.
Remember, this flag is coming from EMX with its brother -Zdll
I agree, it is not necessary to remove -Zexe: if makefile is correctly written to use .exe extension this flag is useless, if makefile is old it is needed. So this option can be safely left in place and used only when really needed.
Sure, I know where this flag comes from. And -Zdll will stay, this is out of the question. But once we fix GNU make to imply .EXE for executables on OS/2, there won't be any use case where -Zexe is needed. It's a dirty hack anyway.
Sure a dirty hack, but why remove it? if you don't need it just don't use it. If you remove the flag, everything using it will complain about an unknown flag.
And that will be a good thing as it will encourage to align things to the current environment (which is much more advanced than when -Zexe was introduced). I thought about making it a no-op, but then came to this conclusion.
IMO, there's no benefit to removing support -Zexe, unless keeping it causes problems when maintaining the codebase.
There was a time when it was needed because the tools did not handle executable extensions well, although the need is less so now.
Those of us that understood the purpose of the -Zexe option have removed it from the makefiles they maintain when possible.
I should not have to remind you that one of the reasons that Firefox ports are no longer viable is because the code owners decided legacy ports were no longer important enough care about.
Given
sandbox.o
with some dumbmain()
, the following command:produces two files:
sandbox.exe
(which is the correct executable) andsandbox
(without any extension) which looks like an empty OS/2 LX EXE stub. Obviously, the second file should not be created.I recall seeing this bug many years ago so it's a pretty hairy one.