As I had said, I had tried to work with a Windows 10 Professional machine during some days, and for probable motherboard problems, I didn't get that system stable. But I also I had problems with command line tools which W10 Prof. systematically refused to execute, notwithstanding all my tweaking tries from hours of reading respective tips and tricks on web forums; I suppose that W10 Home would accept these tools executing but for other reasons (establishing a little LAN network mid-term), I would like to get W10 Prof. instead, so I would like to find a solution to these problems.
Those tools are for example in the form (from the "run" window, then the following, then enter/return)
toolpath\toolname.exe someattributes sourcefilepath\sourcefilename.suffix targetfilepath\targetfilename.suffix
From this input into the commandline, those tools then are expected to open a command window (the thing which is black as a DOS window).
With sourcefile, I mean the file upon the tool will work, and by targetfile, I mean the file the tool will then create from it will have done upon the data from the sourcefile, so in reality, even with misfunction, there is no harm done to the source file which is just read, and the newly-created file will be some changed copy of the source file, not some ".exe" or other harmful file, but W10 Prof just refuses to execute those command lines.
I tried this with an administrator account, but not successfully. I tried to put the tool into other directories and for example into its own directory
c:\toolname\toolname.exe
instead of
c:\toolname.exe
or c:\programs\toolname\toolname.exe
and I also tried to put the sourcefile and the targetfile into other directories than ones that Windows constantly checks. And as said, I messed around with the UAC settings, then was not even able to reset them them, after all that messing around with it, according to those hints and tricks had not been successful.
Also, I did not even create an ordinary user before sending back the pc, just just the administrator account which should be allowed much more, permission-wise, than an additional user account.
It goes without saying that with Windows XP Home, all this works smoothly, and also, the tools in question work also with W10 or are specific versions to work with W10.
So I suppose now that I missed some core concepts in this permission control, since neither directory permissions nor user permissions did not work, for these command line tools.
To begin with, when Windows speaks of folder permissions, it's not evident if that means the folders in which the tools-to-run are put in, and/or the folders in which the files-to-be-worked-upon / files-to-be-accessed-from-these-tools, and the coordination of folder access in general and of account control - what some account is permitted to access / to do - is not evident for me.
Also, I do not understand why the administrator - not some additional user - would not have the right to run some tool from the commandline, independently from the storage folder of that tool, when on the other hand, any program installed into the programs folders - c:\programs (x86)\ and c:\programs\ is executed when run from the start panel, but a tool put into a folder c:\programs\toolname\toolname.exe, when I try to execute it from the commandline, which means from the Windows "execute/run" dialog - which is necessary to enter the necessary attributes, does not run.
I suppose that any program in c:\programs\specificprogramfolder is executed when triggered from the system, is sort of "object attributes heritage" from folder c:\programs, but as said, when I install those tools into such a folder, then try to run them from commandline, which is refused, so it becomes evident that there are possibly 3 or more security concepts which come into play: folder permissions, account permissions, and then also permissions depending on from which system internals a tool/program has been triggered, even when folder and/or account is/are identical, or then also, if has been triggered with or without attributes.
No help I found - and I tried hard, just finished a 1200-pages-W10-Prof.(!)-book without getting any help on this from there either - specifically treated this run-from-commandline (and/or with attributes) permission problem, which, as said, is probably specific to the Prof. versions of Windows in general and/or to the W10 Prof. version in particular.
(If I hadn't bought so many programs for Windows which I then had to leave behind, or would need to run from within a virtualization tool which probably will not be practical, I would jump from XP to iOS, not from XP to W10, but it's not only about buying anew, it's especially about finding, choosing, learning all those new programs then, so I'd better learn some Windows internals.)
