Support for Windows #11

New Issue

2025-12-30T01:19:26+01:00

adam commented

2025-12-30 01:19:26 +01:00

Originally created by @AustinWise on GitHub (Feb 3, 2024).

Support for the Windows platform would be nice. As a member of the open source community (not acting officially with any company), here are some things I noticed that stand in the way of full Windows support.

Cloning the repo on Windows

Currently the Git repo cannot be cloned on Windows.

This file has a backslash in its name:

pkl-core/src/test/files/LanguageSnippetTests/input-helper/globtest/\moduleC.pkl

Since Windows uses the backslash a path separator, it is unable to create this file. Cloning fails with this error message:

error: invalid path 'pkl-core/src/test/files/LanguageSnippetTests/input-helper/globtest/\moduleC.pkl'
fatal: unable to checkout working tree

I tried working around this by doing a sparse checkout and have not had success. Git appears to validate path names before applying the sparse checkout filter.

Additionally, there are two directories with colons in the name. By default Git on Windows does not like these paths, but that could be worked around by setting git config core.protectNTFS false.

pkl-doc/src/test/files/DocGeneratorTest/output/data/localhost:12110
pkl-doc/src/test/files/DocGeneratorTest/output/localhost:12110

Building on Windows

Not yet attempted.

CI support for Windows

Net yet attempted

Release builds on Windows

Net yet attempted

Originally created by @AustinWise on GitHub (Feb 3, 2024). Support for the Windows platform would be nice. As a member of the open source community (not acting officially with any company), here are some things I noticed that stand in the way of full Windows support. # Cloning the repo on Windows Currently the Git repo cannot be cloned on Windows. This file has a backslash in its name: [pkl-core/src/test/files/LanguageSnippetTests/input-helper/globtest/\moduleC.pkl](https://github.com/apple/pkl/blob/main/pkl-core/src/test/files/LanguageSnippetTests/input-helper/globtest/%5CmoduleC.pkl) Since Windows uses the backslash a path separator, it is unable to create this file. Cloning fails with this error message: > error: invalid path 'pkl-core/src/test/files/LanguageSnippetTests/input-helper/globtest/\moduleC.pkl' > fatal: unable to checkout working tree I tried working around this by doing a sparse checkout and have not had success. Git appears to validate path names before applying the sparse checkout filter. Additionally, there are two directories with colons in the name. By default Git on Windows does not like these paths, but that could be worked around by setting `git config core.protectNTFS false`. * pkl-doc/src/test/files/DocGeneratorTest/output/data/localhost:12110 * pkl-doc/src/test/files/DocGeneratorTest/output/localhost:12110 # Building on Windows Not yet attempted. # CI support for Windows Net yet attempted # Release builds on Windows Net yet attempted

adam closed this issue

2025-12-30 01:19:26 +01:00

adam commented

2025-12-30 01:19:27 +01:00

@bioball commented on GitHub (Feb 3, 2024):

Evidently enough, we haven't tried developing on Windows yet :D

Thanks for the report. We do plan on supporting Windows, so this is helpful.

@bioball commented on GitHub (Feb 3, 2024): Evidently enough, we haven't tried developing on Windows yet :D Thanks for the report. We do plan on supporting Windows, so this is helpful.

adam commented

2025-12-30 01:19:27 +01:00

@AustinWise commented on GitHub (Feb 4, 2024):

In the short term, I found a work around: checkout the code in WSL and point IntelliJ at it:

https://www.jetbrains.com/help/idea/how-to-use-wsl-development-environment-in-product.html

@AustinWise commented on GitHub (Feb 4, 2024): In the short term, I found a work around: checkout the code in WSL and point IntelliJ at it: https://www.jetbrains.com/help/idea/how-to-use-wsl-development-environment-in-product.html

adam commented

2025-12-30 01:19:28 +01:00

@bioball commented on GitHub (Feb 5, 2024):

I am re-purposing this issue to track Pkl support for Windows, and pointing other issues to this one.

@bioball commented on GitHub (Feb 5, 2024): I am re-purposing this issue to track Pkl support for Windows, and pointing other issues to this one.

adam commented

2025-12-30 01:19:28 +01:00

@ghyatzo commented on GitHub (Feb 6, 2024):

Is it possible to build native executables on windows as of now?

@ghyatzo commented on GitHub (Feb 6, 2024): Is it possible to build native executables on windows as of now?

adam commented

2025-12-30 01:19:29 +01:00

@odenix commented on GitHub (Feb 7, 2024):

A great first step would be to fix the Git clone issues. They block all other work/contributions.

@odenix commented on GitHub (Feb 7, 2024): A great first step would be to fix the Git clone issues. They block all other work/contributions.

adam commented

2025-12-30 01:19:29 +01:00

@AustinWise commented on GitHub (Feb 7, 2024):

