Hiding non-user-facing executables for Windows applications?

Our Windows application makes use of some open source components in the form of their publicly released executables. (One example is 7za.exe that we use to zip old log files.) We do not want users to directly use these internals, just because they happen to get shipped with our application. (Security audit headaches; update problems, when users start relying on these; etc.) It is well known that you can execute any file type on windows, the extensions are just a convenience when interacting via Windows Explorer. Given that we run these via Process.Start call from our app anyway, someone suggested to just rename the files, so instead of ...\tools\7za.exe our program folder would contain ...\tools\7za.internal_tool (

Feb 21, 2025 - 12:26

Our Windows application makes use of some open source components in the form of their publicly released executables. (One example is 7za.exe that we use to zip old log files.)

We do not want users to directly use these internals, just because they happen to get shipped with our application. (Security audit headaches; update problems, when users start relying on these; etc.)

It is well known that you can execute any file type on windows, the extensions are just a convenience when interacting via Windows Explorer.

Given that we run these via Process.Start call from our app anyway, someone suggested to just rename the files, so instead of ...\tools\7za.exe our program folder would contain ...\tools\7za.internal_tool (<< note that .internal_tool is now the extension; user cannot start it with explorer).

What would be the technical, engineering and/or organizational challenges with this approach?