Classic Shell: Forum

Hello,



quite some time ago, ~ 2 years or so, in the old forum there was a feature request about disabling explorer's auto-sort (the "instant F5" after any change in a folder) - even for list view.

Until now there hasn't been a solution for that anywhere on the net and that time ago classic shell's dev said that this couldn't be achieved since it obviously was done delibaretly by MS and cannot be changed. Until now I'm using WinXP since this is the main show stopper for any newer version for me since I do a lot of file management and don't want to change to another program but keep the well-known explorer...


Nevertheless in the last days I did a bit of researching and I think there might be a possiblity to revert back to XP behaviour of NOT auto-sorting but placing new (i.e. newly unpacked) files at the end of the list until next *manual* F5.


As you can read and experience, Win7's explorer doesn't do this auto-sort in two cases:

1) The directory is a network drive.
2) The directory is a root directory.

Therefore I thougt that it perhaps could be possible to disable auto-sort, if windows' explorer would think in *every* directory that it was a network or root drive.
So I dug into the depths of windows and as far as I could learn the explorer.exe uses the function PathIsRoot() from the shlwapi.dll (located @ %windir%\system32 for x86-version of win7).

So my idea is to just hook shlwapi::PathIsRoot() and if it is called by explorer.exe always "true" is returned, otherwise the call is simply wrapped (means given to shlwapi.dll and the correct result is returned).


After a quick look in Classic Shell's source code (the last public one) I saw - just as I expected - that DLL hooks are used, so it shouldn't be too hard to implement another hook.


I can't try it myself since...
1) I don't have any compiler installed,
2) the last time when I used C++ is some years ago,
3) and when I did it was just a hobby and
4) I was never really good at it
5) and therefore I don't even know if it is possible while hooking an API-call to see which thread called it (to selectively just fake the answer for the explorer.exe and NOT for other threads for not breaking things).


But since classic shell is already using DLL-hooking mechanism I'd love to see you giving this possibility a try and perhaps end with that the "instant-F5" nightmare of me and other users...




Regards,


Spike2

Classic Shell does not hook any APIs. Also changing the behavior of some system function can have effect on many features. And also it is very unlikely that this particular function is used to determine the behavior you describe.
So no.

This would be worth doing if it was possible as this is most definitely the number 1 serious usability issue with newer releases of Windows today. It's so horrible but I've had to live with it all these years because of Microsoft's forced obsolescence of XP.

_________________
Links to some general topics:

● Compare Start Menus

● Read the Search box usage guide.

I am a Windows enthusiast and helped a little with Classic Shell's testing and usability/UX feedback.

Oh sorry, as already stated, I just know very little C++ nowadays and with a quick look I just saw a THREAD_ATTACH somewhere and therefore thought API-Hooking was used.

It's a pity that nothing can be done against this usability nightmare.


I mean - one of the very basic functions an operating system should provide is file management - so it has been since the very first days of MS-DOS and it's just not understandable that Microsoft cripples this functionality deliberately...



Best regards,


Spike2

Yes, this is so frustrating that I did try a lot of file managers just to get away from this shit but no file manager has all features and shell extension handlers of Explorer.

_________________
Links to some general topics:

● Compare Start Menus

● Read the Search box usage guide.

I am a Windows enthusiast and helped a little with Classic Shell's testing and usability/UX feedback.

Well, most probably I'll switch to explorer++ once XP's support ends and I'm forced to upgrade to Win7. At least this nice open-source-app is configurable so that it exactely looks and works like XP's explorer. Together with changed windows' settings for fonts this is the nearest to the initial feature request in this thread, which can be achieved.


But if someone should discover this thread (i.e. per google) and is looking for closer information for further tries to prevent the forced "instant-F5" in WinVista/7/8's Explorer, here are the last things I could figure out:

- most probably it is NOT the API-function PathIsRoot() from shlwapi.dll (changing the call to a NOP with a just-in-time-debugger leads to nothing except explorer.exe's crashs when reboot or shutdown is initiated)

- changing the JNZ-command after this API-call to a JMP has the same results

--> most probably this "functionality" is hardcoded in explorer.exe
--> therefore I'll not make any more tries, because even if I was successful, there's great danger that some other things get broken - the consequences might reach from crashes to data loss

I suspect it is based on the classification of Drive vs Directory in HKCR. However I don't know how I can re-classify a directory to be a drive or what the consequences of that would be.

Sounds interesting... perhaps there's a possiblity of using the "bags"-keys in the registry so that a directory doesn't need to be reclassified as a drive but just needs to inherit the display properties from it....

Hmm, seems like I'll install a new Win7-VM in the next days, this could be worth to be elaborated....

Anyone came with a solution yet?