MacAranym currently not building... compemu_fpp.cpp: CW_X undeclared

[Philipp Donzé]

Hi all

I tried today to compile the latest aranym sources and run into build issues while building a JIT version.

.../src/uae_cpu/compiler/compemu_fpp.cpp:117:5: error: use of undeclared identifier 'CW_X'

  117 |     CW_DEF8(CW_PC_EXTENDED | CW_RC_NEAR)  /* 0x137f, p0r0 extended, round-to-nearest */

      |     ^

.../src/uae_cpu/compiler/compemu_fpp.cpp:116:20: note: expanded from macro 'CW_DEF8'

  116 | #define CW_DEF8(x) CW_DEF | x, CW_DEF | x, CW_DEF | x, CW_DEF | x, CW_DEF | x, CW_DEF | x, CW_DEF | x, CW_DEF | x,

      |                    ^

.../src/uae_cpu/compiler/compemu_fpp.cpp:115:16: note: expanded from macro 'CW_DEF'

  115 | #define CW_DEF CW_X | 0x7f

      |                ^

It seems that this part (lines 113ff) of compemu_fpp.cpp has been added recently in commit bfa128f by Thorsten. 

So I’m wondering where those constants CW_DEF should be defined and what options I would have to use for building?

The MacAranym JIT build currently uses the following configure options:

--with-classicconfig --enable-ctrlkey=ctrl --enable-bpf-ethernet --enable-full-debug --enable-fullhistory --enable-nfosmesa --enable-fpe=ieee --enable-jit-compiler --enable-jit-fpu 

Either the FPE mode or the JIT FPU seems to be misconfigured. 

So I’m wondering what would be a valid setup for an x86_64 Jit build (with best FPU precision)?

Is there somewhere an overview available what the currently best build configurations are for the current builds?

Best regards

Philipp

[Thorsten Otto]

On Freitag, 17. Januar 2025 16:27:09 CET 'Philipp Donzé' via ARAnyM wrote:

> It seems that this part (lines 113ff) of compemu_fpp.cpp has been added

> recently in commit bfa128f by Thorsten.

Oops, yes. The code that i added is only valid for x86, and needs to be ifdef'd. Simplest way would be to use the previous code.

But also note the bug that this fixes. The code sequence is mentioned in the commit. Basically what happened was: when rounding a float to int, the compiler emitted code to change the rounding mode in the FPU ctrl word for the move. The old JIT generated code did not take that into account, and the change was there to update the x86 fpu control word accordingly. Can you find a way to do the same for ARM?

[Philipp Donzé]

Hi Thorsten

I was not looking into Jit for ARM… as far as I know we never got that working for MacAranym.

The aranym JIT I try to compile is for x86 (64 bit only, as Apple dropped 32 bit long ago).

I suppose my FPE engine is not the correct one. Can you tell me your „./configure" call for which works with that code?

As written before MacAranym JIT tries to configure with the following options:

--with-classicconfig --enable-ctrlkey=ctrl --enable-bpf-ethernet --enable-full-debug --enable-fullhistory \

--enable-nfosmesa --enable-fpe=ieee --enable-jit-compiler --enable-jit-fpu 

Kind regards

Philipp

--
You received this message because you are subscribed to the Google Groups "ARAnyM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aranym+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/aranym/2043141.zToM8qfIzz%40earendil.

[Thorsten Otto]

On Freitag, 17. Januar 2025 18:30:41 CET Philipp Donzé wrote:

> I suppose my FPE engine is not the correct one.  for ARM?

CW_X is defined in fpu/core.h, but only for

#if defined(FPU_X86)    || (defined(FPU_UAE) && defined(USE_X87_ASSEMBLY)) ||(defined(FPU_IEEE) && defined(USE_X87_ASSEMBLY))

> Can you tell me your „./configure" call for which works with that code?

--prefix=/usr --disable-sdl2 --enable-jit-compiler --enable-jit-fpu

$ aranym --version

ARAnyM 1.1.0 2024/12/30 (git:24727611)

Using config file: '/home/sebilla/.aranym/config'

Configuration:

SDL (compiled)   : 1.2.64

SDL (linked)     : 1.2.64

CPU JIT compiler : enabled (active)

