Do you know the cause of the 3k requests which Vista made? Do you have a sane theory why these were occurring? Also, do you have any suggestions for better clients to use?
> Do you know the cause of the 3k requests which Vista made? Do you have a sane theory why these were occurring?
Backwards compatibility and layers of indirection.
Microsoft has always made great efforts for backwards compatibility - Raymond Chen's blog is a good source of stories. Quite simply if you upgraded Windows and apps stopped working then you'd blame Windows. Of course it is almost always the apps relying on undocumented behaviour, ignoring documentation, relying on implementation artifacts etc. This means a lot of code to detect and work around problems in other components. For a networked filesystem client the simplest way is sending lots of requests and picking results of interest based on what comes back. Networked filesystem servers also work around client problems in various ways - eg they may return smaller block sizes than the client requested because it is known to have occasional problems. All of this builds up layers and layers of workarounds, workarounds to workarounds, having to test against OS/2 etc. SMB2 was an attempt to wipe the slate clean (no more OS/2!) but of course the crud starts building up again.
Explorer isn't a program that displays files and directories despite appearances. There are layers and layers of abstractions, parts provided by COM etc. The code that knows it wants to display the listing of a zip file is many layers away from the code that generates network requests. It is always easier to write code that does more than strictly needed than the absolute minimum necessary.
Backwards compatibility and layers of indirection.
Microsoft has always made great efforts for backwards compatibility - Raymond Chen's blog is a good source of stories. Quite simply if you upgraded Windows and apps stopped working then you'd blame Windows. Of course it is almost always the apps relying on undocumented behaviour, ignoring documentation, relying on implementation artifacts etc. This means a lot of code to detect and work around problems in other components. For a networked filesystem client the simplest way is sending lots of requests and picking results of interest based on what comes back. Networked filesystem servers also work around client problems in various ways - eg they may return smaller block sizes than the client requested because it is known to have occasional problems. All of this builds up layers and layers of workarounds, workarounds to workarounds, having to test against OS/2 etc. SMB2 was an attempt to wipe the slate clean (no more OS/2!) but of course the crud starts building up again.
Explorer isn't a program that displays files and directories despite appearances. There are layers and layers of abstractions, parts provided by COM etc. The code that knows it wants to display the listing of a zip file is many layers away from the code that generates network requests. It is always easier to write code that does more than strictly needed than the absolute minimum necessary.