On Unix systems, bytecode executables by default are shebang "scripts" where the #! points to ocamlrun (or a trivial sh script which exec's ocamlrun). However, even on Unix not all systems have supported shebang scripts, and there has always been an alternative executable stub, written in C, living in stdlib/header.c. On Windows, where the shebang mechanism is never available, the executable is always required. However, the code is different and it lives a separate life in stdlib/headernt.c. Today, all the Unix systems which can run OCaml also support shebang scripts but, mainly for historical reasons, the Unix version of the executable header remains because the Cygwin port of OCaml (which is a Unix-like clone running on top of Windows) uses it.

Relocatable OCaml changes the mechanism by which these normal bytecode executables find ocamlrun. This primary goal of this PR is to unify the common parts of header.c and headernt.c because the common code between the two is much larger in Relocatable OCaml. Along the way, there are a few minor differences of behaviour / bugs which can be addressed.

The final commit then merges headernt.c into header.c. This last part is not strictly necessary, but I propose is a good idea. It creates the following structure:

/* header.c */

/* "Header" - platform-specific code to support "Common" */
#ifdef _WIN32
/* Windows-specific stuff */
#else
/* Unix-specific stuff */
#endif

/* "Common" - functions shared with both implementations */

/* "Main" - the header entry point */*
#ifdef _WIN32

_Noreturn void __cdecl wmainCRTStartup(void)
{ /* ... */ }

#else

int main(int argc, char *argv[])
{ /* ... */ }

#endif

In this PR, the "Header" is quite large for both implementations, "Common" is fairly small and "Main" is a similar size for each. With Relocatable OCaml, and with some additional fixes I propose afterwards, "Common" becomes much larger and the Unix part "Header" becomes very small. I think it will be slightly easier to maintain just stdlib/header.c rather than adding a third stdlib/header_common.c.

In terms of review, I suggest that it's worth reviewing the final form of stdlib/header.c as it ends up (i.e. as if it were a new file, rather than a diff) and then viewing the commits as the pathway from the current state to that. The commits along the way:

• Deal with a minor typo from #12751 affecting recompilations of the header
• Deal with a regression of 1bbd7c9 in #1200 - the switch to use wmain as the entrypoint caused a considerable increase in size of the executable header, which was the purpose of the original patch. On my laptop, the Linux executable header (in Ubuntu 24.04) is ~14KiB and the Cygwin header is about 10KiB (just for comparison). With the invocations corrected, the x64 mingw-w64 header reduces by 12KiB to 5KiB (x86 by 9.5KiB to 4.5KiB) and the MSVC x64 header by 8.5KiB to 4KiB (x86 by 7KiB to 3.5KiB)
• I have observed problems with stripping the MSVC header (which was enabled in #13282) - in this instance it was reducing it in size slightly and corrupting it in the process
• By including <stdint.h> in caml/exec.h, caml/exec.h becomes "standalone" (which is useful in further work not to leak lots of other things from caml/mlvalues.h)
• Technically, the Unix version of the executable header was leaking a file descriptor across the exec call
• Although the RNTM section is not normally given a relative PATH, by switching from execv to execvp, we have the same semantics for the call between header.c and headernt.c

For information, the work I wish to stack on top of this:

• Relocatable OCaml updates code shared between the two C files, which is the motivation for wanting to unify the common portions of both headers first
• The Unix version of the header (which is actually used by the Cygwin port) will benefit from having access to caml_executable_name - I propose sharing all the PATH-searching code with runtime/unix.c, especially as it's duplicated inconsistently at the moment
• I wish to address this long-standing piece of weirdness (what's going on is left as an exercise to the reader...):

C:\Users\DRA>ocamlopt.byte -vnum
5.3.0

C:\Users\DRA>ocamlopt.byte.exe
No input files

C:\Users\DRA>ocamlopt.byte
no bytecode file specified

and the fix for that similarly involves changes in both header.c and headernt.c otherwise.