FPU JIT compiler : enabled (active)

Addressing mode  : fixed (0x41000000; default: 0x51000000)

Memory check     : sseg

Full MMU         : disabled

FPU              : IEEE

DSP              : enabled

DSP disassembler : disabled

OpenGL support   : enabled

Native features  : audio bootstrap xhdi ethernet hostfs cdrom(linux,sdl) scsi jpeg vdi(opengl,sw) exec config

So thats a bit strange, since IEEE should be the default for that configuration. Could it be that --enable-full-debug causes USE_X87_ASSEMBLY to not be defined?

[Philipp Donzé]

> On Freitag, 17. Januar 2025 18:30:41 CET Philipp Donzé wrote:
> > I suppose my FPE engine is not the correct one. for ARM?
>
> CW_X is defined in fpu/core.h, but only for
>
> #if defined(FPU_X86) || (defined(FPU_UAE) && defined(USE_X87_ASSEMBLY)) ||(defined(FPU_IEEE) && defined(USE_X87_ASSEMBLY))

I see now the relevant constants too. Thanks for point it out.

> > Can you tell me your „./configure" call for which works with that code?
>
> --prefix=/usr --disable-sdl2 --enable-jit-compiler --enable-jit-fpu

I tried it… it didn’t work with "--with-classicconfig --enable-ctrlkey=ctrl --enable-bpf-ethernet --enable-nfosmesa --enable-jit-compiler --enable-jit-fpu"
See below for the details.

> So thats a bit strange, since IEEE should be the default for that configuration. Could it be that --enable-full-debug causes USE_X87_ASSEMBLY to not be defined?

You are right. This constant is not defined here… It seems to be related to the compiler on macOS and or the platform I’m building from: llvm on ARM64, but targeting x86_64.

I see in configure output that "long double size“ is 8.
In core.h USE_X87_ASSEMBLY is set to 1 only if "long double precision is requested“ which means size must be 12 or 16 (in types.h).

So it seems that I cannot enable this feature with my Mac… real cross-compilation of aranym seems not yet supported or I simply do not know how to trigger it properly




From configure:
…
checking size of short… 2
checking size of int... 4
checking size of long... 8
checking size of long long... 8
checking size of float... 4
checking size of double... 8
checking size of long double... 8
checking size of void *... 8
...




——
SDL version ................... ........ : 2.28.1
SDL static .................... ........ : no
Use exclusive spcflags handling ........ : yes
Use JIT compiler ....................... : yes
Use JIT compiler for FPU instructions .. : yes
JIT debug mode ......................... : no
Floating-Point emulation core .......... : IEEE fpu core
Assembly optimizations ................. : x86-64
Addressing mode ........................ : fixed (0x51000000)
Full MMU support ....................... : no
Linux /dev/rtc source timer ............ : no
Real STOP implementation ............... : yes
DSP 56001 support ...................... : yes
DSP 56001 disassembly support .......... : no
Debugger ............................... : no
Check memory ........................... : sseg
First 2kB of RAM Supervisor protected... : yes
FastRAM fixed size ..................... : no
Fixed position of VideoRAM ............. : no
Blitter memmove acceleration ........... : no
Blitter SDL blit acceleration .......... : no
Support for hostfs ..................... : yes
Support for ethernet ................... : yes
GUI .................................... : yes
OpenGL ................................. : yes
Linux-m68k loader ...................... : no
NetBSD-m68k loader ..................... : no
Zlib ................................... : not required
libusb-1.0.............................. : no
NatFeat CD-ROM driver .................. : no
NatFeat PCI driver ..................... : no
NatFeat USB driver ..................... : no
NatFeat OSMesa driver .................. : yes
NatFeat JPEG decoder ................... : yes
NatFeat Clipboard ...................... : yes
NatFeat VDI driver ..................... : yes
NatFeat SCSI driver .................... : no
NatFeat host exec driver ............... : yes
NatFeat configuration .................. : yes
Exception per second limiter ........... : no
Linux/X86 h/w access for parallel port.. : no
Linux /dev/parport for parallel port.... : no
Unix /dev/ttySn for serial port......... : yes
Use C++ exceptions for m68k exceptions.. : no

[Philipp Donzé]

Hi again 

