Pin to Start in Windows 10

[Mircea M]

Hi everyone,

does anyone have a solution through which a shortcut can be pinned to the Windows 10 start menu? By using StdUtils' ${StdUtils.Const.ISV_PinToTaskbar} I could pin the program to the taskbar but ${StdUtils.Const.ISV_PinToStartmenu} throws an "error" message.

Is there any other way to do this maybe?

Thanks,
Mircea

[Anders]

I don't know if anything has changed in Win10 but if it has it is because they want to block people from doing this.

I'll investigate this the next time I boot my VM and report back if things have changed but I'm not going to assist you with pinning because you are not supposed to pin things, see http://blogs.msdn.com/b/oldnewthing/.../03/54760.aspx

If you look in NSIS\Include\Win\COM.nsh you will see that we do have some support for the documented IStartMenuPinnedList which is the only Start Menu API provided for ISVs.

If you are a OEM or are rolling out ISO's on machines there should be some options for you to control pinned items and the apps on the Start Screen by customizing the ISO...

[Mircea M]

Thanks for looking into it. We are not an OEM but in 90% of the cases, our software comes with a new PC "attached" and the PC is only used for work with our software. Our customers actually asked if such a feature (pinning to start menu) would still be possible in windows 10. In the end, if it isn't possible, we can just train them to right-click on the exe and select Pin to Start.

[Anders]

It is possible something changed but I have no symbols so it is a bit of a pain to debug. What is clear is that the plugin you are using has the wrong value for StdUtils.Const.ISV_PinToStartmenu but I don't know if it ever worked or if MS changed the id.

[LoRd_MuldeR]

Originally Posted by Mircea M

does anyone have a solution through which a shortcut can be pinned to the Windows 10 start menu? By using StdUtils' ${StdUtils.Const.ISV_PinToTaskbar} I could pin the program to the taskbar but ${StdUtils.Const.ISV_PinToStartmenu} throws an "error" message.

Is there any other way to do this maybe?

Have you tried the latest plug-in version?
https://github.com/lordmulder/stduti...eases/tag/1.08

Works in my tests...

(Background: The "problem" is that InvokeShellVerb uses a COM interface to invoke the exactly same operations - shell verbs - that you see when you right-click a shortcut in Windows Explorer or inside a standard Windows "File Open/Save" dialog. However, in Windows 10, the operation "Pin to Taskbar" is only visible in the Explorer process, but appears to missing from other processes - including NSIS installers. So, we now do this via the Shell process, which has fixed the problem for me. Note that I got positive feedback from others users too)

[Anders]

Originally Posted by LoRd_MuldeR

However, in Windows 10, the operation "Pin to Taskbar" is only visible in the Explorer process, but appears to missing from other processes - including NSIS installers.

This thread is about broken Pin To Start, not Pin to Taskbar!

[Pawel]

@LoRd_MuldeR
Have you tested it with Menu Start in Win10?
I am afraid it is not working...

[LoRd_MuldeR]

Originally Posted by Pawel

@LoRd_MuldeR
Have you tested it with Menu Start in Win10?
I am afraid it is not working...

Pinning to the Taskbar is working for me. I'll have to try with the Startmenu again...

[LoRd_MuldeR]

Okay, I think I figured out why Startmenu pinning not working in Windows 10.

Guess what, Microsoft has screwed it up! Resource id #5381 no longer gives the correct string in Windows 10. Does anybody know what the correct string id is now? ResHacker doesn't show any resource strings in Shell32. What am I missing?

BTW: Nice example that shows how important it is to detect the correct Windows version - especially form library code, where you have zero control over the EXE's manifesto...

[LoRd_MuldeR]

Okay, hacked together a small tool to dump all Res-Strings from a DLL:
http://sourceforge.net/projects/muld...4.zip/download

It can be seen that the required string does not exist in SHELL32.DLL anymore

[Aminifu]

Do you know that there is a limit to the number of items that the Windows 10 start menu can contain? It was 256 when Windows 10 was first released. Recent updates have increased the limit to 2048.

