• Re: Status of Posix on Windows

    From Kaz Kylheku@21:1/5 to Malcolm McLean on Wed May 29 16:16:05 2024
    On 2024-05-29, Malcolm McLean <malcolm.arthur.mclean@gmail.com> 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.

    I use Cygwin for porting POSIX stuff to Windows. Cygwin moved to the
    LGPL in 2016, which allows you to ship a program with its DLLs,
    even if the program is proprietary.

    I forked the main Cygwin DLL in order to bring about "native Windows"
    behaviors in a number of areas, resulting in a project called Cygnal.
    This is referenced in my current Usenet signature.

    The downside of Cygwin is that it has slow file access. From following discussions on the Cygwin mailing list, my understanding is that at
    least some of it has to do with Cygwin having to make multiple accesses.
    Like when you access a file foo, it has to check whether there is a
    foo.lnk and foo.exe and such.

    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @Kazinator@mstdn.ca

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Malcolm McLean on Wed May 29 13:41:07 2024
    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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Malcolm McLean on Wed May 29 16:24:13 2024
    On 5/29/2024 1:40 PM, Malcolm McLean wrote:
    On 29/05/2024 17:16, Kaz Kylheku wrote:
    On 2024-05-29, Malcolm McLean <malcolm.arthur.mclean@gmail.com> 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.

    I use Cygwin for porting POSIX stuff to Windows. Cygwin moved to the
    LGPL in 2016, which allows you to ship a program with its DLLs,
    even if the program is proprietary.

    I forked the main Cygwin DLL in order to bring about "native Windows"
    behaviors in a number of areas, resulting in a project called Cygnal.
    This is referenced in my current Usenet signature.

    The downside of Cygwin is that it has slow file access. From following
    discussions on the Cygwin mailing list, my understanding is that at
    least some of it has to do with Cygwin having to make multiple accesses.
    Like when you access a file foo, it has to check whether there is a
    foo.lnk and foo.exe and such.

    OK. So bottom line is no, I can't reasonably expect my millions of Windows Baby X programmer users to use directorytoxml. If utterly determined they can of curse make things work by messing abut with Cygwin. But the sirit of BabyX is tht everything is
    easy for the hobby programmer.

    So eitber some nice person will volunteer, or I'll have to get a Windows machine. Work have kindly let me keep my work Apple Mac even though I've had to give up work due to ill health, but the Windows machine is at my own house which I don't live in
    any more (long story, and no it's not family disputes fortunately, except no-one accepts that my house is actually mine because my grandmother got it for free off Margaret Thatcher, and currently sister has designs on it whilst Dad is demented and needs
    me to live with him. So Windows machine not very accessible, and I'm too ill to drive).

    It really depends on what kind of Apple Mac you have, and
    what processor it has got.

    68K <=== Ancient (I have one)
    PowerPC <=== I have several, ancient as well. Mac G4 single core was the last PowerPC.
    Intel <=== During this era, OS was x86, Windows was x86, no translation needed due to HW.
    AppleM1--ARM

    Intel would be ideal at a time like this. You could use Parallels,
    or install Windows native on a drive on the thing. If this is an
    ARM box, there is also a Windows ARM version as well, but then
    your x86 test code is less welcome. Windows 11 will have a version
    coming up, with perhaps a more functional x86 to ARM translator. I
    don't know how good the current x86 translator is. At one time,
    the translator might have done 32 bit but not 64 bit applications,
    or some such story.

    The Windows 10/Windows 11 grace period is longer than what you
    might have seen in older OSes. In older OSes, it was 30 days, with
    two re-arms possible, for a total of 90 days. Current Windows puts
    up a watermark on the screen, but it is not nearly as nasty as
    previous versions. This is how I can run virtual machines of Windows
    here, without activating them. In any case, you should not be spending
    $150.00 on an OS. It can be done for less, or for nothing.

    You can download Windows 10 or Windows 11 DVDs from Microsoft, without presenting a license key to the web page to get them. You can
    transfer the downloaded ISO to a USB stick with this.

    https://rufus.ie/en/

    Due to the size of some of the DVDs, you need dual layer DVD blanks
    to be absolutely guaranteed of being able to make installer discs.
    A USB stick is easier (up to a point). Making media is just as
    nasty for jobs like this, as preparing media for Linux installation.

    Windows 10 has less of a hardware requirement. I used to run it on
    a Core2 Duo.

    The DVDs available, carry either 7 versions of OS or 11 versions of OS.
    Using WADK tools, you can remove all but one OS version on the DVD
    image, and make a new ISO. This then, might fit on single layer media.

    It's just easier to buy the media. I have a small stack of dual-layer discs
    if I need them. I've used one disc so far.

    Refurbished Intel PCs are available for around $200. PCs which are not
    capable of running Windows 11, will run Windows 10. In some cases,
    USENEtters have acquired perfectly working Intel PCs on garbage
    day, on the sidewalk. For nothing. Maybe only a fresh hard drive
    might be used on something like that. The price of legit refurbs
    varies with time, and it might be $300 one day, and $200 the next.
    It's best not to be shopping for one, around August when the
    students "return to school". The selection of refurbs today,
    include quad core CPUs. They might typically include 8GB of RAM,
    and an x64 OS can be run on them (runs x86 or x64 executables).

    It's still a lot of work for a motivated person, no matter what
    you do. See if any community refurbishers are available near
    you, and see what they've got on offer. You could have a
    Pentium 4 for nothing, but it might not boot Windows 10 and
    might need an older OS. There are instruction set requirements
    it would fail to meet.

    As I've given up on Apple, I don't have any "worked examples" of
    Windows running on Apple. My last experiment on the MacG4, was
    running a then-available PowerPC version of Linux on it. Linux might
    have very thin support for that now.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kaz Kylheku@21:1/5 to Malcolm McLean on Thu May 30 00:30:09 2024
    On 2024-05-29, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
    OK. So bottom line is no, I can't reasonably expect my millions of
    Windows Baby X programmer users to use directorytoxml.

    What? On the contrary here is a .zip of the executable, with needed
    DLLs:

    https://www.kylheku.com/~kaz/d2xml.zip

    SHA256: fbd56a70a23cc34e6085c5a754c79046c0f96258e4aebda8197e82a53c3551ef

    All I did weas build this on Cygwin with

    gcc -O2 directorytoxml.c -o d2xml

    Then bundled the d2xml.exe with the needed DLLs and zipped up.
    Literally, a minute of work.

    The cygwin1.dll isn't the Cygwin one but from the Cygnal project,
    so this should understand native Windows paths. If you point it
    at C:\Users\whoever\whatever, it should work.

    Remark: I would have used the POSIX nftw function in this, instead of
    rolling my own recursive traversal.

    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @Kazinator@mstdn.ca

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Malcolm McLean on Thu May 30 01:15:01 2024
    On Wed, 29 May 2024 18:40:39 +0100, Malcolm McLean wrote:

    If utterly determined they can of curse make things work by messing abut
    ^^^^^
    with Cygwin.

    One would call that a “Freudian” slip, but it’s so apt I almost feel it should be called a “Jungian” slip. ;)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)