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.
This patch updates the DNS resolver to support IPv6 and introduces an
improved API for looking up DNS entries. This patch also adds optional
support for mDNS lookups and responses to the DNS resolver.
Here is a quick summary of the changes:
* Added support for IPv6 lookups.
* DNS queries now honor record expiration.
* Added support for mDNS, compatible with "Bonjour".
* Implemented a new lookup api, `resolv_lookup2()`, which provides
more information about the state of the record(error, expired,
looking-up, etc.).
About mDNS/Bonjour Support
--------------------------
This patch adds basic support for mDNS/Bonjour, which allows you to
refer to the name of a device instead of its IP address. This is
incredibly convenient for IPv6 addresses because they tend to be very
long and difficult to remember. It is especially important for
link-local IPv6 addresses, since not all programs support the '%'
notation for indicating a network interface (required on systems with
more than one network interface to disambiguate).
In other words, instead of typing in this:
* `http://[fe80::58dc:d7ed:a644:628f%en1]/`
You can type this instead:
* `http://contiki.local/`
Huge improvement, no?
The convenience extends beyond that: this mechanism can be used for
nodes to talk to each other based on their human-readable names instead
of their IPv6 addresses. So instead of a switch on
`aaaa::58dc:d7ed:a644:628f` triggering an actuator on
`aaaa::ed26:19c1:4bd2:f95b`, `light-switch.local` can trigger the
actuator on `living-room-lights.local`.
What you need to do to be able to look up `.local` names on your
workstation depends on a few factors:
* Your machine needs to be able to send and receive multicast packets
to and from the LoWPAN. You can do this easily with the Jackdaw
firmware on an RZUSBStick. If you have a border router, you will need
it to bridge the mDNS multicast packets across the border.
* If you are using a Mac, you win. All Apple devices support mDNS
lookups.
* If you are using Windows, you can install Apple's Bonjour for Windows
package. (This may be already installed on your machine if you have
installed iTunes) After you install this you can easily do `.local`
lookups.
* If you are using a Unix machine, you can install Avahi.
The default hostname is set to `contiki.local.`. You can change the
hostname programmatically by calling `resolv_set_hostname()`. You can
change the default hostname by changing `CONTIKI_CONF_DEFAULT_HOSTNAME`.
You may disable mDNS support by setting `RESOLV_CONF_SUPPORTS_MDNS` to
`0`.
---------------------------------
core/net/resolv: `resolv_lookup2()` -> `resolv_lookup()`
Note that this patch should fix several `resolv_lookup()` bugs
that already existed. There were many cases where `resolv_lookup()`
was being called and the IP address ignored, but later code
assumed that the IP address had been fetched... ANYWAY, those
should be fixed now.
---------------------------------
examples/udp-ipv6: Updated client to use MDNS to lookup the server.
Also updated the Cooja regression test simulation.
On the C128 the custom PFS code doesn't add functionality (as it does with IDE64 support on the C64) but is "only" smaller than the POSIX file i/o code in the C library. But the stdio code in the C library (used in WGET for screen i/o) relies on the POSIX file i/o code anyway so there no point in additionally adding the PFS code to the WGET program.