Also Microsoft wants users to focus on the tiles in the start menu, so I don't think preventing pinning of items on left side of the menu is an accident. If enough people complain, they may return the feature.

[LoRd_MuldeR]

Originally Posted by Aminifu

Do you know that there is a limit to the number of items that the Windows 10 start menu can contain? It was 256 when Windows 10 was first released. Recent updates have increased the limit to 2048.

Nope, didn't know about the limit.

Originally Posted by Aminifu

Also Microsoft wants users to focus on the tiles in the start menu, so I don't think preventing pinning of items on left side of the menu is an accident. If enough people complain, they may return the feature.

Actually, you can do "Pin to Startmenu" from the Explorer context menu just fine. This will add a new "Tile", not add the application to the "Recent Items" on the left. The problem: To select the proper Shell Verb ("Pin to Startmenu") we need to load the corresponding resource string - using a well-known fixed resource id. Either that, or we need a LUT for all language versions of Windows that exist...

[Aminifu]

Originally Posted by LoRd_MuldeR

... This will add a new "Tile", not add the application to the "Recent Items" on the left. ...

Windows 7's "Pin to Start Menu" feature does not add applications to the recent items list. It adds the apps to a separate area at the top left side of it's Start Menu. Windows 10 does not have a similar separate area. Like I said in the other post, I don't think this design change was an accident. Microsoft's research probably showed that most people did not use the feature. Surely, a significant number of the preview testers must not have complained about the removal (or bug, as you call it).

[LoRd_MuldeR]

Originally Posted by Aminifu

Windows 7's "Pin to Start Menu" feature does not add applications to the recent items list. It adds the apps to a separate area at the top left side of it's Start Menu. Windows 10 does not have a similar separate area. Like I said in the other post, I don't think this design change was an accident. Microsoft's research probably showed that most people did not use the feature. Surely, a significant number of the preview testers must not have complained about the removal (or bug, as you call it).

Yes. Just like I said: In Windows 10 the "Tile" area has replaced the area for "pinned shortcuts". But there still is an "Pin to Startmenu" entry in the Explorer context menu! And it still pins the application/shortcut to the Startmenu - now in the form of a new "Tile".

Fair enough! The issue here is: To select the proper context menu item ("Shell Verb") we need to know what text we are looking for. This text is locale-specific and thus must be loaded from a Resource DLL - via some well-know fixed resource identifier.

