> on Windows

There are many ways to access the filesystem on Windows. CMD.exe and PowerShell respect `..` to go to the parent directory, as does MSVC C++17 with `std::filesystem`, and C#, with `System.IO.Path.Combine(String, String)`.

In PowerShell and C#, there's also the `System.IO.DirectoryInfo.Parent` property, and of course, the equivalent `std::filesystem::path::parent_path` in MSVC C++.

There's an important consideration 'ChrisSD mentions here[0], i.e. whether resolving ".." is done lexically or by querying the filesystem. You may get different answers in each case if e.g. you try to resolve /foo/bar/../baz, when /foo/bar is a symlink to a different directory.

At least in case of std::filesystem, everything in std::filesystem::path is purely lexical. So, to get actual parent of some path, you'll need to go through std::filesystem::directory_entry and std::filesystem::read_symlink().

--

[0] - https://news.ycombinator.com/item?id=33312712

".." works fine in Windows environments.

The difference between Windows ".." and unixy ".." is that the former is done lexically whereas the latter is a link to the canonical parent.

E.g. on Windows: "path\to\..\file" is always the equivalent of "path\file". Whereas on unixy systems "path/to/../file" may take you to a completely different parent directory.

That said, Unix shells can muddy the waters a bit. They may choose to act lexically with some commands.

> E.g. on Windows: "path\to\..\file" is always the equivalent of "path\file". Whereas on unixy systems "path/to/../file" may take you to a completely different parent directory.

Worth noting here that Plan 9 is using lexical names[1], and the Go standard library offers the function path.Clean[2] to achieve similar results. If your language/library/OS doesn't offer this behavior by default, it's likely a good idea to add/reimplement this function, unless you need bug-for-bug compatibility.

[1]: https://web.archive.org/web/20220824070659/https://9p.io/sys...

[2]: https://golang.bg/pkg/path/#Clean

It seems the only official native API for getting the parent directory from a known (full) path is PathCchRemoveFileSpec. But certainly C# and other similar platforms have functions doing similar things, and usually don't require a system API call anyway, it's just string manipulation - unless of course the path is relative to the current directory.

Hold your giggles until you learn that windows MAX_PATH is only 260 characters. Not just filename, the entire path.

Unless an app uses \\?\ prefixes and special API for navigation, which is rare, ime.