Keyboard compatibility on Windows

[pg-cse]

It appears that Capua keyboard currently suffers a compatibility issue between Windows and Linux. The machine will work but CASM written to use the keyboard on Linux will not work on Windows. Reverse is also true.
I will look into a fix that attempts at respecting the following two criteria:

• Compatibility across OS
• Realism

Given the stated goal of Capua to enable students learn more about OS dev in classroom environment, I do think that compatibility is the key element here. Realism, at keyboard code input level, while pleasing would only be used for a somewhat limited (opinions may vary) part of creating an OS (core inner elements, not user experience). Therefore, I am willing to sacrifice realism in favour of compatibility. This is based on the need for teacher to be able to teach the same thing to students using various development platform.

If anyone has suggestions or different opinion that they would like to share, feel free to do so. There might be some elements that I have not thought about.

[cannotparse]

So I tried the changes proposed in #8 and #10 on Ubuntu with 3.6.5 with a simple program that prints to the terminal. I didn't notice any regressions introduced.

However, a simple workaround is to detect if the os is windows or Linux and switch between the two. Considering this would be in the Terminal.__init__(), it would be an appropriate place for the fix.

# Fix for issue #7 - windows compatibility 
if os.name == 'nt':
   self._data = b"\x20" * 0xFFF
else:
   self._data = b"\x00" * 0xFFF

Really depends on what other issues exist for windows and OSX.

[pg-cse]

Cannotparse (@cannotparse)
I might not fully understand but, this specific issue does not deal with display but with actual Keyboard through the TK interface. The pull requests referenced are for a display issue (also present on windows because of how TK apparently handles some non printable char differently across Linux and Windows).

This bug was reported by someone else and I simply filled the ticket for it.

Bottom line is, on Windows, the TK method that normally return some form of scan codes on Linux does not return the scan codes but rather directly ASCII code. This can be seen here:
https://github.com/CommunicationsSecurityEstablishment/spartacus/blob/159d5fe1bbef6e1b590b5fa9d57e5ef282779560/CapuaEnvironment/IOComponent/MemoryMappedDevices/Terminal/Terminal.py#L163

This means that as is, if someone is writing keyboard handling code on a windows host, the code has to be different if it runs on Linux. This is obviously not acceptable as behaviour needs to be consistent across hosts.

Did a quick search about this and I found this:
https://stackoverflow.com/questions/37887962/how-to-identify-non-printable-keypress-events-in-tkinter

So apparently codes are handled in a different way from platform to platform (OS level) and TK will not return the same code for "any platform" This is obviously not desirable for a learning environment. Therefore, this will need some attention in the near future.

[cannotparse]

I didn't look into how tk was handling it. I was assuming the fix proposed was valid. If that is the case, then I agree this will take some work.