From: bc@freeuk.com

On 28/10/2025 17:03, Kaz Kylheku wrote:
> On 2025-10-28, bart  wrote:
>> 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.
>
> Well, then you're fucked. (Which, anyway, is a good general adjective
> for someone still depending on Microsoft Windows.)
>
> The problem with source distribution is that users on Windows don't
> have any tooling. To get tooling, they would need to install binaries.

There seems little problem with installing well-known compilers.

Windows' AV seems to use AI methods to detect viruses which can give
false positives (there is an 'ai' tag on the report code shown). So I
guess 'gcc' etc must pass.

Anyway these days I don't deal with non-technical endusers. People
should know how to build programs. Or I had assumed they did.

Although I'd gone to a lot of trouble to ensure my single-file C
distributions are as easy to build as hello.c (on Windows, that is the
case), I found out something interesting:

Some people don't actually know how to compile hello.c! They know only
how to type 'make', and some argue that is actually simpler in that you
only type one thing instead of two or three.

I was rather surprised: I'd reduced the job of installing a kitchen to
hammering in just one nail so that you can trivially DIY it, but some
people don't know how to use a hammer.


>> To get around that AV, you either need to have some clout, be
>
> The way you do that is by developing a compelling program that helps
> users get their work done and becomes popular, so users (and their
> managers) can they convince their IT that they need it.
>
>> 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
>
> You are perhaps too hastily skipping over the idea of "some sort of
> installer".
>
> Yes, use an installer for Windows if you're doing something
> serious that is offered to the public, rather than just to a handful of
> friends or customers.

An installer is just an executable like any other, at least if it as a
.EXE extension.

If you supply a one-file, self-contained ready-to-run application, then
it doesn't really need installing. Wherever it happens to reside after
downloading, it can happily be run from there!

The only thing that's needed is to make it so that it can be run from
anywhere without needing to type its path. But I can't remember any apps
I've installed recently that seem to get that right, even with a
long-winded installer:

It might go through a long process of perhaps several minutes. It says
it's installed, you type (what you assume to be) its name on the command
line, and you get: File not found. It doesn't even tell where it
installed it, or its actual EXE name.

So my stuff is no worse. I just don't think anybody cares anymore; most
poeple use GUI apps launched via Windows menus.

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)