On 2025-01-17 Pali Rohár wrote: > On Friday 17 January 2025 15:22:30 Lasse Collin wrote: > > Another possible change could be to call FindFirstFileW directly > > instead of going via _wfindfirst. > > Personally I would prefer to stay with _wfindfirst as it is from > MS C runtime library.
Calling FindFirstFile and FirstNextFile directly seems to be faster (perhaps 20 %). I attached over-simple test programs for comparison (error handling is lacking and path length is limited). One can measure the time and check that they produce identical output. The CRT functions prodide timestamps in time_t while Win32 API provides FILETIME. Perhaps the conversion wastes time. The dirent functions don't need file timestamps. Neither _wfindfirst nor FindFirstFileW are available on Windows 98. They are stubs: program runs but FindFirstFileW fails with ERROR_CALL_NOT_IMPLEMENTED. Is Windows 95/98/ME support needed in <dirent.h> functions still? A transparent fallback to FindFirstFileA is possible for Win9x support. I have played around with the idea. It's not a huge amount of code but it makes the overall result significantly more messy to read and review. It would be nice to avoid it. Other things in libmingwex seem friendly to Win9x still. With a quick search with grep, I only spotted one extremely minor thing: getopt.c calls GetEnvironmentVariableW to read POSIXLY_CORRECT. That function exists on Win98 as a stub so the program still runs. It just won't obey the POSIXLY_CORRECT environment variable on Win9x, which is not a problem at all. getopt and dirent in libmingwex exist to make it easier to port code from POSIX. If such POSIX compatibility functions don't work on Win9x, it doesn't affect apps that only use native Windows functions. -- Lasse Collin _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
