From: bc@freeuk.com   
      
   On 27/10/2025 20:52, Kaz Kylheku wrote:   
   > On 2025-10-27, Keith Thompson  wrote:   
   >> bart  writes:   
   >> [...]   
   >>> Yes, but: the development and build procedures HAVE BEEN BUILT AROUND UNIX.   
   >>>   
   >>> So they are utterly dependent on them. So much so that it is pretty   
   >>> much impossible to build this stuff on any non-UNIX environment,   
   >>> unless that environment is emulated. That is what happens with WSL,   
   >>> MSYS2, CYGWIN.   
   >> [...]   
   >>   
   >> **Yes, you're right**.   
   >>   
   >> The GNU autotools typically work smoothly when used on Unix-like   
   >> systems.  They can be made to work nearly as smoothly under Windows   
   >> by using an emulation layer such as WSL, MSYS2, or Cygwin.  It's very   
   >> difficult to use them on pure Windows.   
   >   
   > The way I see the status quo in this matter is this: cross-platform   
   > programs originating or mainly focusing on Unix-likes require effort   
   > /from their actual authors/ to have a native Windows port.   
   >   
   > Whereas when such programs are ported to Unix-like which their   
   > authors do not use, it is often possible for the users to get it   
   > working without needing help from the authors. There may be some   
   > patch to upstream, and that's about it.   
   >   
   > Also, a proper Windows port isn't just a way to build on Windows.   
   > Nobody does that. Windows doens't have tools out of the box.   
   >   
   > When you seriously commit to a Windows port, you provide a binary build   
   > with a proper installer.   
      
   The problem with a binary distribution is AV software on the user's   
   machine which can block it.   
      
   That's if the machine has been unlocked (something to do with 's-mode'),   
   otherwise it can only run software from the Microsoft Store, and won't   
   even run some of MS's own programs such as the command prompt.   
      
   To get around that AV, you either need to have some clout, be   
   'white-listed', or somehow know some tricks.   
      
   In my case, rather than supply a monolithic executable (EXE file, which   
   either the app itself, or some sort of installer), I've played around   
   with several alternatives, all of which are also single monolithic   
   files, and are a step or two back from full binaries:   
      
   * Provide a ASM file in AT&T format, which can be assembled and linked   
   locally. This requires the user to be a programmer, who will already   
   know how to bypass AV for their own programs   
      
   * Provide a headerless C source file, which these days is very low level C.   
      
   * Provide a binary but in my private format, which seems to evade AV.   
   But this needs a launcher (an 800-line true-C program built-locally).   
      
   * If the user has managed to obtain a working version of my compiler via   
   the above means, then further apps could be downloaded in original   
   source code (not C), but again, this will be a single amalgamated file.   
      
   In all cases, there is one file to be assembled, compiled etc. Not   
   dozens of source files, headers, makefiles etc.   
      
   The approach used here can also work for Linux, but there only the C   
   format would be viable ATM since I don't directly support the SYS V ABI   
   needed by the other formats, assuming an x64 target, or the Linux may   
   run on some other target anyway.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)