There's plenty of places in Perl, where the built-ins were modeled to fit Unix. There's plenty of core modules designed to fit Unix. Porting of both to other operating systems often requires complicated hacks and emulations. Whenever there's something that works (a certain way) under Unix, it get's added and others have to bend over backwards to at least emulate it. When, on the other hand, there is anything other operating system specific, it has to be implemented as module with that OS in the name even if there were several "other" systems supporting that in a similar enough way.
In this particular case Windows has had UTF-16 filesystem for years, but as "On Linux, file names are zero-byte terminated binary strings, the interpretation is left to the userland. One can guess based on the locale, or just assume something globally, but neither approach is robust." nothing will ever be done with the core. It would be hard for the Unix-based ports. erm. Sorry, that's not a port, that's the base. Right?
Would it be harder, more restricted or trickier than, say, the fork emulation? I doubt it.
If it was easy under Linux, it would be done and others would find a way to emulate it, even if not 100% correctly, and the emulations would eventually improve. If it's hard under Linux, it doesn't happen.
Jenda
Enoch was right!
Enjoy the last years of Rome.
| [reply] |
On Linux/Unix systems, handling of encodings at the file system level is also broken. The only difference is that there you can work-around it.
| [reply] |
| [reply] |
