fill listbox

[Schmidt]

I didn't know it was in that ZIP, no. I had looked for pages mentioning him and cEnumW32 though.

So you didn't read what he wrote in post #10 - and you didn't read my post which followed in #11 (the one where
I posted the performance-comparison-example - and was directly referring to DrUnicodes code (in the posting #10 directly above).

That's pure ignorance. When you discard well-made arguments, logic - and hard-evidence
(not running the specific code-examples which were posted) - then that's your problem.

If you were interested in a nice technical discussion, you wouldn't start it off by telling me to correct my "myth",

Myth-busting is just one of the reasons, where techical discussions can be helpful.

...then when I defended it saying only cached performance mattered,

You didn't defend anything - you just stuck to your original claim with a "because I say so"-argument...
Properly defending a certain position is done with a code-posting - nothing else matters.
I did so, you didn't - case closed - myth busted.

And that "only cached performance mattered" was mentioned in a certain (narrow) context.
But I can bring that context again, serving as my second argument against your claim...
It's a pure "logical one" - not really necessary anymore, since the hard evidence was already done in #11,
but here we go again:
- kernel32 (which hosts the Find...APIs) is "quite near the kernel-drivers" (hence its naming).
- it doesn't import stuff from shell32.dll - instead it's the other way around (shell32 imports stuff from kernel32)
- both are userland-dlls (which work *on-top* of the FileSystemLayer)
- none of them is communicating directly with the hard-disk-drivers
- when we look at the FileSystem-layer which both dlls work against, this layer works through:
... - the FileSystem-Cache
... - and when stuff is not contained in the FS-Cache it will talk to the HardDisk-drivers

So, here's my questions to you (hopefully you read and understood the above points).
- Do you really think that Shell32.dll has a more "direct path" to the HardDisks (in the uncached case) than kernel32.dll?
- If you agree with me, that this is extremely unlikely - won't you also agree that they *both* just use the very same FileSystem-Layer?
- Logik dictates that both Dlls *do* work through the same FS-Layer, otherwise they wouldn't be *both* much faster in the "fully cached case"

Now the final steps:
Since *both* work through the very same FS-Layer (whilst doing their enumerations),
the only differences which are related to both their enumeration-performances, will happen
in their implementations *atop* the FS-Layer - and can thus reliably measured best, when
*everything is completely cached*.

Your hostility towards me for my anti-closed source stance shows.

That's just another of your illogical-misconceptions.
Here's why I termed it illogical:
If you'd be *really* "anti-closed-source", then you wouldn't invest such a lot of time
working against the closed source shell32.dll (which is provided by a vendor, most of
the VB6-community-members already classify as: "not to be trusted").

If you'd be truly "pro-opensource", you would instead:
- try to find a way out of all these MS-API-dependencies
- investing your time into a new base-environment, to be able to bring VBClassic (in a smooth way) to other platforms
.. (where things as shell32.dll, ADO/JET or GDI/GDI+or DCOM do not exist)

Question to all:
When will the VB6-community wake up and come out of its 'shell'?

Olaf