While analysing and writing about the problem (clang has a long double size of 8), I learnt about the fact that this is more of a platform and not a compiler property…

So I was wondering if I can „cheat“ by ensuring that the Intel build clang binary is executed while the „configure“ step is running.

I simply had to ensure that the correct compiler/architecture is used. 

In the end it was not that difficult: specifying the architecture using CFLAGS while running configure, solved the problem. 

Now MacAranym Jit x86_64 compiles again and is using the proper data types:

checking size of long double... 16

… it is building, but nevertheless it is not running on my ARM based Mac.

If anybody wants to test it on an Intel Mac: a (signed) build can be grabbed here

 https://github.com/pd95/aranym/actions/runs/12837980708/artifacts/2449621189

Kind regards

Philipp

--
You received this message because you are subscribed to the Google Groups "ARAnyM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aranym+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/aranym/ADDEFA66-E1C3-4229-9548-EFFE19CA4095%40gmx.ch.

[Francois LE COAT]

Hi,

Philipp Donzé writes:

If anybody wants to test it on an Intel Mac: a (signed) build can be grabbed here

 https://github.com/pd95/aranym/actions/runs/12837980708/artifacts/2449621189

Kind regards

Philipp

This bookmark produces an ERROR 404. Can you please propose another way to download the binaries ?

Thanks,

Best regards,

--
François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
https://eureka.atari.org/

[Philipp Donzé]

Hi François

Philipp Donzé writes:

If anybody wants to test it on an Intel Mac: a (signed) build can be grabbed here

 https://github.com/pd95/aranym/actions/runs/12837980708/artifacts/2449621189

Kind regards

Philipp

This bookmark produces an ERROR 404. Can you please propose another way to download the binaries ?

I’m not sure, but you would have to be logged in to GitHub to see the binary probably… 

But now I’ve created a „Development Snapshot“ with a build at

https://github.com/pd95/aranym/releases/tag/DEV_SNAPSHOT-2025-01-28

Please try to download it from the releases page.

Kind regards 

Philipp

[Francois LE COAT]

Hi,
Happy New Year 2025!

I'm sorry, but I can't find the snapshot binaries in this GitHub WEB
page. Can you please give a direct download link to ARAnyM snapshot?

Many thanks,

[Francois LE COAT]

Hi Philipp,

As you can see in the attached "philipp.mp4" screenmovie, the ARAnyM snapshot runs perfectly under macOS Catalina, with my 16" MacBook Pro Intel.

I hope this helps,

[Francois LE COAT]

Hi,

Francois LE COAT wrote:
> Philipp Donzé writes:
>>>> If anybody wants to test it on an Intel Mac: a (signed) build can be
>>>> grabbed here
>>>> https://github.com/pd95/aranym/actions/runs/12837980708/artifacts/2449621189
>>>>

>>> This bookmark produces an ERROR 404. Can you please propose another
>>> way to download the binaries ?
>>
>> I’m not sure, but you would have to be logged in to GitHub to see the
>> binary probably…
>> But now I’ve created a „Development Snapshot“ with a build at
>> https://github.com/pd95/aranym/releases/tag/DEV_SNAPSHOT-2025-01-28
>>
>> Please try to download it from the releases page.
>

> I'm sorry, but I can't find the snapshot binaries in this GitHub WEB
> page. Can you please give a direct download link to ARAnyM snapshot?

For a macOS binary, it's not a good idea to download it from GitHub.
This has to do with Apple signature of the binary when downloading.

For instance, for the Hatari project, there's a repository at ...

<https://api.cirrus-ci.com/v1/artifact/github/hatari/hatari/xcode/hatari/hatari-snapshot.zip>

This is working. But the solution from the following page does not work.

<https://framagit.org/hatari/hatari/-/releases> nor
<https://framagit.org/hatari/releases>

It was better when you could download the ARAnyM snapshots at ...

<https://www.xn--donz-epa.ch/atari/software/macaranym/>

But the solution to download from GitHub is not working properly.

I hope it helps.

[Philipp Donzé]

Hi François

For a macOS binary, it's not a good idea to download it from GitHub.
This has to do with Apple signature of the binary when downloading.

This has nothing to do with GitHub vs „regular website". It’s about „signing" the package.

