On Mon, 2 Jan 2023 09:14:03 -0600 Dean Berglund deanberg2044@gmail.com wrote:
Tony, you are correct although just because Microsoft doesn't support Windows 7 doesn't mean a program can't still work on Windows 7.
Likely the limiting factor is, the runtime environment Chirp runs on: Python. And given how much of a royal pain in the arse it is to support Microsoft Windows in any capacity compared to POSIX-like OSes such as Linux and MacOS X, I can understand why.
Serial ports are a nightmare to support under Windows. Anything Unix like, gives you a "standard" interface built around file descriptors with a common API for reading, writing, waiting for data, etc. Windows has one "special" API for network sockets and a second "special" API for serial ports.
Thus lots of special-case code has to be written "just" for Windows.
This is a platform that the manufacturers support by default. Windows users have _lots_ of options available for programming radio equipment. For some equipment, it's your ONLY option.
By comparison, Mac and Linux users often have only Chirp to turn to. (Some DMR radios can be programmed using `dmrconfig` -- I'm unaware of any other radio programming software packages for these OSes.)
Linux is a free download and can be run inside a virtual machine at no monetary cost to the end user beyond the Internet quota costs doing so. There is no legal impediment to doing this.
By contrast, people legally CANNOT USE Windows on a Linux-based desktop without purchasing a license from Microsoft -- and for a VM they expect you to pay top-dollar retail for it. And no, it is not a given that the computer came with Windows 10/11 -- especially if you build the machine from components.
If the Chirp project decided to re-instate support for Windows 7, that would mean having to run on an older release of Python such as Python 3.8 (which should work on Windows Vista and later). If people want Windows XP support, then we're stuck with Python 3.4. Python 3.4 does not support `async/await` features (introduced in 3.5, used by a lot of I/O libs) or type annotations (introduced in 3.6, gaining increasing use now too).
It's a big job to essentially fork old versions of underlying libraries and frameworks to support them yourself. Big enterprise pays big money for that sort of thing. I would suggest a virtual machine running an open-source OS is the easier and cheaper alternative.