Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
OCaml for Windows: a suggestion
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Chris Hecker <checker@d...>
Subject: Re: OCaml for Windows: a suggestion

A couple of suggestions were made for the Windows OCaml port.  I disagree with both.  I'll get to the details in a moment.  

First, it's important to know what your goals are.  Is the goal to make OCaml more widely used for production code on Win32?  That would be my goal if I were running the OCaml project.  Is the goal to make it more "open source" and less dependent on commercial software?  That's a fine goal as well, but it conflicts in some ways with the former goal.

1. making the port a gcc port rather than an msvc port

The reality of the situation is that almost all production programmers on Win32 platforms use msvc.  Moving the port to a gcc variant would just make it even harder for those people to try out ocaml if they ever want to build the compiler.  It will also have a perception problem with professional programmers, who don't take gcc on Win32 very seriously (for lots of good reasons).  And finally, if the port is done in such a way that a standalone runtime ocaml .exe cannot be produced that doesn't depend on cygwin or other nonstandard dlls, it would be a complete disaster and would forever relegate ocaml to research work.

2. moving most of the runtime code into DLLs

This would be fine as an option, but there has to be a way to make a standalone exe that only depends on default installed Win32 dlls (user32.dll, kernel32.dll, advapi32.dll, ws2_32.dll, etc.).  If I have to send a bunch of dlls along with my exe for anybody to use my program then I'm _MUCH_ less likely to use ocaml for anything real.  It just increases my support burden.  I'm actually dealing with this right now.  I want to use ocaml for doing a small OpenGL program, but both available graphics libraries (LablTk and LablGtk) require a bunch of other dlls and installation.  It's making me think twice about using ocaml for this program, because I either have to tell people to install those packages, or I have to write my own quick Win32 layer (hopefully if I choose this path I can use the Togl code and I won't have to wrap OpenGL manually).

My suggestions are the following, in order of importance for the first goal above (to make OCaml more likely to be used by professional Win32 programmers for real programs):

1.  Overloading.  Yes, I know, not a Win32 feature.
2.  Module recursion.  Ditto.
3.  Generics.  Ditto again.

4.  A Win32 programming interface, possibly auto-generated from winuser, wingdi, winbase, etc.  I am a huge fan of cross platform development, but it's important to face facts here:  none of the cross platform gui libraries are ready for real production work in the competitive Win32 commericial software industry.  I'm sure people will argue with this and say "our company shipped SuperMoleculeViz on Solaris with Tk and it was great!"  This is not the same thing.  Those libraries are a long way from letting me do an interface that's as tight and professional (notice I didn't say good :) as one of the Office apps, or any other professional Win32 app.  I do not think anybody has to spend years trying to make a beautiful OO encapsulation of Win32 (as if such a thing was possible), nor do they have to mimic the heinosity that is MFC.  Just allow me to write a Win32 app in all its platform-specific glory if I want to.  This probably means we need to make sure you can include resource files (I wonder, would the resource compiler just work on an ocaml .exe?  hmm...).  If I could show people tight applications that act just like ones written in C to the Win32 API, this would be a powerful thing.

5.  Make dynalinking to ocaml dlls work.  We have to solve the dynalink problem at some point.  Large applications need plugins and other modularity type features, and loading ocaml code in DLLs is important.  It would be nice if this worked in every direction (ocaml exe - c dll, ocaml exe - ocaml dll, c exe - ocaml dll).

6.  More x86 code generation optimizations.  A peephole optimizer would be great for part of this.  There's just a lot of register sloshing that's unnecessary in the code I've looked at.  It seems within reach to get identical loops in C and OCaml the same speed.  Not a big deal but I thought I'd throw it in there.

I'm sure there's more, but that would be a start.  :)