Which makes me think, that there is "something" interpreting the arguments, instead of purely passing the argument string "as is" to the executable, at the desired argument position.

Yeah, its called

$ perl -V:sh
sh='cmd /x /c';
[download]

Well... On a unix system it says:

$ perl -V:sh
sh='/bin/sh';
[download]

But that's exactly my point. This variable should not matter when using system() in the "argument array format". According to official perl documentation, when you use system() in the format:

system('command line with some args and special characters');
[download]

then this might involve calling a local shell. But when you call system() in the format:

system('executable', 'arg1', 'arg2', 'arg3');
[download]

then NO shell should be executed. Only the executable should be run getting the args as they are specified.

As far as I know, on Unix the C-library function 'execv' gets called for this. And it works perfectly well. Even if any of the argN contains special characters or shell metacharacters.

Now... I know that Windows is not Unix, and that on Windows there is no such thing as 'execv'. But even then, I would expect that something similar exists in the OS kernel, and that the Perl implementors (I mean: creators of Perl packages for Windows) are able to run the program, that I specify in the system() call, and pass it my arguments exactly as I specify them at their exact specified positions.

So I'm wondering... Is system() implemented badly on windows ? Or is there really no way in Windows OS to achieve the same behaviour as on Unix (i.e. to make system() simply execute the executable and pass it a stack of arguments) ??

But even then, I would expect that something similar exists in the OS kernel,

See Re^3: system() implementation on Windows (again), the OS kernel function responsible, CreateProcess, does string parsing, it doesn't take an array, it takes string, just like cmd.exe does, all of windows is built on this