Sean Conner wrote:
Please don't assume. FindFirstFile() will take any valid paths. The most convenient >=Win2K method is probably to use FindFirstFileW() and utilize the extended path string format (to exceed MAX_PATH-length strings) and add a UTF-16 translation layer (if we want to enforce a consistent UTF-8 policy). The other problem is that in Windows, you will get most of the stat() information with the Find---File() calls. If we wish to enforce POSIX-style functionality, calling again to get stat() information all the time may not be everyone's cup of tea. For apps that want maximum file system performance, perhaps they should roll a custom library. So, in order to have common functionality, no platform is likely to get a perfect file system library.[snip] Under MS-DOS (and I assume, Windows), you have the following: FindFirstFile() - return first file in current working directory FindNextFile() - return the next matching file FindFirstFile() only works for the current working directory (unlike Unix), it takes a simple file regex (a file glob) and some flags (include archive files, read-only files, system files, etc) and fills in a structure (the address of which is passed in first via another function) with the following information (for Unix, another all is needed to obtain this information):
-- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia