On Saturday 25 January 2025 12:39:19 Lasse Collin wrote: > 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.
Maybe that time conversion is slow. Anyway, it is needed to also check how different CRT versions behave. I guess you have done these checks against msvcrt.dll. Maybe the last UCRT version is faster? Also what could be different is that _findfirst may be affected by setlocale function as IIRC UCRT supports changing process locale but only for UCRT functions. Another important thing is that FindFirstFile is affected by the AreFileApisANSI() function. Some info is in SetFileApisToOEM() spec: https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-setfileapistooem For me it looks like that _findfirst and FindFirstFile do not have to behave in the same way across different crt versions. > Neither _wfindfirst nor FindFirstFileW are available on Windows 98. > They are stubs: program runs but FindFirstFileW fails with > ERROR_CALL_NOT_IMPLEMENTED. Ok, thanks for info. > Is Windows 95/98/ME support needed in <dirent.h> functions still? I guess that no. Basically developers do not care about anything pre-WinXP. But on the other hand I fixed few bugs related to Win9x/NT4.0 because people recently reported them that they are still using it. And those bugs were mostly caused by incorrect definitions and fallbacks in msvcrt* def files, which I was cleaning up and fixing a lot. So it means that there are already "users" who actively use mingw-w64 with older systems. > 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. IMHO this is a bug. We should use getenv() in POSIX/CRT functions and not the GetEnvironmentVariable[AW]() because the WinAPI function does not address things like direct modification of 3rd main argument env, or similar thing which is used in POSIX applications. There is also _enviroment symbol (or function which returns pointer to this symbol) which can be and also is used by windows (msvcrt) applications. > 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
