Thread overview
LDC2 compiling executable requiring elevated privileges?
Oct 14, 2018
spikespaz
Oct 14, 2018
Adam D. Ruppe
Oct 14, 2018
Laurent Tréguier
Oct 14, 2018
Adam D. Ruppe
Oct 15, 2018
Laurent Tréguier
Oct 15, 2018
Adam D. Ruppe
October 14, 2018
I'm compiling an executable that does not need administrator privileges. For some reason though, LDC thinks it does and marks it as elevated.

=============================
ldc2 source\setup.d -i -I source -J build\vars -of build\bin\setup.exe -m32 -g
=============================

No clue why, but what can I do about that?

I'm thinking maybe it's because I'm importing "std.windows.registry". But even then, I'm only writing to "HKEY_CURRENT_USER", so no elevation should be required.

This is the source.
https://github.com/spikespaz/search-deflector/blob/master/source/setup.d
October 14, 2018
On Sunday, 14 October 2018 at 12:16:28 UTC, spikespaz wrote:
> I'm compiling an executable that does not need administrator privileges. For some reason though, LDC thinks it does and marks it as elevated.

This has nothing to do with ldc. It is just any 32 bit program called setup.exe or install.exe is assumed to be an installer by Windows, and thus triggers UAC unless you specifically tell it not to.

More info (including how to override this default behavior):

https://stackoverflow.com/questions/20096706/how-does-windows-decide-whether-to-display-the-uac-prompt


Easiest way, of course, is to just not call it setup.exe
October 14, 2018
On Sunday, 14 October 2018 at 13:20:09 UTC, Adam D. Ruppe wrote:
> On Sunday, 14 October 2018 at 12:16:28 UTC, spikespaz wrote:
>> I'm compiling an executable that does not need administrator privileges. For some reason though, LDC thinks it does and marks it as elevated.
>
> This has nothing to do with ldc. It is just any 32 bit program called setup.exe or install.exe is assumed to be an installer by Windows, and thus triggers UAC unless you specifically tell it not to.
>
> More info (including how to override this default behavior):
>
> https://stackoverflow.com/questions/20096706/how-does-windows-decide-whether-to-display-the-uac-prompt
>
>
> Easiest way, of course, is to just not call it setup.exe

This automation drove me crazy. I changed the name from "install" to "bootstrap" to solve it when I faced this problem.
Why should an OS decide whether an executable should be run with admin privileges ? If it has to, then it's up to the developer to explicitly ask for it...
October 14, 2018
On Sunday, 14 October 2018 at 15:46:57 UTC, Laurent Tréguier wrote:
> Why should an OS decide whether an executable should be run with admin privileges ? If it has to, then it's up to the developer to explicitly ask for it...

Windows supports programs written as much as 30 years ago. The developer might not even be around anymore, yet they try to keep the program working. Sometimes that means some weird hacks in the OS.

It is really good for the end user.
October 15, 2018
On Sunday, 14 October 2018 at 17:49:11 UTC, Adam D. Ruppe wrote:
> On Sunday, 14 October 2018 at 15:46:57 UTC, Laurent Tréguier wrote:
>> Why should an OS decide whether an executable should be run with admin privileges ? If it has to, then it's up to the developer to explicitly ask for it...
>
> Windows supports programs written as much as 30 years ago. The developer might not even be around anymore, yet they try to keep the program working. Sometimes that means some weird hacks in the OS.
>
> It is really good for the end user.

If it's about old programs, then Windows should apply their hacks only for old executables. Since it can somehow detect which compatibility mode to apply in a program's properties, surely it could decide when to and when not to try weird hacks...

Anyway, I was mostly just ranting about Windows, and I'll always blindly do that even if anyone tries to reason with me :)
October 15, 2018
On Monday, 15 October 2018 at 07:23:07 UTC, Laurent Tréguier wrote:
> If it's about old programs, then Windows should apply their hacks only for old executables.

It kinda does - this only applies to 32 bit exes without a manifest resource. If you compile with -m64, it will go away, or if you add a manifest file (which is recommended for all new programs, just it isn't as trivial with D than it is with like C#. Though it isn't hard to run a resource compiler on D programs too).

Just aside from stuff like that, there is no way to tell if it is a new or and old program.