>>With regard to Windows PowerShell: I must be very, very dumb, because I don't understand it. Or else Windows & MSFT did not ever explain it properly.
What do you mean they didn't explain it properly? They are obviously not going to come around to your house and sit down with diagrams. There are a number of good books and sites on Powershell. Which have you read / frequented? MS provided a lot of resources for those who are interested.
>>I do not know what "very standard object orientated interface and scripting approaches" actually means.
It means they are consistent from tool to tool. So if you want to turn an array of objects to a CSV table (attributes become columns), then you can use ConvertTo-CSV. If you want to convert the array to HTML, you can use ConvertTo-HTML and if you want to convert it to JSON objects you can use ConvertTo-JSON. And that's a trivial example, it goes beyond that into consistency of parameters and usage across a very wide range of tools. So you will see common and consistent parameters across like tools such as -DisplayError. That's what is meant by standardised interface. It means the elements you learn once you can reliably use again elsewhere. Ditto for language syntax.
>>I do remember what I could figure out all by myself: DOS 3 up to DOS 6.22, when the "help system" actually did help
DOS is hardly comparable to Powershell which has features including Exception handling, fan-out remoting and more. Also, DOS never had hover over descriptions of what every command did along with a list of acceptable parameters and their types, iirc.
>>So let me ask you again: What is the "object" of "object oriented programming"? To me it is sheer and utter mean-spirited and unnecessary obfuscation, without any good explanation available anywhere.
Object orientation allows for more flexibility and simplicity. Nearly every part of the Windows OS is exposed as an object. Therefore nearly every part of it can be managed from Powershell scripts. The modularity afforded by object orientation allows easy combining of distinct tools and adherence to the UNIX principle of 'do one thing and do it well'. For example, if I want to output a list of files and their attributes, I can take the output of ls which is an array of file and directory objects and pipe it to a tool such as ConvertTo-CSV and the latter tool will work fine because it simply uses the attributes of the passed in objects. Later, I might want to output a list of security settings and I can pipe it to the same tool (ConvertTo-CSV) and it will all just work because it's arriving as an array of objects just as before. The receiving tool doesn't need to know how to parse a list of file paths. It doesn't need to know anything about security settings. It simply accepts and works with an array of objects whatever they may be. No text mangling, no special coding. All just OO niceness.
>>Anyone who tells me different is a paid lackey of MSFT. Essentially, MSFT destroyed "personal computing" as much as possible, preventing people from fixing their own, making their own, deciding what goes on their own computers. I hate them for this.
Yeah, no. I built my own computer, I'm comfortable working around in it. I honestly don't think, based on your post, that you've taken the time to really learn how Windows works.