What idiot would hard-code the path to Notepad?


There seemed to be a great deal of disbelief that anybody would hard-code the path to Notepad.

Here's one example and here's another.

There's a large class of problems that go like this:

I'm running Program X, and when I tell it to view the error log, I get this error message: CreateProcess of "C:\Windows\Notepad.exe errorlog.txt" failed: error 2: The system cannot find the file specified. What is wrong and how do I fix it?

Obviously, the file C:\Windows\Notepad.exe is missing. But how can that be? Well, Windows Server 2008 bit the bullet and removed one of the copies of Notepad. Once you learn this, troubleshooting the above problem becomes a simple exercise in psychic debugging.

My psychic powers tell me that you're running Windows Server 2008. The Notepad program no longer exists in the Windows directory; it's now in the system directory. Find the setting for your program that lets you change the program used for viewing error logs and tell it to use C:\Windows\System32\Notepad.exe.

Of course, this tip works only if the program permits you to change the program used for viewing error logs. If they hard-code the path, then you'll have to find some other workaround. (For example, you might try using the CorrectFilePaths shim.)

Comments (46)
  1. Anonymous says:

    That’s the problem with hardcoding URLs. when the internet changes, they don’t point to the right location anymore.

    Now, the equivalent to a PATH would be a search engine, but as it happens, I could not find a trace of that article. archive.org will have to do :(

    http://web.archive.org/web/20071112140003/http://support.installshield.com/kb/view.asp?articleid=Q108710

    [Fixed. Thanks. -Raymond]
  2. Alternative solution:

    copy /y %windir%system32notepad.exe %windir%notepad.exe

    What went wrong first?  That is to say, what was in the error log?

  3. Anonymous says:

    Do they really mean "c:windowsnotepad.exe" or "%SystemRoot%notepad.exe"? If the former then not just 2008 would break.

    One of the more bizzare twists is why 64bit programs end up in windowssystem32

  4. Anonymous says:

    I’ve always assumed that 64bit programs ended up in windowssystem32 precisely because so many people were hardcoding %windir%system32XXX paths.

  5. Anonymous says:

    Just wondering: How are you supposed to know where Notepad is except by hard coding it? Granted that you could, perhaps, be wrong by referencing the %WINDIR%Notepad one though I don’t know of any definitive reference as to which one was "correct" aside from your blog in ’06.

    Or is this a scenario where you want to ShellExecute instead of CreateProcess? That poses a not-so-fun challenge for Windows Installer :-

    Likely there’s something obvious I’ve missed.

  6. Anonymous says:

    Programs which have bugs like this are probably written after nt3/nt4/w2k was released. Those OS have the windows path to C:WINNT. How can any expect those progams to work? What if I hardcoded the path to c:windows2020notepad.exe today, and expected it to work when windows 2020 is released. Don’t compensate for this kind of bugs.

    notepad.exe is in the PATH, how hard could it be to start it from anywhere? A well written program can then start it from whereever, like "\serversharewin owsno pad.exe".

  7. Anonymous says:

    I think the point is that you shouldn’t be relying on notepad in the first place.  You can either use ShellExecute on the text file to have the default text editor open it, or you can have a configuration option where the user can specify which editor to use.  Notepad is probably the default editor in 95% of cases.  The only issue with the ShellExecute method is if you’re using a file extension that is not registered or registered with something else (i.e. Excel or something).

    [The problem with ShellExecute is that in the general case, you don’t know when the user closes your document. (For example, because you want let the user make changes and save the file, and your program wants to read the changes back out.) -Raymond]
  8. Anonymous says:

    I suppose you could iterate the path and run what you find. If only there was a library function I could call…

  9. Anonymous says:

    To answer the question. What idiot would hard-code the path to Notepad?

    An idiot with requirements.

  10. Anonymous says:

    I think the point is that you shouldn’t be relying on notepad in the first place.

    Why not? It’s a reasonable choice for a text viewer (as opposed to writing your own) and windows doesn’t have an EDITOR variable that you can use.

  11. Anonymous says:

    You could say the same of CreateProcess; closing a document != quitting an application.

  12. Anonymous says:

    Why not?

    Because then you have to keep multiple copies of notepad.exe on the system to maintain backward compatibility.

  13. Anonymous says:

    @John:

    DemoShield is an installation delivery technology: http://en.wikipedia.org/wiki/Packaging_%26_Deployment

    Prompting a user for the location of their favorite text editor is miserable. There are times you don’t want to move on with the install until the user closes the document. There are workarounds to some of these situations, but if you take the DemoShield situation and modernize it:

    Windows Installer has no built-in functionality to launch a text file. The only way to do this is with an EXE Custom Action, which is basically a fancy wrapper around CreateProcess.

  14. Anonymous says:

    Since Notepad is in the path, you can just call CreateProcess with "notepad.exe" and not have to worry about where it’s located.

  15. Anonymous says:

    @Bryan:

    Obviously an installer would use ShellExecute instead of prompting.  I can’t believe I had to write that.

  16. Anonymous says:

    @Bryan

    The directory containing notepad.exe is in the %PATH% variable by default.  It seems to me more sensible to just execute it without specifying an absolute path (or if you for some strange reason need an absolute path, start looking for it in %PATH% yourself), and if the user has manually removed the Windows directory or system32 from their PATH, they kind of deserve the consequences.

    PS: my captcha was 386, nice nerd significance there.

  17. Anonymous says:

    How about using the "EDITOR" environment variable like UNIX? :) ( eg crontab, cvs, svn,…)

  18. Anonymous says:

    @John:

    Windows Installer doesn’t ShellExecute, so I don’t know why you would think you didn’t have to write that.

    @Anonymous and others:

    I also over-simplified and should have been more specific, but MSI calls for the full path & file name for Type 34 Custom Actions. You might be able to just not include the Directory and have it work by luck, but most of the time that’s unacceptable risk in my experience.

  19. Anonymous says:

    The Notepad program no longer exists in the Windows directory; it’s now in the system directory

    Why not create a symbolic/hard link from c:windowsnotepad.exe to c:windowssystem32notepad.exe instead of removing it?

  20. Anonymous says:

    NSIS 4ever!!!

    :P

  21. Anonymous says:

    @Bryan:

    I meant you could invoke ShellExecute from a custom action.

  22. Anonymous says:

    Just call ShellExecute with the text file and let the OS figure out the rest.

  23. Anonymous says:

    Of course, this tip works only if the program

    permits you to change the program used for viewing

    error logs

    This sort of problem is actually one of the strongest arguments for Free Software, or for buying a source code licence for proprietary software.

    If you have access to the source code, you can fix problems like this ten years down the track, or pay someone else to fix it.

    Whenever I’m evaluating commercial third-party software, libraries and tools (which is often as a consultant & contractor) my advice is almost always: buy the source code.  

    It may be more expensive up front, but it’ll save your ass further down the track.

  24. Anonymous says:

    You might not be able to CALL ShellExecute in the first place. One example is installers – specifically Windows installer. You may also not have access to the Windows API, because your application is written in a scripting language for example.

    Hard-coding paths isn’t stupid, it may be a requirement in some cases. And since all widely-used Windows versions except Server 2008 store Notepad in both %WINDIR% and %SYSTEMROOT% you can’t know which one to use, so you’ll just pick one.

    It’s not that programmers are stupid, it’s that in some cases they don’t have a choice besides hard-coding. And how many installations of Windows have you seen in places other than C:Windows today? Exclude old NT that used WINNT.

  25. Anonymous says:

    @Duncan Bayne:

    There are cases where the source code is not available. And for sure you can’t do much to already-installed programs. Users expect their programs to work NOW after a Windows update, not later after a patch.

  26. Anonymous says:

    @Paul M. Parks:

    IIRC, Windows 6 and after won’t install on FAT drives. (That, and only an idiot would install a Windows Server on FAT.)

  27. Anonymous says:

    Somewhat @link and @paul_m._parks

    Well if windows 2008 uses winSXS and if winSXS is the real location of windows files, why is there any issue at all to have links to notepad.exe available in two folders?

    I think the ‘extra’ notepad was removed at a time past when it was necessary to do so. I guess they did the hard work to save the 68K after all.

  28. Anonymous says:

    @Mircea:

    Windows Installer has custom actions.  JScript and VBScript have Shell.Application.  NSIS has ExecShell.  Perl and Python also have wrappers around it.  I’m not saying it is always available, but it seems like those would cover a high percentage of use cases.

  29. Anonymous says:

    > And how many installations of Windows have you seen in places other than C:Windows today?

    You mean like "D:Windows" or "E:Windows" on a system with multiple partitions?

  30. Anonymous says:

    > I guess they did the hard work to save the 68K after all.

    I didn’t know Windows ran on the Motorola 68K!

  31. Anonymous says:

    For installations not in C:Windows, I worked at a company once where it was Z:Windows.  It’s amazing how much malware / viruses don’t work when you’re OS isn’t installed on the C: drive.

    -Josh-

  32. MSDN Archive says:

    Raymond, your physic powers are legendary, but what tipped you off that WS2008 was in use and not just a Windows installation to a different drive letter?  Or maybe an old Windows NT 4 installation in C:WINNT.

    Windows doesn’t need an EDITOR variable as there is always a file association for text files. That can easily be used ShellExecuteEx.

    Plus, EDITOR in Unix is about the users preferred editor (say vi or Emacs), that isn’t necessarily the preferred viewer for text or log files.

    [Psychic powers are like that. You have to pick one or the other, and my psychic powers led me to the right one. -Raymond]
  33. Anonymous says:

    Notepad is not a system program and should not be in the system folder, it should be in the program folder.  C: is being referenced as an environment variable.  C:Windows is being referenced as well, no need to hard code.

    And yes, when will you windows guys learn anything from real programmers.  There exists symbolic links that would allow to install one version of notepad and link to it from different folders.  System32 for 64 bit is a screw-up, just because you redmonders didn’t manage to fully understand superiority of symbolic links.  Come on guys, cut the crap and stop using notepad for anything from within a program.  If you really need to, do a system call with "start notepad filename" and let windows handle tracing down notepad, for everything else, embed a text-field viewer in your code.

  34. Anonymous says:

    playing devil’s advocate here, "%systemroot%notepad.exe" has a hardcoded component as well. it’s impossible to always know the good-bear way of doing things. what if Windows changes "notepad.exe" to "notes.exe" in later versions? What if the directory separator changes? What if the environment variable name changes? Then will we call "%systemroot%notepad.exe" idiotic too? Unless there’s some reasonable-to-find document that explains the proper way to launch notepad, and that confirms that you can wait on the process handle for the document to be closed, then you just can’t be safe enough.

    that being said, i agree it’s idiotic.

  35. Anonymous says:

    @Yves

    I always find it funny how people who give things the least thought seem to be the most confident that they are right.

    Do you really think Microsoft programmers didn’t consider using a symbolic link? Do you really think you considered all the possibilites more thoroughly in the thirty seconds of thought you gave the issue before commenting than the microsoft programmers did before deciding to copy the file to both locations? Raymond has even written an article covering exactly this topic, and it has been linked to in the comments above yours. Also already discussed in the comments is why "start notepad filename" will not always give required results.

    @104

    Certain things are part of the contract that Microsoft will not change, where are other things are implementation details that shouldn’t be relied on. You won’t see Microsoft articles talking about the latter.

    Even if you can’t readily find documentation, I think common sense would dictate that Microsoft aren’t about to change the file delimiter or name of the notepad executable.

  36. Anonymous says:

    @Mircea: "And how many installations of Windows have you seen in places other than C:Windows today? Exclude old NT that used WINNT."

    A random sample of the PCs currently in the room with me. 3 out of four are NOT "C:Windows".

    There are two "D:Windows"’es and an "H:Windows"

    Please please *please* never make this assumption.

  37. Anonymous says:

    >> That can easily be used ShellExecuteEx.

    IFF you want an OLE dependency.

    >> Please please *please* never make this assumption.

    Unless you are a virus/trojan writer, then please carry on.

  38. Anonymous says:

    This might sound a bit impertinence, but I’m looking for information about the winstub.exe file – in particular – what is it ? why is it needed and where can I find it’s source  ? (as for some awkward reason it no longer exists in win7 :/ )

    I’d appreciate if you could refer me to the right sources.

    Thanks in advance,

    REd.

  39. Anonymous says:

    @Porter, Lawrence,

    Windows 6+ makes the system disc always C:, no matter what partition/disc it is.

  40. Anonymous says:

    "It’s amazing how much malware / viruses don’t work when you’re OS isn’t installed on the C: drive."

    Such petty tricks are not necessary if you configured your user account right (that is, you’re running non-administrator).

  41. Anonymous says:

    > Why not create a symbolic/hard link from c:windowsnotepad.exe to c:windowssystem32notepad.exe instead of removing it?

    @link: Raymond covered this previously.

    http://blogs.msdn.com/oldnewthing/archive/2009/03/12/9471146.aspx

    He doesn’t explain why they removed it without replacing it with a link (symbolic/hard/lnk/whatever). Support for FAT file system is not a reason in Windows 2008 becauase that OS cannot be installed to a FAT FS. And the "disk space" reason is plain silly.

  42. Anonymous says:

    >> That can easily be used ShellExecuteEx.

    > IFF you want an OLE dependency.

    All OS which doesn’t have c:windowsnotepad.exe do have the ShellExecuteEx() function.

  43. Anonymous says:

    > All OS which doesn’t have c:windowsnotepad.exe do have the ShellExecuteEx() function.

    All OS which have ShellExecuteEx have ShellExecuteEx as an OLE dependency. All OS which have ShellExecuteEx have CreateProcess which will happily search for notepad.exe on the path.

  44. Anonymous says:

    You might not be able to CALL ShellExecute in the first place. One example is installers – specifically

    But, I guess you can call start.exe, which, in turn, calls ShellExecute.

    e.g. to open readme.txt, just CreateProcess "start path/to/readme.exe"

    Hard-coding paths isn’t stupid, it may be a requirement in some cases.

    Launching notepad may be a requirement… But hard-coding its path… Why?

    And since all widely-used Windows versions except Server 2008 store Notepad in both %WINDIR% and %SYSTEMROOT% you can’t know which one to use, so you’ll just pick one.

    Hard coding is using "c:windowssystem32notepad.exe", and won’t work with alternative windows setups (e.g. d:windows or c:windows_new_install)

    Using %SYSTEMROOT% or %WINDIR%, is, indeed, much better.

    Ideally, just run "notepad readme.txt", because notepad is in the PATH.

  45. Anonymous says:

    @Alexander Grigoriev

    "Windows 6+ makes the system disc always C:, no matter what partition/disc it is."

    Not if you’ve upgraded from Windows 5.1

Comments are closed.