Linux

I've never used the software package in question.

If you already own the software, and if the hardware it uses to talk to the microcontroller is on a serial port or USB-attached serial port, then you can most-likely just run it under WINE. This isn't a VM, but a Windows compatibility layer

you don't need to run a copy of Windows in a VM and all that. It'd be my first shot. That way, you can just use it like any other Linux program, don't need to blow extra memory or overhead on running Windows in a VM.

So, say the program in question has an installer, picbasic-installer.exe.

So you're going to want to install WINE. I don't use Arch, so I'll leave that up to you, but I believe that the Arch package manager is pacman. They may have some graphical frontend that you prefer to use.

Then go ahead and, in a virtual terminal program, invoke picbasic-installer.exe

assuming that that's what the installer is called

under WINE:

$ wine picbasic-installer.exe

That'll run the installer.

Now, my guess is that that much won't have problems. And that WINE will run the thing. And it'll probably let you compile BASIC programs.

You can go ahead and fire up your PICBASIC PRO program. I don't know how you launch Windows programs in your Arch environment. In general, WINE installers will drop a .desktop file under ~/.local/share/applications, and that can be started the way any other application can. I use a launcher program, tofi, to start programs like that under sway using tofi-drun, but you probably have a completely different environment set up. My guess is that your desktop environment on Arch probably has some kind of system menu of applications or something like that that will include WINE programs with a desktop file in it. Or maybe you have some program that shows a searchable list of programs and can launch from that. KDE Plasma, GNOME, Cinnamon, etc will probably all have their own routes, but I don't use those, so I can't tell you what they do. I'll leave that up to you.

What you're likely to run into problems with is that if the PICBASIC PRO program wants to talk to that microcontroller programmer via a serial port (which on Windows would probably be COM0 or COM1 or whatever), it's going to need to talk to /dev/ttyS0 or /dev/ttyS1 or whatever on Linux, or if it's a USB-attached, /dev/ttyUSB0, /dev/ttyUSB1, etc. Ordinary users probably don't have permission to write directly to them, by default.

There are a couple ways to grant permission, but one of the most-straightforward ways is to add your user to a group that has permission.

The basic Unix file permission system has each file

including device files, like /dev/ttyS0

owned by one user and one group.

On my Debian trixie system:

$ ls -l /dev/ttyS0
crw-rw---- 1 root dialout 4, 64 Jan 15 20:46 /dev/ttyS0
$

So that serial port device file is owned by the user root, which has read and write privileges (the first "rw") and the group dialout, which has read and write privileges (the second "rw"). Any user that belongs to that group will be able to write to the serial ports.

On my system, my user doesn't belong to the "dialout" group:

$  groups
tal cdrom floppy sudo audio dip video plugdev users render netdev bluetooth lpadmin scanner docker libvirt ollama systemd-journal
$

So I'm going to want to add my user to that group:

$ sudo usermod -aG dialout tal
$

Group permissions get assigned to processes when you log in (that is, usermod just sets what groups the process started when you log in as has, and then all its child processes). Technically, you don't have to log out to do this

you could run sg dialout at this point, and then from that shell, run wine and see if it works

but I'd probably log out and then back in again, to keep things simplest. After you do that, you should see that you're in the "dialout" group:

$ groups
night_petal <list of groups> dialout
$

After that, you should be able to use the program and write code to the microcontroller.