It was not my intent to be an experience point whore; my intention was to give a case study of Microsoft's "security through obscurity" paradigm with respect to Windows. Let me summarize my points:
- Microsoft's Windows API contains far too much administrative overhead. All of the calls API calls I listed are actually needed to change the owner; if you don't believe me, feel free to paste the code into your copy of VC++, comment out any section, and execute it a few thousand times. (Multiple executions are needed to show memory leaks in the event that you comment out the "free" statements.)
- This overhead is very poorly documented. I spent about a day going through various WinAPI books, code discussion groups, etc. to get the code I posted above. I'm sure that there are sites that I didn't check, and one of them might have similar or better code than what I've listed. But NONE of those sites are as convenient as the Camel or the Camel head.
As far as your points are concerned,
- Your point regarding computer languages is entirely valid. Languages are optimized for different things, and they do indeed suck when you don't play to their strengths. But my rant is not against C, but against Windows. Actually, it's a rant against the Windows API, which appears to be optimized for obscurity. I should have titled this section "Why I hate the Windows API". My bad.
- How do you propose that I "match the tool against the task" of changing a file's owner? By convincing my users to throw out their Win32 boxes and get Linux ones? (wow... that thought just sent me to a happy place :) ).
This example of API overhead is not an isolated case. I've been programming in Windows API for a few years now, and it's always been a huge mess for anything other than popping up message boxes. (Anyone remember when Win32 first came out, and the nightmare of syncing short and long filenames?)
And yes, this is not remotely constructive, and yes, it is childish, and yes, it is little more than an online theaputic temper tantrum. Which is why I prefaced it as such.
-Ton
btw: in the event that anyone does try to compile my code, I omitted the fact that "SetPrivilege" is a subroutine that I wrote, not a windows API call. Here's the code for that:
int SetPrivilege(char *privilege, int enable)
{
TOKEN_PRIVILEGES tp;
LUID luid;
HANDLE token;
if (!OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES
+, &token)) return 0;
if (!LookupPrivilegeValue(NULL, privilege, &luid)) return 0;
tp.PrivilegeCount = 1;
tp.Privileges[0].Luid = luid;
if (enable) tp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;
else tp.Privileges[0].Attributes = 0;
// Enable the privilege or disable all privileges.
return AdjustTokenPrivileges(token, 0, &tp, NULL, NULL, NULL);
}
| [reply]
[d/l] |
Before anything else, I have to ask: why didn't you just use this program? You're already forgetting portability by using the Win32 API, you might as well just save yourself the 40 lines and tell another program to do the work.
Microsoft's Windows API contains far too much administrative overhead...
Hey, haven't you ever wanted to win a million dollars? The day programming becomes easy, I'll write you the cheque.
This overhead is very poorly documented.
The nature of any kind of library/module/program's documentation is that sometimes the more obscure aspects are not well documented. Sadly sometimes even the commonly used features aren't always documented (feel free to point me to some serious Win32::GUI documentation).
But NONE of those sites are as convenient as the Camel or the Camel head.
Can you point me to where in the camel it tells me how to implement graph algorithms for creating wizards? (Think I'm being anal? We do this at work, but using a tool that is not Perl). Or how about the part about creating editmasks in text controls? I would want to do this all the time, but haven't been able to find out how it could be done (and no longer care, because I wouldn't use Perl for serious GUI programming).
The point is, it's in the Camel because changing an owner of a file is something Larry thought a fair number of readers might want to do. If the authors of the books on the Win32 API forgot to mention a simple way of changing ownership of a file, I'd forgive them. It's certainly something I can't even think of needing for any of the Windows programs I've written, and currently work on (and yet, I've done it on Unix systems, just because I could).
How do you propose that I "match the tool against the task" of changing a file's owner?
If this is the entire purpose of the program then you shouldn't have written it because it's already been done. If it's just a tiny piece, I wouldn't think twice about it. Move on.
This example of API overhead is not an isolated case. I've been programming in Windows API for a few years now, and it's always been a huge mess for anything other than popping up message boxes.
Eeek, wait until all the other Windows programmers find this out!
| [reply] |
I agree with mothra completely, and would like to point out that the Windows access control mechanism is far more sophisticated than *nixs. While the *nix security model is adequate for the large majority of *nix users, it does not support a single entity security model well at all. If it was as extensive as what Windows offers, you can bet it would take far more than a single chmod/chown/stat call to do the job.
While man pages in *nix are good, it's hard to beat the MSDN for content. It may not explain *how* to use something every time, but there are good examples, and most every published call, if not all, are listed. Want a bad *nix example of a man page? ioctl().
One of the things that really hacks me off about people that bitch about Windows (in particular) is that they raise hell when a function does everything for them ("I've got no control, because this one function does it *all*"), then when you give them discrete control, it's "Damn, I have to do all these steps myself? Why isn't this one function?". Basically, unless these people like Windows (and count me in that camp, as well as being a happy Linux user), they'll find something to complain about. Get over it. Shaddup and write some code.
Oh yea, and the reason *Perl* does everything for you, is because it's buried in XS calls, or other peoples modules. Perl only makes it *look* simple. And poor Larry and crew are who you should be thanking for that ease. 'C' was never, ever designed to abstract the user that far from the functionality.
--Chris
e-mail jcwren
| [reply] |
As I stated at the bottom of my original post, I needed code that could access NTFS file permissions, and decided to bundle owner and group in the resulting package. Owner, group, and dacls are all stored in the Security Descriptor for a resource, so extending my DACL code to Owner and Group was a natural next step. As NTFS is a Windows specific file system, I don't need to worry about portability. I do wish I had found that program before, as it lays down the process that I ended up illustrating in my code. Oh well.
Programming isn't supposed to require 50+ lines to perform one simple operation. This is one of the matras of Perl: keep simple things simple. It's not like I'm trying to render an object in 3D; I am changing one piece of data (the owner SID) for a file.
Incedentally, complexity in programming arises because of the multiplicity of intent. A person creating a wizard has to specify (I imagine) a huge number of options before a program can take over: what size should the dialog box be, what color, should it return 'OK' when a user presses enter, etc. And that's just the UI!
Conversely, changing the owner of a file is a pretty unambiguous process. There is little room for misinterpretation, so the resulting code _should_ be simple. Face it: changing the owner of a file and implementing a graph algorithm for creating wizards are not even in the same league.
My whole point is this: unambiguous commands should be simple to write. If the API authors forget to make something easy doable in one line, that is understandable... but it certainly shouldn't take fifty lines.
That being said, I'm completely clueless as to what your beef is. Programming should be hard? If that's the case, you should code in assembly. Some tools are better for some things? Of course they are... but when we're dealing with an OS, then only one tool is available: that OS's API. Switching tools is not an option. High level tasks (implement graph algorithms for creating wizards) are tough? Well, duh. This isn't something an OS API should be dealing with anyway.
I would appreciate it if you would summerize your argument in a couple points (as I have been trying to do), so I can better understand what you are arguing...
-Ton
| [reply] |