Jump to content


Member Since 24 Jul 2016
Offline Last Active Sep 28 2021 03:59 PM

Topics I've Started

On Upgrading CC: Tweaked to Lua 5.2

16 April 2021 - 11:13 PM

In the past few weeks I've been working on getting Cobalt, the Lua runtime for CC: Tweaked, updated for Lua 5.2. Even though most of the libraries are already in place, a few language features don't exist yet: the main ones being actual _ENV environments (not just the _ENV global placed in by CraftOS) and goto statements.

I finished porting Lua 5.2 last week, and it now passes all tests. Currently it is open as a pull request on the Cobalt repository. It also boots CraftOS successfully, and passes all tests in the CC: Tweaked test suite. I've set it up so that there are very few backwards-compatibility concerns: Lua 5.1 bytecode loading is retained, the old functions removed in 5.2 are still in place, and goto is still a valid name, only being used as a statement when it's used in the form "goto <name>".

However, there are concerns with backwards compatibility and how it makes the VM much more messy. Specifically, the 5.1 bytecode loader has a lot of duplicate code, and keeping it in place may hinder maintaining the VM. I can easily remove 5.1 bytecode, but at that point I'd likely remove the old Lua 5.1 functions as well. These can be reimplemented on the Lua side in CC:T. But then there's also the idea of making the long-standing disable_lua51_features config option set to true by default, which could break programs that use the old functions.

In short: how important are the Lua 5.1 features that would be removed in 5.2? I see three different scenarios for how to do this:
  • Ke ep it all as-is, allowing loading 5.1 bytecode and using 5.1 functions (implemented in Java)
  • Remove 5.1 bytecode support, but keep 5.1 functions (recreated in the BIOS) available by default (loadstring, setfenv, getfenv, math.log10, table.maxn)
  • Remo ve all 5.1 support by default, and have the old functions available by disabling "disable_lua51_features"
I doubt breaking bytecode loading has any real effect on most things, but there may be a few programs that rely on it. I'm much more concerned about removing old functions, as I've seen plenty of normal programs using them. In fact, a lot of my more complex things use setfenv/getfenv extensively. Luckily, I'd guess most of the incompatibilities would come from loadstring being missing, and that can easily be replaced with load. However, I'd like to hear from the community on what the best strategy is.

Feel free to leave your comments either on this post, or on the pull request. I'm open to other suggestions as well, so if you have an alternative strategy on this I'm happy to hear it.

VeriCode - Easy code signing for ComputerCraft

20 February 2021 - 11:34 PM

After seeing a number of people running raw code received over Rednet, I decided to make a code signing library that attempts to make it easy enough to add code signing that a beginner could do it. Introducing VeriCode, a simple library that allows you to sign, send, receive, and verify Lua scripts over Rednet or on disk. All that's required is to generate a keypair, add the public key to the client computer(s), load the key files, and then send/receive just like through the normal rednet API. You can also use the plain dump/load functions to use your own destination, such as a file. A simple receiver can be written in as few as three lines. The functions provided are very simple, and most of them mirror pre-existing function syntax to keep the entry barrier low. More instructions documentation, and an example are available in the source code. You can get it at https://gist.github....a028abd615e8750 (or for Pastebin plebs, it's at Ptq5vRvp + ZGJGBJdg as ecc.lua). (Requires CC:T 1.91.0 or later.)

Do note that there are no mechanisms to avoid replay attacks at the moment, so attackers could re-send messages that are listened to. If this is a concern, I'd recommend handling that in your own send/receive functions.

CraftOSOS: ComputerCraft as a real desktop OS

13 November 2020 - 10:49 PM

A few months ago I released CraftOS-EFI, a ComputerCraft emulator that ran as a UEFI application. I've gotten requests to make it into a real operating system instead of an EFI app, and I finally found a way to do this without having to write my own libc. Introducing CraftOSOS, a full ComputerCraft 1.80pr1 operating system for x86 PCs.
Posted Image
CraftOSOS is based off of the code from CraftOS-EFI, but instead runs under its own microkernel, and directly interfaces with the system's hardware. It uses the standard VGA 16-color 640x480 mode to draw a full graphical terminal, using the real ComputerCraft font. It also properly supports file and directory I/O, meaning you can list directories as usual. It can be booted from any multiboot-compatible bootloader such as GRUB.

As of version 0.1, CraftOSOS requires the following setup to function properly:
  • x86-64 PC or virtual machine
  • 32 MB RAM
  • Monitor and video card that support 16-color 640x480 VGA (this should be standard)
  • PIIX3 IDE interface for storage, or SATA in ATA emulation mode
    • All ROM files must be on the first partition of the primary master drive, formatted as FAT
    • 20 MB should be enough space to fit everything (GRUB, chainloader, kernel, ROM)
  • PS/2 keyboard, or a BIOS that supports PS/2 emulation for USB
  • For debug messages, a serial port is required
It is recommended that you run CraftOSOS in QEMU, as this is where it has been tested the most. Instructions for doing so are in the readme.

You can download the latest version of CraftOSOS on GitHub, or you can browse the source online.