Thorsten Schöning
Thorsten Schöning

Reputation: 3728

Why does ShellExecuteEx with verb "print" take LNK file settings of an app into account?

Context

I have a Windows app printing PDF files by forwarding the file paths to ShellExecuteEx and the verb print. Adobe Reader is installed and registered for that verb. Reader by default creates a LNK shortcut file in the start menu:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Adobe Acrobat DC.lnk

Hide windows

By default, reader shows a GUI window when printing a PDF. Some customer doesn't want that window and simply tried to "hide" it by changing the LNK file content using Windows Explorer properties to at least minimize the windows by default. That customer didn't know if that works or not, one simply tried.

LNK file settings

To my surprise this worked, changing the minimize vs. non-minimize/default setting of the LNK file made the reader windows being visible or minimized.

No changes in registry

I've searched the registry for changed settings regarding the print verb, but couldn't find any. The new setting really seemed to be only stored within the LNK file:

DIFF of LNK file with vs. without minimized set

The registry contained references to the actual EXE only, not the LNK file. Pretty much like expected, I've never came across any shell verb registration using LNK files at all.

"C:\Program Files\Adobe\Acrobat DC\Acrobat\Acrobat.exe" /p /h "%1"

Though, all invocations of the verb print seemed to recognize that setting, either manually using the context menu of some PDF in Windows Explorer or executing things on the shell:

powershell -Command "Start-Process -Verb print '\\?\C:\[...].pdf'"

Why is that important?

Adobe Reader provides the command line argument /h to minimize itself as well, but using that doesn't fully hide a window at all. Instead, a window is shown for a second or so and afterwards minimized, e.g. like Adobe is doing that itself. OTOH, with the changed LNK file things are different: Either really now window is shown at all or only some artifacts like the window title or alike for less than a second.

It really seems that the difference is between Adobe doing something on it own after it has loaded and stuff vs. Windows itself creating the minimized window already.

Additionally, if possible at all I would like to avoid customers needing to change the LNK file themself. The problem with that change is that it's not tied to the print verb only, but whenever Adobe Reader gets opened. And sometimes customers really need to have a look at PDFs themself instead of automatic printing only.

So, how does that work?

Is Windows itself using the setting of that LNK file or is this something implemented by Adobe Reader?

Using ProcMon, I couldn't find any hint about that Adobe Reader itself reads the LNK file. As well, I couldn't find this behaviour documented in the topics about shell verbs, ShellExecuteEx etc. It's totally unexpected to me, as the LNK file is some arbitrary file in theory, which might not exist at all, can be named as one likes, even multiple of those could exist in theory starting different apps of some package or the same app with different arguments etc.

Thanks for any insights.

Upvotes: 0

Views: 193

Answers (0)

Related Questions