UAC / PopMenu Question

[fhammer]

I'm not sure how to properly phrase this question. Please bear with me.

I log into Windows 10 on my personal laptop with administrator privileges. Nothing special, I'm the only user.

I often have several text files open at once using my favorite text editor.
It's very convenient to have them appear as tabs in the same editor window.

As long as I open them manually (e.g. clicking their desktop icons), they all open in the same window.

However, it's convenient to open some from a PopMenu script.
When I do, the new ones appear in a separate editor window, with "(as administrator)" as part of the window name.
This is inconvenient. I have to switch windows (not just  tabs) to view, copy text, etc.

Is there a way I can keep then all in the same editor window?
I would prefer that the window name not contain "(as administrator)", but that's a minor issue for me.

Thanks much.

[td]

The most likely explanation for the "As Administrator" appears in the title is that PopMenu executes as an elevated admin when you are logged on as an admin so your editor is launched with the same elevated privileges.  Apparently, your editor detects it's elevated state and slaps that fact in the title for some reason.  The only way to get around that would be to spawn another WinBatch process using one of the reduced privileges version of WinBatch and launch the editor from there.  However, that can be tricky and you need to select the correct version of the WinBatch exe or Windows may have one of its many security fits. 

As for opening new tabs as opposed to a new exe, you will need to consult your editor's documentation for possible command line switched that permit that behavior.

[td]

Neglected to mention that another way to open multiple tabs in a single instance of an application is to use UI automation.  This involves some combination Control Manager, window, menu, and/or SendKey functions.  While it isn't too difficult for an experienced user it can be a bit of a challenge for the uninitiated. 

If you want to attempt to launch your editor from a separate script to clean up the title, your best bet may be to try the "WinBatch_IF.exe" version of WinBatch with the ShellExecute function.

[ChuckC]

The Win32 API function, GetTokenInformation(), has a couple of information classes that it can retrieve that are of interest.  In particular, TokenElevationType, TokenElevation and TokenLinkedToken would be useful in this situation.  The first two allow for identifying that the current process is, in fact, running elevated [e.g. is an administrator w/o restrictions] under UAC.  If the process token is elevated, then querying TokenLinkedToken allows you to obtain a handle to the restricted token that is used by processes in the session that are running without elevation.  Once the restricted token has been obtained, it can be used for impersonation or to create a child process that runs using that restricted token.

In effect, an elevated process can then create a restricted child process.  Some judicious use of DllCall() wrapped up in some UDF's might be sufficient, but a new variant of the Run*() functions might be a lot easier to use in the long run.

Depending on how some WIL code in PopMenu is being used to "open" the files in the editor, it may well be necessary for the restricted child process to actually execute the WIL code that performs the "open".  For example, if it's done via shell file type associations and invoking a Shell API function, this technique would be necessary.  If it's as simple as launching a command line along the lines of 'C:\<some-path>notepad++.exe "C:\<some-other-path>\ReadMe.txt"' where the editor [notepad++ in this example] will detect an existing instance of itself and tell that instance to open the file in a new tab rather than starting a new instance of the editor.

[td]

The WinBatch Studio uses several Win32 APIs including CreateProcessWithToken to detect its current integrity level and then start WinBatch with different integrity levels based on the file extension of the WinBatch script being processed.  This was necessary because the ShellExecute shell API does not display consistent behavior across versions of Windows and Windows configurations. Also, the system does block integrity levels of child process created from a process with uiAccess set to TRUE as is the case with WinBatch Studio.  This behavior is dependent on specific registry settings on some versions of Windows. There isn't a workaround for those instances because the system simply ignores the integrity level you specify when starting the process.  None of this is particularly well documented by MSFT.

On newer Windows 10 semi-annual updates MSFT seems to have lighted up a bit on child process restrictions and ShellExecute works most of the time on a system with default registry settings. 

[fhammer]

A Solution to my Problem (and thank you)

Thanks td and ChuckC for the helpful suggestions.

In an attempt to avoid both the "As Administrator" and separate-window issues, I tried td's suggestion:

"... spawn another WinBatch process using one of the reduced privileges version of WinBatch and launch the editor from there".

I used WinBatch_IF.exe and ShellExecute. BTW, my text editor is EditPad Pro.

Unfortunately files opened in WB scripts or PopMenu segments (using this method) still opened "As Administrator"
in a separate window from files opened manually using established Windows file associations.

I couldn't find anything helpful in the EditPad Pro documentation.


To addresses my basic issue: (Having to switch between windows when editing multiple files):

I tried, unsuccessfully, to adust my Windows file associations to cause manually opened "double-clicked"
files to open "As administrator".

I ended up putting an "EditPad Pro" option near the top of my "FileMenu for all filetypes".

My first FileMenu attempt (passing the file directly to EditPad Pro via Run) didn't work.
The file still opened without "As Administrator".
Apparently there is something different about executing WB statements from a FileMenu as opposed to a WBT file or Popmenu.
I think FileMenu is somewhat-more-tightly-integrated with Windows.

What finally worked for me was, within the FileMenu script, spawning a separate Winbatch process and using ShellExecute.

I can now easily open all files as tabs within a single "As Administrator" EditPad Pro window,
as long as I use the new FilMenu option instead of double-clicking them.

[ChuckC]

PopMenu runs in its own process and is typically started at logon time [via the "Startup" folder] and gets launched with a 2-step "runner" script that allows UAC elevation to be performed when PopMenu itself is actually started.

FileMenu is implemented as a shell extension DLL that is hosted within the Windows Explorer [explorer.exe] process.  By default, when UAC is enabled and an admin-privileged user logs on, the process-level access token used for all instances of explorer.exe is the restricted token.  At times when explorer.exe needs to perform an admin-related function, it will present prompt asking if you would like to perform that task elevated at admin level.


The end result is that PopMenu is always running elevated and FileMenu is running restricted.