Re: _wstat on Windows (actually stat stuff in general)

[Kean Johnston <kean johnston gmail com>]

> The problem is that stat is API from the 1970's. None of us really
So is malloc. So is chmod. They are wrapped.

> want to prolong the life of code with such readable names as S_IFMT,
> S_IFREG, st_blksize and EBADF. One of GIO's design goals was to come
> up with a fully portable, modern abstraction on top of all this. I for
And if your application can benefit from that, please, by all means go 
ahead and USE it! But why should that be used as a precluder for someone 
who wants to USE the smaller, more efficient, working since the 1970's API? 
A USEFUL tool provides choices. That's what I want to do - provide a 
choice. I don't want to use GIO thank you very much. Pull in a library with 
173762 lines of code (aside from GObject which it depends on)) so I can use 
G_FILE_ATTRIBUTE_TIME_ACCESS instead of buf.st_atime? No thanks.

> GLib is a 21st century platform library, not a pile of portability
> hacks. I admit that for convenience it's managed to acquire a bunch of
> portability hacks, but this isn't a design goal. If you would like to
I want to add one more portability hack. It serves a need and doesn't 
impact anyone who isn't interested in using it. I am trying to improve 
Glib. Not GIO, but Glib. I want to use GLib. Not GObject and libFFI, not 
Gthread, not GIO. GLib. It has its own headers and its own library. There 
is one function I want to make more portable, and 2 I want to add because 
they are missing (seek and tell). If the way you develop software allows 
you to bring in hundreds of thousands of lines of code rather than using a 
single structure, then please, be my guest and do so. But please for the 
love of all that's holy stop trying to tell me that's how *I* should be 
doing things.

> use GIO but find measurable performance problems or missing
1,155,072 jx10-gio2.dll - 'nuff said.

I hear people complaining about lack of maintainers all the time. I am 
trying very hard to participate in the community and add value. As all 
newcomers to a project do I pick something small that can benefit others as 
well as scratch a personal itch. That's how a development community grows. 
Whether you realize it or not you guys are being down-right contributor 
hostile. I have absolutely *NO* problem making my own changes to glib and 
maintaining them for my own purposes. I can use my time writing software 
instead of debating things with you. But if you want help, and you want 
fresh blood and you want a developer who is trying desperately to maintain 
the software on the worlds most common platform and offer precious cycles 
to your team, then please consider that not every single change has to 
appeal to one audience, that there are multiple uses of GLib far divorced 
from the GNOME community or UNIX and that not everyone thinks as you do or 
uses the software the way you do.