I have setup my Github build pipeline in a way that the package is automatically signed at the end of the process. 

In the end the Github releases on my website are identical to what I upload to my website.

The build script is part of my „main“ branch and uses my personal "development team“ ID and build certificate from Apple.

On lines 70 to 72 the built DMG file is sent to Apple for notarization and when successful, the confirmation „Apple has inspected the package for malicious software" is stapled onto the package, so macOS will trust the package when opening it.

It was better when you could download the ARAnyM snapshots at ...

<https://www.xn--donz-epa.ch/atari/software/macaranym/>

Yes, beside updating code I had to maintain a website :-)… 

Completely unnecessary work if you ask me. I’m more of a software engineer which fixes/automates stuff than a „maintainer“.

Doing repetitive work is not much fun.

But the solution to download from GitHub is not working properly.

The Github solution works for people using regular/common browsers and systems.

Same thing for MacAranym: The package I’m building is called „MacAranym-Latest“ because I don’t want to restrict myself in upgrading to latest versions. 

Time is progressing constantly and new hardware and software is regularly released by Apple. 

When something needs updating, I don’t care about maintaining compatibility to older systems. (The Aranym source code is already full of „compatibility“ code for many different OS and CPU architectures… which makes it difficult in building it.)

The „Latest“ postfix in the project „MacAranym-Latest“ means that it requires a „recent“ computer and macOS version. 

Basically we could, if there was a need, cut off Intel support, since 4 years ago Apple has moved away from building Macs with Intel processors. It would reduce the file size for most users!

Kind regards

Philipp

[Francois LE COAT]

Hi Philipp,

Philipp Donzé wrote:

It was better when you could download the ARAnyM snapshots at ...

<https://www.xn--donz-epa.ch/atari/software/macaranym/>

Yes, beside updating code I had to maintain a website :-)… 

Completely unnecessary work if you ask me. I’m more of a software engineer which fixes/automates stuff than a „maintainer“.

Doing repetitive work is not much fun.

I'm a bit desapointed...  Can you then please send me the "ARAnyM snapshot.dmg" by email, if it's not too big?

I need it to maintain the ARAnyM miniPack at <https://eureka.atari.org/miniPack.zip> but I can't download it from GitHub, I'm really sorry.

I try to maintain my ATARI WEB site up to date. I think that it's one of the oldest, since March 1996. The ARAnyM miniPack is popular.

Many thanks,

[Chris Ridd]

I think you've touched on a few interesting points Philipp.

The ARAnyM project is kind of a mess.

• docs are awful - and this is a wiki so it should be easy to maintain!
• code is full of technical debt, aka "compatibility code"
• still support ancient dependencies; now that SDL 3 is out, SDL 2 is dying, and SDL 1 is really dead.
• lack of good support for modern hardware, and I'm mostly thinking ARM CPUs here.
• hard to build on macOS, apart from Philipp's fork. Not sure if those changes are in main yet?
• maybe there are other issues on other platforms?

I think there needs to be an effort at modernising things with the goal of making it easy for developers to maintain.

• removing technical debt
  
• upgrade to SDL 3
• replace the old MacOS Xcode project with Philipp's. (Or ditch it for cmake?)

If support is needed for platforms/environments that nobody can easily build for any more, then create a legacy branch of that old code in git and hope that someone is interested in maintaining it.

If there are issues in SDL 2 or SDL 3, then raise bugs with the upstream project and (ideally) help them fix them.

--
You received this message because you are subscribed to the Google Groups "ARAnyM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aranym+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/aranym/3B0BF0D2-AB39-401E-9781-5EC0533E26B0%40gmx.ch.

[Thorsten Otto]

On Freitag, 14. Februar 2025 19:24:45 CET Chris Ridd wrote:

> The ARAnyM project is kind of a mess.

I could take this as a personal attack.

>docs are awful - and this is a wiki so it should be easy to maintain!

This is opensource. Feel free to post patches.

> code is full of technical debt, aka "compatibility code"

What do you mean by this?

>still support ancient dependencies; now that SDL 3 is out, SDL 2 is dying, and SDL 1 is really dead.

Not all users run aranym on hardware from last year. For me, SDL1 still works best. SDL2 (and upcoming SDL3) does not really offer anything useful for ARAnyMs purpose. Quite the contrary, some functionality (like CDROM access) has been removed.

