RE: Mac address of remote host
<[EMAIL PROTECTED]> wrote on 10/19/2005 03:06:55 AM: > > That seems a roundabout way of getting the source MAC > > address. Net::Ping > > provides means to ping a host and can return the resolved IP > > address and > > round-trip time. > > I'm confused. How does getting the source mac address help with getting > the remote one? Am I missing something here? > My bad. Although my eyes saw MAC, my brain thought IP. ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Mac address of remote host
<[EMAIL PROTECTED]> wrote on 10/18/2005 11:44:43 AM: > > Is it possible to obtain the Mac address of a remote host from a ping > > response? > > > If you are on the same subnet as the remote host, you can ping them and > then read your arp cache - arp -a on my Windows box. If you're going > across subnets, you have various options. Wmi, nbtstat -a are the two > that immediately spring to mind. > > Paul > That seems a roundabout way of getting the source MAC address. Net::Ping provides means to ping a host and can return the resolved IP address and round-trip time. ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Win32:API Problem
"$Bill Luebkert" <[EMAIL PROTECTED]> wrote on 07/22/2005 07:19:56 PM:
> David Legault wrote:
>
> > Hello,
> >
> > I'm trying to use the Win32:API module to access a DLL function with
> > this perl code :
> >
> > $function = Win32::API->new( 'test.dll', 'int startSimulation(int
> > eRunMode)', );
>
> Try an alternate calling method and see if it makes a diff :
>
>my $function = Win32::API->new('test.dll', 'i', 'i') or die
> "import: $! ($^E);
>my $return = $function->Call(0);
>
> or
>
>my $startSimulation = Win32::API->Import('test.dll',
> 'int startSimulation (int eRunMode)') or
> die "import startSimulation: $! ($^E)";
>my $return = startSimulation (0);
>
>print "$return\n";
>
>
> > $return = $function->Call(0);
> > print $return;
> >
> > The C code for the function in the DLL is :
> >
> > int startSimulation( int eRunMode ) {
> >
> >return 0;
> > }
> >
> > Which is very basic and the Symbol is exported with a .def file.
> >
> > When I run the perl code, it crashes with a pointer to NULL memory
access.
> >
> > If anyone has a clue on why this is happening, or has a fix for it,
I'd
> > be glad to know.
> >
> > P.S. I also tried WJ patched version available at
> > http://www.xs4all.nl/~itsme/projects/perl/ with the same result.
I experienced a similar problem with accessing a vendor DLL from Perl. The
cdecl calling convention was the culprit and using
http://www.xs4all.nl/~itsme/projects/perl/ Win32::API package resolved it.
If you provide the DLL (or at least a makefile), I'm willing to try to
access it from Perl.
Lloyd
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Change in "goto" behavior
"$Bill Luebkert" <[EMAIL PROTECTED]> wrote on 07/13/2005 10:36:04 PM: > > In structured programming practice, a goto would be totally inappropriate. > > But ... when you look at how a switch is implemented in actuality, it's > full of goto's. > > I guess the point is that you should leave the gotos to the underlying > generated compiler code and not use it yourself. But if your language > is lacking on suitable constructs, you may be forced to use a goto just > to save all the otherwise unnecessary code to go structured. > > My suggestion - avoid if possible - else use cautiously and infrequently. > My opinion is that the goto statement can be useful in error handling situations, particularly when parsing data. This removes the rarely-executed error handling code from the expected, normal processing code. This makes the normal code more cohesive, understandable, and maintainable (IMO) because it remains sequential, uncluttered by unnecessary indentation, braces, etc. Of course, Perl provides synonyms for 'goto' in these scenarios (last, continue). ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: NET-DNS & Regex
[EMAIL PROTECTED] wrote on 07/06/2005 05:53:34 AM: > > $the_ip='80.224.159.46'; > $the_ip =~ /^(\d+)\.(\d+)\.(\d+)\.(\d+)$/; $the_domain="$4.$3.$2.$1. > sbl-xbl.spamhaus.org"; > >>## you're reversing the order of the IP here. . . Is there some > reason you're >>doing this? $the_domain should now equal "46.159. > 224.80.sbl-xbl.spamhaus.org" > 46.159.224.80.sbl-xbl.spamhaus.org is not a valid domain name (unless it has been explicitly defined in the name server). The IP address uniquely identifies a network node. The node name is a convenience and an address-name association must be defined somewhere (in name server, local hosts file, etc.). Domains partition the namespace and allow distribution of services; e.g., each domain has a name server which are heirarchically invoked when resolving a name, as opposed to a single network-wide name server. ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: problems with Win32::API import
"Sumitro Chowdhury" <[EMAIL PROTECTED]> wrote on 06/20/2005 02:12:49 AM: > Thanks Lloyd. that was good info. > I couldn't find related problem in the archives ... can you please send me > the URL to the discussion you mentioned ? I hope to learn more from that > thread. > http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/perl-win32-users There are several threads there regarding Win32::API. The referenced thread occurred on May 20, 2005. ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: problems with Win32::API import
[EMAIL PROTECTED] wrote on 06/17/2005 02:01:21 PM:
> Hi Masters.
>
> This code on my WinXP crashes perl.
> Searched the list , but only the old syle ( Method 1 or Method 2 ) comes
up.
> I am trying Method 3 , new with .40 onwards.
>
> Please can somebody point out my "basic" mistake :
>
> print "TYPE DWORD is known to Win32::API::Type \n" if
> Win32::API::Type->is_known('DWORD');
> print "TYPE LPTSTR is known to Win32::API::Type \n" if
> Win32::API::Type->is_known('LPTSTR');
>
> my $GetTempPathRetVal = Win32::API->Import('kernel32','DWORD
GetTempPath(
> DWORD nBufferLength, LPTSTR lpBuffer )');
> if($GetTempPathRetVal eq 0) {
> die "Can't import API GetTempPath : $^E\n";
> }
>
>
> my $lpBuffer = '-'x80;
> my $returnval = GetTempPath(79,$lpBuffer);
> my $TempPath = substr($lpBuffer,0,$returnval);
>
> print "Temp path is : $TempPath !!\n";
This problem was recently discussed. Please check the archives. The fix is
# around 158 in Win32::API::Type.pm if you comment these three lines out,
# it should work:
# if($is_pointer and $packing eq 'c') {
# $packing = "p";
# }
This now works:
use strict;
use warnings;
use Win32::API;
Win32::API->Import('kernel32',
'DWORD GetTempPathA(DWORD ccBuffer, LPSTR lpszBuffer)') or
die "Import GetTempPathA: $^E";
my $lpszBuffer = pack 'Z*', ' ' x 80;
my $ret = GetTempPathA (80, $lpszBuffer);
printf "ret='%s'; lpszBuffer='%s'\n", $ret, substr $lpszBuffer, 0, $ret;
__END__
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Win32::API LPTSTR
<[EMAIL PROTECTED]> wrote on 05/20/2005 12:33:29 PM:
> Not sure if this is a resend, I needed to subscribe to this list:
> I am trying to use Win32::API to import by prototype only;
> of the functions I have tried the ones with type LPTSTR fail;
> I would like to just use the prototypes because if its packing functions
> Win32::API::Struct and Win32::API::Type - see the example in API.pm
>
> example
>
> use Win32::API;
$Win32::API::DEBUG = 1; # this may be useful
>
> #DWORD GetTempPath(
> # DWORD ccBuffer,
> # LPTSTR lpszBuffer
> #);
>
> #Win32::API->Import("kernel32", "DWORD GetTempPath(DWORD ccBuffer,
> LPTSTR lpszBuffer)",);
# this allows success(1) or fail(0) to be checked
$rc = Win32::API->Import("kernel32", "DWORD GetTempPath(DWORD ccBuffer,
LPSTR lpszBuffer)",);
> #this fails and causes generic a windows error when GetTempPath() is
called
>
> Win32::API->Import('kernel32', 'GetTempPath', 'NP', 'N');
> #this of course works, but I would like to use the prototype
> #the example at the end of API.pm demonstrates using the prototype
>
> $lpszBuffer = " " x 80;
> GetTempPath(80, $lpszBuffer);
>
> print $lpszBuffer;
This (with the changes above) fails for me, also. The program output is
(PM)Struct::recognize got 'ccBuffer', 'DWORD' -> 'L'
(PM)Struct::recognize got 'lpszBuffer', 'LPSTR' -> 'p'
(PM)parse_prototype: got PROC 'GetTempPath'
(PM)parse_prototype: got PARAMS 'DWORD ccBuffer, LPSTR lpszBuffer'
(PM)parse_prototype: IN='DWORD' PACKING='L' API_TYPE=1
(PM)parse_prototype: IN='LPSTR' PACKING='p' API_TYPE=2
parse_prototype: IN=[ 1 2 ]
parse_prototype: OUT='DWORD' PACKING='L' API_TYPE=1
(PM)Type::Unpack: unpacking 'p' 'C:\D'
Then I get an application error dialog box that says
"The instruction at 0x78001cf7" referenced memory at "0x445c3a43". The
memory could not be "read".
I'm using Win32-API 0.41.1 - a 0.41 version modified by another subscriber
to support cdecl calling convention. Is there a version newer than 0.41?
Stepping with the debugger, it appears that a bad value (coincidently,
0x445c3a43, which is ascii 'C:\D') is getting picked up as the pointer
to the string variable data.
I don't know what's happening under the Win32::API hood (a lot of XS
stuff).
I've included my program and a debug log below with the hope it may be
useful to someone who has more smarts and time than I.
Let me know if anyone makes progress.
Lloyd
use Win32::API;
$Win32::API::DEBUG = 1;
# DWORD GetTempPath(
# DWORD ccBuffer,
# LPSTR lpszBuffer
# );
$rc = Win32::API->Import("kernel32", "DWORD GetTempPath(DWORD ccBuffer,
LPSTR lpszBuffer)",);
#! Win32::API->Import('kernel32', 'GetTempPath', 'NP', 'N');
$lpszBuffer = " " x 128;
GetTempPath(128, $lpszBuffer);
print $lpszBuffer;
-
>> perl -d try.pl
Loading DB routines from perl5db.pl version 1.28
Editor support available.
Enter h or `h h' for help, or `perldoc perldebug' for more help.
Win32::API::Type::CODE(0x1cda6b0)(C:/Perl/site/lib/Win32/API/Type.pm:40):
40: my $section = 'nothing';
DB<1> r
scalar context return from CODE(0x1cda6b0): ''
main::(try.pl:3): $Win32::API::DEBUG = 1;
DB<1> l
3==>$Win32::API::DEBUG = 1;
4
5 # DWORD GetTempPath(
6 # DWORD ccBuffer,
7 # LPSTR lpszBuffer
8 # );
9
11: $rc = Win32::API->Import("kernel32", "DWORD GetTempPath(DWORD
ccBuffer,
LPSTR lpszBuffer)",);
13
14 #! Win32::API->Import('kernel32', 'GetTempPath', 'NP', 'N');
17
18: $lpszBuffer = " " x 128;
19: GetTempPath(128, $lpszBuffer);
20
21: print $lpszBuffer;
22
DB<1> c 11
main::(try.pl:11): $rc = Win32::API->Import("kernel32", "DWORD
GetTempPath(
DWORD ccBuffer, LPSTR lpszBuffer)",);
DB<2> n
(PM)parse_prototype: got PROC 'GetTempPath'
(PM)parse_prototype: got PARAMS 'DWORD ccBuffer, LPSTR lpszBuffer'
(PM)parse_prototype: IN='DWORD' PACKING='L' API_TYPE=1
(PM)parse_prototype: IN='LPSTR' PACKING='p' API_TYPE=2
parse_prototype: IN=[ 1 2 ]
parse_prototype: OUT='DWORD' PACKING='L' API_TYPE=1
main::(try.pl:18): $lpszBuffer = " " x 128;
DB<2> x $rc
0 1
DB<3> l
18==> $lpszBuffer = " " x 128;
19: GetTempPath(128, $lpszBuffer);
20
21: print $lpszBuffer;
22
DB<3> n
main::(try.pl:19): GetTempPath(128, $lpszBuffer);
# start stepping into Win32::API glue
DB<3> s
main::GetTempPath((eval 7)[C:/Perl/site/lib/Win32/API.pm:132]:2):
2: sub main::GetTempPath {
$Win32::API::Imported{"kernel32:DWORD Ge
tTempPath(DWORD ccBuffer, LPSTR lpszBuffer)"}->Call(@_); }
DB<3> s
# Win32::API packs pointer to $lpszBuffer to pass to GetTempPath???
Win32::API::Type::Pack(C:/Perl/site/lib/Win32/API/Type.pm:189):
189:my $type = $_[0];
DB<3> x @_
0 'LPSTR'
1 '
'
DB<4> l
189==> my $type = $_[0];
190
191:if(packing($type) eq 'c' and is_pointer($type)) {
192:$_[1] = pack("Z*", $_[1]
Re: General question.
Артем Аветисян wrote on 04/28/2005 10:05:53 AM: > > Why do YOU use Perl for Windows? > GUI implementation for R&D of radar systems. Simulation of system component interfaces. "Quick and dirty" programs. ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Win32-API and ghostscript API
Rogers, John wrote on 04/20/2005 11:26:52 PM:
> Rob and Lloyd,
> Robs code actually works with gs8.15
> >I've just now noticed that the function you're accessing is called
> >'gsapi_revision' whereas I'm accessing 'gsdll_revision'.
> I got gsapi_ from the api.htm doc with gs8.15 gsdll_ is depreciated.
> A dll export browser shows both though. I assume there the same,
> only different format parameters
> Cant make gsapi_ work though.
> A Win32::API::Struct solution would be interesting though, following
> gives protection fault "memory can not be written.
>
> use strict;
> use Win32::API;
> my($GS_Rev,$rev,$DLL,$size);
> Win32::API::Struct->typedef( REVINFO => qw {
> CHAR *product;
> CHAR *copyright;
> LONG revision;
> LONG revisiondate;
> } );
> $rev = Win32::API::Struct->new('REVINFO');
> $DLL = 'C:\gs\gs8.15\bin\gsdll32.dll';
> $GS_Rev = Win32::API->new($DLL,'gsdll_revision','SL','V')
> or die "no-worky $! $^E";
> ### need to fix interface spec
> #
What is the value of $size? I don't see where it is set. (Although I
doubt this would result in a protection fault.) It appears that the
problem is the semantics of using a Struct in a Win32 call.
> $GS_Rev->Call($rev,$size);
> print $rev->{revision};
>
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: die() without setting $@
John Deighan wrote on 04/20/2005 08:25:09 AM:
> The problem with trying to use goto, or a return, or setting a global
> variable is that they don't work well in a function that's being called
by
> the code that contains the eval. 'return' won't work because it will
simply
> return from the function that was called. I don't think that 'goto' will
> work, though you might be able to goto ::EOB, I don't know. The
> global variable would still work, but I think that it requires too much
> dependency between the module that the called function is in and the
module
> containing the eval. I was hoping for something that works just like
die(),
> but didn't set $@, but in the absence of that, I think that perhaps the
> best solution is to do something like die("All is well\n"), then when
> checking for $@ after the eval block, just treat that string as a
special
> case. Does anyone see a problem with that?
>
> At 02:28 AM 4/20/2005, Anderson, Mark (Service Delivery) wrote:
> >perldoc -f goto
> >
> >eval {
> > ...
> > goto EOB;
> > ...
> > ...
> > EOB: return;
> >};if($@){
> > ...
> >}
> >
> >Kind regards,
> >
> >Mark Anderson
> >Service Improvement Programme
> >Level 2, 113 Dundas Street
> >Edinburgh, EH3 5DE
> >Tel: 0131 523 8786
> >Mob: 07808 826 063
> >
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [SMTP:[EMAIL PROTECTED] On Behalf
Of John
> > > Deighan
> > > Sent: Tuesday, April 19, 2005 4:57 PM
> > > To: perl-win32-users@listserv.ActiveState.com
> > > Subject: die() without setting $@
> > >
> > > *** WARNING : This message originates from the Internet ***
> > >
> > > I need to be able to jump to the end of the enclosing eval block,
just
> > > like
> > > a die() does, but without setting [EMAIL PROTECTED] Is there a way to do
> > > that?
(I've
> > > checked the Perl docs, but couldn't find it). I could possibly die()
with
> > > a
> > > specific string, then use "if ($@ && ($@ ne ))" as the error
trap,
> > >
> > > but that's aesthetically unpleasing.
> > >
> > > If you're interested in why, here's the explanation. Our web site is
> > > implemented via a series of "opcodes". The opcode is passed in the
URL.
> > > There is a goto in our main script that dispatches to a particular
opcode,
> > >
> > > and the code implementing the opcodes is surrounded by an eval
block. When
> > >
> > > the output is generated, it's generated via a call to a library that
> > > outputs a page - usually using a template file. There is, however,
also a
> > > function called errorPage() to which you pass a string. Now, when
> > > errorPage() is called, there has to be no further HTTP output, so
I'd
> > > prefer, at the end of the errorPage() routine, to pass directly to
the end
> > >
> > > of the eval block in the main code. die() does just that, but after
the
> > > eval block, there's a "if ($@)" that handles any real errors, like
> > > database
> > > connection errors, direct calls to die(), etc., and I don't want
calls to
> > > errorPage() to be treated like true errors (they're "user errors",
which
> > > just means that we want to display a page to the user informing them
of
> > > their error and how to correct it, and errorPage() does just that.
Real
> > > errors result in us receiving an e-mail with the error message, and
the
> > > error being logged to a database table).
> > >
Here's an off-the-cuff idea. But it may not meet your requirement to be
aesthetically pleasing. At the point the eval block is to be exitted,
use die() with the current $@ encoded in the die string. Immediately
following the eval block, the die string would have to be decoded to
recover the $@ representing a "real error" and the rest of the die string
indicating "user error."
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Win32-API and ghostscript API
"Rogers, John" wrote on 04/20/2005 02:00:58 AM:
>
> -Original Message-
> From: Rogers, John
> Sent: Wednesday, 20 April 2005 4:56 PM
> To: Perl-Win32-Gui-Users (E-mail)
> Subject:Win32-API and ghostscript API
> hi,
> I want to access the ghostscript API for the gsdll32.dll.
> been trying this any which way cant make it work, I must be doing
> some thing wrong any Ideas ?
I made corrections to your program, but did not get it to work first try,
and I don't have time to spend on it right now. I've made comments below.
> ###
> use strict;
> use Win32::API;
> Win32::API::Struct->typedef( REVINFO => qw{
> CHAR *product;
> CHAR *copyright;
> LONG revision;
> LONG revisiondate;
> });
> my $rev = Win32::API::Struct->new('REVINFO');
I haven't used Win32::API::Struct. I'll have to get more familiar
before I can get a working version.
> Win32::API->new('C:\gs\gs8.15\bin\gsdll32.
> dll','gsapi_revision','CCNN',V) or die "no-worky $! $^E";
This call returns an object which you must save. The DLL function is not
invoked. According to GS 8.50 documentation, the gsapi_revision interface
is if gsapi_revision(&r, sizeof(r)), where r is a REVINFO struct. So your
description of the interface ('CCNN','V') is incorrect. Also, 'C' is a
char, not a *char. Passing a pointer to a structure that contains pointers
makes it a little tricky defining the interface. You'll have to pack Perl
variables into a 'binary' string. I don't have it correct yet - that's why
I haven't gotten it to work.
> print $rev->{revision};
The function has not been invoked. You need $obj->Call(parms) where
$obj is the return from the Win32::API->new.
Here's what I've got so far. Passing of parameters still needs to be
resolved.
#==
use strict;
use Win32::API;
use vars qw($GS_Rev);
Win32::API::Struct->typedef( REVINFO => qw {
CHAR *product;
CHAR *copyright;
LONG revision;
LONG revisiondate;
} );
my $rev = Win32::API::Struct->new('REVINFO');
my $DLL = 'C:\Program Files\gs\gs8.50\bin\gsdll32.dll';
$GS_Rev = Win32::API->new($DLL,'gsapi_revision','PL','V')
or die "no-worky $! $^E";
### need to fix interface spec
#
$rev = $GS_Rev->Call(???);
print $rev->{revision};
#==
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: This is fun
Chris Wagner wrote on 04/18/2005 01:16:05 PM: > At 10:10 AM 4/18/05 -0700, Jan Dubois wrote: > >> > $x=10; > >> > $x=$x++; > >> > print "$x\n"; > >> > #Results: $x=10, $x=11. > >> The first result ($x=10) puzzles me. Are not the $x on the LHS and RHS > >> refering to the same scalar? I would think that $x would be assigned the > >> value of $x (10), and then be post-incremented, resulting in 11. > > I think the best way to understand this is that the evaluation of the = > operator comes later than the evaluation of the ++ operator. First $x is > interpreted as a right hand value of 10. The = operator now has a 10 in > it's queue of things to shove into the left hand side. Once $x is > interpreted into a 10, the ++ operator is evaluated and $x becomes 11. But > wait, the = operator still has to shove it's queue of things into $x. It > does this and the preincrement value of $x is shoved back into $x. > > $x = 10; > $x = ++$x; > print $x; > #->> 11 > Here the = operator sees the postincrement value of $x and shoves > that into $x. > > > >Think about how a more complex expression would need to be compiled: > > > > $x = 10; > > $x = $x++ + $x++; > > Same thing here, the + operator has a 10 and an 11 to work on. The 2nd $x > is eleven because one ++ operator has been evaluated. Basically the ++ > operator leaves the old value as the argument to whatever operator or > context it's used in. > That's a clear and "computer scientistish" explanation. Boils down to operator precedence, where assignment is included as an operator. It's been fun tossing this around. ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: This is fun
Jerry Kassebaum wrote on 04/17/2005 06:56:29 AM: > > $x=10; > > $x=$x++; > > print "$x\n"; > > $x=10; > > $y=$x++; > > print "$x\n"; > > #Results: $x=10, $x=11. > #I understand it, but I think it's weird anyway. > The first result ($x=10) puzzles me. Are not the $x on the LHS and RHS refering to the same scalar? I would think that $x would be assigned the value of $x (10), and then be post-incremented, resulting in 11. Explanation? ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Inline::CPP
Lloyd Sartor wrote on 04/11/2005 10:01:15 AM: > "Sisyphus" <[EMAIL PROTECTED]> wrote on 04/08/2005 05:23:42 PM: > > I get an unusual error: Can't open perl script "and" when testing. > > $ perl makefile.pl > This will configure and build Inline::C++. > What default C++ compiler would you like to use? [cl -TP] > What default libraries would you like to include? [MSVCIRT.LIB] > Writing Makefile for Inline::CPP::grammar > Writing Makefile for Inline::CPP > > $ nmake test > > Microsoft (R) Program Maintenance Utility Version 7.10.3077 > Copyright (C) Microsoft Corporation. All rights reserved. > > Skip blib\lib\Inline\CPP.pm (unchanged) > Skip blib\lib\Inline\CPP.pod (unchanged) > C:\Perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" > "test_harness(0, 'bl > ib\lib', 'blib\arch')" t\01basic.t t\02prefix.t > t\01basic.Can't open perl script "and": No such file or directory > Failed to autogenerate C:\Documents and Settings\a1027277\My > Documents\Perl\Inli > ne-CPP\Inline-CPP-0.25\_Inline\config. > > at t\01basic.t line 30 > BEGIN failed--compilation aborted at t\01basic.t line 64. > t\01basic.dubious > Test returned status 2 (wstat 512, 0x200) > DIED. FAILED tests 1-10 > Failed 10/10 tests, 0.00% okay > t\02prefixCan't open perl script "and": No such file or directory > Failed to autogenerate C:\Documents and Settings\a1027277\My > Documents\Perl\Inli > ne-CPP\Inline-CPP-0.25\_Inline\config. > > at t\02prefix.t line 0 > INIT failed--call queue aborted, line 1. > t\02prefixdubious > Test returned status 2 (wstat 512, 0x200) > DIED. FAILED tests 1-4 > Failed 4/4 tests, 0.00% okay > Failed Test Stat Wstat Total Fail Failed List of Failed > --- > t\01basic.t 2 51210 20 200.00% 1-10 > t\02prefix.t2 512 48 200.00% 1-4 > Failed 2/2 test scripts, 0.00% okay. 14/14 subtests failed, 0.00% okay. > NMAKE : fatal error U1077: 'C:\Perl\bin\perl.exe' : return code '0x2' > Stop. > I was bitten by MS directory names that include spaces. After fixing that and updating the $INCLUDE environment variable, Inline::CPP tested ok. Rob, thanks for the guidance. Lloyd $ nmake test Microsoft (R) Program Maintenance Utility Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. Skip blib\lib\Inline\CPP.pm (unchanged) Skip blib\lib\Inline\CPP.pod (unchanged) C:\Perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0, 'bl ib\lib', 'blib\arch')" t\01basic.t t\02prefix.t t\01basic.ok t\02prefixok All tests successful. Files=2, Tests=14, 28 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) C:\Perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0, '.. \blib\lib', '..\blib\arch')" t\01nherit.t t\02scope.t t\03inline.t t\04const.t t \05virt.t t\06deflt.t t\07static.t t\08anon.t t\09purevt.t t\10struct.t t\11minh rt.t t\12retlst.t t\13vararg.t t\14const.t t\15stvar.t t\16varlst.t t\01nheritok t\02scope.ok t\03inlineok t\04const.ok t\05virt..ok t\06deflt.ok t\07staticok t\08anon..ok t\09purevtok t\10structok t\11minhrtok t\12retlstok t\13varargok t\14const.ok t\15stvar.ok t\16varlstok All tests successful. Files=16, Tests=34, 118 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Inline::CPP
Lloyd Sartor wrote on 04/11/2005 10:01:15 AM: > "Sisyphus" <[EMAIL PROTECTED]> wrote on 04/08/2005 05:23:42 PM: > > I get an unusual error: Can't open perl script "and" when testing. > > $ perl makefile.pl > This will configure and build Inline::C++. > What default C++ compiler would you like to use? [cl -TP] > What default libraries would you like to include? [MSVCIRT.LIB] > Writing Makefile for Inline::CPP::grammar > Writing Makefile for Inline::CPP > > $ nmake test > > Microsoft (R) Program Maintenance Utility Version 7.10.3077 > Copyright (C) Microsoft Corporation. All rights reserved. > > Skip blib\lib\Inline\CPP.pm (unchanged) > Skip blib\lib\Inline\CPP.pod (unchanged) > C:\Perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" > "test_harness(0, 'bl > ib\lib', 'blib\arch')" t\01basic.t t\02prefix.t > t\01basic.Can't open perl script "and": No such file or directory > Failed to autogenerate C:\Documents and Settings\a1027277\My > Documents\Perl\Inli > ne-CPP\Inline-CPP-0.25\_Inline\config. > > at t\01basic.t line 30 > BEGIN failed--compilation aborted at t\01basic.t line 64. > t\01basic.dubious > Test returned status 2 (wstat 512, 0x200) > DIED. FAILED tests 1-10 > Failed 10/10 tests, 0.00% okay > t\02prefixCan't open perl script "and": No such file or directory > Failed to autogenerate C:\Documents and Settings\a1027277\My > Documents\Perl\Inli > ne-CPP\Inline-CPP-0.25\_Inline\config. > > at t\02prefix.t line 0 > INIT failed--call queue aborted, line 1. > t\02prefixdubious > Test returned status 2 (wstat 512, 0x200) > DIED. FAILED tests 1-4 > Failed 4/4 tests, 0.00% okay > Failed Test Stat Wstat Total Fail Failed List of Failed > --- > t\01basic.t 2 51210 20 200.00% 1-10 > t\02prefix.t2 512 48 200.00% 1-4 > Failed 2/2 test scripts, 0.00% okay. 14/14 subtests failed, 0.00% okay. > NMAKE : fatal error U1077: 'C:\Perl\bin\perl.exe' : return code '0x2' > Stop. > I was bitten by MS directory names that include spaces. After fixing that and updating the $INCLUDE environment variable, Inline::CPP tested ok. Rob, thanks for the guidance. Lloyd $ nmake test Microsoft (R) Program Maintenance Utility Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. Skip blib\lib\Inline\CPP.pm (unchanged) Skip blib\lib\Inline\CPP.pod (unchanged) C:\Perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0, 'bl ib\lib', 'blib\arch')" t\01basic.t t\02prefix.t t\01basic.ok t\02prefixok All tests successful. Files=2, Tests=14, 28 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) C:\Perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0, '.. \blib\lib', '..\blib\arch')" t\01nherit.t t\02scope.t t\03inline.t t\04const.t t \05virt.t t\06deflt.t t\07static.t t\08anon.t t\09purevt.t t\10struct.t t\11minh rt.t t\12retlst.t t\13vararg.t t\14const.t t\15stvar.t t\16varlst.t t\01nheritok t\02scope.ok t\03inlineok t\04const.ok t\05virt..ok t\06deflt.ok t\07staticok t\08anon..ok t\09purevtok t\10structok t\11minhrtok t\12retlstok t\13varargok t\14const.ok t\15stvar.ok t\16varlstok All tests successful. Files=16, Tests=34, 118 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Inline::CPP
"Sisyphus" <[EMAIL PROTECTED]> wrote on 04/08/2005 05:23:42 PM:
>
> > $Bill wrote on 04/08/2005 09:23:03 AM:
> >
> > > Sisyphus wrote:
> > >
> > > > Try cpan :-)
> > > >
> > > > As was mentioned a few days back, there might be problems with
some
> > > > compilers on Win32 - but I thought we covered those issues. What's
the
> > > > problem you've come up against ?
> > >
> > > If there were no problems, it would be available via PPM somewhere.
:)
> > >
>
> That's correct - but those (2) problems were discussed a few days back
in
> the thread 'More on Re: Windows DLL - Perl Interface' which op was
> following.
>
> > I need to link functions from a vendor's CPP source to a Perl program.
> > (Inline::C doesn't find the functions because of the name mangling.)
The
> > ActiveState web site does not indicate that Inline::CPP is available
for
> > Win32. Am I SOL?
> >
>
> Go to http://search.cpan.org/~neilw/Inline-CPP-0.25/ and click on the
> 'Download' link. Extract the downloaded file to some folder and cd to
that
> folder. As was mentioned in a link provided in that other thread,
starting
> at about line 44 of CPP.pm you have:
>
> #ifndef bool
> #include <%iostream%>
> #endif
> extern "C" {
> #include "EXTERN.h"
> #include "perl.h"
>
> Add "#include " to the top of that list - so it reads:
>
> #include
> #ifndef bool
> #include <%iostream%>
> #endif
> extern "C" {
> #include "EXTERN.h"
> #include "perl.h"
>
> Then run, in succession,
> perl makefile.pl
> nmake test
> nmake install
>
> The last test in the test suite will fail (with VC++ 6.0) - not sure
why,
> but it probably won't lead to any problems for you. If it does, let us
know.
>
> I assume you are using VC++ 6.0.
I am using Microsoft Visual C++ Toolkit 2003 installed per
http://aspn.activestate.com/ASPN/docs/ActivePerl/lib/Pod/perlwin32.html.
However,
I never rebuilt Perl. Is that necessary?
$ cl /?
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for
80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
I get an unusual error: Can't open perl script "and" when testing.
$ perl makefile.pl
This will configure and build Inline::C++.
What default C++ compiler would you like to use? [cl -TP]
What default libraries would you like to include? [MSVCIRT.LIB]
Writing Makefile for Inline::CPP::grammar
Writing Makefile for Inline::CPP
$ nmake test
Microsoft (R) Program Maintenance Utility Version 7.10.3077
Copyright (C) Microsoft Corporation. All rights reserved.
Skip blib\lib\Inline\CPP.pm (unchanged)
Skip blib\lib\Inline\CPP.pod (unchanged)
C:\Perl\bin\perl.exe "-MExtUtils::Command::MM" "-e"
"test_harness(0, 'bl
ib\lib', 'blib\arch')" t\01basic.t t\02prefix.t
t\01basic.Can't open perl script "and": No such file or directory
Failed to autogenerate C:\Documents and Settings\a1027277\My
Documents\Perl\Inli
ne-CPP\Inline-CPP-0.25\_Inline\config.
at t\01basic.t line 30
BEGIN failed--compilation aborted at t\01basic.t line 64.
t\01basic.dubious
Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 1-10
Failed 10/10 tests, 0.00% okay
t\02prefixCan't open perl script "and": No such file or directory
Failed to autogenerate C:\Documents and Settings\a1027277\My
Documents\Perl\Inli
ne-CPP\Inline-CPP-0.25\_Inline\config.
at t\02prefix.t line 0
INIT failed--call queue aborted, line 1.
t\02prefixdubious
Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 1-4
Failed 4/4 tests, 0.00% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t\01basic.t 2 51210 20 200.00% 1-10
t\02prefix.t2 512 48 200.00% 1-4
Failed 2/2 test scripts, 0.00% okay. 14/14 subtests failed, 0.00% okay.
NMAKE : fatal error U1077: 'C:\Perl\bin\perl.exe' : return code '0x2'
Stop.
>>
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Inline::CPP
$Bill wrote on 04/08/2005 09:23:03 AM: > Sisyphus wrote: > > > Try cpan :-) > > > > As was mentioned a few days back, there might be problems with some > > compilers on Win32 - but I thought we covered those issues. What's the > > problem you've come up against ? > > If there were no problems, it would be available via PPM somewhere. :) > I need to link functions from a vendor's CPP source to a Perl program. (Inline::C doesn't find the functions because of the name mangling.) The ActiveState web site does not indicate that Inline::CPP is available for Win32. Am I SOL? Lloyd ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Inline::CPP
Can anyone tell me where I can find a working Inline::CPP for Win32? ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: [OT] Spam to list
> > 1) Remove all .sigs and other parts of the message that aren't pertinent > > to your reply. (Don't be lazy and force it on the next guy.) > > > 2) Respond to each sentence/paragraph immediately below that item and > > keep the quoting intact (the >>> stuff on the left) so people know you > > said what. > > > 3) Post in plain text only and keep the width to around 70 to allow for > > quoting of responses and still stay under 80 (obviously a code snippet > > would go the full 80 since you're pasting it in). > > This should be taught in elementary school along with sex education > and nutrition. They didn't have sex education when I was in elementary school. Nor did my father ever tell me about the birds and the bees. So I learned much about sex, like posting, from friends and observation. Sometimes, these were poor examples. The what, how, and why of many things were not learned until much later in life. This thread has been very enlightening. I'm sure there are others like me that "top posted" simply because of ignorance, not malice or laziness. Now I can't wait to respond in proper style! ;-) Lloyd ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: [OT] Spam to list
Ye of little faith...even PERL blesses those of the proper class...[EMAIL PROTECTED] wrote: -To: Sisyphus <[EMAIL PROTECTED]>From: "$Bill Luebkert" <[EMAIL PROTECTED]>Sent by: [EMAIL PROTECTED]Date: 03/31/2005 08:15PMcc: perl-win32-users Subject: Re: [OT] Spam to listSisyphus wrote:> Hi,> Whenever I reply to this list I receive a message from> [EMAIL PROTECTED] with the following subject:> > Symantec Mail Security detected that you sent a message containing> prohibited content that is considered spam - please call email recipient.> > The body of the email reads something like:> > Subject of the message: Re: More on Re: Windows DLL - Perl Interface> Recipient of the message: "Perl-Win32-Users@listserv.ActiveState.com"> > > Does anybody else receive these gems ? Anyone know what's (likely to be)> going on ? It's only mail to this list that generates the spam notification.> I don't know if I will receive it when I *start* a thread on this list > but I'm about to find out.Obviously they don't like Aussies.If that's not it, must be that M$ crap you're using to post with.If that's not it, I recommend bumping [EMAIL PROTECTED] from the Win32 list.If that doesn't help, quit posting to the list.If that doesn't get it, email your posts to me and I'll forward them to the list.If that doesn't work, pray - but I'm sure that won't help.PS: I don't get the rejections you speak of, but I do get tons of OOF replies.-- ,-/- __ _ _ $Bill Luebkert Mailto:[EMAIL PROTECTED] (_/ / ) // // DBE Collectibles Mailto:[EMAIL PROTECTED] / ) /--< o // // Castle of Medieval Myth & Magic http://www.todbe.com/-/-' /___/_<_http://dbecoll.tripod.com/ (My Perl/Lakers stuff)___Perl-Win32-Users mailing listPerl-Win32-Users@listserv.ActiveState.comTo unsubscribe: http://listserv.ActiveState.com/mailman/mysubs___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: More on Re: Windows DLL - Perl Interface
It's not clear to me what is meant by "an OO manner." Is the DLL an implementation of one or more C++ classes? Or is the DLL being accessed from within a Perl class/object? Or both? Your questions lead me to consider passing objects between C++ and Perl. I don't know how that would/could be done. But it might be an interesting science project. But if I needed a solution in a timely manner, I would concisely define what must be OO, and then probably attack it with Inline::C or Inline:C++. Win32::API certainly has its limitations. I will be interested in hearing how you proceed. Good luck, Lloyd [EMAIL PROTECTED] wrote on 03/31/2005 03:21:42 PM: > Any updates on this? > > I have no choice but to access a DLL in an OO manner. Win32::API in its > latest release seems to be geared towards non-oo implementation > (importing it in to behave like a sub) with little doc on how to handle > it in an OO manner. Additionally, all of the packing and unpacking... > > Isn't there something easier to use out there? > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Sisyphus > Sent: Tuesday, March 15, 2005 4:03 PM > Cc: Perl-Win32-Users@listserv.ActiveState.com > Subject: Re: More on Re: Windows DLL - Perl Interface > > Lloyd Sartor wrote: > > FYI - if I had to do it all over again, I would go the Inline::C > route, > > although it may take some time to get the compiler tools installed. > > > > That's my preferred route, too - and installing the "compiler tools" > amounts to nothing more than installing the MinGW binaries (and also > installing ExtUtils::FakeConfig if you're running ActiveState perl. > > Cheers, > Rob > > ___ > Perl-Win32-Users mailing list > Perl-Win32-Users@listserv.ActiveState.com > To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs > > > ___ > Perl-Win32-Users mailing list > Perl-Win32-Users@listserv.ActiveState.com > To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: problem with TERM::ReadKey
For information on building AS Perl under Windows, see http://aspn.activestate.com/ASPN/docs/ActivePerl/lib/Pod/perlwin32.html. All the tools are available on the internet at no cost - including MSVC++. The link explains where to get them. Lloyd Jezebel <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 03/29/2005 03:03 PM To perl-win32-users@listserv.ActiveState.com cc Subject problem with TERM::ReadKey okay, i have a perl script that sends a text file as serial data records out an I/O port at variable baudrates, etc.. I need to have a way to interrupt the data transmission *cleanly* (not via CTRL-C), so that the current data string completes to the next CR/LF terminator before stopping. therefore, i need some sort of unbuffered input so the program can check whether a character has been pressed (say, the ESC key), and stops the program, otherwise it will carry on normally. I havent been able to get the getc() function to work as i wanted; i dont have stty. cygwin is not an option as this is going to be used by other windows users who just point to my perl build on a networked drive. I have found what i think is what I need: The TERM::ReadKey module and/or the TERM::GetKey module (which depends on ReadKey) problem is, i can not compile the TERM::ReadKey from source. whoever wrote it thought that Microsoft's Visual C++ was a good build environment. Since I don't have Visual C++, my nmake always fails at the cl.exe command. I tried spoofing it to my c++.exe and removing some switches, but then it fails on the link.exe command. I am not a C++ programmer, so now I'm stuck. (My work is also not going to buy me MSVC++ just so i can compile one stinkin perl module either.) can anyone help me out? Is there a better way to solve my original problem? thanks Jez __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: c -> perl
There are recent threads in the archive
that discuss Perl-to-C interface options. I recommend taking a good look
at Inline::C before deciding on Win32::API.
"Paul Rogers"
<[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
03/28/2005 08:11 AM
To
"Perl-Win32-Users"
cc
Subject
c -> perl
I've been tasked with getting some perl scripts to
connect to the GoldMine
API. I checked some of their API docs and they have C and VB sample
code.
I figured it'd be easier to translate directly from C, even though I have
no
real clue about C. Easier, in the sense that I'm dealing with C data
types,
not VB data types.
>From my research on this, it looks like I'll need to use Win32::API
to do
this job.
Any hints/direction as to how I can do this?
Paul ---
// prototypes
typedef int (*fnGMW_LoadBDE) ( char *szSysDir, char *szGoldDir, char
*szCommonDir, char *szUser );
typedef int (*fnGMW_UnloadBDE) ();
void GM5S32_DLL_Test() {
// load the GM5S32.DLL
HMODULE hLib = LoadLibrary("GM5S32.DLL");
if( hLib ) {
// get proc addresses of GM5S32 functions
fnGMW_LoadBDE GMW_LoadBDE = (fnGMW_LoadBDE) GetProcAddress( (HINSTANCE)
hLib, "GMW_LoadBDE" );
fnGMW_UnloadBDE GMW_UnloadBDE = (fnGMW_UnloadBDE)
GetProcAddress((HINSTANCE) hLib,"GMW_UnloadBDE");
// initialize the BDE
GMW_LoadBDE( "d:\\gm4", "d:\\gm4", "d:\\gm4\\demo",
szUser, szPass );
// do whatever..
// shut down BDE
GMW_UnloadBDE();
// unload the DLL
FreeLibrary(hLib);
}
return;
}
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: ppm and proxies
Ask your network administrator - whoever manages your firewall. You might check your browser configuration - it may already be configured to use a proxy. That is information local to your network. It has nothing to do with Perl and I don't think the list will be able to find the info for you. Arnold Wiegert <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 03/23/2005 11:54 AM To [EMAIL PROTECTED] cc Perl-Win32 Subject Re: ppm and proxies [EMAIL PROTECTED] wrote: > In your system environment variables set up the following: > > VARIABLE - VALUE > HTTP_proxy - http://proxyAddr.com > HTTP_proxy_user - username > HTTP_proxy_pass - pass > The real problem is figuring out what to put in the HTTP_proxy field ;-) Arnold ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: ppm and proxies
Set the HTTP_proxy environment variable to the URL of your proxy. Arnold Wiegert <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 03/22/2005 04:05 PM To Perl-Win32 cc Subject ppm and proxies Any one have any details or Howtos on setting up a 'proxy' for use with ppm. Me and my Activestate Perl (running under WinME) live behind a Dachstein LEAF/LRP firewall and 'we' have been having troubles setting up some of the packages by downloading the files from ActiveState to a local repository and installing from there. I've also had a lot of help in trying to install some troublesome modules manually, but things are still not working as well as they should. As a result I would like to investigate using a proxy, but I have next to no clue as to where to find one and/or how to go about getting/setting up/using it. My main assumption is that this proxy lives on my firewall and I am asking in the appropriate group for more details. Is this a good assumption, and if not, what part is wrong and in which way, where can I find out more? Activestate simply says a proxy is one way to install packages when one is behind a firewall, but I've not found much in the way of details and specifics for setting it up. Any help is greatly appreciated. TIA, Arnold ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: variable question
What is your intent here? What should $test2 be? Depending on your answers, maybe one of the following will help. Solution 1: In your code, $test2 is set to the value of $test. To get it to $ultimate_value, do the same. Now all three variables are "boo". $test = "boo"; $test2 = "$test"; $ultimate_value = "$test2"; print "$test\t$test2\t$ultimate_value\n\n"; boo boo boo Solution 2: Make $test2 a hard reference to $test, so the value of $test2 at any time is the value of $test. Then assign $test2 to $uv: $test = "boo"; $test2 = \$test; $ultimate_value = $$test2; print "$test\t$test2\t$ultimate_value\n\n"; boo SCALAR(0x1a4baa4) boo Solution 3: Use a symbolic reference to $test: $test = "boo"; $test2 = 'test'; $ultimate_value = $$test2; print "$test\t$test2\t$ultimate_value\n\n"; boo test boo Cheers, Lloyd "vaughnte" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 03/16/2005 04:03 PM Please respond to vaughnte To: cc: Subject: variable question Howdy I am looking to achieve the following : $test = "boo"; $test2 = "$test"; $ultimate_value = <$test2>; where $ultimate_value ends up with contents of $test. Any suggestions...(beyond $ultimate_value = $test)... :) Terry E. Vaughn VCS222 phone: 843-841- Email: [EMAIL PROTECTED] Web: VCS222.com ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
More on Re: Windows DLL - Perl Interface
FYI - if I had to do it all over again, I would go the Inline::C route, although it may take some time to get the compiler tools installed. Lloyd __ I recently had to interface Perl to a Windows DLL. I learned that Win32::API 0.41 did not support cdecl calling convention. Another list subscriber provided a modified WIn32::API patched to handle cdecl convention. However, it has a quirk when calling a procedure with zero parameters - do not specify cdecl in that case. Look at the list archive for a thread describing my experience and results. (I would give you the link, but I can not get to the ActiveState web site right now. A pertinent part of the thread is inserted below.) I have had success with Willem's modified Win32::API, but with an anomoly. (FYI, I had to download msvcr71.dll to get it to work.) The following is from the vendor-provided C include file: #define IMPORT extern "C" __declspec(dllimport) IMPORT DWORD Card_Check(void); IMPORT DWORD Card_Open(DWORD CardNum); When I created the API objects specifying 'cdecl' as the calling convention: $CardCheck = new Win32::API($XXX_DLL,'_CardCheck',[],'L','_cdecl'); die "**ERROR** unable to create Win32::API object" if !$CardCheck; $CardOpen = new Win32::API($xxx_DLL,'_CardOpen','L','L','_cdecl'); then the process died on the call to $CardCheck. When I created $CardCheck without specifying '_cdecl', then both $CardCheck and $CardOpen succeeded. I'm sure both DLL procedures use the same calling convention. My guess is $CardCheck behaves differently because it has zero input arguments. It may be nice if Win32::API defaulted to the cdecl convention if the procedure name begins with an underscore. (DIY project?) Thank you for help, Lloyd willem <[EMAIL PROTECTED]> 02/04/2005 01:21 PM To: Lloyd Sartor <[EMAIL PROTECTED]> cc: perl-win32-users@listserv.ActiveState.com Subject: Re: Help for debugging Win32::API DLL interface the standard version of Win32::API does not support api's declared with 'cdecl'. maybe your dll has functions declared that way? If this is the case, see a patch I made to Win32::API, to support cdecl type functions too: see http://www.xs4all.nl/~itsme/projects/perl/ willem Lloyd Sartor wrote: > > I am trying to use a third-party DLL to control their PCI board. The > first call to the DLL works, but the second causes the entire Perl > process to die with the following error in a dialog box: > > The instruction at "0x280414c5" referenced memory at "0x0004". The > memory could not be "written". > > My first suspicion is the stack is being corrupted because of mismatched > parameter types. But to test this theory, I repeatedly called the > working function with no problems. The DLL procedure objects appear to > be created correctly - the lower word of the address matches the DLL > offset for the procedures. Here is a code snippet. (I have changed the > function names to protect the privacy of our vendor.) > > $Card_Check = new Win32::API($XXX_DLL,'_CheckCards',[],'L'); > die "**ERROR** unable to create Win32::API object" if !$CheckCard; > $Card_Open = new Win32::API($XXX_DLL,'_CardOpen','L','L'); > > $CardPresent = $Card_Check->Call(); > die "**ERROR** installation error\n\n" if $CardPresent != 1; > > $CardStatus = $Card_Open->Call(1); > die "**ERROR** Card_Open error\n\n" if $CardStatus != 0; > > I have set env var PERL_DL_DEBUG = 9, hoping to get useful output, but > nothing that helped. > > My understanding is that parameter type 'L' (or 'N') on Win32 is 32-bits. > > Any help on how can I find the error source? If the DLL uses the "cdecl" "$Bill Luebkert" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 03/14/2005 09:54 PM To: honery <[EMAIL PROTECTED]> cc: Perl-Win32-Users@listserv.ActiveState.com Subject: Re: Windows DLL - Perl Interface honery wrote: >>From my read of the applicable docs, and the examples I cannot find an > appropriate tool for building a Perl interface to a Windows DLL (a > Perl extension?). > I'd appreciate it if some of the folks in this group experienced in > Perl could provide a sanity check. > > The DLL is written in C; it has an interface that uses the "standard" > calling convention. In VB, I can directly invoke the function in this > DDL after declaring in the following form: > > Public Declare Function CheckComponent Lib "Check.dll" (ByVal FileName >
Re: Windows DLL - Perl Interface
I recently had to interface Perl to a Windows DLL. I learned that Win32::API 0.41 did not support cdecl calling convention. Another list subscriber provided a modified WIn32::API patched to handle cdecl convention. However, it has a quirk when calling a procedure with zero parameters - do not specify cdecl in that case. Look at the list archive for a thread describing my experience and results. (I would give you the link, but I can not get to the ActiveState web site right now. A pertinent part of the thread is inserted below.) I have had success with Willem's modified Win32::API, but with an anomoly. (FYI, I had to download msvcr71.dll to get it to work.) The following is from the vendor-provided C include file: #define IMPORT extern "C" __declspec(dllimport) IMPORT DWORD Card_Check(void); IMPORT DWORD Card_Open(DWORD CardNum); When I created the API objects specifying 'cdecl' as the calling convention: $CardCheck = new Win32::API($XXX_DLL,'_CardCheck',[],'L','_cdecl'); die "**ERROR** unable to create Win32::API object" if !$CardCheck; $CardOpen = new Win32::API($xxx_DLL,'_CardOpen','L','L','_cdecl'); then the process died on the call to $CardCheck. When I created $CardCheck without specifying '_cdecl', then both $CardCheck and $CardOpen succeeded. I'm sure both DLL procedures use the same calling convention. My guess is $CardCheck behaves differently because it has zero input arguments. It may be nice if Win32::API defaulted to the cdecl convention if the procedure name begins with an underscore. (DIY project?) Thank you for help, Lloyd willem <[EMAIL PROTECTED]> 02/04/2005 01:21 PM To: Lloyd Sartor <[EMAIL PROTECTED]> cc: perl-win32-users@listserv.ActiveState.com Subject: Re: Help for debugging Win32::API DLL interface the standard version of Win32::API does not support api's declared with 'cdecl'. maybe your dll has functions declared that way? If this is the case, see a patch I made to Win32::API, to support cdecl type functions too: see http://www.xs4all.nl/~itsme/projects/perl/ willem Lloyd Sartor wrote: > > I am trying to use a third-party DLL to control their PCI board. The > first call to the DLL works, but the second causes the entire Perl > process to die with the following error in a dialog box: > > The instruction at "0x280414c5" referenced memory at "0x0004". The > memory could not be "written". > > My first suspicion is the stack is being corrupted because of mismatched > parameter types. But to test this theory, I repeatedly called the > working function with no problems. The DLL procedure objects appear to > be created correctly - the lower word of the address matches the DLL > offset for the procedures. Here is a code snippet. (I have changed the > function names to protect the privacy of our vendor.) > > $Card_Check = new Win32::API($XXX_DLL,'_CheckCards',[],'L'); > die "**ERROR** unable to create Win32::API object" if !$CheckCard; > $Card_Open = new Win32::API($XXX_DLL,'_CardOpen','L','L'); > > $CardPresent = $Card_Check->Call(); > die "**ERROR** installation error\n\n" if $CardPresent != 1; > > $CardStatus = $Card_Open->Call(1); > die "**ERROR** Card_Open error\n\n" if $CardStatus != 0; > > I have set env var PERL_DL_DEBUG = 9, hoping to get useful output, but > nothing that helped. > > My understanding is that parameter type 'L' (or 'N') on Win32 is 32-bits. > > Any help on how can I find the error source? If the DLL uses the "cdecl" "$Bill Luebkert" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 03/14/2005 09:54 PM To: honery <[EMAIL PROTECTED]> cc: Perl-Win32-Users@listserv.ActiveState.com Subject: Re: Windows DLL - Perl Interface honery wrote: >>From my read of the applicable docs, and the examples I cannot find an > appropriate tool for building a Perl interface to a Windows DLL (a > Perl extension?). > I'd appreciate it if some of the folks in this group experienced in > Perl could provide a sanity check. > > The DLL is written in C; it has an interface that uses the "standard" > calling convention. In VB, I can directly invoke the function in this > DDL after declaring in the following form: > > Public Declare Function CheckComponent Lib "Check.dll" (ByVal FileName > As String) As Long Can't you use Win32::API to access it ? > I like the idea of creating an interface file rather than turning SWIG > loose on the header to mak
Capturing package "source"
I've used ppm and it's great. However, I need to capture the Perl modules that I've used on a project so the software environment can be recreated at some later time. How can I capture Perl packages (on my local machine) that can later be installed using ppm? Thanks, Lloyd ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: unpack returning an array?
> What I still cannot get it to do is extract them as hex words This I don't understand. The unpacked number is stored in 8 memory bits. Displaying these 8 bits as decimal, hex, or binary is for human convenience. Use printf if you want to display in hex. ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: eval a file inside a script
that's beautiful...thanks "$Bill Luebkert" <[EMAIL PROTECTED]> 03/07/2005 09:19 AM To: Lloyd Sartor <[EMAIL PROTECTED]> cc: perl-win32-users@listserv.ActiveState.com Subject: Re: eval a file inside a script Lloyd Sartor wrote: > > Is there an easier or more concise way to eval a script file inside > another script than the following? > > open WCFG,'<.\waveform_conf.pl'; > @cfg = ; > close WCFG; > eval "@cfg"; Have you tried do './waveform_conf.pl'; -- ,-/- __ _ _ $Bill Luebkert Mailto:[EMAIL PROTECTED] (_/ / ) // // DBE Collectibles Mailto:[EMAIL PROTECTED] / ) /--< o // // Castle of Medieval Myth & Magic http://www.todbe.com/ -/-' /___/_<_ ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
eval a file inside a script
Is there an easier or more concise way to eval a script file inside another script than the following? open WCFG,'<.\waveform_conf.pl'; @cfg = ; close WCFG; eval "@cfg"; ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: unpack returning an array?
I think you want to use 'C4' (or 'C*' or whatever) instead of 'H8' to get an array of bytes.
$buffer = pack('C*',0x7c,0x45,0x3e,0x02);
$MyArray[0] = [ unpack('C*',$buffer) ];
"Ed Chester" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
03/07/2005 08:39 AM
To: "Paul Sobey" <[EMAIL PROTECTED]>, perl-win32-users@listserv.ActiveState.com
cc:
Subject: RE: unpack returning an array?
> How about:
> my @array = unpack ("H8", $buffer);
> $MyArray[$i] = [EMAIL PROTECTED];
> Or even:
> $MyArray[$i] = [ unpack ("H8", $buffer) ];
Thanks for the suggestion - you're right, unpack is seeing scalar context. Your two ideas are the same, they do indeed assign the output of pack to a (1-element) array which is passed to $MyArray[$i]. What I know isn't right is the H8 - instead of H8 as a single array element, i'd like an array like e.g. H2, H2, H2, H2. my explanation wasn't brilliant, but i hope the example i gave is better. any idea how to set unpack's template to do this?
thanks a lot for your time,
ed c
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Word and Byte Types
However, perl does provide the pack and unpack functions for squeezing variables into machine-dependent quanta. This is very useful when a precise data structure must be provided, such as when using library functions or a message-passing interface. Win32::API::Structure also provides the ability to use C structures. [EMAIL PROTECTED] (Chris Wagner) Sent by: [EMAIL PROTECTED] 02/25/2005 01:53 PM To: perl-win32-users@listserv.ActiveState.com cc: Subject: Re: Word and Byte Types Sorry, perl has no concept of variable type. Any variable is beaten into the form necessary for the context in which it was called. $bob = "abc" print $bob + 5; "5" At 07:04 PM 2/25/05 +, Anton Ganeshalingam wrote: >I have a Delphi code as following: > > var Key: word; // Key variable is a word type; > var Sum: byte; // Sum variable is a byte type; > >How do I make perl (a type free language) variables $key and $sum behave >as the above code. > >Please help. > > -- REMEMBER THE WORLD TRADE CENTER ---=< WTC 911 >=-- "...ne cede males" 0100 ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Help for debugging Win32::API DLL interface
Success!
While modifying my program to use Inline::C, I realized why Win32::API was crashing: I was specifying a reference to a packed string for a pointer parameter in a Call (code for which I didn't provide snippets in previous emails) when only the string should have been specified.
So now I have both Win32::API and Inline::C versions.
The whitespace-in-pathnames problem is inconvenient, but easy enough to work-around.
Thanks to everyone for their insight and advice. It's been a great learning experience.
Cheers,
Lloyd
Sisyphus <[EMAIL PROTECTED]>
02/07/2005 11:24 PM
To: Lloyd Sartor <[EMAIL PROTECTED]>
cc: perl-win32-users@listserv.ActiveState.com
Subject: Re: Help for debugging Win32::API DLL interface
Lloyd Sartor wrote:
> Well, I'm back. Continuing to have problems using Win32::API so abandoning
> it in favor of Inline.
>
> However, having spaces in pathnames is causing problems. Any suggestions?
>
Best to simply avoid any directory with a space in its name. But if you
can't do that - then you'll avoid the problem if you specify those
horrible DOSish type names instead.
So - at a guess - run:
cd \DOCUME~1\a1027277\MYDOCU~1\temp
If that succeeds you should then be able to run that Inline script.
If the 'cd' call fails then obviously I failed to provide the correct
alternative name.
Following script should work:
use Inline C => Config =>
'LIBS' => '-L/path/to/lib -lname_of_lib',
'BUILD_NOISY => 1; # display compiler warnings
use Inline C => <<'EOC';
#include "/full_path/to/external/header.h"
int wrap_card_check() {
return Card_Check();
}
int wrap_card_open(int num) {
return Card_Open(num);
}
EOC
# Add the perl bit.
See also 'perldoc Inline::C-Cookbook' for examples on using external
libs with Inline.
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Help for debugging Win32::API DLL interface
Well, I'm back. Continuing to have problems using Win32::API so abandoning it in favor of Inline.
However, having spaces in pathnames is causing problems. Any suggestions?
use Inline C => <<'END_C';
void greet() {
printf("Hello, world\n");
}
END_C
greet;
>> dir
Directory of C:\Documents and Settings\a1027277\My Documents\temp
02/07/2005 02:13p 178 greet.pl
>> perl greet.pl
Can't open C:\Documents\config for output.
No such file or directory
at -e line 0
BEGIN failed--compilation aborted.
Failed to autogenerate C:\Documents and Settings\a1027277\My Documents\temp\_Inl
ine\config.
at greet.pl line 5
BEGIN failed--compilation aborted at greet.pl line 10.
Lloyd Sartor
02/07/2005 08:54 AM
To: Sisyphus <[EMAIL PROTECTED]>
cc: perl-win32-users@listserv.ActiveState.com
Subject: Re: Help for debugging Win32::API DLL interfaceLink
Yes, there are missing underscores - a typo when I converted the lengthy vendor procedure names into shorter generic names. The leading underscore, of course, is added by the C compiler.
> $CardCheck = new Win32::API($XXX_DLL,'_Card_Check',[],'L','_cdecl');
> die "**ERROR** unable to create Win32::API object" if !$CardCheck;
> $CardOpen = new Win32::API($xxx_DLL,'_Card_Open','L','L','_cdecl');
I'm aware that XS may be a better long-term solution (from the Win32::API doc), but I've never used it and need an immediate solution. I am also not familiar with Inline C - I will have to investigate. The compiler is no problem. The vendor provides a .lib and .dll (no source) and include files.
You have provided other avenues to explore. Thanks for the feedback.
Lloyd
Sisyphus <[EMAIL PROTECTED]>
02/05/2005 03:32 AM
To: Lloyd Sartor <[EMAIL PROTECTED]>
cc: perl-win32-users@listserv.ActiveState.com
Subject: Re: Help for debugging Win32::API DLL interface
Lloyd Sartor wrote:
> I have had success with Willem's modified Win32::API, but with an anomoly.
> (FYI, I had to download msvcr71.dll to get it to work.)
>
> The following is from the vendor-provided C include file:
>
> #define IMPORT extern "C" __declspec(dllimport)
>
> IMPORT DWORD Card_Check(void);
> IMPORT DWORD Card_Open(DWORD CardNum);
>
> When I created the API objects specifying 'cdecl' as the calling
> convention:
>
> $CardCheck = new Win32::API($XXX_DLL,'_CardCheck',[],'L','_cdecl');
> die "**ERROR** unable to create Win32::API object" if !$CardCheck;
> $CardOpen = new Win32::API($xxx_DLL,'_CardOpen','L','L','_cdecl');
>
If the functions are named 'Card_Check' and 'Card_Open' then why are
they named '_CardCheck' and '_CardOpen' in the perl script ?
I assume there's a typo or two there somewhere ... but presumably not in
the actual code you're running ?
If you have a compiler, then those 2 functions would be dead easy to
wrap in an Inline C script (assuming the vendor has provided all of the
files that are required for linking purposes). You could even write a
little XS module to do it - Inline can help with that, too. This would
be a far better solution than screwing around with Win32::API but
only if you have a compiler - and only if the vendor has supplied
everything that's needed :-)
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Help for debugging Win32::API DLL interface
Yes, there are missing underscores - a typo when I converted the lengthy vendor procedure names into shorter generic names. The leading underscore, of course, is added by the C compiler. > $CardCheck = new Win32::API($XXX_DLL,'_Card_Check',[],'L','_cdecl'); > die "**ERROR** unable to create Win32::API object" if !$CardCheck; > $CardOpen = new Win32::API($xxx_DLL,'_Card_Open','L','L','_cdecl'); I'm aware that XS may be a better long-term solution (from the Win32::API doc), but I've never used it and need an immediate solution. I am also not familiar with Inline C - I will have to investigate. The compiler is no problem. The vendor provides a .lib and .dll (no source) and include files. You have provided other avenues to explore. Thanks for the feedback. Lloyd Sisyphus <[EMAIL PROTECTED]> 02/05/2005 03:32 AM To: Lloyd Sartor <[EMAIL PROTECTED]> cc: perl-win32-users@listserv.ActiveState.com Subject: Re: Help for debugging Win32::API DLL interface Lloyd Sartor wrote: > I have had success with Willem's modified Win32::API, but with an anomoly. > (FYI, I had to download msvcr71.dll to get it to work.) > > The following is from the vendor-provided C include file: > > #define IMPORT extern "C" __declspec(dllimport) > > IMPORT DWORD Card_Check(void); > IMPORT DWORD Card_Open(DWORD CardNum); > > When I created the API objects specifying 'cdecl' as the calling > convention: > > $CardCheck = new Win32::API($XXX_DLL,'_CardCheck',[],'L','_cdecl'); > die "**ERROR** unable to create Win32::API object" if !$CardCheck; > $CardOpen = new Win32::API($xxx_DLL,'_CardOpen','L','L','_cdecl'); > If the functions are named 'Card_Check' and 'Card_Open' then why are they named '_CardCheck' and '_CardOpen' in the perl script ? I assume there's a typo or two there somewhere ... but presumably not in the actual code you're running ? If you have a compiler, then those 2 functions would be dead easy to wrap in an Inline C script (assuming the vendor has provided all of the files that are required for linking purposes). You could even write a little XS module to do it - Inline can help with that, too. This would be a far better solution than screwing around with Win32::API but only if you have a compiler - and only if the vendor has supplied everything that's needed :-) Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Help for debugging Win32::API DLL interface
I have had success with Willem's modified Win32::API, but with an anomoly. (FYI, I had to download msvcr71.dll to get it to work.) The following is from the vendor-provided C include file: #define IMPORT extern "C" __declspec(dllimport) IMPORT DWORD Card_Check(void); IMPORT DWORD Card_Open(DWORD CardNum); When I created the API objects specifying 'cdecl' as the calling convention: $CardCheck = new Win32::API($XXX_DLL,'_CardCheck',[],'L','_cdecl'); die "**ERROR** unable to create Win32::API object" if !$CardCheck; $CardOpen = new Win32::API($xxx_DLL,'_CardOpen','L','L','_cdecl'); then the process died on the call to $CardCheck. When I created $CardCheck without specifying '_cdecl', then both $CardCheck and $CardOpen succeeded. I'm sure both DLL procedures use the same calling convention. My guess is $CardCheck behaves differently because it has zero input arguments. It may be nice if Win32::API defaulted to the cdecl convention if the procedure name begins with an underscore. (DIY project?) Thank you for help, Lloyd willem <[EMAIL PROTECTED]> 02/04/2005 01:21 PM To: Lloyd Sartor <[EMAIL PROTECTED]> cc: perl-win32-users@listserv.ActiveState.com Subject: Re: Help for debugging Win32::API DLL interface the standard version of Win32::API does not support api's declared with 'cdecl'. maybe your dll has functions declared that way? If this is the case, see a patch I made to Win32::API, to support cdecl type functions too: see http://www.xs4all.nl/~itsme/projects/perl/ willem Lloyd Sartor wrote: > > I am trying to use a third-party DLL to control their PCI board. The > first call to the DLL works, but the second causes the entire Perl > process to die with the following error in a dialog box: > > The instruction at "0x280414c5" referenced memory at "0x0004". The > memory could not be "written". > > My first suspicion is the stack is being corrupted because of mismatched > parameter types. But to test this theory, I repeatedly called the > working function with no problems. The DLL procedure objects appear to > be created correctly - the lower word of the address matches the DLL > offset for the procedures. Here is a code snippet. (I have changed the > function names to protect the privacy of our vendor.) > > $Card_Check = new Win32::API($XXX_DLL,'_CheckCards',[],'L'); > die "**ERROR** unable to create Win32::API object" if !$CheckCard; > $Card_Open = new Win32::API($XXX_DLL,'_CardOpen','L','L'); > > $CardPresent = $Card_Check->Call(); > die "**ERROR** installation error\n\n" if $CardPresent != 1; > > $CardStatus = $Card_Open->Call(1); > die "**ERROR** Card_Open error\n\n" if $CardStatus != 0; > > I have set env var PERL_DL_DEBUG = 9, hoping to get useful output, but > nothing that helped. > > My understanding is that parameter type 'L' (or 'N') on Win32 is 32-bits. > > Any help on how can I find the error source? ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Help for debugging Win32::API DLL interface
I am trying to use a third-party DLL to control their PCI board. The first call to the DLL works, but the second causes the entire Perl process to die with the following error in a dialog box: The instruction at "0x280414c5" referenced memory at "0x0004". The memory could not be "written". My first suspicion is the stack is being corrupted because of mismatched parameter types. But to test this theory, I repeatedly called the working function with no problems. The DLL procedure objects appear to be created correctly - the lower word of the address matches the DLL offset for the procedures. Here is a code snippet. (I have changed the function names to protect the privacy of our vendor.) $Card_Check = new Win32::API($XXX_DLL,'_CheckCards',[],'L'); die "**ERROR** unable to create Win32::API object" if !$CheckCard; $Card_Open = new Win32::API($XXX_DLL,'_CardOpen','L','L'); $CardPresent = $Card_Check->Call(); die "**ERROR** installation error\n\n" if $CardPresent != 1; $CardStatus = $Card_Open->Call(1); die "**ERROR** Card_Open error\n\n" if $CardStatus != 0; I have set env var PERL_DL_DEBUG = 9, hoping to get useful output, but nothing that helped. My understanding is that parameter type 'L' (or 'N') on Win32 is 32-bits. Any help on how can I find the error source? Thanks, Lloyd ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Regex Help
The reason that "200412" matches in your first regex is that the first four characters match the pattern (as expected) but there is nothing in the regex that causes the additional characters "12" to result in a mismatch; the regex engine simply ignores them. Adding "$" to the regex (as Mike has done) will disallow any additional characters in the string, and should work as you expected.
Furthermore, using * instead of {0,2} will match strings such as 2004-12-01-02-03.
<[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
01/27/2005 11:06 AM
To: <[EMAIL PROTECTED]>,
cc:
Subject: RE: Regex Help
Dirk,
I'm not a regex pro, but this worked for me: /^\d{4}(-\d{2}){0,2}$/
I tested it with this:
@test = qw( 2004 200412 20041201 2004-12 2004-12-01 );
foreach $test (@test) {
print "$test : " . ($test =~ /^\d{4}(-\d{2}){0,2}$/ ? "TRUE" : "FALSE") . "\n";
}
Regards,
Mike
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Dirk Bremer
Sent: Thursday, January 27, 2005 10:43 AM
To: perl-win32-users
Subject: Regex Help
I need to test for the following date-type strings:
2004
2004-12
2004-12-01
All of the above would be legal, any other combination would be illegal.
I have been using the following data to test the regex:
'' Should produce a false result.
'2004' Should produce a true result.
'200412' Should produce a false result.
'20041201' Should produce a false result.
'2004-12' Should produce a true result.
'2004-12-01' Should produce a true result.
My first attempt at a regex is /\d{4}(-\d{2})*/. This produces the
following result:
is false
2004 is true
200412 is true
20041201 is true
2004-12 is true
2004-12-01 is true
I would prefer that '200412' and '20041201' would fail, i.e. be reported
as false. I'm not sure what's going on with this regex as I would expect
the following:
match the first four numeric characters, then match zero or more
occurrences of a dash character followed by two numeric characters
The next regex /\d{4}(-\d{2})+/ produces the following results:
is false
2004 is false
200412 is false
20041201 is false
2004-12 is true
2004-12-01 is true
This is closer, but I also want '2004' to be true.
The next regex /\d{4}(?=-\d{2})/ produces the same results as the
previous regex:
is false
2004 is false
200412 is false
20041201 is false
2004-12 is true
2004-12-01 is true
I've done quite a few regexes in the past but have never used the
positive lookahead assertion before because I have never really
understood it.
Out of the three regexes, I would have expected the first to fulfill my
requirements. I do not understand why it is not, although I suspect it
has something to do with the dash character.
What am I doing wrong here? I should be able to accomplish this test
using a single regex, right?
Dirk Bremer - Systems Programmer II - ESS/AMS - NISC St. Peters
USA Central Time Zone
636-922-9158 ext. 8652 fax 636-447-4471
[EMAIL PROTECTED]
www.nisc.cc
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
**
The information contained in this message, including attachments, may contain
privileged or confidential information that is intended to be delivered only to the
person identified above. If you are not the intended recipient, or the person
responsible for delivering this message to the intended recipient, ALLTEL requests
that you immediately notify the sender and asks that you do not read the message or its
attachments, and that you delete them without copying or sending them to anyone else.
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
