Jonathan Stowe wrote:
>On Fri, 2005-01-14 at 11:31, Jonathan Stowe wrote:
>
>
>>On Thu, 2005-01-13 at 18:52, [EMAIL PROTECTED] wrote:
>>
>>
>
>
>
>>>GetConsoleMode failed, LastError=|6| at blib\lib/Term/ReadKey.pm line 265.
>>>END failed--call queue aborted.
>>>NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x9'
>>>Stop.
>>>
>On further examination I have distilled it down to:
>
>Test.xs:
>
> #include "EXTERN.h"
> #include "perl.h"
> #include "XSUB.h"
>
> #include "ppport.h"
> #include <io.h>
>
> MODULE = Test PACKAGE = Test
>
>
> void Test(fh)
> PerlIO *fh
> CODE:
> {
> int handle;
> HANDLE hwnd;
> handle = PerlIO_fileno(fh);
>
> if ((hwnd = (HANDLE)_get_osfhandle(handle)) == -1)
> croak("bad file handle");
> }
>
>Test.t:
>
> use Test
> use Fcntl;
>
> sysopen( IN, 'CONIN$', O_RDWR );
>
> Test::Test(IN);
>
>Which croaks with the message as above.
>
>In normal usage CONIN$ and CONOUT$ work normally ( I can read, print and
>take their fileno()).
>
>So my question is: am I looking at a bug in the MS CRT here ( I am
>testing with "Microsoft (R) 32-bit C/C++ Optimizing Compiler Version
>13.10.3077" i.e. the one that comes with Visual Studio 2003 ) and if so
>are there any workarounds, or is this something strange (bug,
>undocumented behaviour?) with PerlIO or indeed (quite likely) something
>that I have missed and/or failed to understand. It occurs to me that it
>could be something that is happening when the extension is compiled with
>a diversion version of the compiler and/or CRT from that which compiled
>the Perl but I am not in a position to test this right now.
>
>Any input welcomed, especially testing with various MS compiler and Perl
>versions.
>
I suspect that the problem is using the VC7 (aka Visual Studio 2003)
compiler with ActivePerl, which is built with VC6 (aka Visual Studio 98).
I've had error reports from the same cpan-tester in which this turned
out to be the problem, e.g. see:
http://www.mail-archive.com/[email protected]/msg157084.html
I tried your module using ActivePerl Build 810 and VC7 and got the same
error. Retrying with ActivePerl Build 810 and VC6 it works fine.
Trying again with VC7 but now using my own build of Perl also done with
VC7 it also works fine.
So it certainly looks like a CRT conflict in the ActivePerl/VC7 scenario
-- any time that you pass CRT resources between the msvc71.dll loaded by
your module's DLL and the msvcrt.dll loaded by ActivePerl's DLL you will
get problems. For example, in your XS above you open a file via
msvcrt.dll (the sysopen in Perl) and then pass the handle to msvc71.dll
(your XS code). The latter CRT doesn't think that the handle opened by
the former CRT is valid.
The only "solution" that I've come up with in cases where sharing CRT
resources in this way is unavoidable is to recommend that users use the
same compiler to build my modules as was used to build Perl. I don't
even have a good way of checking for this, so I just have a note in my
INSTALL file to this effect.
If anyone has any better solutions, I'd love to hear them!
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender
immediately. The unauthorized use, disclosure, copying or alteration of this
message is strictly forbidden. Note that any views or opinions presented in
this email are solely those of the author and do not necessarily represent
those of Radan Computational Ltd. The recipient(s) of this message should
check it and any attached files for viruses: Radan Computational will accept no
liability for any damage caused by any virus transmitted by this email.