>lack of good support for modern hardware, and I'm mostly thinking ARM CPUs here.

I don't have any ARM hardware, nor do i have enough knowledge to maintain that part. Previous maintainers are still around, but lost interest or have other priorities.

>hard to build on macOS, apart from Philipp's fork.

That's apple's fault. ARAnyM is supposed to work on quite old hardware which is still in use by some users. That means it must support MacOS 10.6 atleast. OTOH, current Xcode can neither be installed on such machines, nor generate code for them. So what do you expect? That i have about 10-20 Macs around to be able to build for all os releases, just because Apple decides that each update means it is incompatible to previous versions? Not that i like windows much, but they did a much better job in this regard. I still have exes around that run without modificaton on all systems from Windows12 back to Win32s from 1998.

Not to mention that i would have to pay around $1000 a year just to be able to sign packages, of an opensource project.

[Chris Ridd]

> I could take this as a personal attack.

It certainly wasn't meant to be a personal attack. I apologise if you felt it was.

> That's apple's fault. ARAnyM is supposed to work on quite old hardware which is still in use by some users

It doesn't matter if this is Apple's fault or not.

But if nobody can easily build for that old hardware, those users might have to be satisfied with not using the latest MacAranym, eg something built from an older branch. Or just leave them at some final build for their hardware/OS? Calibre (ebook library software) uses the latter approach, and that seems to work.

> Not to mention that i would have to pay around $1000 a year just to be able to sign packages, of an opensource project.

Googling suggests this is not at all correct; it is $99 annually for an individual, but there are ways to get it for free. Phillip's the best person to answer this accurately. But this is not IMO a showstopper - if nobody can notarise official builds, so be it.

I did write a bunch of docs a while ago. They may not be correct any more, but I'll raise a pull request.

--
You received this message because you are subscribed to the Google Groups "ARAnyM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aranym+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/aranym/7680400.A5hrfCrGMc%40earendil.

[Mark Duckworth]

On 2/14/25 2:06 PM, 'Thorsten Otto' via ARAnyM wrote:

>still support ancient dependencies; now that SDL 3 is out, SDL 2 is dying, and SDL 1 is really dead.

Not all users run aranym on hardware from last year. For me, SDL1 still works best. SDL2 (and upcoming SDL3) does not really offer anything useful for ARAnyMs purpose. Quite the contrary, some functionality (like CDROM access) has been removed.

SDL2 just doesn't work for me at all...  As to the rest, yeah it's an open source project and nobody is going to reject good PR's. 

Thanks,

Mark

[Francois LE COAT]

Hi,

Philipp Donzé wrote:

> François Le Coat writes:
>> But the solution to download from GitHub is not working properly.
>
> The Github solution works for people using regular/common browsers and
> systems.

No it's not. I'm using FireFox 115.20.0esr (64 bits) under macOS Mojave.

Here is a post exchanged with Chris Ridd <chri...@mac.com>
______________________________________________

Francois LE COAT wrote:
> In the current situation I have a lot of difficulties with the binaries.
> Can you test *ARAnyM miniPack* <https://eureka.atari.org/miniPack.zip>
> I hope that it runs correctly, but I'm not sure at all. Because the
> binary was downloaded on GitHub, and there's issues with signature...

It fails to open because it isn't notarised. The alert looks like:

"MacAranym" Not Opened

Apple could not verify "MacAranym" is free of malware that may harm your
Mac or compromise your privacy.

[Done] [Move to Bin]

If you hit Done, you can go to System Settings > Privacy and Security >
it has a button at the bottom letting you "Open Anyway".

It looks like it is signed OK, but the notarisation hasn't been attached
("stapled" in codesign terminology) to the app. Here's the output of
codesign against MacAranym.app and Sigil.app (which is a correctly
notarised and opensource app)

