The email and ftp programs aren't relevant anymore so support for them was removed from the cc65 builds. The explicit 80 column programs were added. The 80 colum web browser and Telnet server are built for all cc65 platforms as they are the largest and as such show best code increase issues.
Recently support for 80 column CONIO based on 320x200 graphics was added to the cc65 C library for the C64. This change leverages this for the IRC client and the web browser. Because not everybody prefers this 'soft80' display with its small 4x8 charbox the 40 column programs are still available as before (with the new programs called 'irc80' and 'webbrowser80').
So far 80 column display was an attribute of a cc65 platform. Now each cc65 application can ask for 80 column display by defining WITH_80COL. Of course this is ignored by platforms incapable of 80 column display.
I see three types of application:
* Applications not benefitting from 80 column at all and in fact looking better with 40 column display. These are now using 40 column display. Examples: ethconfig, ipconfig
* Applications taking advantage of 80 column display if it is available without drawbacks. These stay as they were. Examples: Telnet server, web server, wget
* Applications needing 80 column display so urgently that it is likely desirable even if the display becomes harder to read. These come now in both flavors allowing the user to choose. Examples: IRC, web browser
Note: This change doesn't actually introduce any 80 column display with drawbacks. This if left to a subsequent change.
The cc65 memory map for the ATARI XL has two holes so the linker needs hints which object files go where. Source changes lead to object file size changes requiring now and then to rearrange the object files.
Using clang (on osx) yields to some warnings
(conversion between signed/unsigned, unused variable)
which gcc would only produce when used with -Wall.
This commit fixes those.
In these cases data was set as `process_post_synch(window->owner, ctk_signal_keypress, (process_data_t)(size_t)c);` so it seems reasonable to cast "back" to `size_t`. Additionally the comparison can be limited to `char`. See i.e. calcc for reference:
```
if(ev == ctk_signal_keypress) {
if((char)(size_t)data >= '0' &&
(char)(size_t)data <= '9') {
```
