Why is the StartRunNOHOMEPATH policy so very specific about what it does?


The Start­Run­No­HOME­PATH policy affects whether the user's HOME path is the current directory when you run a program from the Run dialog. But that's all it does. DWalker asks, "I wonder why the behavior is different between Start and Start.Run."

The Start.Run dialog is not related to the Start menu. It's just some dialog box that happens to be directly invokable from Start. This dialog is also used by Task Manager when you say File.New Task, and you can also invoke it programmatically.

The search box on the Start menu is a search box, not a run box. Its job is to use what you typed as the basis for a search and present you a list of matches, and to execute the top match if you press Enter. That it runs Notepad if you type N-O-T-E-P-A-D is a consequence of the search rather than any attempt to run the command line "notepad".

As for why the policy is so narrowly-defined, a lot of that falls back to the customer who requested the policy in the first place. Many policies are the result of direct requests from IT departments who want to control some very precise aspect of the system because it affects their network or otherwise creates a burden on their computing infrastructure. You can usually spot these types of policies because of their extremely precise formulation.

morlanweb wonders if there are equivalent policies for other launch points. Given that the Start­Run­No­HOME­PATH policy was created in response to a specific customer request, it stands to reason that corresponding policies for other launch points would exist only if a customer requested them. And so far, no corporate IT department has asked for them.

As a rule, IT departments do not notify us when they no longer need a policy, so these random strange-looking policies can linger for a long time without any real clients. Not that it would help, because once the policy is published, any other company's IT department could start using it without telling us.

These special one-off policies are tested primarily by the customers who requsted them. If the policy implementation solves their problem, then that's that. This helps to shift the support burden of the policy from the product team to the individual who requested the policy. If a service pack or a future version of Windows causes the policy to behave strangely, we rely partly on the customer letting us know. In a sense, the loser become responsible for testing his check box.

Comments (9)
  1. Joshua says:

    "The loser becomes responsible for testing his checkbox." Good. Among other reasons this ensures the box solves the actual problem.

    It's pretty obvious this box predates vista and doesn't solve its problem anymore.

  2. Adam Rosenfield says:

    For those who missed it, that last sentence was a subtle reference to blogs.msdn.com/.../9416485.aspx .

  3. Dan Bugglin says:

    @Adam Haha, I stumbled on this comment in there: blogs.msdn.com/.../9416485.aspx

    Gotta wonder what he thinks about Windows 8 and Windows 10. I disagree with his argument about Windows 7, but looking back it does likely apply to Windows 8 since it would seem users did not like the "one size fits all" attempt at a tablet and desktop UI. Windows 10 in fact uses such a "loser checkbox" with two different start menus, though I am sure they share a lot of code especially with the tiles UI.

  4. Rick C says:

    Interesting article, with the insight into how some "features" make it into Windows.

  5. morlamweb says:

    Thanks, Raymond, for answering my question. I'm glad to see that my question helped us get a greater understanding of these obscure policies.

  6. DWalker says:

    That explains it!  Thanks, Raymond.

  7. Gabe says:

    At first I read "NOHOMEPATH" as "NOHOMEOPATH", and wondered what Windows has against alternative medicine quackery.

  8. 640k says:

    Once again, please stop adding useless features that increases your maintenance cost! When will you learn, never? You should actually start *deleting* code. No one wants bloated software. Do one thing, and do it well.

    "This helps to shift the support burden of the policy from the product team to the individual who requested the policy"

    No it does NOT. If the individual have any problems at all with the feature, YOU will be the one responsible for fixing it, and that will require double amount of work. For YOU.

    Or as in most cases, the individual detects problems but cannot be bothered to post an issue to a non-cooperative support department, and solves the problem in another way himself using a good enough work-a-round. Result: Useless code in the code base + Angry customer.

Comments are closed.

Skip to main content