Up to and including Windows 7 this was working fine (ID was #5381). Now, in Windows 10, they seem to have "broken" that method

[Anders]

Originally Posted by LoRd_MuldeR

Up to and including Windows 7 this was working fine (ID was #5381). Now, in Windows 10, they seem to have "broken" that method

5381 does not exist in Windows 8 so this has been broken for years...

[LoRd_MuldeR]

Originally Posted by Anders

5381 does not exist in Windows 8 so this has been broken for years...

Okay. But that's not much of a surprise, as Windows 8 didn't have a Startmenu where you could have pinned anything.

(Adding something to the so-called "Start" screen, which most users didn't use anyway, doesn't count here)

Originally Posted by LoRd_MuldeR

Actually, you can do "Pin to Startmenu" from the Explorer context menu just fine. This will add a new "Tile", not add the application to the "Recent Items" on the left. The problem: To select the proper Shell Verb ("Pin to Startmenu") we need to load the corresponding resource string - using a well-known fixed resource id. Either that, or we need a LUT for all language versions of Windows that exist...

Anders, do you have any idea or suggestion where we could find the required string for Startmenu pinning in Windows 10?

In my German edition of Windows 10, the text of the required Shell Verb (context menu entry) is as follows:
An "Start" anheften

I dumped all Res-Strings from all DLL's in my Windows and System folders and then performed a full-text search for the above text.

Not found

[Yathosho]

Originally Posted by Anders

I don't know if anything has changed in Win10 but if it has it is because they want to block people from doing this.

More accurately: they don't block people from doing this, just rogue installers

[Anders]

Originally Posted by LoRd_MuldeR

Okay. But that's not much of a surprise, as Windows 8 didn't have a Startmenu where you could have pinned anything.

(Adding something to the so-called "Start" screen, which most users didn't use anyway, doesn't count here)

Pinning in 10 is the same thing.

Originally Posted by LoRd_MuldeR

Anders, do you have any idea or suggestion where we could find the required string for Startmenu pinning in Windows 10?

I know how to fix it but like I have already said, I'm not going to help people programmatically pin things.

[LoRd_MuldeR]

Originally Posted by Anders

I know how to fix it but like I have already said, I'm not going to help people programmatically pin things.

If you really know a proper solution, but are not willing to share it with the community, this is unfortunate...

[Anders]

Originally Posted by LoRd_MuldeR

If you really know a proper solution, but are not willing to share it with the community, this is unfortunate...

Me trying to get people to follow the official Windows guidelines is unfortunate?

I realize some people might be in situations where automatic pinning might be desirable but this also lets the cat out of the bag and allows everyone to pin themselves. Microsoft have already locked down the file associations to the point where it is now annoying in all sorts of ways because people have abused the ability to take them over for so long.

[Aminifu]

Originally Posted by LoRd_MuldeR

...

It can be seen that the required string does not exist in SHELL32.DLL anymore

If the only difference between this library file in Windows 7 and Windows 10 is the missing string, you could try replacing the file in Windows 10 with the one from Windows 7 or you could use a hex editor to add the string to the Windows 10 file.

Use a process monitoring app (like Process Explorer) to see which folder(s) "shell32.dll" is being read from. In Windows 7, sometimes a system library file is read from a 'WinSyS' folder. Also, if running a 64-bit OS, there will be a 32-bit version and a 64-bit version.

[LoRd_MuldeR]

Okay, please try again with the new TEST version, it (hopefully) fixes the problem on Windows 10 without breaking Windows 7:
http://sourceforge.net/projects/muld...6.zip/download

Please note the changes in the include file. You'll need to build the installer with the new (updated) include file!

Originally Posted by Aminifu

If the only difference between this library file in Windows 7 and Windows 10 is the missing string, you could try replacing the file in Windows 10 with the one from Windows 7 or you could use a hex editor to add the string to the Windows 10 file.

I can't replace or modify the SHELL32.DLL, even if I wanted to, because it's an integral part of the OS. And there's also protections for such system DLL's, which prevent any modifications. Also, the problem is not so much that the string is missing. The problem is that we need to know what the string is - the string that does appear in Explorer's context menu - but it's no longer loaded from the "known" place. Injecting our own string into the "old" known place wouldn't help at all. We have to detect the actual string at runtime, from the "new" place!

Originally Posted by Aminifu

Use a process monitoring app (like Process Explorer) to see which folder(s) "shell32.dll" is being read from. In Windows 7, sometimes a system library file is read from a 'WinSyS' folder. Also, if running a 64-bit OS, there will be a 32-bit version and a 64-bit version.

It uses the SHELL32.DLL in "System32" directory. Nothing changed about that.

Originally Posted by Anders

Me trying to get people to follow the official Windows guidelines is unfortunate?

I realize some people might be in situations where automatic pinning might be desirable but this also lets the cat out of the bag and allows everyone to pin themselves. Microsoft have already locked down the file associations to the point where it is now annoying in all sorts of ways because people have abused the ability to take them over for so long.

I think "obfuscating" existing API's was a really bad decision to begin with. The "evil" guys are going to figure out how to use the API anyway - it only may take a little longer. At the same time, it is an unnecessary and annoying burden for all the legitimate applications out there.

[Aminifu]

Originally Posted by LoRd_MuldeR

I can't replace or modify the SHELL32.DLL, even if I wanted to, because it's an integral part of the OS. And there's also protections for such system DLL's, which prevent any modifications.

Ok. It used to be possible to edit "shell32.dll" (I haven't done it since Vista). I'm glad Microsoft closed that door. The context menu command in Explorer is for adding to the 'tiles' area of the new Start Menu, which may be an acceptable substitute for some people.

It's things like this that will make me wait at least 6 months before upgrading to Windows 10, if I ever do.

[Anders]

Originally Posted by LoRd_MuldeR

Please note the changes in the include file. You'll need to build the installer with the new (updated) include file!

Just FYI, Windows 8 does not provide a unpin from start verb in IContextMenu, the unpin action seems to only be visible on the start screen special menu...

[Pawel]

New "Test" version of the plugin works for me.
(InvokeShellVerb.nsi, both Ansi and Unicode)
Win10 Home, Polish (pl-PL).
Good job! How did you get it to work?
I see you have changed "magic numbers"...

- Pinning one application works nice. Did you test the plugin in scenario when you have to pin (unpin) for example 10 applications, one by one.
- My antivirus software (Norton) was trying to block test installer when trying to pin, I wonder if there is a way to avoid this (I guess not)

Ps:
@Anders
I think it is good that such tool exists. I know, it can be used by many installers to pin unwanted stuff... but, if it is only possible someone will do that anyway... I understand why Microsoft blocked app associations in Windows - In that case I think it was very clever - now user decide what he want to run as default for his system...

I use @LoRd_MuldeR plugin in my installer (it installs plenty of apps). First, I was using VBS script (it was language depend, so I had to know Verbs for each language), but the plugin is much simple to use. I don't force user to pin stuff - user decide it (via nice custom page with app trees). I belive in that way such function (Pin, unpin actions) have sense.

[LoRd_MuldeR]

Originally Posted by Pawel

New "Test" version of the plugin works for me.
(InvokeShellVerb.nsi, both Ansi and Unicode)
Win10 Home, Polish (pl-PL).

Thanks for confirming.

Originally Posted by Pawel

Good job! How did you get it to work?
I see you have changed "magic numbers"...

With the help of my DumpStrings tool, I was able to figure out that the "missing" String is in SHELL32.DLL, after all. So I got its ID.

Didn't notice this at a first glance though. Maybe I needed some sleep

The bad news is, that we need to look for a different resource id in Windows 10 than what we need to look for in Windows 7. That's because Windows 10 actually has a "new" string, with a different resource id. The "old" resource id now leads to some other (unrelated) text in Windows 10. The good news is that the "new" id used in Windows 10 has been unused in Windows 7. So we can first try to lookup the Windows 10 string and, if not found, revert to the Windows 7 string. Detecting the actual OS version is not required for now, for this task...

Originally Posted by Pawel

Pinning one application works nice. Did you test the plugin in scenario when you have to pin (unpin) for example 10 applications, one by one..

Nope. But I'm confident if it works for one item, it will work for multiple items too...

Originally Posted by Pawel

My antivirus software (Norton) was trying to block test installer when trying to pin, I wonder if there is a way to avoid this (I guess not)

Report the false positive to Norton. There is no other way, except for switching to a less annoying A/V product.

A/V software tends to be overly parnoid when it comes to installers

[Anders]

Originally Posted by LoRd_MuldeR

With the help of my DumpStrings tool, I was able to figure out that the "missing" String and its ID in SHELL32.DLL, after all.

It is in the MUI file IIRC.

Microsoft are free to break this whenever they want, these resource ids are not part of the API contract. (Some string ids that actually are documented (from the IE4 era) are now broken and gone!)

[LoRd_MuldeR]

Originally Posted by Anders

Microsoft are free to break this whenever they want, these resource ids are not part of the API contract. (Some string ids that actually are documented (from the IE4 era) are now broken and gone!)

If somebody knows a better solution, I'd be happy to learn it.

Until then, we are locked in the usual "Microsoft breaks stuff → developers invent the required workarounds" cycle

(If everything just worked via a well-documented an stable API, things would be too much boring)

Originally Posted by Anders

It is in the MUI file IIRC.

Yup, seems like LoadStringW() transparently redirects the correct MUI file, when loading the string from SHELL32.DLL.