Skip Menu |

This queue is for tickets about the Win32-API CPAN distribution.

Report information
The Basics
Id: 90597
Status: resolved
Priority: 0/
Queue: Win32-API

People
Owner: Nobody in particular
Requestors: eduard1963 [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 0.76_05



Subject: module Win::API (0.75) installation failed
Date: Thu, 21 Nov 2013 20:07:30 +0200
To: bug-Win32-API [...] rt.cpan.org
From: Eduard <eduard1963 [...] gmail.com>

Message body is not shown because it is too large.

Message body is not shown because it is too large.

can you run t/02_Callback.t and t/03_Jim_Shaw.t manually please so I can see at which test it crashed, and also provide a perl -V?
Subject: Re: [rt.cpan.org #90597] module Win::API (0.75) installation failed
Date: Sun, 24 Nov 2013 11:28:34 +0200
To: bug-Win32-API [...] rt.cpan.org
From: Eduard <eduard1963 [...] gmail.com>
perl -V Summary of my perl5 (revision 5 version 14 subversion 4) configuration: Platform: osname=cygwin, osvers=1.7.18(0.26353), archname=cygwin-thread-multi uname='cygwin_nt-6.1 yaakov04 1.7.18(0.26353) 2013-03-07 19:25 x86_64 cygwin ' config_args='-d -e -Dprefix=/usr -Dmksymlinks -Dusethreads -Darchname=x86_64-cygwin-threads -Dlibperl=cygperl5_14.dll -Dcc=gcc -Dld=g++' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -fno-strict-aliasing -pipe -fstack-protector', optimize='-O3', cppflags='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -fno-strict-aliasing -pipe -fstack-protector' ccversion='', gccversion='4.8.0 20130307 (experimental)', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='g++', ldflags =' -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--enable-auto-image-base -fstack-protector' libpth=/usr/lib /lib libs=-lgdbm -ldb -ldl -lcrypt -lgdbm_compat perllibs=-ldl -lcrypt libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=cygperl5_14.dll gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags=' --shared -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--enable-auto-image-base -fstack-protector' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_PRESERVE_IVUV PERL_USE_SAFE_PUTENV USE_64_BIT_ALL USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_PERL_ATOF USE_REENTRANT_API Locally applied patches: Bug#55162 File::Spec::case_tolerant performance CYG07 $vendorarch/auto/.rebase CYG15 static Win32CORE CYG17 cyg-1.7 paths-utf8 0c612ce82 Fix building static extensions on cygwin, -UUSEIMPORTLIB 1bac5ecc1 Fix 64-bit threading sv.c: S_anonymise_cv_maybe Cygwin::sync_winenv added Built under cygwin Compiled at Mar 11 2013 18:25:23 @INC: /usr/lib/perl5/site_perl/5.14/x86_64-cygwin-threads /usr/lib/perl5/site_perl/5.14 /usr/lib/perl5/vendor_perl/5.14/x86_64-cygwin-threads /usr/lib/perl5/vendor_perl/5.14 /usr/lib/perl5/5.14/x86_64-cygwin-threads /usr/lib/perl5/5.14 ./Callback/t/02_Callback.t use: Command not found. use: Command not found. use: Command not found. Badly placed ()'s. ./Callback/t/03_Jim_Shaw.t 1..6 ok 1 - use Win32::API; ok 2 - use Win32::API::Callback; ok 3 - use Win32::API::Test; ok 4 - loaded get_window_pids: Desktop hwnd: 6555 Illegal instruction (core dumped) the dump file attached On Fri, Nov 22, 2013 at 2:59 AM, Daniel Dragan via RT < bug-Win32-API@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=90597 > > > can you run t/02_Callback.t and t/03_Jim_Shaw.t manually please so I can > see at which test it crashed, and also provide a perl -V? > >
-- Best regards, Eduard
Download perl.exe.stackdump
application/octet-stream 1k

Message body not shown because it is not plain text.

Since you are not a native english speaker (Google говорит вы пишит на русском языке), I will use simpler language from now on. On Sun Nov 24 04:29:07 2013, eduard1963@gmail.com wrote: Show quoted text
> perl -V > Summary of my perl5 (revision 5 version 14 subversion 4) configuration: > > Platform: > osname=cygwin, osvers=1.7.18(0.26353), archname=cygwin-thread-multi > uname='cygwin_nt-6.1 yaakov04 1.7.18(0.26353) 2013-03-07 19:25 x86_64 > cygwin ' > config_args='-d -e -Dprefix=/usr -Dmksymlinks -Dusethreads > -Darchname=x86_64-cygwin-threads -Dlibperl=cygperl5_14.dll -Dcc=gcc > -Dld=g++' > hint=recommended, useposix=true, d_sigaction=define > useithreads=define, usemultiplicity=define > useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef > use64bitint=define, use64bitall=define, uselongdouble=undef > usemymalloc=n, bincompat5005=undef > Compiler: > cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ > -fno-strict-aliasing -pipe -fstack-protector', > optimize='-O3', > cppflags='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -fno-strict-aliasing > -pipe -fstack-protector' > ccversion='', gccversion='4.8.0 20130307 (experimental)', > gccosandvers='' > intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 > d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 > ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', > lseeksize=8 > alignbytes=8, prototype=define > Linker and Libraries: > ld='g++', ldflags =' -Wl,--enable-auto-import -Wl,--export-all-symbols > -Wl,--enable-auto-image-base -fstack-protector' > libpth=/usr/lib /lib > libs=-lgdbm -ldb -ldl -lcrypt -lgdbm_compat > perllibs=-ldl -lcrypt > libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=cygperl5_14.dll > gnulibc_version='' > Dynamic Linking: > dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' > cccdlflags=' ', lddlflags=' --shared -Wl,--enable-auto-import > -Wl,--export-all-symbols -Wl,--enable-auto-image-base -fstack-protector' > > > Characteristics of this binary (from libperl): > Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV > PERL_IMPLICIT_CONTEXT PERL_PRESERVE_IVUV > PERL_USE_SAFE_PUTENV USE_64_BIT_ALL USE_64_BIT_INT > USE_ITHREADS USE_LARGE_FILES USE_PERLIO > USE_PERL_ATOF > USE_REENTRANT_API > Locally applied patches: > Bug#55162 File::Spec::case_tolerant performance > CYG07 $vendorarch/auto/.rebase > CYG15 static Win32CORE > CYG17 cyg-1.7 paths-utf8 > 0c612ce82 Fix building static extensions on cygwin, -UUSEIMPORTLIB > 1bac5ecc1 Fix 64-bit threading sv.c: S_anonymise_cv_maybe > Cygwin::sync_winenv added > Built under cygwin > Compiled at Mar 11 2013 18:25:23 > @INC: > /usr/lib/perl5/site_perl/5.14/x86_64-cygwin-threads > /usr/lib/perl5/site_perl/5.14 > /usr/lib/perl5/vendor_perl/5.14/x86_64-cygwin-threads > /usr/lib/perl5/vendor_perl/5.14 > /usr/lib/perl5/5.14/x86_64-cygwin-threads > /usr/lib/perl5/5.14 > > ./Callback/t/02_Callback.t > use: Command not found. > use: Command not found. > use: Command not found. > Badly placed ()'s.
I did not see the above "use: Command not found" myself. Show quoted text
> > ./Callback/t/03_Jim_Shaw.t > 1..6 > ok 1 - use Win32::API; > ok 2 - use Win32::API::Callback; > ok 3 - use Win32::API::Test; > ok 4 - loaded > get_window_pids: Desktop hwnd: 6555 > Illegal instruction (core dumped) > > the dump file attached >
The dump file is useless. It does not include a C callstack. I see you are using 64 bit Cygwin. This is a new product I have never used before, and Win32::API has never been tested on before. To go back and forth with you to solve all crashes will take a dozen or more posts and very many days. Instead I downloaded Cygwin 64 bit. I found and fixed many small problems in WIn32::API to make Cygwin 64 bit work, (see https://github.com/bulk88/perl5-win32-api/commit/57a4457011b915c8581bb84e47664eb3ec4c0183 ). Win32::API::Callback first failed because 32 or 64 bit detection code was less than perfect. This caused Win32::API::Callback to create 32 bit machine code at runtime instead of 64 bit machine code. Callback's return value (42 vs 0 test fail) problem was new -fstack-protector option, which corrupted RAX register in function Stage2CallbackX64. Another problem was native Win32 Perl, with Visual C or Mingw, when compiling 64 bit, Perl's authors define "WIN64" macro. WIN64 is not a Microsoft macro. Cygwin Perl does not define WIN64, only Microsoft's _WIN64 macro. This caused junk parameters to be passed to Call_asm function, which causes SEGV in all Win32::API (note, not Win32::API::Callback) calls to C functions. I made new release of Win32::API with Cygwin 64 fixes, version 0.76_05, it on CPAN at http://search.cpan.org/~bulkdd/Win32-API/ . Please try it and report if it passes tests without failure.
Subject: Re: [rt.cpan.org #90597] module Win::API (0.75) installation failed
Date: Mon, 25 Nov 2013 11:29:08 +0200
To: bug-Win32-API [...] rt.cpan.org
From: Eduard <eduard1963 [...] gmail.com>
Hi, You are right, my native language is Russian:) And second is Hebrew :) From some historical reasons we're using the Cygwin environment. Till now it was 32-bit version, now I try to I tried to productize the new 64-bit version, but met with some problems with perl modules ;( I downloaded the updated version of the the Win32::Api module. All tests are passed. But I faced other problem. This fragment of the perl code does not work now: *$jtagConnect = new Win32::API('jtagvsdll', 'jtagConnect','I', 'I', '_cdecl');* *$jtagDisConnect = new Win32::API('jtagvsdll', 'jtagDisConnect','', 'V');#, '_cdecl'* *$JtagReadMem = new Win32::API('jtagvsdll', 'JtagReadMem','NNP','I', '_cdecl');* *$JtagWriteMem = new Win32::API('jtagvsdll', 'JtagWriteMem','NNP','I', '_cdecl');* *$JtagWriteReg = new Win32::API('jtagvsdll', 'JtagWriteReg','NN','I', '_cdecl' );* *$JtagReadReg = new Win32::API('jtagvsdll', 'JtagReadReg','N','N', '_cdecl' );* *$JtagRun = new Win32::API('jtagvsdll', 'JtagRun', '', '', '_cdecl' );* *$JtagStep = new Win32::API('jtagvsdll', 'JtagStep', '', '', '_cdecl' );* But it works perfect in the Cygwin 32-bit environment , with your module (releases 72,73,74,75). Regards, Eduard On Mon, Nov 25, 2013 at 6:10 AM, Daniel Dragan via RT < bug-Win32-API@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=90597 > > > Since you are not a native english speaker (Google говорит вы пишит на > русском языке), I will use simpler language from now on. > > On Sun Nov 24 04:29:07 2013, eduard1963@gmail.com wrote:
> > perl -V > > Summary of my perl5 (revision 5 version 14 subversion 4) configuration: > > > > Platform: > > osname=cygwin, osvers=1.7.18(0.26353), archname=cygwin-thread-multi > > uname='cygwin_nt-6.1 yaakov04 1.7.18(0.26353) 2013-03-07 19:25 x86_64 > > cygwin ' > > config_args='-d -e -Dprefix=/usr -Dmksymlinks -Dusethreads > > -Darchname=x86_64-cygwin-threads -Dlibperl=cygperl5_14.dll -Dcc=gcc > > -Dld=g++' > > hint=recommended, useposix=true, d_sigaction=define > > useithreads=define, usemultiplicity=define > > useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef > > use64bitint=define, use64bitall=define, uselongdouble=undef > > usemymalloc=n, bincompat5005=undef > > Compiler: > > cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ > > -fno-strict-aliasing -pipe -fstack-protector', > > optimize='-O3', > > cppflags='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__
> -fno-strict-aliasing
> > -pipe -fstack-protector' > > ccversion='', gccversion='4.8.0 20130307 (experimental)', > > gccosandvers='' > > intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 > > d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 > > ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', > > lseeksize=8 > > alignbytes=8, prototype=define > > Linker and Libraries: > > ld='g++', ldflags =' -Wl,--enable-auto-import
> -Wl,--export-all-symbols
> > -Wl,--enable-auto-image-base -fstack-protector' > > libpth=/usr/lib /lib > > libs=-lgdbm -ldb -ldl -lcrypt -lgdbm_compat > > perllibs=-ldl -lcrypt > > libc=/usr/lib/libc.a, so=dll, useshrplib=true,
> libperl=cygperl5_14.dll
> > gnulibc_version='' > > Dynamic Linking: > > dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' > > cccdlflags=' ', lddlflags=' --shared -Wl,--enable-auto-import > > -Wl,--export-all-symbols -Wl,--enable-auto-image-base -fstack-protector' > > > > > > Characteristics of this binary (from libperl): > > Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV > > PERL_IMPLICIT_CONTEXT PERL_PRESERVE_IVUV > > PERL_USE_SAFE_PUTENV USE_64_BIT_ALL
> USE_64_BIT_INT
> > USE_ITHREADS USE_LARGE_FILES USE_PERLIO > > USE_PERL_ATOF > > USE_REENTRANT_API > > Locally applied patches: > > Bug#55162 File::Spec::case_tolerant performance > > CYG07 $vendorarch/auto/.rebase > > CYG15 static Win32CORE > > CYG17 cyg-1.7 paths-utf8 > > 0c612ce82 Fix building static extensions on cygwin,
> -UUSEIMPORTLIB
> > 1bac5ecc1 Fix 64-bit threading sv.c: S_anonymise_cv_maybe > > Cygwin::sync_winenv added > > Built under cygwin > > Compiled at Mar 11 2013 18:25:23 > > @INC: > > /usr/lib/perl5/site_perl/5.14/x86_64-cygwin-threads > > /usr/lib/perl5/site_perl/5.14 > > /usr/lib/perl5/vendor_perl/5.14/x86_64-cygwin-threads > > /usr/lib/perl5/vendor_perl/5.14 > > /usr/lib/perl5/5.14/x86_64-cygwin-threads > > /usr/lib/perl5/5.14 > > > > ./Callback/t/02_Callback.t > > use: Command not found. > > use: Command not found. > > use: Command not found. > > Badly placed ()'s.
> > I did not see the above "use: Command not found" myself. >
> > > > ./Callback/t/03_Jim_Shaw.t > > 1..6 > > ok 1 - use Win32::API; > > ok 2 - use Win32::API::Callback; > > ok 3 - use Win32::API::Test; > > ok 4 - loaded > > get_window_pids: Desktop hwnd: 6555 > > Illegal instruction (core dumped) > > > > the dump file attached > >
> > The dump file is useless. It does not include a C callstack. > > I see you are using 64 bit Cygwin. This is a new product I have never used > before, and Win32::API has never been tested on before. To go back and > forth with you to solve all crashes will take a dozen or more posts and > very many days. Instead I downloaded Cygwin 64 bit. I found and fixed many > small problems in WIn32::API to make Cygwin 64 bit work, (see > https://github.com/bulk88/perl5-win32-api/commit/57a4457011b915c8581bb84e47664eb3ec4c0183). Win32::API::Callback first failed because 32 or 64 bit detection code > was less than perfect. This caused Win32::API::Callback to create 32 bit > machine code at runtime instead of 64 bit machine code. Callback's return > value (42 vs 0 test fail) problem was new -fstack-protector option, which > corrupted RAX register in function Stage2CallbackX64. > > Another problem was native Win32 Perl, with Visual C or Mingw, when > compiling 64 bit, Perl's authors define "WIN64" macro. WIN64 is not a > Microsoft macro. Cygwin Perl does not define WIN64, only Microsoft's > _WIN64 macro. This caused junk parameters to be passed to Call_asm > function, which causes SEGV in all Win32::API (note, not > Win32::API::Callback) calls to C functions. > > I made new release of Win32::API with Cygwin 64 fixes, version 0.76_05, it > on CPAN at http://search.cpan.org/~bulkdd/Win32-API/ . Please try it and > report if it passes tests without failure. >
-- Best regards, Eduard
On Mon Nov 25 04:29:47 2013, eduard1963@gmail.com wrote: Show quoted text
> I downloaded the updated version of the the Win32::Api module. All > tests > are passed. But I faced other problem. This fragment of the perl code > does > not work now: > > *$jtagConnect = new Win32::API('jtagvsdll', 'jtagConnect','I', 'I', > '_cdecl');* > *$jtagDisConnect = new Win32::API('jtagvsdll', 'jtagDisConnect','', > 'V');#, > '_cdecl'* > *$JtagReadMem = new Win32::API('jtagvsdll', 'JtagReadMem','NNP','I', > '_cdecl');* > *$JtagWriteMem = new Win32::API('jtagvsdll', 'JtagWriteMem','NNP','I', > '_cdecl');* > *$JtagWriteReg = new Win32::API('jtagvsdll', 'JtagWriteReg','NN','I', > '_cdecl' );* > *$JtagReadReg = new Win32::API('jtagvsdll', 'JtagReadReg','N','N', > '_cdecl' > );* > *$JtagRun = new Win32::API('jtagvsdll', 'JtagRun', '', '', '_cdecl' > );* > *$JtagStep = new Win32::API('jtagvsdll', 'JtagStep', '', '', '_cdecl' > );* > > But it works perfect in the Cygwin 32-bit environment , with your > module > (releases 72,73,74,75).
What are the C prototypes from headers of those functions? What are precise symptoms of "does not work"? new() returns undef? Crash? C function returns failure value (false or non-zero error code)? Common mistakes are, loading 32 bit DLL into 64 bit process (forbidden by windows), improper pack()ing of structs or machine values for 'P' letter, 'I' (32 bit always) instead of 'N' (32 or 64 bit, AKA pointer size), 'N' instead of 'I' (high 32 bits are not zero). _cdecl has no effect on 64 bit os, because 64 bit Windows has 1 calling convention. Visual C treats all the different 32 bit calling convention as the 1 and only 64 bit calling convention.
Subject: Re: [rt.cpan.org #90597] module Win::API (0.75) installation failed
Date: Mon, 25 Nov 2013 18:30:54 +0200
To: bug-Win32-API [...] rt.cpan.org
From: Eduard <eduard1963 [...] gmail.com>
Hi, new() returns undef example of the C prototype: *int JtagWriteReg(unsigned long uiRegister, unsigned long ulValue ) * We're using the module Win32::API with 64-bit windows, but with 32-bit Cygwin. It works perfect On Mon, Nov 25, 2013 at 6:09 PM, Daniel Dragan via RT < bug-Win32-API@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=90597 > > > On Mon Nov 25 04:29:47 2013, eduard1963@gmail.com wrote:
> > I downloaded the updated version of the the Win32::Api module. All > > tests > > are passed. But I faced other problem. This fragment of the perl code > > does > > not work now: > > > > *$jtagConnect = new Win32::API('jtagvsdll', 'jtagConnect','I', 'I', > > '_cdecl');* > > *$jtagDisConnect = new Win32::API('jtagvsdll', 'jtagDisConnect','', > > 'V');#, > > '_cdecl'* > > *$JtagReadMem = new Win32::API('jtagvsdll', 'JtagReadMem','NNP','I', > > '_cdecl');* > > *$JtagWriteMem = new Win32::API('jtagvsdll', 'JtagWriteMem','NNP','I', > > '_cdecl');* > > *$JtagWriteReg = new Win32::API('jtagvsdll', 'JtagWriteReg','NN','I', > > '_cdecl' );* > > *$JtagReadReg = new Win32::API('jtagvsdll', 'JtagReadReg','N','N', > > '_cdecl' > > );* > > *$JtagRun = new Win32::API('jtagvsdll', 'JtagRun', '', '', '_cdecl' > > );* > > *$JtagStep = new Win32::API('jtagvsdll', 'JtagStep', '', '', '_cdecl' > > );* > > > > But it works perfect in the Cygwin 32-bit environment , with your > > module > > (releases 72,73,74,75).
> > What are the C prototypes from headers of those functions? What are > precise symptoms of "does not work"? new() returns undef? Crash? C function > returns failure value (false or non-zero error code)? > > Common mistakes are, loading 32 bit DLL into 64 bit process (forbidden by > windows), improper pack()ing of structs or machine values for 'P' letter, > 'I' (32 bit always) instead of 'N' (32 or 64 bit, AKA pointer size), 'N' > instead of 'I' (high 32 bits are not zero). _cdecl has no effect on 64 bit > os, because 64 bit Windows has 1 calling convention. Visual C treats all > the different 32 bit calling convention as the 1 and only 64 bit calling > convention. >
-- Best regards, Eduard
On Mon Nov 25 11:31:32 2013, eduard1963@gmail.com wrote: Show quoted text
> Hi, > new() returns undef > example of the C prototype: > *int JtagWriteReg(unsigned long uiRegister, unsigned long ulValue ) * > > We're using the module Win32::API with 64-bit windows, but with 32-bit > Cygwin. It works perfect
................ Show quoted text
> > > *$JtagWriteReg = new Win32::API('jtagvsdll', > > > 'JtagWriteReg','NN','I', > > > '_cdecl' );*
The 'NN' should be 'II', but that IS NOT the source of your problem. I recommend you turn on Win32::API's undocumented debug logging, before calling new(). To do this, put "$Win32::API::DEBUG = 1;" before new(). Alot of console logging will be outputted. Either 'JtagWriteReg' is not exported, or jtagvsdll is a 32 bit DLL being loaded into a 64 bit process, or jtagvsdll.dll does not exist.
Subject: Re: [rt.cpan.org #90597] module Win::API (0.75) installation failed
Date: Tue, 26 Nov 2013 10:58:48 +0200
To: bug-Win32-API [...] rt.cpan.org
From: Eduard <eduard1963 [...] gmail.com>
With debug I got the following error: *FAILED Loading library 'jtagvsdll': 193* The function JtagWriteReg exported, dll exists. As I already wrote it works perfect under old cygwin (32-bit). I run the same perl scritps from the same directories, simply launch another cygwin. We didn't face with problem to use 32-bit DLL in the 64-bit windows before On Mon, Nov 25, 2013 at 9:39 PM, Daniel Dragan via RT < bug-Win32-API@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=90597 > > > On Mon Nov 25 11:31:32 2013, eduard1963@gmail.com wrote:
> > Hi, > > new() returns undef > > example of the C prototype: > > *int JtagWriteReg(unsigned long uiRegister, unsigned long ulValue ) * > > > > We're using the module Win32::API with 64-bit windows, but with 32-bit > > Cygwin. It works perfect
> ................
> > > > *$JtagWriteReg = new Win32::API('jtagvsdll', > > > > 'JtagWriteReg','NN','I', > > > > '_cdecl' );*
> > The 'NN' should be 'II', but that IS NOT the source of your problem. I > recommend you turn on Win32::API's undocumented debug logging, before > calling new(). To do this, put "$Win32::API::DEBUG = 1;" before new(). Alot > of console logging will be outputted. Either 'JtagWriteReg' is not > exported, or jtagvsdll is a 32 bit DLL being loaded into a 64 bit process, > or jtagvsdll.dll does not exist. >
-- Best regards, Eduard
On Tue Nov 26 03:59:20 2013, eduard1963@gmail.com wrote: Show quoted text
> With debug I got the following error: > *FAILED Loading library 'jtagvsdll': 193* > The function JtagWriteReg exported, dll exists. As I already wrote it > works > perfect under old cygwin (32-bit). I run the same perl scritps from > the > same directories, simply launch another cygwin. We didn't face with > problem > to use 32-bit DLL in the 64-bit windows before
Error 193 is ERROR_BAD_EXE_FORMAT. ERROR_BAD_EXE_FORMAT happens when you try to load a DLL with a different CPU type into a process. You have a 32 bit DLL. You are trying to use it in a 64 bit process. MS does not allow this to work. http://msdn.microsoft.com/en-us/library/windows/desktop/aa384249%28v=vs.85%29.aspx Contact whoever created that DLL (jtagvsdll) for a 64 bit version of the DLL. The other more difficult choice is RPC between a 32 bit Perl and a 64 bit Perl process.