It would appear that I win the prize for being the first person to
try and load DARCS under windows 2003 server (enterprise edition).  Needless
to say, it doesn't load.  The error is a missing DLL import from MAPI32.dll.
	As such I added a note on windows version compatibility to the Wiki
download page, consisting of the three versions of windows I know about.
	That means two things:
	1) Any windows versions under which DARCS has been tested working
should be added to that page http://darcs.net/DarcsWiki/CategoryBinaries.
	2) DARCS needs some (hopefully minor) debugging under Windows 2003
Server.  I suspect the simplest fix would be to make a Windows 2003 build
without e-mail support.

	Unfortunately I don't have the time to try and debug this one.
Which means I won't complain if it doesn't get fixed.  I just wanted to let
you know.

-Greg

I can clarify this further.  In fact the original message was wrong.

	DARCS runs just fine under Windows 2003.  On further investigation
the problem lies in it's interaction with Exchange 2003 SP1.  The problem is
DARCS imports MAPILogoff from MAPI32.dll.  However the version of MAPI32.dll
which comes with Exchange does not include this function.
	Versions of MAPI32.dll can be easily identified by the "product
name" field of the version block (Windows vs Exchange).
	There is also a MAPISTUB.DLL which on all machines I've seen so far
contains the necessary MAPILogoff function.  In addition, copying
MAPISTUB.dll to DARCSDIR/MAPI32.dll will allow DARCS to run, but doesn't
seem like a fully viable option.

	In the long run there are two possibilities I know of: one, the
Exchange installer simply does not work properly and two, DARCS should be
linked with MAPISTUB.dll rather than MAPI32.dll.  Which is really correct, I
don't know.  The windows PlatformSDK or MSDN library should have the answer
somewhere, possibly in the MAPI sample applications.

	I fixed the wiki to reflect this discovery.  My apologies for the
premature report.

-Greg

> -----Original Message-----
> From: Greg Gibeling [mailto:bugs@darcs.net]
> Sent: Wednesday, November 23, 2005 4:19 AM
> To: droundy@darcs.net; gdgib@eecs.berkeley.edu; ptp@lysator.liu.se
> Subject: [issue18] Windows 2003
> 
> 
> New submission from Greg Gibeling <gdgib@eecs.berkeley.edu>:
> 
> It would appear that I win the prize for being the first person to
> try and load DARCS under windows 2003 server (enterprise edition).
> Needless
> to say, it doesn't load.  The error is a missing DLL import from
> MAPI32.dll.
> 	As such I added a note on windows version compatibility to the Wiki
> download page, consisting of the three versions of windows I know about.
> 	That means two things:
> 	1) Any windows versions under which DARCS has been tested working
> should be added to that page http://darcs.net/DarcsWiki/CategoryBinaries.
> 	2) DARCS needs some (hopefully minor) debugging under Windows 2003
> Server.  I suspect the simplest fix would be to make a Windows 2003 build
> without e-mail support.
> 
> 	Unfortunately I don't have the time to try and debug this one.
> Which means I won't complain if it doesn't get fixed.  I just wanted to
> let
> you know.
> 
> -Greg
> 
> ----------
> messages: 70
> nosy: droundy, gdgib, tommy
> status: unread
> title: Windows 2003
> 
> ____________________________________
> Darcs issue tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue18>
> ____________________________________

There is no import library for MAPISTUB.dll in mingw, and hence not in GHC
either.  Quick search didn't show any plans to add it to the mingw.

Best solution would probably be to use LoadDLL/GetProcAddress.  Given that it
isn't many functions we need, that is probably viable.

I will give it a go in a few days unless I hear objections, but I
can't probably test it.  (Except on machines where it already it works.)

I'd be happy to help with the testing as I definitely have some
machines where it fails.

-Greg

> -----Original Message-----
> From: Esa Ilari Vuokko [mailto:bugs@darcs.net]
> Sent: Tuesday, November 29, 2005 9:21 AM
> To: droundy@darcs.net; ei@vuokko.info; gdgib@eecs.berkeley.edu;
> ptp@lysator.liu.se; will@glozer.net
> Subject: [issue18] Windows 2003
> 
> 
> Esa Ilari Vuokko <ei@vuokko.info> added the comment:
> 
> There is no import library for MAPISTUB.dll in mingw, and hence not in GHC
> either.  Quick search didn't show any plans to add it to the mingw.
> 
> Best solution would probably be to use LoadDLL/GetProcAddress.  Given that
> it
> isn't many functions we need, that is probably viable.
> 
> I will give it a go in a few days unless I hear objections, but I
> can't probably test it.  (Except on machines where it already it works.)
> 
> ----------
> assignedto:  -> eivuokko
> nosy: +eivuokko
> 
> ____________________________________
> Darcs issue tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue18>
> ____________________________________

Thanks to Greg's analysis and testing, here's a patch.

This patch implements dynamic loading of mapistub.dll or mapi32.dll
using LoadLibrary and GetProcAddress.  It also improves error messages
somewhat, but it seems that atleast Thunderbird knows only one errorcode:
Generic error: :-(  Maybe Outlook behaves better.

There are atleast few more alternatives:
 * User runs Ms-given programs that fix this sort of problems, but feedback
   for those (on net) appears to be very bad...  and it's not clear if
   there is such program for all diffrent ways to mapi can conflict.
 * Link to that stub dll, which is hard because a) we don't have import
   library, and would need to build it. b) I have no idea if that library
   is available on older Windowses.
 * Provide two executables, with diffrent dependencies.  I am not fond of
   this, one is sure to bitrot, and it's...inelegant :-)

