Windows resolve() is based on ntpath._getfinalpathname, which requires that the file exists and is accessible. resolve() defaults to non-strict behavior, which tries to resolve as much as possible by traversing the path in reverse and trying _getfinalpathname until it succeeds. For this to work reliably, it needs to begin with a fully-qualified path from ntpath._getfullpathname. This is also required in order to correctly resolve paths that have a reserved DOS device name in the final component (e.g. "nul", "nul:", "nul.txt")

Additionally, for an empty path, resolve() returns os.getcwd(). I don't know whether this case occurs in practice, but the working directory has to be resolved in Windows the same as any other path. It's not already resolved.

Also, the non-strict case should be relaxed like the POSIX version. It should continue resolving the path on any OSError, with possibly one exception. The POSIX version raises RuntimeError for a symlink loop. In Windows this case is ERROR_CANT_RESOLVE_FILENAME (1921). For cross-platform compatibility, this should probably be handled by raising the same RuntimeError.