Ocaml works fine on windows with the mingw and msys toolchain. Cygwin is 
not needed. What you are doing with (1) and (2) would be duplicating msys.

With regards to (4), you need at the very least to be able to parse 
header files correctly, & provide link stubs. This would again be 
duplicating parts of the mingw toolchain.

In addition, binding to C code is not just a matter of wrapping the bare 
C functions. First C function declarations are underspecified (is char* 
a string? is int* an array of ints or a pointer to an in-out parameter? 
How long is the array?). Second, C types do not always match easily to 
ML types (converting C to ML is easy, the other way round is often 
harder). Third, it is often necessary to do extra processing in an FFI 
function i.e. between receiving the ocaml parameters and calling the c 
function.

(3) would be nice, though. And fleshing out the non-functional win32 
stubs in the Unix library (fork etc).

Regards,

Elliott

Kuba Ober wrote:
> I've looked briefly at what it'd take to have OCaml
> fully working natively (with mingw/VS), without any Cygwin
> needed for compilation.
>
> What I've surmised is this:
>
> 1. I need some "hacked up" make implementation, good enough just
>    to let it build; this would be a-la web2c in concept. This "make"
>    would implement bits and pieces of make, bash and sed -- just
>    the bare minimum needed to get it going. The goal is for people to
>    have bare mingw or VC and have OCaml build for them.
>    The functionality needed is quite minimal, so requiring people to
>    actually pull full sed, bash and make would not be necessary.
>    I would prototype it in Qt (it's quicker that way),
>    and then port it to "bare" C++ as time permits.
>
> 2. I need to get OCaml to use nasm instead of masm. I would go as far
>    as completely pruning any masm references from OCaml -- there is just
>    no need for masm when a good, free alternative exists. nasm is a single
>    standalone executable -- you can't get much better than that. Heck, it
>    works on unixes too, so it could be used on all platforms. gas is horrible
>    too -- it's only raison-d'etre is to process output from gcc.
>    Masm exists in "alternate reality" and the legality of its use is dubious.
>    So-called masm9/masm10 (non-Microsoft products) have licenses which are a
>    slap in the face and don't deserve a second look.
>
> 3. I need to look at the bytecode debugger and figure out why doesn't it work
>    on non-Cygwin builds.
>
> 4. I need to get OCaml to generate C binding code using assembly, without a
>    need for C compiler. It's easy enough and removes one big dependency from
>    OCaml. I don't know if OCaml side of things is expressive enough (whether
>    you can pass parameter/struct descriptions without use of C per se),
>    but it should generally work just fine.
>
> Can anyone add to/elaborate on this list?
>
> Cheers, Kuba
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>