develooper Front page | perl.perl5.porters | Postings from April 2020

Re: Status of :win32 perlio layer?

Thread Previous
From:
bulk88
Date:
April 29, 2020 00:54
Subject:
Re: Status of :win32 perlio layer?
Message ID:
20200429005357.10106.qmail@lists-nntp.develooper.com
Tomasz Konojacki wrote:
> I was wondering about the status of the :win32 perlio layer. It's been
> marked as experimental for ages.
> 
> What is preventing it from becoming non-experimental? What is not
> working/missing?
> 
> (CC-ing bulk because he's the last person who worked on it)

Egh, Im not sure why its around, I would say, im not going to check P5P 
archives, a couple things :win32 COULD do but doesnt.

-supporting interruptible (Alertable Wait/signals/alarm) reads and 
writes. Async/non block opens are impossible on Win32 without threads, 
NTDLL doesn't expose async opens to user mode, rumor says you can't 
allocate a FD to file/device that doesnt exist, and without that FD, 
there is no way to pass an identifier to select/poll to find out if the 
"open event" was a success. A wonderful way to hang any Win32 app is " 
dir "\\100.64.254.254\C$" ", a 30 second blocking CreateFile() system 
call (get FD to enumerate a dir).

-unicode aware on Win32 open()

-borland supposedly had its own not-MS Win32 libc, maybe :win32 was 
supposed to fix bugs in that but instead any libc/CRT IO bugs fixed by 
Jan Dubois and Sarathy put into :unix/libc on Win32 layer. Perl used to 
have numerous bug fixes for Windows 95 mid 1990s compiled VC CRT/libc 
DLLbut they were removed with Windows 98/ME support. At certain points 
Perl barely even called the MS libc and just used libc as a FD to kernel 
handle mapping/allocator table for XS/3rd party C intraprocess 
compatibility and did all the FD->native calls itself rather than use 
libc's read()/write()/ioctl().

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About