[ANN] State of OCaml Platform on Windows

Community
21

Ok, but what does "OCaml itself " mean? Compilers? Tools? What does “cygwin” mean? Everything or just the dll? Is cygwin required for the build process (ie cygwin Tools) or for the built artifacts (e.g. the dll), or both?

22

Or to put it a little more perspicuously: what would it take to eliminate the dependency on cygwin?

1 Like
23

It means the build process of the whole OCaml toolchain, which today depends on Autconf, Make, Awk, Sed, etc. On Windows, these tools are provided by Cygwin. The dependency is only for the build process, the final artifacts of the native Windows ports have no dependency on Cygwin.

There are many possibilities, see [ANN] State of OCaml Platform on Windows - #17 by dra27.

Cheers,
Nicolas

2 Likes
24

I’ll summarize two things from the Tarides | Feature Parity Series: Restoring the MSVC Port (2025-04-23) blog post that I find relevant to this thread:

  1. there was a years-long delay supporting MSVC on OCaml 5 because the atomics model was not designed with MSVC in mind, and
  2. a shim for pthreads was made for MSVC (aside: it sounds from the blog that it is getting rolled back)

Both are examples of a reliance on a Unix-first way of doing things, which work great when the first-class target is GCC+POSIX 64-bit nativecode. More examples in the footnote [1]. But these types of Unix-purist design decisions can’t be made if Windows 64-bit nativecode is to become a first-class citizen in the future. So, I’d also like to suggest that unless Windows is part of the design decisions for GitHub - ocaml/ocaml: The core OCaml system: compilers, runtime system, base libraries (that means buy-in from the core compiler team possibly even to revisit some of the old decisions) … you may be chasing a never-ending set of papercuts/backlogs/etc trying to make Windows first class.

Thanks for assembling the doc!

[1] Other Unix/GNU centricisms I’ve seen over the years: MinGW, autoconf, pkg-config, Make, having a system package manager, /bin/sh, flat namespaces for linking, using expansive file trees to substitute for databases, having to escape spaces and backslashes everywhere, reliance on the terminal

7 Likes
25

Yes thanks that’s what was wondering. Sorry for not being more clear.

26

Sorry for being dense but I’m confused: if the built compilers tools etc do not depend on cygwin, doesn’t that make them first class citizens? If not does that mean the codebase itself contains unix-to-win adapter code? Like I can imagine that process management is very different and complex. What is needed to make win64 a first-class citizen?

27

Well done, sir. Recursion everywhere!

28

Two unrelated issues in that tiny question!

What is meant by “first class”.

I wouldn’t call anything first class if the intended audience gets delivery years after other users … regardless on what the delivered tool depends upon. That is what happened with the Windows MSVC users. In other words, “first class” is how a user base is treated with respect to priority and user experience. You may have a different definition.

What is meant by “Cygwin”.
I think it would be best to think of “Cygwin” as an analog of “Debian”. And it would be weird to speak of “if the built compilers tools etc do not depend on Debian cygwin”. However, it would be natural to speak of “if the built compilers tools etc do not depend on libc.so.6 and libm.so.6” … since all of those dependencies are provided with the conventional Debian build-essential packages. Just like conventional Cygwin build packages makes all of your compiled executables depend on cygwin1.dll.

But we don’t have to follow the convention. We can install musl-gcc into Debian to get rid of the libc.so.6 … and we can install MinGW into Cygwin to get rid of the cygwin1.dll.

Usually when people are talking about the Cygwin build process with OCaml, they are talking about Cygwin + MinGW.

2 Likes
29

I second that, the opam-cross-windows project is not experimental but quite mature and can be used for fairly large codebases.

1 Like
30

(W17) Debugging
… only DkML will get you access to PDBs for C runtime analysis…

That’s not quite accurate, getting PDBs for the C runtime on Windows is a function of the C compiler flags. There is no technical reason why MSVC, gcc or clang-cl won’t generate debugging information.

31

Perhaps an obvious question, but does the standard library work on Windows? Some of the APIs like In_channel/Out_channel seem specific to Unix

32

Yes.

No. Everything in the standard library generally works on Windows, unless documented otherwise. Even the ill-named Unix library does, up to a few exceptions.

2 Likes
33

May I ask why you thought they were Unix-specific?

34

Because there’s some Unix specific stuff in the APIs. Like how do file permission codes work on Windows? Windows doesn’t have a 1-1 equivalent to Unix file permissions. Or what about paths and string encodings? Does the standard library return paths in the system encoding or convert to UTF-8 when possible? If it’s the system encoding, then how does that interact with string manipulation functions?

As an example, here’s a comparison of Rust and Go’s standard library APIs.

1 Like
35

I admit I don’t know, it’s a good question. And it should be documented.

what about paths and string encodings? Does the standard library return paths in the system encoding or convert to UTF-8 when possible?

The standard library does not automatically convert strings into UTF-8. So I expect the file names will be in the system encoding. But it might be worth documenting this as well!

36

Yeah in retrospect my question was ill-posed, in that “working” is not a binary state. Like the standard library compiles and when functions are called, nothing crashes. But ideally we’d want to have some cross platform abstractions, and avoid unexpected behavior or footguns. For instance the paths one is quite tricky, because UTF-16 is not compatible with 8 bit ASCII, so any string operations could totally mangle a UTF-16 string.

37

The standard library, unix, etc all use UTF-8, converting to- and from- UTF-16 as needed: ocaml/README.win32.adoc at trunk · ocaml/ocaml · GitHub.

This works seamlessly for the most part.

No, there is no 1-1 equivalent, but the Windows API contains a partial POSIX compatibility layer that interprets the read and write-permissions for the current user, and the unix library uses that; see eg _chmod, _wchmod | Microsoft Learn.

There is not much more that can be done cross-platform here since the permission models are so different between Unix and Windows.

Cheers,
Nicolas

2 Likes
38

Thanks for the explanation! I think what could be done is refactoring the standard library to have a core that is completely platform agnostic, i.e. no file permission codes, and have separate platform specific extensions to that agnostic base.

39

This sounds like a good idea, but also a lot of work :slight_smile:

A good first step would be to design and implement these platform-specific libraries outside of the compiler. That allows for quick development and easy experimentation. Once they stabilize and prove themselves, the possibility of bundling them with the compiler could be discussed.

Also, and just to dispel any misunderstandings from this line of discussion, I want to offer as a counterpoint that LexiFi has been developing on Windows with OCaml for over 20 years and 90% of our needs are satisfied by the standard library + unix. So while they may not look very imposing at first sight, these libraries have stood the test of time and are quite capable all in all.

Cheers,
Nicolas

5 Likes
40

I agree, and imho we can get some very quick and easy wins by adding documentation about the issues that have been raised here directly in the library docs.