$ codesign -dvvv MacAranym.app
Executable=/Users/cjr/Downloads/miniPack
2/MacAranym.app/Contents/MacOS/MacAranym
Identifier=org.aranym.MacAranym.aranym
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=29383 flags=0x10000(runtime) hashes=907+7
location=embedded
Hash type=sha256 size=32
CandidateCDHash sha256=2a4c13f1f6d1fa12f51b2623de564e41865de240
CandidateCDHashFull
sha256=2a4c13f1f6d1fa12f51b2623de564e41865de2409cf06649a29bac2c662a8717
Hash choices=sha256
CMSDigest=2a4c13f1f6d1fa12f51b2623de564e41865de2409cf06649a29bac2c662a8717
CMSDigestType=2
CDHash=2a4c13f1f6d1fa12f51b2623de564e41865de240
Signature size=8977
Authority=Developer ID Application: Philipp Donze (P8CC95REUG)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=17 Jan 2025 at 22:40:46
Info.plist entries=27
TeamIdentifier=P8CC95REUG
Runtime Version=14.5.0
Sealed Resources version=2 rules=13 files=7
Internal requirements count=1 size=220

$ codesign -dvvv /Applications/Sigil.app
Executable=/Applications/Sigil.app/Contents/MacOS/Sigil
Identifier=com.sigil-ebook.Sigil.app
Format=app bundle with Mach-O thin (arm64)
CodeDirectory v=20500 size=67717 flags=0x10000(runtime) hashes=2105+7
location=embedded
Hash type=sha256 size=32
CandidateCDHash sha256=12161a2aa64d527d73f95367a1788ae6bdbb44f2
CandidateCDHashFull
sha256=12161a2aa64d527d73f95367a1788ae6bdbb44f2bc4c59b3a8a466575f913717
Hash choices=sha256
CMSDigest=12161a2aa64d527d73f95367a1788ae6bdbb44f2bc4c59b3a8a466575f913717
CMSDigestType=2
CDHash=12161a2aa64d527d73f95367a1788ae6bdbb44f2
Signature size=8979
Authority=Developer ID Application: Kevin Hendricks (2SMCVQU3CJ)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=31 Jan 2025 at 16:00:58
Notarization Ticket=stapled
Info.plist entries=17
TeamIdentifier=2SMCVQU3CJ
Runtime Version=14.5.0
Sealed Resources version=2 rules=13 files=374
Internal requirements count=1 size=188


--
Chris
______________________________________________

Philipp you should either send the ARAnyM snapshot by email, or upload
it to your site <https://www.xn--donz-epa.ch/atari/software/macaranym/>
All was working great since you decided to use GitHub for binaries...

I'm ever so sorry, but you're wrong! And download on GitHub doesn't work

I hope it helps.

Regards,

[Philipp Donzé]

Hi François

Look carefully at Chris‘ analysis. He is perfectly right and has all the findings in it:

1. All my binaries are signed with my developer certificate.
2. Only the diskimage (DMG) is notarized by Apple. (=inspected and searched for malware by Apple)

This is how I‘ve done it since I am releasing signed builds, since „modern“ macOS started to alert the user if the downloaded software/package may be risky to execute.

If your „repackaging process“ somehow breaks this notarization (which in my opinion it should, as Apple has not inspected your package for malware, which is a combination of binaries from dubious sources :-D), it must have been a change in how you download it or copy the binaries. 

To be honest I wonder how it would have ever worked properly. Can you please send me a link to a version which worked in the past for users of modern macOS, so I can inspect the binaries?

There is nothing really special about how the disk image is build and hosted on GitHub (I used the same commands to notarize them when I did the steps manually). 

It’s finally just a file hidden behind some JavaScript which makes your „browsers“ choke. But in the end it’s HTTP GET of a specific URL. 

And no it’s not because of Microsoft… time goes on! We are past Atari vs Amiga, Atari vs PC or Mac vs PC times! They all have/had their purpose and place in computer history.

If you want to blame anybody then you should pick Apple because they want to make their macOS environment secure and save to use for the basic user! For the basic user there is no need for a repackaged version of a binary. The basic user wants a trust worthy site to download too!

** this part has been deleted, as it would not bring the discussion any further **

Kind regards

Philipp

Von meinem iPhone gesendet

Am 16.02.2025 um 21:05 schrieb Francois LE COAT <lec...@gmail.com>:

Hi,

--
You received this message because you are subscribed to the Google Groups "ARAnyM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aranym+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/aranym/83ddfccc-8df4-0bb2-02c8-f5ba494ee1b6%40gmail.com.