Use MSXML in perl without registration

[Vinay]

I would like to use MSXML4.0 in my perl script, but not have it
register on my machine. The way to do that is explained for C++ at this
link:
http://www.perfectxml.com/articles/msxml/TipsAugust02.asp
I am finding it difficult to port it over to perl. Anyone has any clue
for the same? What steps do I need to take?

Thanks for your time.
Vinay

 

[Sisyphus]

I would like to use MSXML4.0 in my perl script, but not have it
register on my machine. The way to do that is explained for C++ at this
link:
http://www.perfectxml.com/articles/msxml/TipsAugust02.asp
I am finding it difficult to port it over to perl. Anyone has any clue
for the same? What steps do I need to take?

You could use Inline::CPP to run that code from perl .... but only if you
have a C++ compiler.

Otherwise you can use the Win32::API module.

With Win32::API, I envisage that there's no need to call LoadLibrary,
GetProcessAddress, and FreeLibrary. Instead you just access the functions
from the dll directly. (However, I'm not sure if that's correct - given that
you're dealing with COM objects.)

Cheers,
Rob

 

[Ben Morrow]

You could use Inline::CPP to run that code from perl .... but only if you
have a C++ compiler.

But what would be the point of that? The point is to write Perl .

Note you could probably make mingw work with some effort... and you can
precompile the module. I would probably *not* use Inline, but just write
an XS module in C++ if I was going down that route.

Otherwise you can use the Win32::API module.

With Win32::API, I envisage that there's no need to call LoadLibrary,
GetProcessAddress, and FreeLibrary. Instead you just access the functions
from the dll directly. (However, I'm not sure if that's correct - given that
you're dealing with COM objects.)

That is correct insofar as calling Win32 APIs (or: C functions in DLLs
with the __stdcall calling convention) goes: the Win32::API
instantiation process does the LoadLibrary for you. However, you can't
call C++ member functions at all, so you can't translate that code.

The whole concept seems a little dodgy to me: why can't you just
register the component from your script
(system "regsvr32 $ENV{SYSTEMROOT}\\system32\\msxml4.dll"; IIRC; perhaps
in a BEGIN block) and then use it properly with Win32::OLE?

Ben

 

[Vinay]

Thanks Rob.
I checked out Win32::API. It can be used. What I am not sure of is how
does a DLL being a COM object differ the way code is written.
I will look more into using that module, meanwhile if anyone has worked

 

[tuser]

I would like to use MSXML4.0 in my perl script, but not have it
register on my machine. The way to do that is explained for C++ at this
link:
http://www.perfectxml.com/articles/msxml/TipsAugust02.asp
I am finding it difficult to port it over to perl. Anyone has any clue
for the same? What steps do I need to take?

Have a look at the posting in comp.lang.perl.misc
"Windows ActiveState Perl: MSXML transformNodeToObject finally
succeeded"
Date: 17/02/2006 23:14
http://tinyurl.co.uk/5ljh

 

[Vinay]

You would think whats the harm in registering? I think so too
But the issue is that this script fo mine will be part of a set of
bigger changes(more scripts), that some one can just copy over to the
system and use. It should not touch the base OS or install anything on
the machine.
Its a customer's requirement.
Thanks for your analysis. I have not yet looked into the problem
deeply. I will post something if I find an answer to this.

Vinay

 

[Vinay]

Thanks. It explains how to use MSXML better, not on how to load it from
the dll, which I want to do.

 

[Sisyphus]

But what would be the point of that? The point is to write Perl .

Note you could probably make mingw work with some effort... and you can
precompile the module. I would probably *not* use Inline, but just write
an XS module in C++ if I was going down that route.

Yeah - I just wanted to make the OP aware of the Inline::CPP module as an
option - but I didn't want to take the time to get too involved in providing
details, given that I didn't even know if the OP was prepared to go down
that route.

As to whether you use Inline or you write the XS module yourself, it boils
down to whether you want Inline to write the XS code for you ... or whether
you .... ummm .... want to write the XS code yourself. (I'd be using Inline
as I'm not all that proficient in writing XS code.) One advantage with
Inline is that running/debugging/fixing the functions as you develop them is
easy. One disadvantage with Inline is that, when it comes to converting that
script to a module there are some (fairly easily negotiated) hoops to jump
through.

That is correct insofar as calling Win32 APIs (or: C functions in DLLs
with the __stdcall calling convention) goes: the Win32::API
instantiation process does the LoadLibrary for you. However, you can't
call C++ member functions at all, so you can't translate that code.

Oh .... bummer. Wasn't aware of that - thanks for correcting. (I try to
avoid Win32::API - usually go the XS route.) Is there some C-style way of
accessing those member functions with Win32::API ? Or does "you can't
translate the code" really *mean* "you can't translate the code"

Cheers,
Rob

 

[Ben Morrow]

Oh .... bummer. Wasn't aware of that - thanks for correcting. (I try to
avoid Win32::API - usually go the XS route.) Is there some C-style way of
accessing those member functions with Win32::API ? Or does "you can't
translate the code" really *mean* "you can't translate the code"

I believe there is no way. You may be able to create a dll that does the
work for you (which you can then call with W32:API), but I'm having a
hard time seeing how you could specify the method names.

To the OP: if you're really into some pain , you could see if you can
find a way to adapt that code into something that returns a real COM
instance, and then grovel around in the guts of W32::OLE to find a way
to bind your instance to a W32::OLE object....

Ben