Native windows port of c65

[patricksurry]

c65 does not compile natively on windows using the mingw compiler because select.h is a POSIX thing. We'd need a Windows specific version of io.c if we wanted it to work natively on Windows. WSL can be our recommended method for use under Windows.

gcc -o c65 c65.c io.c
io.c:6:10: fatal error: sys/select.h: No such file or directory
    6 | #include <sys/select.h>
      |          ^~~~~~~~~~~~~~
compilation terminated.
make: *** [c65] Error 1

[SamCoVT]

I think we can use getch() on Windows (from conio.h), which reads an ASCII character with no echo.

[SamCoVT]

#include <conio.h> appears to give access to non-standard getch() that gets a character (blocking) without echo. This should work nicely with TaliForth2 in the c65 simulator. The Makefile can look at the OS environment variable (will contain Windows_NT on Windows systems) to determine if c65 is named c65 or c65.exe - the command to generate either should be the same. In my testing, using -o c65 with gcc results in c65.exe on Windows. Should probably test to make sure this solution works with WSL as well.

[patricksurry]

if needed, could also check for WSL_... env vars to distinguish native from wsl on windows

[SamCoVT]

I'm hoping that WSL just reports as Linux and follows all of the Linux instructions. That's more of just a reminder to me to actually try it under WSL and make sure I didn't break it there. I only just recently started using WSL (used cygwin mostly, before that), so I'm not sure how well behaved it is when trying to deal with cross-platform stuff. Cygwin, for example, is generally very good about taking forward or back slashes in paths but has some gotchas.

[SamCoVT]

So I think I got it working (already merged into master-64tass) with the exception of git-bash on windows, but apparently that's a known issue and can be resolved with winpty in front of the command (eg. winpty make csim seems to work from git-bash).

I did find that make ctests does not work on Windows, even when editing talitest_c65.py to change the name of the executable from c65 to c65.exe. It hangs and I get the following error on CTRL-C:

TaliForth2> make ctests

make -C c65
make[1]: Entering directory `C:/Users/scc12260/projects/TaliForth2/c65'
gcc -o c65 c65.c io.c -D WINDOWS_NATIVE
make[1]: Leaving directory `C:/Users/scc12260/projects/TaliForth2/c65'
cd tests && py -3 ./talitest_c65.py
< CTRL-C PRESSED HERE >
Traceback (most recent call last):
  File "C:\Users\scc12260\projects\TaliForth2\tests\talitest_c65.py", line 94, in <module>
    (out, err) = process.communicate(test_string.encode('ascii'))
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Program Files\Python311\Lib\subprocess.py", line 1207, in communicate
    stdout, stderr = self._communicate(input, endtime, timeout)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Program Files\Python311\Lib\subprocess.py", line 1575, in _communicate
    self._stdin_write(input)
  File "C:\Program Files\Python311\Lib\subprocess.py", line 1154, in _stdin_write
    self.stdin.close()
KeyboardInterrupt
^CTerminate batch job (Y/N)? y
make: *** [ctests] Error 255

I'll leave this open while I investigate how difficult it is to get testing working, and if it's possible to detect when running in git-bash on windows vs cmd on windows.

Everything works under WSL, including make ctests.

[patricksurry]

cool!

could the hang be a line-ending thing, e.g. does it need \r\n instead of just \n for windows line buffering somewhere?

there's a universal_newlines option that sounds interesting https://docs.python.org/3/library/subprocess.html

[SamCoVT]

I thought it might be a newline thing as well, but it's actually that the git-bash window is not a real console and simply doesn't provide the console functions. Here's from their wiki: https://github.com/git-for-windows/git/wiki/FAQ#some-native-console-programs-dont-work-when-run-from-git-bash-how-to-fix-it

Their fix of using winpty to provide all of the console functions works with Tali2, and you need this for most interactive console programs. It might be worth adding a note for Windows users to let them know of that workaround, or they can use WSL or run it natively in CMD and no workaround is needed. This is really more of a git-bash issue/bug and I don't think there is a workaround for us other than documentation and using the git-supplied winpty program. I can't see a way to get an immediate character read with no echo otherwise.

I'll leave this open until I can update the docs.

[SamCoVT]

Also still need to figure out testing on windows. That might also be a stdin vs conio difference. A possible solution might be to add a (windows only) command line switch to use stdio functions instead of conio functions. That will require more digging, but I'm probably not going to have the time for a couple of weeks.