
Daan, Kevin, (and Mike, Sarah?) You two/three seem to be the de-facto experts when it comes to building DLLs with GHC and linking them to C++ DLLs. Would either of you like to write up some stand-alone notes that explain how to do it, and what the pitfalls are? You can make suggestions for improving GHC too! What otherwise happens is that everyone has to reinvent the wheel. And, to be honest, we're not well up on this at GHC home base, so you could do a far better job than we could. The important thing is to explain enough context that someone does not have to be a total Win 32 expert to understand what's going on. Claus's recent message explaining about Cygwin paths was an excellent example of how to do it. It'd be a real service. Simon | -----Original Message----- | From: Daan Leijen [mailto:daanleijen@xs4all.nl] | Sent: 02 February 2003 22:34 | To: Nick Name; gui@haskell.org | Subject: Re: [GUI] ByeDemo | | > > I have been thinkering with the wxWindows library | > > and made a small Haskell binding to it that just supports this | > > example. It was an interesting exercise since the wxWindows library | > > is a large object-oriented C++ library. (but very portable, well | > > supported, efficient and with lots of super widgets, like an openGL | > > canvas and a HTML renderer) | > | > It is really interesting. How did you bind the library? Could you make a | > tarball of the binding, the example and a makefile? It could be used as | > an "Haskell->C++" tutorial. | | (warning: rather detailed and long answer...) | | I have only done it for windows yet, both with mingw32 and visual C++. | Funny thing: the final (stripped) DLL with mingw32 was 2.8mb, while the | visual C++ DLL (with the same functionality) was just 640kb :-). | | In the end, I couldn't link it directly with a haskell application due to the | difference between the C++ and plain C runtimes, so I have made dynamic | link library (.dll) of the C++ code. This code exposes a plain C interface (with "extern | "C""). | This interface is basically a flat C view on the object oriented wxWindows library. | | This DLL is accessed with foreign imports from Haskell. Call backs are dynamically | created using dynamic exports ("wrapper"). Actually, the hardest part was to | make sure that the resource files (.rc) were properly linked in the DLL, as we don't | want to deal with those from Haskell. | | I don't know yet if this approach also works for unix's (.so files?) or MacOSX, | but there probably is a way to do this. In the end, it is good enough if there is | some way of wrapping the C++ code into a C library. Maybe someone on this list | can tell me more about how this could work on unix like platforms??? | | The part that is most challenging, and which I am still working on, is trying to fit | the event model of wxWindows into a reasonable model for Haskell (or other | languages for that matter). Somehow, I need to create "universal" widget objects | that are programmable from outside (i.e. Haskell) but normally, one derives | application | specific objects for each widget in wxWindows. There are mechanisms for more | dynamic | applications (like I want) but I am still trying to figure out the right way to do it. | | I think this is basically a universal problem when trying to interface to foreign object | oriented | (or any other paradigm for that matter) with a functional language. It is not just the | marshalling | and calling conventions, but the programming model makes a huge difference. Years | ago, when | designing H/Direct we automated the marshalling process, but it seems that that is | just a small | part of the problem. Trying to fit into an entirely different programming model is very | hard. For | an extreme example, I think that there is no reasonable way of interfacing to the Java | Swing model. | | Fortunately, it seems that the wxWindows library is much more flexible, and up till | now, I haven't | encountered any hard problems. Maybe this is actually the right way to go for a | Haskell GUI library | -- let others do the hard work of maintaining a rich,portable gui library, and we just | have to do | the hard work of interfacing to c++ once. | | All the best, | Daan. | | | > Vincenzo | > | > -- | > First they ignore you, then they laugh at you, | > then they fight you, then you win. | > [Gandhi] | > | > _______________________________________________ | > GUI mailing list | > GUI@haskell.org | > http://www.haskell.org/mailman/listinfo/gui | > | > | | | _______________________________________________ | GUI mailing list | GUI@haskell.org | http://www.haskell.org/mailman/listinfo/gui

"Simon" == Simon Peyton-Jones
writes:
Simon> Would either of you like Simon> to write up some stand-alone notes that explain how to do Simon> it, and what the pitfalls are? You can make suggestions Simon> for improving GHC too! I'd be happy to take a first stab at a write-up. It's not a trivial exercise--the Microsoft, Borland, and GNU compilers do not agree on a naming scheme for symbols exported from DLL's. -- Kevin S. Millikin Architecture Technology Corporation Research Scientist Specialists in Computer Architecture (952)829-5864 x. 162 http://www.atcorp.com
participants (2)
-
Kevin S. Millikin
-
Simon Peyton-Jones