Drop Windows code in favor of WSL?

[alexsavulescu]

Opening this thread up for discussion.

Windows support and maintenance are time consuming. It would be ideal to rely on WSL and use the same Linux codebase (and wheels). By dropping Windows code we would greatly improve development aspects and CI robustness.

What would be the impediments ?

• are there any specific user requirements?
• are there any UX aspects to consider?
• are there any Windows-only models? couldn't they be "migrated" to linux?
• what are the benefits of maintaining "native" Windows support?
• are the Desktop scripts replaceable? (IMO yes)
  
• Could we automate WSL setup? (IMO yes)
• ...

[alexsavulescu]

Windows 11 comes in with direct GUI support via wslg, whereas for Windows 10 they are being shady about adding that support or not: microsoft/wslg#414

[alexsavulescu]

WSLg (GUI support) is also available in Windows10. See https://github.com/microsoft/wslg

[ramcdougal]

I see the advantages of this.

From the user-experience side, I want to raise:

• Providing a native Windows program means that regular e.g. Windows Anaconda Python will work with whatever other libraries they're using. Managing more than one Python can be confusing for users.
• Not all users have updated to Windows 11. Some, I'm told, still use 32-bit versions of Windows. (NEURON hasn't supported those in years, but it speaks to the long tail of technology.)
• Is there a path through WSL to know that we're inside Windows not regular Linux so that a future Interviews replacement could use a Windows-specific look-and-feel?
• Can we maintain compatibility for Windows tools built on top of NEURON, like HNN? Or would they have to be updated?
• When I teach, I have people run NEURON via cmd and then launch python. Can that be made to still work if we're using wsl? (Relatedly, consider the teaching use-case.)

For developers, this might be a one-way transformation because there are certain aspects where Linux and macOS allow us to be sloppy with data types, as basically all integers are 64 bits, but when working with Windows we have to be explicit about using a 64-bit type because the default long is only 32 bits.

[cstricker]

I have been using wsl and Neuron for about 5 years now, initially wsl1 and from about 2018 onwards wsl2. In fact, we have been using this arrangement to even successfully run student practicals with Neuron - rock solid. Because I also use this environment for development purposes on macOS via VMware fusion, I had to recently downgrade back to wsl1 (Fusion 12.2 is the issue...) - i.e. not using the newer wslg as that only works with wsl2. I am using VcXsrv instead - which over the years has served me very well and is well maintained. The easiest way (for me...) is to just do "everything" via the wsl terminal (ubuntu, in my case). I have not seen speed differences when testing against a win10-specific version - or there is no speed penalty for using wsl. There is if you script from the win side - but only when spawning a "terminal" window - that is particularly slow on wsl1 - reasonable on wsl2.

I am also regularly building from source via a script... works like a charm.

An advantage is that any wsl install comes with it's "standard" python install - but you can also install your python of choice - but you use it pretty much as a *NIX box... and not as a win box. I have made the transition to 64 bit win quite some time ago. I have tested this with win10 and win11 - and seen no difference. To interface with win applications, standard windows scripting does the trick. I have found that MS has bent backwards to have wsl conform to *NIX standards. In fact, I had to brush up a little when scripting ... as I got used to some shell specific idioms that are not quite "correct".

I am sure that with a few win "scripts" for the "standard" user (like creating . bashrc/.zshrc files with appropriate PATH statements), it would be possible to run nrniv straight from win - i.e. everything *NIX could be hidden if that was desirable. In fact, the "new" Windows terminal allows an easy way to use either the win or the wsl side.

Because it is possible to run Neuron via wsl on win, I think it is best now drop the Windows specific branch and concentrate the development effort on the several *NIX flavours. This is more efficient.

My few cents.