Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Wednesday March 05, 2008
02:58 PM

Win32::File::Object - Rounding out the Win32 "experience"

[ #35841 ]

I've had pretty much all the basic modules I need for a while now, which has put a damper on my release rate. No bad thing, since when you are looking after 100+ you tend to end up doing a lot more maintenance and feature additions than new coding.

I'm by and large completely happy coding Perl on Unix now.

Unfortunately, as I start to do more coding on Windows (in this case, funky Perl::Dist internals magic) I find myself back in the past a bit.

Win32::File, for example, is a horrible piece of API ugliness. It's all CamelCase and return-by-param and bit fields. Ugh...

So here I am again writing simple usability wrappers about code that does the right thing but makes you feel dirty while doing it.

Win32::File::Object is a wrapper around Win32::File, which is basically only a thin Perl/XS wrapper around the raw C API.

So now if you have some code that needs to remove a readonly flag, you can just go...

Win32::File::Object->new('file.txt', 'autowrite')->readonly(0);

The only downside of this module is that my release code can't deal with Windows code, so I'm stuck with an absolutely tortuous release process.

And given the state of Win32:: I've got a feeling this won't be the first Win32:: module I'm going to be forced to write to feel like a human being when I'm coding on Win32.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I'd have to inspect the source code, but this looks like a handle leak to me:

    Win32::File::Object->new('file.txt', 'autowrite')->readonly(0);
    Is the object a wrapper for the underlying filehandle? Or more abstract than that? If it is a handle wrapper, is it being closed automatically? I'm not sure.

    And, since I'm a Ruby troll:

    require 'win32/file'
    File.set_attributes('file.txt', File::READONLY)
    • There's no handle leak, because there's simply no filehandle.

      It uses the GetAttributes( 'filename', $bitfield ) C function, which doesn't need to open a filehandle because it just reads from filesystem metadata or something...

      If you REALLY want API bling, I'm sure I could make

      use Win32::File::Functions;
      set( readonly => filename );

      or even just...

      readonly $filename;

      or seventeen alternative API styles.
      • Whoops, yeah, you're right. I forgot GetFileAttributes() and SetFileAttributes() don't require a HANDLE. Disregard.