develooper Front page | perl.perl5.porters | Postings from June 2006

Re: OS abstraction (was Re: Its time we set the score straight on Perl 5 and Perl 6 and debunk our own self-generated FUD.)

June 25, 2006 12:00
Re: OS abstraction (was Re: Its time we set the score straight on Perl 5 and Perl 6 and debunk our own self-generated FUD.)
Message ID:
On 6/25/06, Nicholas Clark <> wrote:
> On Tue, Jun 20, 2006 at 08:32:11AM +0200, demerphq wrote:
> > Yes, core perl support for Win32 is much less than what it should be,
> > which in turn means all the linux programmers who dont have a clue
> > about how windows work[1] end up just coding as tho their code will
> > run on *nix regardless, and therefore their code doesnt work when it
> > gets run on Win32.
> Linux programmers who don't have a clue write code that doesn't even
> work on real Unix.

Heh. Ok, i dont feel so bad now. :-)

> > The solution to this problem is to improve core support for OS
> > abstraction. Something ive been advocating and sending patches in for
> No, I'm not convinced that it is. Surely down this road lies lowest common
> denominator? How does this differ from cross-platform GUI toolkits, which
> seem to generate quite a lot of comments about how they don't have the
> look-and-feel of native apps, for any given platform.

Actually, to a certain extent what im talking about is that *nix is
for all intents and purposes the lowest common denominator, and that
providing functionality at that level only, which is pretty much what
perl does, is not sufficient when dealing with OS'es that have more
sophisticated (don't assume this means better by any means)

So for instance a lot of unixisms are faked by OS'es like Win32. An
example would be file executable status. Whats an executable? On *nixy
os'es they are the ones with the executable file attribute set. On
win32 its something else. Which leads to weirdness like:

d:\>echo print 1 >
d:\>perl -e"print -x '' ? 1 : 0"

Another more common example of this is code that completely ignores
the fact that on some OS'es files have volume specifications in
addition to path specifications. Even code that uses File::Spec tend
to assume that the vol part of File::Spec->splitpath() is going to be

Other examples are things like how to work with tempfiles, default
permissions and sharing attributes when files are opened....

So I think that if you are going to provide an abstaction layer it
needs to be designed with the opposite of the lowest common
denominator in mind. Where an OS cant provide that functionality the
abstraction layer should do what makes sense.

If the semantics of 'open' where changed to support more advanced
locking and sharing models, in memory temp files, or delete on close
semantics then UNIX would just ignore or fake it as needed. But where
the additional semantics are supported the os should do so.
In fact i once recommended that open be extended to support the idea
of opening a self deleting temporary file. On unix this would mean
that open would do the unlink logic, on win32 it would do something
else.  Either way it would mean that programmers wouldnt have to worry
about how it happens.


perl -Mre=debug -e "/just|another|perl|hacker/" Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About