I developped TLALOC with gnat on Linux Ubuntu. I would be interested to have a statistics of OSes used by the community. Having some other OSes for TLALOC could be examined. Probably Windows would be next. I have no real sympathy for µsoft W but it is used by some 
…
I use:
- Windows 7 (32/64-bit),10,11 on x86
- Fedora armhf, aarch64, x86 (32/64-bit)
- Ubuntu armhf, aarch64, x86 (32/64-bit)
- CentOs x86 (32/64-bit)
- Arch x86 64-bit
- FreeBSD x86 64-bit
Windows is my major platform for developing. Others are mainly for testing. I do not think you should face any problems with Windows. It has more comprehensive (but awful) API than Linux. After all it was a kind of bastard of glorious VMS. Just do not try to use the Posix layer, go direct to the Wn32 API. Also Windows has the most stupid UTF-16 encoding, though that should be irrelevant for Ada 83..
My OS is Ubuntu 26.04 x86_64.
I personally use:
- EndeavourOS x86 64-bit
- Debian x86 64-bit
(used to use Windows 11 but made the full switch to linux previously)
Not sure if you already have a setup for testing TLALOC via CI. A start could be checking if the code builds/runs/tests pass on different distros/platforms (not going too into many individual architectures yet as it would get costly time wise).
Void Linux Musl on x86-64
FreeBSD on x86-64
OpenBSD on x86-64
Plan 9 on x86, x86-64, Arm32, Arm64.
Windows 11 in an x86-64 Virtual machine. I also have 2k/XP/7 VM’s as well and a 10 tablet that sees little use.
Most of all, I would like to see Ada on Plan 9 with the same portability as the native tooling where I change the objtype environment variable to the target architecture, e.g. power64 and target a big endian Power 64 machine.
edit: I’d also like to add that the Plan 9 fork I use, 9front, has no plans to drop 32 bit support as the abstractions are done so well that maintaining both is not difficult. In fact, the lead programmer (who writes high reliability aerospace c code for a living) says 32 bit helps shake out bugs you would not catch on 64 bit platforms.
1 Like
macOS 26.6.2, arm64.
The following:
- OpenSuse Tumbleweed on amd64
- macOS Tahoe on arm64
I commonly use Win7 and Win10; in my previous job I also used Solaris 9.
I heard VMS is having a resurgence, and about 2020 they finished porting to x86_64 — VMS would probably be the best one to really strengthen your system and test its robustness: it can run on VAX, Itanium, Alpha, and now x86_64 and (IIUC) you can have all of these architectures on-line interconnected together via clustering.
CI is essentially a solved problem as of the late 80s.
This paper details how to construct a VCS wherein the “root node” is the history of the project in a consistent/compilable state — all you have to do to include CI and Regression-tests is have those gate on the final “merge upward” test.
@VMo, if you are doing an APSE (as that other thread suggested), I would absolutely recommend that if you do a VCS you apply this paper’s structuring.
During Alire’s design, I advocated updating DIANA and using it, plus that paper, in order to make the entire system more robust (eg as a database, you could have a field for ‘license’ and allow search by compatible license; you could integrate an “interface checker” so that you could see if an update in a dependency would impact you code, etc).
1 Like
Hi.all !
Thank you a lot to all respondents for this interesting information. Updated statistics :
Mentions type version processor
1 Linux Fedora x86_64, arm64
2 Linux Ubuntu x86_64, arm64
1 Linux CentOs x86_64
1 Linux Arch x86_64
1 Linux Ubuntu 26.04 x86_64
1 Linux EndeavourOS x86_64
3 Linux Debian x86_64
1 Linux Void Linux x86_64
1 Linux OpenSuse Tumbleweed Leap x86_64
1 Linux Slackware64 15 x86_64
7 Windows Windows 7,10,11 x86_64
4 macOS 26.6.2, Tahoe, Sonoma arm64
1 FreeBSD x86_64
2 OpenBSD x86_64
1 Plan 9 9front x86_64, arm64
---------- S U M M A R Y ----------
13 Linux mainly x86 some arm
7 Windows x86
4 MacOS arm
4 Unix/Plan9 mainly x86
-----------------------------------
no risc-v64
So Linux on x86 come first. Then Windows, MacOS, BSD Unix and Plan 9. Nobody uses risc-v.
I wrote the codi_x86_64W.finc which allows producing PE32+ executables for Windows 64 with fasmg. It uses the kernel32 api. I obtained the compiler TLALOC.PE64 which executes with wine. No modification to the LLIR stack machine, only 15 system services calls in codi are adapted.
What would be funny is having a “bare metal” codi using UEFI so that the BOOT64.EFI PE32+ could launch it.
I think I will let MacOS version aside, it is a closed world with signature problems in Mach-O.
I set up a minimal Ren3000 Gen machine with 9front to have a closer look, that’s for hacking fun.
Windows 11 on x86_64
macOS Tahoe on arm64
openSuse Tumbleweed on x86_64
PC with Windows 11 64 bit
I’d love to try the old aztec rain god.
I use macOS, arm64, currently on Sonoma but I need to upgrade at some point.
Ubuntu 26.04, x86_64, GNAT
Windows 11 x86_64 virtual machine, ObjectAda
Arch on an old x86_64 (2009 I think) 
Hi.HF
What kind of Plan 9 do you use ? A modern 9front or an historical Bell Labs version ? What kind of processor would you prefer, x86 or arm ?
Today Debian x86 64-bit everywhere : laptops with XFCE, stations 43" 4K with XFCE, servers in DC with Xen and many virtual machines. Around 50 real machines or virtual ones.
Ubuntu was used on laptops and stations and then discontinued because 1) we can no longer remove Snap on the latest versions 2) performance was getting poor.
One very old mac (2012) not used theses days (was used for Ableton Live and Da Vinci Resolve).
Windows was vaporized almost 10 years ago in our company, for our greatest serenity.
Debian x86 64-bit testing
OpenBSD amd64 (x86_64)
OpenSUSE Leap 16 amd64 (x86_64)
Windows 11 amd64 (x86_64)
Devuan Excalibur amd64 (Debian Trixie without systemd x86_64)
9front. Though I’m curious how the platform abstractions will be handled. There’s are a lot of differences in Plan 9. The C language is different though largely c99 compatible. in-line assembly is not supported because it’s a bad idea for portability. Dynamic code is supported but purposefully avoided, you build servers instead. There’s also no use of ugly platform #ifdef nonsense. You split everything into platform specific files, assembler included.