I updated the description of the issue to reflect the broader scope that as been assigned to this issue. I don't know know how issue editing permissions work in GitHub, so feel free to update the issue description as you see fit. Or close this in favor an issue that the maintainers of this project control if that is more convenient.

@AustinWise commented on GitHub (Feb 7, 2024): I updated the description of the issue to reflect the broader scope that as been assigned to this issue. I don't know know how issue editing permissions work in GitHub, so feel free to update the issue description as you see fit. Or close this in favor an issue that the maintainers of this project control if that is more convenient.

adam commented

2025-12-30 01:19:29 +01:00

@holzensp commented on GitHub (Feb 9, 2024):

Is it possible to build native executables on windows as of now?

It is not actively supported. @translatenix makes a valid point about cloning needing to be fixed first. Native executables are part of "done" for this issue.

@holzensp commented on GitHub (Feb 9, 2024): > Is it possible to build native executables on windows as of now? It is not actively supported. @translatenix makes a valid point about cloning needing to be fixed first. Native executables are part of "done" for this issue.

adam commented

2025-12-30 01:19:29 +01:00

@jack3898 commented on GitHub (Feb 12, 2024):

Extending the above comments about WSL, you can simply type bash in PowerShell to put your current terminal instance into a WSL bash shell. It's what I have been doing to test this on Windows. Saves faffing about with cd 🤣

@jack3898 commented on GitHub (Feb 12, 2024): Extending the above comments about WSL, you can simply type `bash` in PowerShell to put your current terminal instance into a WSL bash shell. It's what I have been doing to test this on Windows. Saves faffing about with `cd` 🤣

adam commented

2025-12-30 01:19:30 +01:00

@mitchcapper commented on GitHub (Feb 23, 2024):

Some additional items to add to this:

Paths on windows are not case sensitive but things like internal whitelisting checks are. AKA --allowed-modules file:///c:/myPath/to/Something will fail when it expects a capital drive letter --allowed-modules file:///C:/myPath/to/Something will work
backslash paths explode, windows allows forward slash paths too though so can work around
Windows absolute paths fail as file:// is not appended as it is for linux paths, calling with "c:/myPath/to/Something/test.pkl" when adding "c:/myPath/to/Something" will fail with "MalformedURLException: unknown protocol: c"
/myPath/to/Something is transformed into: file:///myPath/to/Something ; ./myPath/to/Something is transformed to file:///C:/myPath/to/Something ; c:/myPath/to/Something just fails (per above) ; file:///c:/myPath/To/Something will work, but is not whitelisted by either of file:///myPath/to/Something / file:///C:/myPath/to/Something there is https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfinalpathnamebyhandlea which will return the full final path to the handle opened it will return it like FinalPath: \\?\C:\myPath but that is easy enough to translate to file:/// form.

@mitchcapper commented on GitHub (Feb 23, 2024): Some additional items to add to this: - [ ] Paths on windows are not case sensitive but things like internal whitelisting checks are. AKA `--allowed-modules file:///c:/myPath/to/Something` will fail when it expects a capital drive letter `--allowed-modules file:///C:/myPath/to/Something` will work - [ ] backslash paths explode, windows allows forward slash paths too though so can work around - [ ] Windows absolute paths fail as file:// is not appended as it is for linux paths, calling with "c:/myPath/to/Something/test.pkl" when adding "c:/myPath/to/Something" will fail with "MalformedURLException: unknown protocol: c" - [ ] `/myPath/to/Something` is transformed into: `file:///myPath/to/Something` ; `./myPath/to/Something` is transformed to `file:///C:/myPath/to/Something` ; `c:/myPath/to/Something` just fails (per above) ; `file:///c:/myPath/To/Something` will work, but is not whitelisted by either of `file:///myPath/to/Something` / `file:///C:/myPath/to/Something` there is https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfinalpathnamebyhandlea which will return the full final path to the handle opened it will return it like `FinalPath: \\?\C:\myPath` but that is easy enough to translate to file:/// form.

adam commented

2025-12-30 01:19:30 +01:00

@Ai-N3rd commented on GitHub (Mar 14, 2024):

Please fix this. I want to try to mess around with Pkl but only own a windows machine.

@Ai-N3rd commented on GitHub (Mar 14, 2024): Please fix this. I want to try to mess around with Pkl but only own a windows machine.

adam commented

2025-12-30 01:19:31 +01:00

@mitchcapper commented on GitHub (Mar 14, 2024):

@Ai-N3rd my PR #241 or #237 include details on how to acquire and use the java version of PKL on windows. Not the most convenient given some of the above but it certainly works.

@mitchcapper commented on GitHub (Mar 14, 2024): @Ai-N3rd my PR #241 or #237 include details on how to acquire and use the java version of PKL on windows. Not the most convenient given some of the above but it certainly works.

adam commented

2025-12-30 01:19:31 +01:00