Hey i've found your project after using Classic shell and now encountering an issue where opening the classic start menu takes a very long time and freezes explorer while doing it. I am hoping that your updated version of its code resolves this, but which do I download if I am just a simple user?
Please correct me if I'm wrong but, it looks like you installed Classic Start over the Classic Shell with the impression that Classic Start is an upgrade to the Classic Shell already installed. Am I correct?
~Ibuprophen
I am not quite sure what you mean by that. I installed the classic shell and it had options for the start menu. It worked fine for a while but is now horrendously slow compared to the default menu.
If it's Classic Shell your having an issue with, why are you reporting this within the Classic Start (now Open Shell) area?
I am hoping that your updated version of its code resolves this, but which do I download if I am just a simple user?
@Icarus77 The latest version of Classic Start/Open Shell works fine for me. https://github.com/Open-Shell/Open-Shell-Menu/releases/latest. I don't know if it's really necessary, but I would make sure you delete your existing installation of Classic Shell first.
@ibuprophen1 What I make of it is that he/she is having issues with Classic Shell, and hopes this fork fixes it. However, he/she is not sure which of the releases to pick.
@MythikAngel, I know that @Icarus77 is asking about this as well but, I was just pointing out that the Classic Start/Open Shell isn't a direct Update, Upgrade, Migration, etc... to its Classic Shell predecessor.
Basically when the individual installs the Classic Start/Open Shell, while the Classic Shell still installed, this will create a new entry and start the member from square one while the Classic Shell software files are still there as a form of residential and inactive installation.
I've actually been communicating with the developers regarding a Separate Migration style Batch file that will aid those who want to install this and keep their Classic Shell customizations and such.
I hope that I've explained this okay via text... 馃憤
~Ibuprophen
Well yes, that would be nice, in the meantime What I did was to back up my setting in classic Shell to xml file. Then uninstalled Classic Shell rebooted then install Classic Start and then restore the xml file to restore my setting's. This was all discussed on the 10 Forum perhaps this needs to be made more clear in the same area that the download to start is? So that an ordinary user moving too Classic Start or whatever name we end up with will understand what they need to do..
The xml does restore many/most of the settings but, certain settings (that would take forever to outline) that an individual has in the Classic Shell are either not restored or not backed up (most of which are stored in the Registry as well).
Thank you for understanding... :-)
~Ibuprophen
Please specify those certain settings
I was under the impression that this project tries to keep the parity with the original one, and should at least try to have 100% compatible settings (any new features would simply be ignored in the original version).
If it does not, then we have a problem.
Atm configuration can be freely be exported and imported across the two versions without noticing issues.
For example, my "optimized" xml (default built-in profile desperately need such revisiting)

_edit: updated main icons_
@AveYo
There was no change in settings themselves, but rather in paths (registry, AppData) to them.
I'm preparing automatic (one-time) import of legacy Classic Shell settings/data. So it should be possible to upgrade to Open-Shell without any hassle.
Will submit PR soon.
Hi, I'm a long time Classic Shell user who is extremely happy to see that this project has been picked up after Classic Shell was mothballed. I'm slightly confused about which version is the latest stable version though. I've been using Classic Start 4_4_109 since early July which appears fine but note its successor Open_Shell is up to version 4_4_128 but 109 is the latest version of the 4 versions that appear in the Releases tab. I briefly installed 128 but it seemed to lag when a program was selected before opening and twice windows explorer crashed entirely with a black screen and no start menu or quick start bar visible. Rolled back to 109 and there's been no repeat. Currently running Windows 10 build 17134. Will next stable release be added to Release tab when all the developers are happy with it? Thanks.
@JasonUK67
Latest nightly build (4.4.128) works for me on Win10 17134.
If you are getting _explorer_ crashes, please, follow guidance in this comment and submit crash dump. I can have a look.
Will next stable release be added to Release tab when all the developers are happy with it?
I think we should wait for PR #66 to be merged. So that Open-Shell will automatically import previous ClassicShell settings.
After that I think it will be good idea to create new Github _release_.
Thanks for response. WIll wait for next Github release and use the ProcDump tool if similar issues encountered.
@JasonUK67, the installer/uninstaller has a few issues atm when switching versions. Best bet is to:
@AveYo
the installer/uninstaller has a few issues atm when switching versions
Could you be more specific? What issues have you seen?
The only _issue_ I've had was that installer needs to close _explorer_ (and then start it once installation finishes) because there may be still some DLLs from previous version loaded.
This is basically default and safe option. And it should work well.
restart explorer
Wondering what's the reason for this.
There should be no need to restart _explorer_ on your own after installation finishes.
We have a version that supports ClassicShell data/settings import.
For more info see this comment.
@ge0rdi: a previous version repeatedly failed to end tasks _(falsely indicating Total Commander as having files in use in addition to explorer_) and then failed to restart explorer, and so it did not proceed to the initial setup screen - but was fine after relaunching explorer manually via ctrl+alt+del so the restart pc hint was bullshit. This only happened while migrating from original version.
As for the custom reload explorer item, it is very handy in general, as well as when changing hard-coded stuff such as icon sizes _(that should honestly be fixed, not to mention supporting png files so that people can for example import monochrome icons used by UWP apps and default start menu)_
Interesting.
What OS do you have?
Also do you happen to work under administrator or limited user account?
Because when I was testing upgrade process on VM, there were practically no issues at all.
Though when I tried it for real on my work machine (yup, using Open-Shell already) I've experienced similar behavior as you. Installer wasn't able to restart _Windows Explorer_ properly.
I'm usually working under limited user account, that was one of differences comparing to VM I tested.
I guess I'll have another look at this.
falsely indicating Total Commander as having files in use in addition to explorer
It actually may be due to shell extension (_Pin to ClassicShell_) that is loaded to every process that displays context menu for files (certain file types).
It seems that is is not easy to force such shell extensions to unload at will. They are unloaded automatically, but after some time if they weren't used anymore.
1803, admin account.
Yes there are differences running virtual / real, as windows security has been revamped and defender started doing some more aggressive stuff like blocking mshta shell run and other known uac-bypassers.
Just do a taskkill /im explorer.exe /im ClassicStartMenu.exe /im StartMenu.exe /f to be sure,
then in the end restart explorer via killing it's host process taskkill /im sihost.exe /f
_sihost automatically relaunches, and opens explorer and StartMenu along with it_
Should we put up some download links here?: https://github.com/Open-Shell/Open-Shell-Menu/blob/master/README.md
Maybe users don't understand those badges?
What links do you want to put there?
We already have link to latest _nightly_ build.
Official builds are available through standard Github _release_ page.
I'd say there is no need to add it to README.md.
Though we should consider creating Github pages for the project (*.github.io). So that this will be official project page and it could contain all the necessary information for non-technical users.
Because from 1 or 2 issues, it seems people or general users are confused about where to get the binaries.
Good point, a web page is better, I agree. 馃憤
It looks, to me, like this issue has been resolved and discussed elsewhere too.
I'm just going to close this one...
~Ibuprophen
Most helpful comment
@AveYo
There was no change in settings themselves, but rather in paths (registry, AppData) to them.
I'm preparing automatic (one-time) import of legacy
Classic Shellsettings/data. So it should be possible to upgrade toOpen-Shellwithout any hassle.Will submit PR soon.