[Caml-list] Re: OCaml for Windows: a suggestion

["Vijay Chakravarthy" <vchakravarthy@verticalnet.com>]

While we are on this topic, some observations (trying to coordinate my
windows based Ocaml development with the rest
of my team (they use Linux, I have a laptop and use Win2000)) that can be
considered feedback:

1. findlib etc dont work on windows, and there is enough of  a difference
between make and nmake that most make scripts break.
That causes a bunch of packages to be difficult to build under windows
(difficult enough to put off novice programmers that
I'm trying to get hooked on Ocaml)
2. I guess 1. stems from dbm not being available on windows. Would it be
difficult to have an interface to Sleepycat's version on windows,
and make that part of the standard distrib?
3. Since fork() doesnt work on windows, I cant use most of the web-server
type stuff written in Ocaml. It would be nice to have
a (medusa,thttpd,zeus) style single threaded web-server based on equeues. It
would also rock -- performance wise (upto a certain
number of users I guess)

Vijay


----- Original Message -----
From: "Lionel Fourquaux" <lionel.fourquaux@wanadoo.fr>
To: "'Chris Hecker'" <checker@d6.com>
Cc: <caml-list@inria.fr>
Sent: Monday, February 12, 2001 1:27 PM
Subject: RE: OCaml for Windows: a suggestion




> -----Message d'origine-----
> De : Chris Hecker [mailto:checker@d6.com]
> Envoyé : lundi 12 février 2001 20:38
> À : Xavier Leroy; Jean Martos
> Cc : lionel.fourquaux@wanadoo.fr; caml-list@inria.fr
> Objet : 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.

Well, since I'm not a professional programmer, I don't
qualify to discuss this. My goal when I wrote this suggestion
was to point out changes that are IMHO good for the future
development of ocaml for windows. (I don't see how to support
dynamic loading of native code without this.)


>
> 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.

I think you are right. However, note that Mingw32
doesn't depend on nonstandard dlls, and produces code
that is compatible with msvc.

>
> 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).

I was thinking of one standard ocaml dll (something like
"ocamlrun.dll"), that would be shared by all ocaml executables.
Is it really a burden?


>
>
> 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.

It wouldn't be easy, would it?


>
> 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).

This point is very important. If you want this, I don't
see how to avoid using the ocaml dll I proposed: you don't
want one gc per dll, do you?

>
> 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.  :)

Well, it looks like a lot of work for the Consortium !


>
> Chris
>


Lionel Fourquaux


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr