Why does PathIsUNC say that paths that begin with \\?\ are not UNCs?


An application vendor opened a bug with the product team saying that the Path­Is­UNC function was returning incorrect values in Windows Vista. Specifically, the Path­Is­UNC function was returning FALSE for strings that begin with \\?\, whereas Windows XP returned TRUE.

The answer is, "Yes, the Path­Is­UNC function returns FALSE for strings that begin with \\?\. Because they aren't UNCs."

There was a bug in the Windows XP version of the Path­Is­UNC function where it reported that anything that began with two backslashes was a UNC, even if it wasn't. In particular, paths that begin with \\?\ are not UNCs, unless they happen to begin with \\?\UNC\. The bug was fixed in Windows Vista so it returned TRUE only if the \\?\ is followed by UNC\.

Fortunately, the application compatibility team had a ready answer for this: The Emulate­Old­Path­Is­UNC compatibility shim returns the Path­Is­UNC function to its old behavior that is bug-for-bug compatible with Windows XP.

Comments (15)
  1. Juan says:

    The compiler should give a warning somehow saying. Look this only for compatibility issues and IT IS A BUG. Use PathIsUNC instead and treat UNCs correctly.

    1. The MAZZTer says:

      There is no way for the compiler to know if you are relying on the buggy behavior or not.

      But it doesn't matter, since the buggy behavior will only be exposed to OLD apps. Windows XP is no longer supported so this is no longer an issue, as any supported new app will be using the fixed function.

      1. Josh B says:

        I wish I was as confident. Almost any old CodeProject page is littered with comments asking why it doesn't work on a new OS and asking for fixes or even blaming Microsoft for breaking it. People telling each other to turn on compatibility flags (in the installer!) is par for course, or just breaking it in such a way that the OS automatically applies them. In fact, it's not just old samples, quite a few new ones rely on old and broken things that the compat team has made work.

        1. smf says:

          Sites like Codeproject should be a starting point for you learning how to do something, not a place to go to copy and paste code that you don't understand just so you can get a brownie. It is impossible to stop the inept from doing bad things.

        2. smf says:

          Sites like Codeproject should be a starting point for you learning how to do something, not a place to go to copy and paste code that you don't understand just so you can get a brownie. It is impossible to stop the inept from doing bad things.

  2. IanBoyd says:

    Does the shell ever look at the `supportedOS` entries of an application's assembly manifest in order to decide what behavior to emulate? The supportedOS guids were added starting with Windows Vista. The downside of depending on a developer adding those entries to their assembly manifest is that no applications (±1%) do it. So the vast majority of applications would not get the fix for free.

    Are there rules about who is, and is not, allowed to alter behavior based on the assembly manifest's declared supported operating systems?

    1. skSdnW says:

      SupportedOS GUIDs are 7+(*1), the Vista GUID let's 7 treat it as a Vista app (knows about UAC and DWM etc) although I don't think I have seen any documentation about the difference between the Vista GUID and no GUID.

      *1 "Windows 7 introduces a new section in the application manifest called "Compatibility."" https://msdn.microsoft.com/en-us/library/dd371711(v=vs.85).aspx

    2. Antonio Rodríguez says:

      You already answered yourself when you said only 1% of binaries include a supportedOS entry. The loader (not the shell) may look at it, but with such low usage, it would be really dangerous to use its presence (or, in this case, its absence) to apply a compatibility shim on the fly. On the other hand, if it had been defined in the times of NT 3.1 and its use enforced, it would be safer. When will that time machine be ready, I wonder?

      1. skSdnW says:

        The shell looks at the exe type in some instances to help out with short paths etc. but those are Win95 era workarounds. In Vista the ImageVersion field in the PE header is compared to 6.0 in some places and will skip compatibility behavior if it is 6.0.

  3. While I understand the need for compatibility... I would argue that "PathIsUNC" is named for exactly what it does... if you don't want to trust the OS to determine UNC paths, write your own logic instead of asking the OS.

    Really, if anything, I would hope (and assume) that the XP bug was fixed in a hotfix, not ignored until the next major OS release.

    1. smf says:

      I doubt XP was fixed because it didn't include the shim framework and would therefore be difficult to provide both the old and busted and new hotness functionality. Line of business app compatibility is the no. 1 priority at Microsoft, if Linux ever becomes popular then they'll have to eat a tonne of humble pie.

      1. McBucket says:

        Linux is already popular. It's called "Android".

        1. smf says:

          Google said it isn't (in 2009). http://arstechnica.com/gadgets/2009/02/an-introduction-to-google-android-for-developers/

          Compatibility doesn't appear to be high on google's list in any event.

  4. Brian_EE says:

    But wait! What if I named my server "?"

    1. smf says:

      Go on try it. While you are at it, create a user called ..

  5. immibis says:

    Isn't this the same sort of bugfix as making `IsBadReadPtr` etc use `VirtualQuery` (instead of trying to access the address, and catching access violations)?

    I'm guessing it's a case of different teams having different boundaries between "acceptable bug fixes" and "bug fixes that would break compatibility".

Comments are closed.

Skip to main content