@silvermoon82 @eris2cats @kami_kadse @mewsleah there’s even multiple different ways to get an mksh.exe if you’re so inclined:

• OS/2 is natively supported, build it with EMX/kLibc or get the binaries from komh
  • note komh adds the -T build option which makes it (permissively) use CRLF line endings, but you can also leave it out and run with LF line endings, and that’s the mode upstream supports
• there’s a port of mksh R39 (old) to native WinAPI, which is usable if you must, but really only if you must
  • uses shm for fork emulation, which likely has security implications, don’t run elevated
• for NT, if you have Interix/SFU/SUA, you can build current (R59c or (preferably) CVS HEAD aka just before R60) mksh there and add the .exe suffix so it can be called from Win32 programs; this works very very well
• for Windows, otherwise you can build one with Cygwin/MSYS2, AT&T UWIN, PW32, and probably other frameworks like this
  • use if you must
  • in that case prefer Cygwin/MSYS2 if that can match your environment, they work very well
  • UWIN mostly works
  • PW32 does not really work well
  • likely works worse on DOS-based Windows than on NT
• if you have real WSL, you probably can link/copy mksh to mksh.exe like with Interix; this will likely work well
• if you have WSL2, you have a badly done Linux VM with minor integration, and renaming is cosmetic *shrug* it’ll work no problem