Re: OCaml for Windows: a suggestion

Re: OCaml for Windows: a suggestion

[Jean Martos]

Lionel Fourquaux a écrit :

> [French version at the end]
>
>         Hello,
>
>         I'd like to suggest a change in the way OCaml is built
> under Windows. Wouldn't it be better if the files from byterun/
> that are shared by ocamlrun, the native code compiler and the
> otherlibs (i.e. the GC, the primitives, and support functions)
> were put in a DLL ?

In poor English :

This is a good idea. But I think that the most important job to do for
OCaml on Windows
is to port it under gcc. I already compile it with mingw32. I do it
because I need to interface OCaml and gnat, and for the moment it runs
fine.

Due to the cleany OCaml code, the modifications are limited, and the job
to make
the patches in order to make a cleany distribution is not so important.

I think that such a distribution is awaited by a numerous people of the
Ocaml community.

En français :

C'est une bonne idée. Mais il me semble qu'il serait plus intéressant de
disposer d'une
distribution compilée avec gcc.

J'ai compilé la version 3.0 avec mingw32, car j'ai besoin d'interfacer
OCaml avec gnat. Et cela marche trés bien.

Le code Ocaml est trés bien écrit et les modifications que j'ai
effectuées, aussi bien dans les sources que dans les makefiles sont trés
limitées (Merci de ne pas avoir utilisé AUTOCONF).

Je crois que nous sommes nombreux parmi la communauté OCaml à attendre
une distribution compilant avec gcc sous Windows, cela permetrait de
s'affranchir du compilateur vcc et, surtout de l'assembleur masm, qui
est difficile à trouver et à installer.

Le travail à effectuer pour fournir une distribution  gcc officielle
sous windows n'est pas si important. Peut être que nos amis de l'INRIA
... nous ferons ce cadeau pour la naissance du consortium?

Jean Martos.

OCaml for Windows: a suggestion

[Lionel Fourquaux]

[French version at the end]

	Hello,


	I'd like to suggest a change in the way OCaml is built
under Windows. Wouldn't it be better if the files from byterun/
that are shared by ocamlrun, the native code compiler and the
otherlibs (i.e. the GC, the primitives, and support functions)
were put in a DLL ? IMHO, it has a number of advantages, notably:
 o It's makes it simpler to implement dynamically imported
   primitives (because the support functions can be imported
   from this DLL).
 o It reduces the size of OCaml executables (because this part
   of the code is shared)

	So I suggest to split byterun/ into two directories:
one for the base OCaml implementation, and another (very small)
for ocamlrun, and to split ocamlrun into a DLL and a small
executable. (This is about what is done for the Windows versions
of Perl and Python.)


	What do other users think of this proposal?


		Lionel Fourquaux




[Français]


	Bonjour,


	Je voudrais proposer une modification dans la manière
