Re: OCaml for Windows: a suggestion

Re: OCaml for Windows: a suggestion

[Hao-yang Wang]

>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


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.

Cheers,
Hao-yang Wang

[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

[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

[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

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

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