mapserv Win32 DLLs / ActiveX / COM

[Chris Stuber]

Brent (and list),

Tonight I tried to re-SWIG mapscript on Win2000 with the command:
swig -perl5 -shadow mapscript.i
using swig 1.3a3 for NT, I kept getting an Application Error whilst
using the -shadow switch.  I suspect there is some problem with 
swig that I could not identify. 

I think your theory about interface issue is right on target.
I was reading up on DLLs tonight, and found a HOWTO that
describes the necessity for each DLL to have a LibMain and
something called WEP (Windows Exit Procedure).  Quite possibly
this is the problem with ActiveState Perl loading the DLL.
I am not yet in a position to test this, but should be able
get there in a day or 2.    I also read in the swig documentation
that it is possible to build the swig'd module from static libs
from within the Visual Studio environment by linking
the same as mapserver.

The ActiveState Perl is a little klunky for Windows people in
general... most Windows people prefer an ActiveX wrapper
interface.

Thanks again... If I make any progress on this, I will let
you know.

Regards,

Chris Stuber (mapsurfer)
Silicon Mapping Solutions, Inc.


Brent Fraser wrote:
> 
> Chris (and list subscribers),
> 
>   I've made Windows DLLs for the MapServer-related
> libraries you've listed.
> 
> And I've made a couple of attempts at getting a Perl
> version of MapScript built but was unsuccessful.  See the
> included text below for some details (it's an email I sent
> to the list on June 13, 2000).
> 
> The short story is I was able to build a mapscript.dll, but
> ActivePerl would not load it.  My current theory there are
> some function interfacing issues.  The answer may be
> to "Swig" mapscript on NT to see if the generated code
> is any different then the code generated on Unix (and
> packaged with the rest of the MapServer source).  Haven't
> got around to that yet...
> 
> As for the ActiveX/COM question, I had written a rudimentary
> ActiveX layer to MapServer (before MapScript came out).
> It worked ok, but was lacking features, mostly related to
> dealing with layers as a collection.  I put the work on hold
> until I had a chance to examine Steve's MapScript object
> model and haven't returned to it.  Too bad Swig doesn't
> produce ActiveX wrappers...
> 
> Brent Fraser
> bfraser at geoanalytic.com
> GeoAnalytic Inc.
> #300 , 700 - 4th Avenue SW Calgary, AB
> Canada T2P 3J4
> Tel:  (403)213-2700 Fax:  (403)213-2707
> www.geoanalytic.com
> 
> ======================================
> Steve (and list subscribers),
> 
>     I'm using the makefile created by using the
> command "perl makefile.pl" (I'm using ActivePerl,
> on NT 4.0.  I then  do an "nmake" at the command
> line.
> 
>  I removed the "-nodefaultlib" from the makefile
> (what a hacker), and now it will compile to a DLL
> using "nmake". I then did a "nmake install" and it
> seemed to work (it copied files into the ActivePerl
> directory and updated some other files).
> 
>   I tried the dump.pl perl script in the mapscript
> examples directory, and got the following error:
> 
> Error: Parse Exception
> 
> When I use perl interactively, and type in the first
> line of the dump.pl script "use mapscript;" I get
> the same error as above.  So likely some perl file
> has not been updated properly so it will recognize
> the mapscript package.
> 
> Any perl experts out there..?
> 
> Brent Fraser
> 
> ----- Original Message -----
> From: "Stephen Lime" <steve.lime at dnr.state.mn.us>
> To: <bfraser at geoanalytic.com>
> Sent: Tuesday, June 13, 2000 9:11 AM
> Subject: Re: some progress building MapScript on NT
> 
> Which makefiles you using and are you using the perl MakeMaker
> module to build the perl code? I'm a win32 neophyte so how to install
> the dll is a mystery. A note to the list might help cause I think there are
> a bunch of people trying to do this same thing.
> 
> s.
> 
> >>> "Brent Fraser" <bfraser at geoanalytic.com> 06/13/00 09:24AM >>>
> Steve,
> 
>   Well, it looks like we won't have to change the variable names
> (maybe).  I edited the Makefile at the line CCFLAGS (approx
> line 244) and removed -TP and -DPERL_OBJECT.
> 
> Things compiled alot cleaner, but I still had some unresolved
> symbols at the linking stage.  I added perlCAPI.lib to the list
> of libaries in perlvars, and inserted  #include "perlCAPI.h" into
> mapscript_wrap.c
> 
>   It compiles and links in the VC++ GUI.  I actually get a DLL !
> 
> However, on the command line with nmake, the linking stage
> gives unresolved symbols in regex and proj of "HUGE" and
> "pctype".  I'm not sure if it's worth pursuing since I can use
> the GUI to produce the DLL.
> 
>   Now that I have a mapscript.dll (the same as mapscript.so
> in Unix?), what do I do with it (be nice!)?  Do I need to place
> it in the perl dir tree somewhere?
> 
> Thanks,
> Brent
> =========================================
> 
> ----- Original Message -----
> From: "Chris Stuber" <imap at chesapeake.net>
> To: "mapserver-users" <mapserver-users at lists.gis.umn.edu>
> Sent: Tuesday, December 19, 2000 12:06 PM
> Subject: mapserv Win32 DLLs / ActiveX / COM
> 
> >
> > Has anyone created Win32 DLLs for any of the following?
> >
> > mapserv,freetype,libtiff,proj,regex,gd,gdft
> >
> > I believe that in order to get mapscript to run
> > on the Windows platform, the components needs to be
> > callable presumably via DLL.  Or perhaps mapscript
> > can be statically linked to these libs???   Has anyone
> > gotten mapscript to run under Perl, ActiveX/COM?
> >
> > If anyone has gone down this road, your comments
> > would be appreciated.
> >
> > Regards,
> >
> > Chris Stuber (mapsurfer)
> > Silicon Mapping Solutions, Inc.