dont OCaml est compilé sous Windows. Est-ce qu'il ne serait pas
péférable de placer les fichiers utilisés à la fois par ocamlrun,
asmrun et les otherlibs (c'est-à-dire le GC, les primitives,
et des fonctions de `support') dans une DLL ? A mon avis, cela
présenterait plusieurs avantages, dont en particulier :
 - de faciliter l'implémentation de bibliothèques dynamiques
   de primitives (puisqu'une telle DLL pourrait importer les
   fontions dont elle a besoin);
 - de rédure la taille des exécutable produits par OCaml
   (en partageant cette partie du code).

	Alors, je suggère de séparer byterun/ en deux répertoires :
un pour l'implémentation des services de base d'OCaml, et un
autre (très petit) pour ocamlrun, et de scinder ocamlrun en une
DLL et un petit exécutable. (C'est à peu près ce qui est fait
dans les versions Windows de Perl et de Python.)


	Qu'en pensent les autres utilisateurs ?


		Lionel Fourquaux

RE: OCaml for Windows: a suggestion

[Lionel Fourquaux]

> -----Message d'origine-----
> De : Jean Martos [mailto:jean.martos@wanadoo.fr]
> Envoyé : dimanche 4 février 2001 18:54
> À : lionel.fourquaux@wanadoo.fr
> Cc : caml-list@inria.fr
> Objet : Re: OCaml for Windows: a suggestion
>
>
>
>
> Lionel Fourquaux a écrit :
>
> > [French version at the end]
> >
> >         Hello,
> >
> >         I'd like to suggest a change in the way OCaml is built
> > under Windows. Wouldn't it be better if the files from byterun/
> > that are shared by ocamlrun, the native code compiler and the
> > otherlibs (i.e. the GC, the primitives, and support functions)
> > were put in a DLL ?
>
> In poor English :
>
> This is a good idea. But I think that the most important job to do for
> OCaml on Windows
> is to port it under gcc. I already compile it with mingw32. I do it
> because I need to interface OCaml and gnat, and for the moment it runs
> fine.

	It's probably a very good idea. However, I'd like the support
for msvc to continue. It shouldn't be too difficult : the headers
and the libraries are similar.
	Moreover, compiling with gcc would create a faster bytecode
interpreter : interp.c is full of gcc-specific optimizations,
while msvc sees only normal C code. (I tried a comparison, and
the difference was huge.)


>
> Due to the cleany OCaml code, the modifications are limited,
> and the job
> to make
> the patches in order to make a cleany distribution is not so
> important.
>
> I think that such a distribution is awaited by a numerous
> people of the
> Ocaml community.
>
> En français :
>
> C'est une bonne idée. Mais il me semble qu'il serait plus
> intéressant de
> disposer d'une
> distribution compilée avec gcc.

	C'est probablement une très bonne idée. J'aimerais quand même
que le support pour msvc continue, ce qui ne devrait pas être
difficile : les deux environnements sont quand même assez proches.
	En plus, une version compilée avec gcc disposerait d'un
interpréteur de bytecode beaucoup plus rapide : interp.c est plein
d'optimisations pour gcc, alors que msvc ne voit que du C normal.
(J'ai fait un petit essai : la différence est très importante.)

>
> J'ai compilé la version 3.0 avec mingw32, car j'ai besoin d'interfacer
> OCaml avec gnat. Et cela marche trés bien.

	Est-ce qu'il est vraiment nécessaire d'utiliser mingw32
pour interfacer avec gnat ? (Pure curiosité : il me semble
que les différences avec msvc ne sont pas si grandes.)

>
> Le code Ocaml est trés bien écrit et les modifications que j'ai
> effectuées, aussi bien dans les sources que dans les
> makefiles sont trés
> limitées (Merci de ne pas avoir utilisé AUTOCONF).
>
> Je crois que nous sommes nombreux parmi la communauté OCaml à attendre
> une distribution compilant avec gcc sous Windows, cela permetrait de
> s'affranchir du compilateur vcc et, surtout de l'assembleur masm, qui
> est difficile à trouver et à installer.

	Je suis à peu près sûr qu'il est possible de se débarasser
complètement du compilateur C, et de n'utiliser qu'un assembleur
et un linkeur, avec les bibliothèques associées. Comme je l'ai
déjà indiqué ici, tout cela est inclus dans le DDK de Windows 2000,
qu'il est facile de télécharger depuis le site de Microsoft.
Donc même sans gcc, il serait facile de ne pas avoir à acheter msvc.
(Et masm n'est pas si dur à trouver...)

	A mon avis, en plus de ne pas utiliser ce compilateur C,
il y aurait une autre modification très utile dans ce sens :
placer les lignes de commandes à l'extérieur de l'exécutable
(dans le registry, ou dans un fichier de configuration), là
où elles seraient faciles à modifier, et ajouter la possibilité
de choisir le style d'assembleur généré. Ainsi, chacun pourrait
utiliser les outils qui lui plaisent (msvc, gcc, nasm+alink, etc...)
sans avoir à recompiler la distribution. (Bien sûr, cela
nécessiterait un peu plus de travail.)


>
> Le travail à effectuer pour fournir une distribution  gcc officielle
> sous windows n'est pas si important. Peut être que nos amis de l'INRIA
> ... nous ferons ce cadeau pour la naissance du consortium?

	Je l'espère !


		Lionel Fourquaux

Re: OCaml for Windows: a suggestion

[Xavier Leroy]

> This is a good idea. But I think that the most important job to do
> for OCaml on Windows is to port it under gcc. I already compile it
> with mingw32. I do it because I need to interface OCaml and gnat,
> and for the moment it runs fine.

I did a Cygwin port of OCaml a few months ago.  It is available for
testing from the CVS repository (http://camlcvs.inria.fr/), and will
be available publically in the forthcoming 3.01 release.

Everything works (including the debugger!) except the threads library,
the COM interface via CamlIDL, and the toplevel GUI application.

This port uses full Cygwin, not the Mingw subset.

For the time being, the MSVC port is still maintained, but it is clear
that we at INRIA don't have the resources to work on two Windows ports
in parallel -- one port is already enough of a pain...  So, one of the
ports will eventually have to go or be maintained by others.

Enjoy,

- Xavier Leroy

Re: OCaml for Windows: a suggestion

[Chris Hecker]

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

Chris

RE: OCaml for Windows: a suggestion

[Lionel Fourquaux]

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

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

[Mattias Waldau]

The problem that many of the extra code written for Ocaml don't work in the
Windows version was my reason to convert to cygwin. Also, that ocamldebug
works is a real bonus.

Currently it is a big pain trying to compile packages like PXP for windows,
even if you normally succeed after a while.

I don't really know how to solve this problem, but one solution could be to
have more packages precompiled for windows, for example pxp, lablgtk (incl
necessary dlls).....

Until we do that, doing serious developing on a windows platform is hard.

/mattias

-----Original Message-----
From: owner-caml-list@pauillac.inria.fr
[mailto:owner-caml-list@pauillac.inria.fr]On Behalf Of Vijay
Chakravarthy
Sent: Wednesday, February 14, 2001 4:33 PM
To: lionel.fourquaux@wanadoo.fr; 'Chris Hecker'
Cc: caml-list@inria.fr
Subject: [Caml-list] Re: OCaml for Windows: a suggestion


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

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

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

[Gerd Stolpmann]

On Wed, 14 Feb 2001, Vijay Chakravarthy wrote:
>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?

No, this is not the reason. The problem with findlib (and other packages) is
that there are no shell scripts under Windows. Findlib uses scripts for
configuration, and for the installation of new packages. It is possible to
replace these scripts by O'Caml programs; but it is not a simple task.

Of course, there is a second problem: I neither have a Windows system nor the
VC compiler. (Ok, there is now the cygwin port, but it should be compatible
enough such that findlib works (with little effort), so the cygwin port is not
the problem.)

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

I would appreciate such a server, too.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 100             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

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

[Vijay Chakravarthy]

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

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

[Dave Berry]

> -----Original Message-----
> From: Chris Hecker [mailto:checker@d6.com]

> A couple of suggestions were made for the Windows OCaml port. 
>  I disagree with both. 

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

I agree that most production programmers use MSVC.  The question is whether
they/we need to compile the compiler, and whether they/we will be willing to
install GCC and Cygwin to build the system (as opposed to using it).  My
personal opinion is that I'd prefer MSVC, to avoid cluttering my machine
with other applications, but if this restricts the functionality of the
system, then I'd be willing to install Cygwin.  If I didn't already own a
copy of MSVC on my home machine, I might have a different opinion.

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

My experience is that most production code builds an InstallShield or
similar installer, so users don't see all the files that are installed.
Even if you just use a zip file, all you need to do is to put the DLLs in
the same folder as the executable.

If the aim is to install a system-wide OCaml runtime DLL (and Cygwin, if
needed), then that is more complicated.  You can run into versioning
problems, if two applications are built to use different versions of the
runtime.  You also need a scheme for supplying the DLLs, and only installing
them if they aren't already installed.  Probably the simplest way to do this
is to provide boiler-plate installer code that people can adapt to build
their own installers.

> My suggestions are the following, 
> ...
> 3.  Generics. 

I believe OCaml supports functors, i.e. parameterised modules.  Did you have
something else in mind?

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

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

[Brian Rogoff]

On Mon, 12 Feb 2001, Hao-yang Wang wrote:
> I don't mind whether the development environment of ocaml itself is built 
> with MSVC or gcc. However, the interoperatibility (spelling?) between 
> codes written in ocaml and MSVC is important to me.

Having been in that world, I agree, if you're doing professional work you
want to pay all the $$ for the full MS developers kit and have Ocaml
working with that.

This is actually where a Consortium is helpful. Maintaining the port is 
actually "engineering effort" (no pejorative intended) and if the
companies making big $$ in that big market kick in the money you can hire
an engineer full time to keep the port going, getting back ends for the 
.NET VM, low level bindings to Windows libraries, etc. Not my interest,
but it's not helping competitors and allows INRIA to use their time to 
help us all. 

-- Brian


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