Daniel Lacasse

The problem seems to be related that [`FileOrUriNotationConverter` thinks](https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/api/internal/file/FileOrUriNotationConverter.java#L114-L121) a Windows absolute path is a `URI`. Then, that URI is bubble up to `AbstractFileResolver#convertObjectToFile` (https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/api/internal/file/AbstractFileResolver.java#L126). Presumably, on Windows [`FileOrUriNotationConverter` will...

@eriwen This seems to be more of a core issue than native one. I updated the title and description. The result is the same if you have a `build.gradle` script...

Be mindful this workaround is all about compiling C sources with a C++ compiler. Generally the outcome will be the same but the code is subject to the C++ standard...

That's what I thought. I encountered the same issue when I was comparing the commits. Kind of disappointing that the `.rc` files are treated as binary files.

I like what you did with this PR. I wonder if passing `prefix` is necessary given that all new examples ignore it and the standard implementation always uses the same...

You have to close the app to work around this issue.

Looking at implementing something similar as part of my current "TempDir" extension, I think it would be important to ensure `Factory` can be `AutoCloseable` as, for example, `Jimfs` are `AutoCloseable`...

Great, I just noticed the example didn't close the FileSystem object and though about mentioning it for completeness. You are right that it won't change the current architecture.

See PR: https://github.com/NationalSecurityAgency/ghidra/pull/456

I think the `WindowsResourceCompile` task can be used without any tie to the software model. It may not be able to keep task lazy but that is a different issue....