Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re: Re: Changing owner of files: Windows vs Linux (or Why I hate Windows)

by ton (Friar)
on Apr 07, 2001 at 02:14 UTC ( #70635=note: print w/replies, xml ) Need Help??


in reply to Re: Changing owner of files: Windows vs Linux (or Why I hate Windows)
in thread Changing owner of files: Windows vs Linux (or Why I hate Windows)

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:

  1. 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.)
  2. 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,
  1. 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.
  2. 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); }
  • Comment on Re: Re: Changing owner of files: Windows vs Linux (or Why I hate Windows)
  • Download Code

Replies are listed 'Best First'.
Re: Re: Re: Changing owner of files: Windows vs Linux (or Why I hate Windows)
by mothra (Hermit) on Apr 07, 2001 at 02:59 UTC
    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!

      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
        I am mixed in my opinions about this.

        So let me start with the uncontroversial note that I find it ironic that Larry Wall criticized Lisp as an exemplar of the "sweep-it-under-someone-else's-carpet" school of simplicity. Ironic because a large part of what I think is good about Perl is how it has encouraged people to hide complexity under someone else's carpet. (Very frequently with that someone being an author on CPAN.) This is one of the reasons that programming in Perl is productive, because you get a lot done with little work.

        That said the security model of Windows is not one of the things that I would call a shining success. To be sure they have a lot of interesting ideas. However security is one thing that you don't want to get wrong, and Microsoft has done exactly that, repeatedly. Plus when I hear someone say, "sophisticated", what I hear is, "complex, poorly understood, and likely buggy". Those are not things you want in a security model.

        Not that Unix is an exemplar here either. As with most things, Unix takes the approach of solving a very simple problem and declaring that to be enough. Well it isn't. With the sole exception of OpenBSD, there is not a single flavour of modern Unix that I would feel comfortable letting an untrusted and competent cracker local access to. And the security model of Unix is also singularly unsuited to handling a complex permissioning system. Plus authenticating actions by the current user/group of the process is using global data. If you need to do complex stuff with restricted access to permissions beyond the normal, well be cautious because it is easy to go wrong. (This is a key cause of why Unix is so characteristically vulnerable to root compromises.)

        But for all that Unix is not very good, it is head and shoulders above Windows in practice. Largely because Unix made a lot of the mistakes that Windows is still making a long time ago. (Based on theory, I am favorably inclined to believe the claims of the EROS folks that they really do have a good security model. At least reading their articles taught me a lot about where and why security goes wrong!)

        Now back to Windows and Unix. And unbridled advocacy.

        IMNSHO anyone who is so put off by the perceived faults of a system that they cannot see the qualities is a narrow-minded fool. Unlike jcwren, I am not a fan of Windows. But I am not stupid either. Microsoft may not have always achieved and held their position through using the best technical product, but when they truly do put out the worst (hello Bob) they don't succeed. Windows has merits. It has things it does very well. Office is a capable office suite. A lot of research and effort went into IE. Any programmer who is blinded by bigotry and decides that this is irrelevant is hurting themselves first, second, and third.

        In fact many of the things that I do not like about Windows are tied to intentional decisions. For instance I do not like the way that Windows pushes people in subtle and not so subtle ways to interact through the GUI rather than with a command line. I am not visually oriented. I generally prefer text. Always have, probably always will. (Which might be why I am writing this from Debian, using fvwm2 as my window manager. Isn't the purpose of a GUI to let you run more xterms...? :-)

        What this means is that Windows is generally harder to script than Unix. But Windows is easier for most people to use on the desktop. Now do I think that it is possible to have a system that is better than either is tooday? Yes. But that doesn't change the fact that the choice to actively focus on moving people off of the command prompt and to the GUI was intentional on the part of Microsoft. And it wasn't necessarily (my preferences notwithstanding) the wrong decision to make either.

        Now for two further takes on this kind of religious war see Why I hate Advocacy by Dominus, and my previous thoughts on this kind of argument at Re (tilly) 2: An interesting and poignant quote.

      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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://70635]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (5)
As of 2020-02-22 07:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    What numbers are you going to focus on primarily in 2020?










    Results (98 votes). Check out past polls.

    Notices?