Mayayana wrote:
"Paul" wrote

| 2) Highlight all four in File Explorer.
| 3) Select Edit from the right-click menu, which
| causes four copies of Notepad to open.
| 4) When Process Monitor is running a trace, the
| windows stack on the screen in the proper order.
|

What's the proper order? Didn't you lasso
them with the mouse? It may depend on
which direction you came from. In any case,
Explorer will be sendind the list in its order
to Notepad. But that might not be the same
order you get with a multi-selection FileOpen
dialogue. That could also be lassoed or single-
selected and will then return the list to the
calling process in the order it sees.

Then there's the other glaring question:
Why didn't anyone ask Arlen what difference
it makes?

There's two aspects to the observation so far.

1) The order the windows appear on the screen
appears to be random. Not "random" as in
"suitable for generating cryptographics keys"
random, but just not exactly reproducible. And it's
not a good thing, when we can't predict what a
computer will do. There are all sorts of situations
where we expect "race conditions" to inject non-determinism.
This one could have happened in order, without
too much trouble.

2) There's an assumption on my part, that the launch
is actually ordered.

When I ran the "findnextfile" test that I joked that
Wolf could compile up and test, I gave it a try
myself, and the order the file system enumerates in,
isn't exactly an order you might normally expect. It
didn't seem to be date or alphabetic or size. The routine
is optimized for speed (as a previous experiment to
list millions of test files on my RAMDisk proved).

But the important thing in the findnextfile test,
was the order remained consistent from run to run.
The order the directory listing popped out in each
run was the same. That's still determinism, and what
you'd expect from a process running in its own thread.

It shouldn't be possible to have the results show up
in a different order each time. We hope the test is
consistent from run to run.

With regard to the Process Monitor test result, it
occurred to be later that I was running Process Monitor
with the Backing Store set to the same drive as the
drive with the files I was testing with. And perhaps
that has something to do with changing the behavior.

And the weird part is, by using Process Monitor to observe
Notepad opening four text files at once, the windows
stack in alphabetical order, each time.

This tells me the process may have started launching
things alphabetically, but the wheels fell off during
the operation. There are lots of ways to lose serialization,
Why is a little file system activity (from Process Monitor
to the Backing Store file) causing serialization to
happen properly ?

*******

The windows are labeled at some level, so I probably
won't select the wrong one by accident. It doesn't really
matter that they don't pop out in order. I'm minorly
annoyed that the order is different each time. Selecting
Cascade from the Task Bar menu doesn't make a difference either.

Note that this isn't generally true with the Virtual Desktop
Manager in Windows 10. As a joke, I launched 500 copies of
Command Prompt from a script in Windows 10, and (obviously)
the presentation in Virtual Disk Manager was "non-useful".
That was mainly a test to see whether the system would
even tolerate opening 500 windows. And that part seemed
to work OK. But as a GUI design, the VDM was "mostly useless".
And it isn't particularly a tractable problem at that
level either. Even if you listed the PID on the screen of
each one, PIDs are recycled often enough that the order
of them is also "a bit random".

And as someone might already have noticed, Win10 by default
is set to not open more than 15 items like that in an
extended selection. You can set the registry value to
make the extended selection size having "Edit" available
to "unlimited" if you want. So you could then highlight 500
text files and click "Edit" and have 500 copies of
Notepad open (once you set the registry entry to make
it happen). This is possibly why the OP (Arlen) refers
to working in small batches, because he ran into the
limit and couldn't make it do more of them at once :-)

I don't recommend overwhelming the system with windows
like that. The machine may have the resources to handle
it, but for the human operator, it rapidly loses value
as a means of working.

For large numbers of files, you may want to script
something to process them. Or risk carpel tunnel from
all the HID activity needed... :-)

Paul