--Esa

Attachments

• mapi-fix

On Wed, Nov 30, 2005 at 04:32:18PM +0000, Esa Ilari Vuokko wrote:
> This patch implements dynamic loading of mapistub.dll or mapi32.dll
> using LoadLibrary and GetProcAddress.  It also improves error messages
> somewhat, but it seems that atleast Thunderbird knows only one errorcode:
> Generic error: :-(  Maybe Outlook behaves better.

I'll leave the judgement as to whether this is a good approach (vs. the
alternatives) to someone who knows something about this stuff.

> if(send_res==MAPI_E_USER_ABORT)
>   fprintf(stderr, "MAPI error: User aborted.\n");
> else if(send_res== MAPI_E_FAILURE)
>   fprintf(stderr, "MAPI error: Generic error.\n");

I think I'd prefer here to export these things to Haskell.  One could
create a static lookup table of error messages in C and then have a
function that exports the table to Haskell, then you could return with the
actual error message, and in case of failure the Haskell code would throw
an exception with the appropriate text.  That would seem more flexible,
since we could then customize the error messages as appropriate without
writing windows-specific code.  In general, I'd prefer to avoid printing
from C.
-- 
David Roundy
http://www.darcs.net

> I think I'd prefer here to export these things to Haskell.  One could
> create a static lookup table of error messages in C and then have a
> function that exports the table to Haskell, then you could return with the
> actual error message, and in case of failure the Haskell code would throw
> an exception with the appropriate text.  That would seem more flexible,
> since we could then customize the error messages as appropriate without
> writing windows-specific code.  In general, I'd prefer to avoid printing
> from C.

I see, I just followed existing practice in that sourcefile.
It definetely is improvement over previous, before we just
printed numeric code, the very same way my patch does.

In case patch is otherwise ok, should I build another patch
on top of my current one or make a new and more intrusive patch?
(To fix the error handling)

Thanks,
--Esa

On Thu, Dec 01, 2005 at 02:19:03PM +0000, Esa Ilari Vuokko wrote:
> > I think I'd prefer here to export these things to Haskell.  One could
> > create a static lookup table of error messages in C and then have a
> > function that exports the table to Haskell, then you could return with
> > the actual error message, and in case of failure the Haskell code would
> > throw an exception with the appropriate text.  That would seem more
> > flexible, since we could then customize the error messages as
> > appropriate without writing windows-specific code.  In general, I'd
> > prefer to avoid printing from C.
> 
> I see, I just followed existing practice in that sourcefile.  It
> definetely is improvement over previous, before we just printed numeric
> code, the very same way my patch does.

I may have become more picky over time... :) This is definitely not a
showstopper sort of issue, it'd just be a bit cleaner.  I don't think we've
got anything like this sort of an error-lookup-table in the code yet, but
I think it'd be nice to have.

You might define functions like

throwTranslatedErrorCode :: (IO (Ptr CInt, Ptr CString))
    -> CInt -> IO a

translateMAPIErrorCode :: IO (Ptr CInt, Ptr CString) -- a foreign function

throwMAPIError :: CInt -> IO a
throwMAPIError = throwTranslatedErrorCode translateMAPIErrorCode

I'm imagining static arrays of ints and char *s, with some sort of null
termination.  throwTranslatedErrorCode here would be a reuseable function,
which might also be useful for git or something.

> In case patch is otherwise ok, should I build another patch on top of my
> current one or make a new and more intrusive patch?  (To fix the error
> handling)

That'd be up to the maintainers.  I think either solution is fine, provided
your first patch hasn't been applied centrally (and I doubt anyone's
applied it non-centrally at this stage).
-- 
David Roundy
http://www.darcs.net

I need a Windows person to test this patch and send it to darcs-unstable if it
is confirmed that it works on whatever versions of Windows we are supporting.

Sorry for that -- while I own no less than four distinct Windows licenses, I do
not have a machine with Windows installed, which makes it somewhat difficult to
test Windows versions.

I unassign myself as I'm not planning to take this on right now. I'll
leave the bug open because atleast dependency in MAPI dll is a bug
which should be fixed by (I think) delay loading DLLs (not supported
by GNU toolchain) or dynamic loading DLLs (approach taken on my patch).

I have no resources to test patch more, and I think MAPI stuff is
currently broken anyway - I recommend rewrite in haskell ffi.

Best regards,
-Esa

Esa's patch has made it into darcs 1.0.9.  Greg, is this working any better? 
May I close this?

It's been a while since I used it, but yes, it works a lot better.
Thanks guys!

-Greg

> -----Original Message-----
> From: Eric Kow [mailto:bugs@darcs.net]
> Sent: Tuesday, July 17, 2007 5:34 AM
> To: beschmi@cloaked.de; droundy@darcs.net; ei@vuokko.info;
> eric.kow@gmail.com; gdgib@eecs.berkeley.edu; jch@pps.jussieu.fr;
> ptp@lysator.liu.se; will@glozer.net
> Subject: [issue18] Windows 2003, Microsoft Exchange (MAPI issues)
> 
> 
> Eric Kow <eric.kow@gmail.com> added the comment:
> 
> Esa's patch has made it into darcs 1.0.9.  Greg, is this working any
> better?
> May I close this?
> 
> ----------
> nosy: +EricKow, beschmi
> 
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue18>
> __________________________________

Resolving, thanks!  Btw, Esa had some comments on MAPI and MIME for which we
should probably open a new issue.  I'll put our (public) chat log online.