Launching the First-Class Windows Project

I’m excited to introduce the First-Class Windows Project, which aims to make OCaml more accessible by enhancing the developer experience on Windows to match that of Linux and macOS. Our goal is to create a roadmap outlining the steps needed to fully support OCaml on Windows.

Check our blog post for details: Launching the First-Class Windows Project

As always, happy to receive questions and feedback.


@sudha This will be awesome. Looking forward to it. Happy to test.

To do so, we will prototype the packaging of the OCaml platform using the following systems: the OCaml compiler distributed via VCPKG,

Sorry for the naive question, but in the past I only saw vcpkg used for C/C++ libraries; could you say a few more words about this means concretely?

Another factor we need to address is that the current system is deeply tied to Unix-based scripting, necessitating a Unix layer on Windows for OCaml to function. […] However, as part of this project, we also want to implement native Windows support and remove the Unix layer.

My understanding is that only the build system of the compiler is really tied in this way; the rest of the system is perfectly cross-platform. Could you expand a bit on this item (in particular, what “native Windows support” and “removing the Unix layer” would mean)?



Yes, this would be mainly for depexts. So it’d be using vcpkg to provide C/C++ things to opam, rather than packaging ocaml in vcpkg. Will try to clarify this in the post itself.

You’re right. The compiler is the main bit that requires a Unix layer to build. Well-written dune files shouldn’t need any Unix layer to build. In practice, though, a lot of packages require a Unix layer due to how they’re packaged. Opam supports this via Cygwin or MSYS2. I believe esy also uses Cygwin internally.

My guess is that 90+% of OCaml packages that use C require a Unix layer (typically through conf-pkg-config and ctypes-foreign).

And a Unix layer creeps into some non-C packages (ex. Use (copy) to avoid backslashes/spaces on Windows · jonahbeckford/core@ea006ab · GitHub) but those are usually easy to fix for a maintainer once identified (linter?). A search says this happens often:

As a package maintainer I wouldn’t care to fix my own Unix-isms because today building the OCaml compiler requires Unix. I’m guilty of this myself.


The Unix way is the right way. :smiley:

1 Like

Thank you for this effort! I work on Flow which has a Windows build and we have absolutely run into difficulty because the OCaml ecosystem is not very Windows compatible.

It seems like this effort is mostly focused on the experience of developing OCaml on Windows. I think this is a good focus, although my needs are a bit different. I don’t need to do much development on Windows, but I do need to create Windows binaries. Currently, the nicest way to do this is using Cygwin but using MinGW-w64 cross-compilers for the build, so the resulting binaries do not depend on cygwin.dll.

The cygwin/mingw setup works well enough for us. What does not work well is 3rd party dependencies which have C stubs, native dependencies, or build scripts that won’t run on Windows. Notably, Jane Street libraries aren’t tested against Windows, although JS devs have been welcoming of patches.

In summary, while I whole-heatedly welcome improvements to the OCaml compiler and Opam project to improve Windows support, what would help me more is better support for Windows in Opam packages themselves. Even there, I don’t mind Unix-isms, since I’m happy to cross-compile from Cygwin, although if library build scripts were compatible with MSVC as well, all the better.

Thanks again for this effort!


This seems like a good place to mention support for Debugging OCaml programs on Windows. What debuggers do Windows developers use eg what is the equivalent to lldb / gdb? Visual Studio and WinDbg seem like the obvious tools. Are there other popular options? How can the compiler support the PDB files needed for debug information?

Also what kinds of performance tools are available for Windows and how do we get OCaml programs to interact with them? Is there an equivalent to Linux perf or macOS Instruments?

The other major part of supporting Windows is getting the CI infrastructure to support testing packages on that platform. We had an early version of obuilder that supported running opam-ci, and ocaml-ci on Windows Docker Windows support / Docker backend · Issue #123 · ocurrent/obuilder · GitHub We could use someone with Windows experience to help finish that off.


That’s a very good point, thanks for bringing it up! This effort will also encompass improving the user experience of OCaml on Windows, along with the development experience, to be on par with Tier-1 platforms.

1 Like