Classic Shell's Classic Start Menu appears to run fine as a portable app --
this is especially valuable on the Server 2012 iteration of NT 6.2 where some
may not want to be running 3rd party services, and a minimal application
footprint can be desirable for auditing and minimizing 'attack surface'. Just
copying a directory with:
· Start Menu Settings.lnk
To a Server 2012 system and executing "ClassicStartMenu.exe" appears to work
fine; as well there doesn't appear to be any program data generated anywhere
else on the system excpet for two Windows Registry keys in:
But this was just from a cursory examination not an deep forensic dif analysis
to run down every possible change. Have I missed anything important? Are there
any hazards to executing the application in this manner? And while this is a
very manageable solution 'as is' is there any way sans using registry
virtualization and redirection to get Classic Shell to save it IvoSoft key
data to a local application directory?
There are no hazards to running it this way. The installer is there because
the other two components, Classic Explorer and Classic IE9 must be registered
with admin permissions. The Start Menu will run fine in "portable" mode as you
There is also the ClassicShellService, which installs on Windows 8 and Server
2012. It has 2 purposes - first, it starts the classic menu early enough so
it's ready when you log in. and second, it skips the Metro start screen.
Oh I had forgotten about that! I guess Windows 8 has not sunk into my brain as
a respectable OS to remember. :P
That being the case an install option or parameter for installing Classic
Start Menu on the Sever iteration of NT 6.2 would be desirable as Server 2012
already incorporates a faster native method for auto-loading the Desktop which
is enabled in the Windows Registry Key "ClientExperienceEnabled" under:
This requires Administrative permissions to edit...
Many Server Administrators will prefer or even require running the the smallest Service payload for the lowest profile attack surface as well as a prophylactic measure against issues that running undocumented or non-Microsoft Services can present not just technically but often administered and limited by corporate policy.
If there are other features being performed by the Classic Start service it may be beneficial to migrate them to the other Classic Start binaries to grow the appeal of Classic Start for the Enterprise/Sever market (which is considerable), and incorporate an option to use the native load method which is faster.
Processes that are launched via the Run registry key or the Startup folder
have a 5-10 seconds delay in Win8 (not sure about the server edition). The
only way I have found to start the menu as soon as you log in is with a
The "ClientExperienceEnabled" key is not a 'Run Key'. It is a feature
exclusive to Server 2012 that loads the Desktop instead of the
Metro/Modern/NCI interface first -- there is no delay, in fact it loads faster
then NCI on most systems. Windows 8 lacks the libraries for this to work on
If you should like to test this for your self you can get a free, fully
licensed copy of the Server 2012 OS (not a trail or expiring key) through
WebsiteSpark, if you'd like to
configure Server 2012 as a Workstation there's a site by IT Professionals that
documents how to do that here...
The "ClientExperienceEnabled" key is not a 'Run Key'
The "ClientExperienceEnabled" key is not a 'Run Key'
I understand. So it doesn't solve the problem "how to start the menu sooner".
The only known solution is a service.
So you have 2 options - use the service, or don't use the service and wait
5-10 seconds before you can use the start menu.
Again, this is the Sever OS; even in production deployments where it's used as
a Workstation -- overhead, corporate policy, and unknowns of running a 3rd
party service outweigh a few second delay to start an interface feature on an
OS that in most applications is rarely restarted.
Add to that on my sluggish server, Classic Shell loads in under two seconds
even if loaded via the 'Start Folder' -- but even if it was twenty seconds I'd
prefer the option for the delay without the service. I believe most Operators
and Administrators that are going to be using a GUI on the Server OS will have
Of course most
OK, if few seconds delay is acceptable, simply don't use the service. Find
some other way to launch the menu that suits your needs.
Nothing is stopping you from creating your own portable package and deploying
it to your servers.
Ok! I was just concerned that you might have plans to migrate features to the
service that make Classic Start dependent on it (as some similar projects
have)... Also some Developers don't like their work lopped up by a third
party; and I personally see your installer as a means to promoting well earned
and deserved donations.
Currently there are no plans to depend on the service, at least short term.
Adding more features to the service will make it a potential security risk.
Also the service is not used on Vista, Windows 7, or Server 2008/R2, which are
still supported platforms. So the rest of the software must work without a
As for not running the installer, I have no problem with that, as long as you
ensure that the end users still follow the EULA.
Cool Cool! As NT 6.0 - 6.1 doesn't use the service, perhaps you could add an
installer option or switch in a future build for Server 2012 and portable
installs that just calls the NT 6.0 - 6.1 install feature... Opera does this
with a 'Portable Install Option' that has apparently been quite successful in
getting more people to try the browser... Just a thought...