Classic shell needs to configure itself for the new operating system

[dbdan22]

Hi,

Well I've put off Win 10 Build 1803 as long as I can, but it's going to come in any day now on about 30 some odd PC's.

Been using Classic Shell for a while, want to try Open Shell. We don't allow our users to be Admin.

Just wondering if non-Admin users will get the same message "Classic shell needs to configure itself for the new operating system" and require Admin priv's to proceed when the new build is installed.

If so are there plans to fix it, and/or is there a workaround?

Thanks.

[sarthurdev]

If this is a domain environment, you could use GPO to do the tasks run by the upgrade.

HKEY_LOCAL_MACHINE\Software\OpenShell\OpenShell\WinVersion needs updating to the latest Windows version.

The upgrade then calls regsvr32 /s "%windir%\System32\StartMenuHelper64.dll" (change to StartMenuHelper32.dll for 32-bit OS),

I suppose you could set the WinVersion registry key to something very high so the upgrade check is always false, I'm not sure if the DLL actually needs re-registering on every Windows 10 feature update.

[dbdan22]

We have several sites, both domain and workgroup.

[sarthurdev]

For the domain PCs it's as simple as above, however for workgroup non-admin users you will probably need to manually run the upgrade.

[dbdan22]

I suppose you could set the WinVersion registry key to something very high so the upgrade check is always false,

Why is there a need for the WinVersion registry key in the first place if you can fake it?

How difficult would it be to write a system service, manual start, that would sit idle most of the time, until Open Shell detected a build change? Then it would kick off the system service to do this.

[Nodens-]

A dll once registered, does not need to be registered again after a windows update. A dll can get unregistered by an AV application though or registry can get corrupted requiring to register again.

The way I see it, making an educated guess, this mechanism was implemented in order to deal with some kind of issue in a hackish way. Perhaps at some point windows build upgrades were causing the dll to get unregistered somehow (maybe windows defender or other AV product had something to do with it).
So if this is tested in VM and the dll remains registered after build update, this code should be actually removed as it's actually bad practice to implement fixes not actually required just to cover edge cases. Specially when those require elevation.
Users actually hitting a problem of an unregistered dll due to an edge case should just rerun the installer or in case of large network environments contact the admins which they will have to do anyway since they can't get elevated rights.

[dbdan22]

Agreed.

Well please pardon my ignorance for this is all new to me. But the string "Open-Shell needs to configure itself for the new operating system." is assigned resource 3575 and ID IDS_UPGRADE_ERROR, which is only referenced once in StartMenu.cpp. Now as to what the developer is trying to do leading up to this message, I'll have to stare at this cross-eyed for a few more hours to figure that out... But I do see the regsvr32 calls a few lines up...

[dbdan22]

The way I see it, making an educated guess, this mechanism was implemented in order to deal with some kind of issue in a hackish way.

Actually, Ivo addressed this in a post here:
http://www.classicshell.net/forum/viewtopic.php?f=7&t=8082

The helper DLL does more than just update it's COM registration. It hooks into Explorer in a special way to make it possible for the start menu to launch as soon as you log in, not after 10 seconds (like other auto-start programs). That registration is lost between Windows updates.

So for this to work for non-admin users, this would have to be done in a system service.

[Nodens-]

Ah, I see. Yes. This should indeed be implemented as a service.

[dbdan22]

Can we have this marked as a future enhancement? Thanks.

[sarthurdev]

You could in the mean time push a group policy start up script to register the DLL silently, or use task scheduler.

How did you install Open Shell on all these machines in the first place?

[dbdan22]

You could in the mean time push a group policy start up script to register the DLL silently, or use task scheduler.

As stated previously, most PC's are workstation, not domain.
And as also stated previously, it's more than just registering a DLL. Open Shell has to hook itself into Explorer. See Ivo's comment http://www.classicshell.net/forum/viewtopic.php?f=7&t=8082
What code am I supposed to execute to do this? I haven't found it in the code yet, not that familiar with C++.

How did you install Open Shell on all these machines in the first place?

One at a time, as the PC's were rolled out, over several years. Now I have to go running around to several sites for 10 seconds of work, to log in as Admin and "configure Open Shell for the new operating system", which happens whenever Windows decides to install a new build, a process which I have no control over (other than to delay it by 365 days).

The process of writing a system service is rather straightforward, there are a number of templates for it. Here's one: https://code.msdn.microsoft.com/windowsapps/CppWindowsService-cacf4948 . You cut and paste the code from Open Shell to register the DLL and hook itself into Explorer, and you're done.

So basically the service can get installed with manual start. When Open Shell detects that a new build came in, instead of doing the work itself, it just kicks off the system service and waits a few seconds. So you don't need group policy or a scheduled task to do something every single time you turn on the computer and/or log in, when 99% of the time there will be nothing to do.

A program should not be crippled for one class of users when it is fairly simple to fix this.

[ge0rdi]

What code am I supposed to execute to do this?

You just need to run:
"C:\Program Files\Open-Shell\StartMenu.exe" -upgrade

This is what Open-Shell Menu does on startup when it detects that OS version changed.

[sarthurdev]

And as also stated previously, it's more than just registering a DLL. Open Shell has to hook itself into Explorer. See Ivo's comment http://www.classicshell.net/forum/viewtopic.php?f=7&t=8082

The code that is run when the helper DLL is registered is the what applies the explorer hook and updates the WInVersion in registry so the "Configure Open Shell..." popup does not appear.

See here: https://github.com/Open-Shell/Open-Shell-Menu/blob/master/Src/StartMenu/StartMenuHelper/StartMenuHelper.cpp#L317

[dbdan22]

This might be a little easier. What if this were done via Scheduled Task?

The equivalent would be along these lines:
https://www.digitalcitizen.life/use-task-scheduler-launch-programs-without-uac-prompts
Making sure that "allow task to be run on demand" and "run with the highest privileges" are selected,

except that Open_shell can create the task programmatically on installation, using this as a template
https://docs.microsoft.com/en-us/windows/desktop/taskschd/weekly-trigger-example--c---

and trigger the task when it detects a new build, using this as a template
https://docs.microsoft.com/en-us/windows/desktop/taskschd/c-c-code-example-starting-a-task

and the scheduled task would be
"C:\Program Files\Open-Shell\StartMenu.exe" -upgrade

??

[NomDeMorte]

I'm going to sound like a rude bastard here so I want you to know that it comes from a good place and is intended to, and will, if you accept it, help you. Please, see past my bastardly tone and see that if you listen to what I'm telling you, everyone wins.

There should be no need whatsoever to change an application in order to deploy it. Learn to deploy it properly.

As stated previously, most PC's are workstation, not domain.

So what? You can still push policies to workgroup PCs. If you can push anything to them, policies are among those things.

which happens whenever Windows decides to install a new build, a process which I have no control over (other than to delay it by 365 days).

Wrong. Learn to configure windows update. There's this myth that win10 prevents users controlling updates. You can still select individual updates just as you used to be able to in previous versions. You just need to read the docs to find out how.

A program should not be crippled for one class of users when it is fairly simple to fix this.

A program's development resources should not be wasted in catering for the inadequacies of inexperienced sysadmins.

Again, I know, I sound like a total bastard here. I could spend hours carefully curating this post so as not to hurt your feelings but hopefully you'll just nut up and realise that you're crippling the development resources of this tool by relying upon them to compensate for your lack of experience and knowledge of the tools you're using.

This is not something I say in order to put you down - on the contrary. It's something I say that, hopefully, you will take this constructive criticism, take some time and learn some new skills that will both save this project development time, and expand your skills and career prospects.