Re: Status of Posix on Windows

On 5/29/2024 5:40 AM, Malcolm McLean wrote:

I'm currently using a Mac.
 
The recent discussion about the "embed" directive inspired me to find a solution to the problem of embedding a directory in an ANSI C program, of course without a modern compiler. You can see my proposal at
 
http://malcolmmclean.github.io/babyxrc/importingdirectories.html
 
(It's in the babyxrc documentation on github if this link doesn't work)
 
The program directorytoxml crawls a diectory and converts it to XML. And
it can't be written in ANSI C. It has to use Posix. The question is whether this in in practise portable to Windows, or if I need to dust off a Windows machine and write a Windows version using FindFirstFile and FindNextFile.
 
 

You find sample codes in the strangest places. I happen to have
RosettaCode open right now, and there are several items there for C.

If you examine the totality of the code in the "Recursively" contest,
many of the developers cannot read, and they submitted flat directory
readers. Don't be surprised if a code snippet is way too short and
submitted to the wrong article.

https://rosettacode.org/wiki/Walk_a_directory/Recursively#C

C
Library: POSIX
Works with: POSIX version .1-2001

#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#include <dirent.h>
#include <regex.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <err.h>

I feel certain, I had a copy of one of those, written years ago in C
and I tried to find it in my archive, and I could not find it. The
one on Learn is not recursive (URL below) and is just for enumerating one folder.

This is the one I have open in my editor, because I use MinGW32 for hobby projects.

Windows
Library: Win32
Works with: MinGW

#include <windows.h>
#include <stdio.h>
#include <stdlib.h>
#include <wchar.h>

*******

This is the non-recursive one.

https://learn.microsoft.com/en-us/windows/win32/fileio/listing-the-files-in-a-directory

What is interesting about that, is the findnextfile performance never
ceases to amaze. Many Windows operations are slug-slow. But that's
not one of them.

D:\>findnextfile.exe  D:\out > list.txt     1.6GB of output for 64million files
Start time (epoch seconds) 1716930446
Stop  time (epoch seconds) 1716930480
Total time                 34               34 seconds or stat'ing around *2 million files a second*

Other operations on Windows, work at around 4000 to 12000 operations a second.
It means, more or less, it is parsing the contents of $MFT and friends,
at around 2GB/sec from the storage device.

*******

Someone codes up two examples here, showing recursion options. Which
is useful for a copy/paste programmer like myself, but will not
be news for professional programmers.

https://stackoverflow.com/questions/15068475/recursive-hard-disk-search-with-findfirstfile-findnextfile-c

   Paul