On Fri, 21 Sep 2018 10:24:02 -0400, Paul wrote:

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.

I agree with everything you said, Paul, where I interject an
unsubstantiated musing that it's not really random; we just don't know what
the algorithm is.

I don't mean that flippantly; I mean that seriously.

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

I think it "is" ordered; but that we just don't know the ordering.

For example, perhaps there is an "inode" for each file, where that inode is
the order. I am conjecturing since I don't believe it's random.

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.

We should "standardize" on procedure, which, I posit, is likely the
simplest, which is to left click selectg the first file in the File
Explorer sequence, and then shift left click on the last file to selecdt
all ... and then right click on the first file to "open with".

If we use a different approach, that's fine - but we should be consistent.

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)

I don't see the date being a factor either but there are different dates
other than the creation date (as you're well aware).

If there is a good "dating" program that can date the files, oh, say, a
minute apart, we could ensure all the various dates are valid (such as the
modification date, last used date, whatever date).
..
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.

Interesting test. It proves "determinism" is still valid.

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.

Agreed. It shouldn't be capricious.

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 ?

Interesting what you found it.
a. It starts serialized,
b. But then, it goes unserialized
c. Unless, something keeps it serialized.

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.

The original test case matters a *lot*, as I explained to Mayayana, where
if you open a score of thumbnails, they all look exactly the same in the
image editor.

You have to re-order them by hand, which shouldn't be necessary.

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.

I habitually launch scores of VPN processes, where what happens is that
only the first successful connection wins.

I sometimes set it up so that all unsuccessful connections close the window
after a few seconds, but that's a pain (registry edits), so lately I've
taken to changing the windows transparency and stacking the windows on top
of each other.

Then I can click the close box in sequence, where, since the windows are
transparent to a degree, I get two or three files' warning of the one
successful connection.

This transparency trick works very well simply because you don't actually
'do anything' inside a vpn connection report.

But the point is that I open scores of command windows all the time, where
once in a while I can open a hundred of them, and there's no problem.

(They do seem to open in sequence though ... but I haven't actually checked
that to be a fact.)

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.

This is step 15 of setting up a new Windows OS:

Add a 32-bit DWORD to open more than 15 files at a time.
- HKCU\Software\Microsoft\Windows\CurrentVersion\Exp lorer
- Name : MultipleInvokePromptMinimum
- Type : DWORD
- Default : 15 (decimal)
- Change to: 100 (decimal)

I need it for two reasons, using it every day:
a. Open up 50 VPN files where only one randomly takes, and,
b. Edit a score of screenshots

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 :-)

Nope. I set up my system, in step 15, to open up as many as 100 files.

The small batches are about a score, where I'm editing screenshots,
although there are times I need to edit 100 screenshots at a time in
sequence.

But because of this flaw, I can't.

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.

Paint.NET handles a score of files to about 50 with aplomb.
They're just in the wrong order.

The OpenVPN client daemon easily handles 100 command windows, where only
one wins by design. The rest close on their own when properly set up in the
registry to do so. (It's a trick that I learned from an expert that nobody
knows since it's not the default setup for OpenVPN.)

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

How would you script a *single* instance of Paint.NET to open multiple
files?

You don't want multiple instances of the editor for a whole bunch of
reasons, not the least of which is that the settings won't take between
sessions.