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
[Caml-list] ocamldot on steroids
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-07-21 (08:15)
From: Dmitry Bely <dbely@m...>
Subject: Re: [Caml-list] Looking for sample DLL
"Mattias Waldau" <> writes:

> The reason I was looking for a sample is that it will take me 
> probably a couple of days just getting the makefile right etc.
> Therefor, much easier to just take someone else code and tweak
> it a little.

Well, look into camlidl runtime. In fact, all you need is

extern "C"
BOOL APIENTRY DllMain(HANDLE module, DWORD reason, void *reserved)
  char * argv[2];
  char dll_path[_MAX_PATH];

  switch(reason) {
    GetModuleFileName( (HMODULE) module, dll_path, _MAX_PATH );
    argv[0] = dll_path;
    argv[1] = NULL;
    camlidl_module_handle = (HMODULE) module;
#if 0
    int fd = open("/tmp/camllog", O_RDWR|O_TRUNC|O_CREAT, _S_IWRITE|_S_IREAD);
    dup2(fd, 1);
    dup2(fd, 2);
  /* TODO: free all memory when DLL detached */
  return TRUE;

and an appropriate Makefile. You can also easily modify camlidldll script,
removing all COM-related stuff from there.

>> I cannot understand this. DLL and COM are not concepts of the 
>> same level. That's like to say "I prefer fruits to oranges" :-)
> COM's are implemented as a DLL, I have been unclear. What I need
> is to be able using the old win16/32 dll-calling convention, not
> using the modern COM-convention.
> The reason is that VBA doesn't support the COM supported by camlidl,
> it only supports IDISPATCH.

But once again, IDISPATCH is *supported* by camlidl. Why not to create
IDispatch-equipped Ocaml COM component?

> (I made some COM-stuff in my life, but
> I do not like it, especially if you need to use C++. Now at last
> in dotnet seems Microsoft gotten it right without wizards that
> creates enormous amounts of code I don't understand.)

For VB and OCaml, no wizard-generated code is necessary, just normal C
stubs and virtual method tables plus type libraries, generated by MIDL.

> I would like to keep it as simple as possible, thus the dll-calling
> convention is enough. I will only call a few functions and I only
> need to return integers. (Thus no need to mess with BSTR, which
> would be needed if I would return strings from ocaml to vb).

- Dmitry Bely

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: