Jcee wrote: The registry changes made by classic shell only affect classic shell, something like this would persist after classic shell was uninstalled. which is one of the reasons classic shell doesn't go into it. Changes to the registry can be reversed when uninstalling and this is probably what CS does too; but that is not the issue.
CS writing some of it's own parameters to the registry while probably true, should not be confused with what a program like CS needs to do in order to affect the behavior of another application, in this case a major Windows component like Explorer. It is most probable that changing the behavior of Explorer in the ways that CS does, must involve not only changing some of Explorer's registry setting, but also some much more intimate / intrusive mechanism(s) - as NoelC has correctly assumed. In order to affect an application's behavior through the registry, that application i.e. Explorer needs to be pre-programmed to be able to respond to what is written/modified in the registry. If Explorer was pre-programmed to optionally do the things that CS offers, it would probably default to doing them itself, or at least offer them to users as setup options - which it does not and this is why a more sophisticated solution like CS is called for.
So I agree with NoelC that CS probably needs to significantly touch on Explorer's internal logic, not only on it's parameters exposed in the registry.
However
GauravK wrote: It requires modifying system files by resource hacking, a registry hack can't hide the command bar AFAIK. Out of Classic Shell's scope since it is more dangerous to modify system fileson disk. So maybe the problem the developers see is in modifying system files, as opposed to what CS probably does currently: programatically bypass / add to / replace parts of Explorer's code without ever touching its code or files (probably done by intercepting and responding at run-time to system "messages" intended for Explorer).
Of course keeping Explorer files untouched is safer than changing them, because Microsoft can later decide to change those file and this can complicate things. But I still wonder, Ivo & Co., in what way is what CS is doing right now to Explorer's internal logic (alas "from the outisde") less dangerous all-in-all than changing a single UI parameter inside a DLL ? It would seem both are somewhat dangerous, but isn't the former more prone to disaster than the latter ?
|
)
