[PATCH] IO fixes for Win32
Goplat
in win98 and will cause the CreateFile to fail, so the ParrotIO is NULL, and
subsequent PIO_read on its io PMC will return -1. When len is -1, some tests
in t/src/io.t will think it's positive since it has it as a UINTVAL (should
be an INTVAL) causing it to loop forever. Also using -1 as an index into the
buffer could overwrite that len variable, making it actually positive. And it
uses ParrotIO* where it should be using PMC* (dosen't really matter but it's
nice to use the right type of pointer). Furthermore, test 13 fails since it
expects a 60000 byte file, but actually creates one larger than that because
of \n -> \r\n translation.
__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html
Vladimir Lipsky
> flags_to_win32 sets fdwShareMode to FILE_SHARE_DELETE, which is not
supported
> in win98 and will cause the CreateFile to fail, so the ParrotIO is NULL,
and
A fix for that should be windows version specific and needs support of the
config subsystem.
The logic is as follows:
In the config subsystem ...
1) run a test which defines the os version
2) set the compiler option up
if version is windows 95
add -D_WIN32_WINDOWS=0x0400 to cflags
else if version is windows 98 then
add -D_WIN32_WINDOWS=0x0410 to cflags
else if version is windows Me then
add -D_WIN32_WINDOWS=0x0500 to cflags
else if version is winnt 4.0 then
add -D_WIN32_WINNT=0x0400 to cflags
else if version is windows 2000 then
add -D_WIN32_WINNT=0x0500 to cflags
else if version is windows XP then
add -D_WIN32_WINNT=0x0501 to cflags
else if version is windows server 2003 then
add -D_WIN32_WINNT=0x0502 to cflags
end
In io.h ...
#ifdef _WIN32
# if defined(_WIN32_WINDOWS) && (_WIN32_WINDOWS <= 0x0500)
# define PIO_WIN32_SHARE_MODE (FILE_SHARE_READ |\
# FILE_SHARE_WRITE)
# else
# define PIO_WIN32_SHARE_MODE (FILE_SHARE_READ |\
# FILE_SHARE_WRITE |\
# FILE_SHARE_DELETE)
#endif
0x4C56
Vladimir Lipsky
> A fix for that should be windows version specific and needs support of the
> config subsystem.
And 0f course in io_win32.c
*fdwShareMode = PIO_WIN32_SHARE_MODE;
> 0x4C56
0x4C56
Goplat
> From: "Goplat" <mrnob...@yahoo.com>
>
> > flags_to_win32 sets fdwShareMode to FILE_SHARE_DELETE, which is not
> > supported in win98
>
> config subsystem.
If you did that, a version compiled on NT wouldn't work on 9x. I'd say most
9x users don't compile perl themself, they just download a binary from
ActiveState (who use NT)...
If you really need FILE_SHARE_DELETE that badly, the check would have to be
done at runtime. I don't think it's all that necessary though... in fact perl
5 only uses FILE_SHARE_READ, and that only if the file's not opened for write/append.
Vladimir Lipsky
> --- Vladimir Lipsky <lip...@kaluga.ru> wrote:
> > From: "Goplat" <mrnob...@yahoo.com>
> >
> > > flags_to_win32 sets fdwShareMode to FILE_SHARE_DELETE, which is not
> > > supported in win98
> >
> > A fix for that should be windows version specific and needs support of
the
> > config subsystem.
>
> If you did that, a version compiled on NT wouldn't work on 9x. I'd say
most
> 9x users don't compile perl themself, they just download a binary from
> ActiveState (who use NT)...
Then there should be different binaries for different versions
> If you really need FILE_SHARE_DELETE that badly, the check would have to
be
Yeah and async I/O, and other stuff that aren't avaible in perl5 and windows
95/98/Me/CE. If we didn't yet distinguish windows versions, it's the time to
do so.
> done at runtime. I don't think it's all that necessary though... in fact
perl
> 5 only uses FILE_SHARE_READ, and that only if the file's not opened for
write/append.
Does perl5 use FILE_SHARE_READ when >+ and <+ modes are specified? In any
case what you said sounds like a bug to me, since this policy restricts
other threads(even threads of the same process) to access the file in the
indentical mode.
Dan Sugalski
>From: "Goplat" <mrnob...@yahoo.com>
>
>> --- Vladimir Lipsky <lip...@kaluga.ru> wrote:
>> > From: "Goplat" <mrnob...@yahoo.com>
>> >
>> > > flags_to_win32 sets fdwShareMode to FILE_SHARE_DELETE, which is not
>> > > supported in win98
>> >
>> > A fix for that should be windows version specific and needs support of
>the
>> > config subsystem.
>>
>> If you did that, a version compiled on NT wouldn't work on 9x. I'd say
>most
>> 9x users don't compile perl themself, they just download a binary from
>> ActiveState (who use NT)...
>
>Then there should be different binaries for different versions
Yeah, I'm actually coming to that conclusion. Yes, it's sort of
easier to keep a single binary around from a packaging standpoint,
it's a hassle for everyone else because of it.
We talked ages ago about having the system identification ops let you
know the sub-version of whichever OS you were on, and I think it's
time to get that dusted off. That'll help with this a bit.
The one downside is the whole "minimum capability" issue. A Win9x
binary, if built for Win9x, will run on WinXP yet lack all the
crunchy WinXP features. Not that this is exclusive to windows as it's
a problem on any system with any amount of backwards compatibility
(or in some cases if we restrict operations with privs), so I'm OK
with making it a non-issue here. We just need to think about ways to
present interpreter capabilities so programs can query them if they
need to.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Vladimir Lipsky
> If you really need FILE_SHARE_DELETE that badly, the check would have to
be
> done at runtime. I don't think it's all that necessary though... in fact
perl
> 5 only uses FILE_SHARE_READ, and that only if the file's not opened for
write/append.
What's more, a value of the parameter C<dwDesiredAccess> doesn't depend on a
value the parameter C<dwShareMode> and shouldn't do.
0x4C56
Goplat
> At 12:40 AM +0300 2/18/04, Vladimir Lipsky wrote:
> >From: "Goplat" <mrnob...@yahoo.com>
> >
> >> --- Vladimir Lipsky <lip...@kaluga.ru> wrote:
> >> > From: "Goplat" <mrnob...@yahoo.com>
> >> >
> >> > > flags_to_win32 sets fdwShareMode to FILE_SHARE_DELETE, which is not
> >> > > supported in win98
> >> >
> >> > A fix for that should be windows version specific and needs support
> >> > of the config subsystem.
> >>
> >> If you did that, a version compiled on NT wouldn't work on 9x. I'd say
> >> most 9x users don't compile perl themself, they just download a binary
> >> from ActiveState (who use NT)...
> >
> >Then there should be different binaries for different versions
>
> Yeah, I'm actually coming to that conclusion. Yes, it's sort of
> easier to keep a single binary around from a packaging standpoint,
> it's a hassle for everyone else because of it.
Where is the hassle? It's just a few lines of code to check windows version.
It's easier to code that than to make another configure option.
__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools
Melvin Smith
>--- Dan Sugalski <d...@sidhe.org> wrote:
> > At 12:40 AM +0300 2/18/04, Vladimir Lipsky wrote:
> > >From: "Goplat" <mrnob...@yahoo.com>
> > >
> > >> --- Vladimir Lipsky <lip...@kaluga.ru> wrote:
> > >> > From: "Goplat" <mrnob...@yahoo.com>
> > >> >
> > >> > > flags_to_win32 sets fdwShareMode to FILE_SHARE_DELETE, which is not
> > >> > > supported in win98
> > >> >
> > >> > A fix for that should be windows version specific and needs support
> > >> > of the config subsystem.
> > >>
> > >> If you did that, a version compiled on NT wouldn't work on 9x. I'd say
> > >> most 9x users don't compile perl themself, they just download a binary
> > >> from ActiveState (who use NT)...
> > >
> > >Then there should be different binaries for different versions
> >
> > Yeah, I'm actually coming to that conclusion. Yes, it's sort of
> > easier to keep a single binary around from a packaging standpoint,
> > it's a hassle for everyone else because of it.
>
>Where is the hassle? It's just a few lines of code to check windows version.
>It's easier to code that than to make another configure option.
Then submit a patch.
I have no problem with that scenario. The code in question
is mine, but I don't have the ability to play with older versions
of Windows. I develop on XP, 2000, Linux and Solaris, and I
really don't claim to be much of a Windows programmer, outside
of Winsock.
-Melvin
Goplat
> At 09:27 AM 2/19/2004 -0800, Goplat wrote:
> >--- Dan Sugalski <d...@sidhe.org> wrote:
> > > At 12:40 AM +0300 2/18/04, Vladimir Lipsky wrote:
> > > >From: "Goplat" <mrnob...@yahoo.com>
> > > >
> > > >> --- Vladimir Lipsky <lip...@kaluga.ru> wrote:
> > > >> > From: "Goplat" <mrnob...@yahoo.com>
> > > >> >
> > > >> > > flags_to_win32 sets fdwShareMode to FILE_SHARE_DELETE, which is
> > > >> > > not supported in win98
> > > >> >
> > > >> > A fix for that should be windows version specific and needs
> > > >> > support of the config subsystem.
> > > >>
> > > >> If you did that, a version compiled on NT wouldn't work on 9x. I'd
> > > >> say most 9x users don't compile perl themself, they just download a
> > > >> binary from ActiveState (who use NT)...
> > > >
> > > >Then there should be different binaries for different versions
> > >
> > > Yeah, I'm actually coming to that conclusion. Yes, it's sort of
> > > easier to keep a single binary around from a packaging standpoint,
> > > it's a hassle for everyone else because of it.
> >
> >Where is the hassle? It's just a few lines of code to check windows
> >version. It's easier to code that than to make another configure option.
>
> Then submit a patch.
Okay. (attached)
Melvin Smith
>--- Melvin Smith <mrjol...@mindspring.com> wrote:
> > >Where is the hassle? It's just a few lines of code to check windows
> > >version. It's easier to code that than to make another configure option.
> >
> > Then submit a patch.
>
>Okay. (attached)
Very good, thank you sir. I see
you also addressed another outstanding issue with
the negative return val to read (into an unsigned).
Did you run the test suite and get successes?
If so, I will apply.
-Melvin
Goplat
> At 10:02 AM 2/19/2004 -0800, Goplat wrote:
> >--- Melvin Smith <mrjol...@mindspring.com> wrote:
> > > >Where is the hassle? It's just a few lines of code to check windows
> > > >version. It's easier to code that than to make another configure
> option.
> > >
> > > Then submit a patch.
> >
> >Okay. (attached)
>
> Very good, thank you sir. I see
> you also addressed another outstanding issue with
> the negative return val to read (into an unsigned).
>
> Did you run the test suite and get successes?
> If so, I will apply.
Failed Test Stat Wstat Total Fail Failed List of Failed
------------------------------------------------------------------------
imcc/t/syn/file.t 1 256 12 1 8.33% 11
t/pmc/env.t 3 768 6 3 50.00% 3 5-6
t/pmc/perlarray.t 1 256 26 1 3.85% 26
t/pmc/sub.t 3 768 49 3 6.12% 36-38
t/pmc/tqueue.t 2 512 5 2 40.00% 2-3
2 tests and 69 subtests skipped.
Failed 5/94 test scripts, 94.68% okay. 10/1320 subtests failed, 99.24% okay.
Not exactly success, but it's just the same failures I got before applying
it. At least the IO stuff succeeded this time (imcc/t/syn/file.t fails
because of shell issues).
Melvin Smith
>Failed Test Stat Wstat Total Fail Failed List of Failed
>------------------------------------------------------------------------
>imcc/t/syn/file.t 1 256 12 1 8.33% 11
>t/pmc/env.t 3 768 6 3 50.00% 3 5-6
>t/pmc/perlarray.t 1 256 26 1 3.85% 26
>t/pmc/sub.t 3 768 49 3 6.12% 36-38
>t/pmc/tqueue.t 2 512 5 2 40.00% 2-3
>2 tests and 69 subtests skipped.
>Failed 5/94 test scripts, 94.68% okay. 10/1320 subtests failed, 99.24% okay.
>
>Not exactly success, but it's just the same failures I got before applying
>it. At least the IO stuff succeeded this time (imcc/t/syn/file.t fails
>because of shell issues).
Works for me, applied, thanks.
-Melvin