Help Propel The Original ARM OS Into The Future

March 30, 2025 by Jenny List 33 Comments

We use ARM devices in everything from our microcontroller projects to our laptops, and many of us are aware of the architecture’s humble beginnings in a 1980s Acorn Archimedes computer. ARM processors are not the only survivor from the Archimedes though, its operating system has made it through the decades as well.

RISC OS is a general purpose desktop operating system for ARM platforms that remains useful in 2025, as well as extremely accessible due to a Raspberry Pi port. No software can stand still though, and if RISC OS is to remain relevant it must move with the times. Thus RISC OS Open, the company behind its development, have launched what they call a Moonshots Initiative, moving the OS away from incremental development towards much bolder steps. This is necessary in order for it to support the next generation of ARM architectures.

We like RISC OS here at Hackaday and have kept up to date with its recent developments, but even we as fans can see that it is in part a little dated. From the point of view of RISC OS Open though, they identify support for 64-bit platforms as their highest priority, and to that end they’re looking for developers, funding partners, and community advocates. If that’s you, get in touch with them!

ReactOS 0.4.15 Released With Major Improvements

March 25, 2025 by Maya Posch 84 Comments

Recently the ReactOS project released the much anticipated 0.4.15 update, making it the first major release since 2020. Despite what might seem like a minor version bump from the previous 0.4.14 release, the update introduces sweeping changes to everything from the kernel to the user interface and aspects like the audio system and driver support. Those who have used the nightly builds over the past years will likely have noticed a lot of these changes already.

Japanese input with MZ-IME and CJK font (Credit: ReactOS project)

A notable change is to plug-and-play support which enables more third party drivers and booting from USB storage devices. The Microsoft FAT filesystem driver from the Windows Driver Kit can now be used courtesy of better compatibility, there is now registry healing, and caching and kernel access checks are implemented. The latter improvement means that many ReactOS modules can now work in Windows too.

On the UI side there is a much improved IME (input method editor) feature, along with native ZIP archive support and various graphical tweaks.

Meanwhile since 0.4.15 branched off the master branch six months ago, the latter has seen even more features added, including SMP improvements, UEFI support, a new NTFS driver and improvements to power management and application support. All of this accompanied by many bug fixes, which makes it totally worth it to regularly check out the nightly builds.

Simulating Embedded Development To Reduce Iteration Time

March 18, 2025 by Lewin Day 22 Comments

There’s something that kills coding speed—iteration time. If you can smash a function key and run your code, then watch it break, tweak, and smash it again—you’re working fast. But if you have to first compile your code, then plug your hardware in, burn it to the board, and so on… you’re wasting a lot of time. It’s that problem that inspired [Larry] to create an embedded system simulator to speed development time for simple projects.

The simulator is intended for emulating Arduino builds on iPhone and Mac hardware. For example, [Larry] shows off a demo on an old iPhone, which is simulating an ESP32 playing a GIF on a small LCD display. The build isn’t intended for timing-delicate stuff, nor anything involving advanced low-level peripherals or sleep routines and the like. For that, you’re better off with real hardware. But if you’re working on something like a user interface for a small embedded display, or just making minor tweaks to some code… you can understand why the the simulator might be a much faster way to work.

For now, [Larry] has kept the project closed source, as he’s found that it wouldn’t reasonably be possible for him to customize it for everyone’s unique hardware and use cases. Still, it’s a great example of how creating your own tools can ease your life as a developer. We’ve seen [Larry]’s great work around here before, like this speedy JPEG decoder library.
Continue reading “Simulating Embedded Development To Reduce Iteration Time” →

C+P: Combining The Usefulness Of C With The Excellence Of Prolog

March 14, 2025 by Maya Posch 8 Comments

In a move that will absolutely not over-excite anyone, nor lead to any heated arguments, [needleful] posits that their C Plus Prolog (C+P for short) programming language is the best possible language ever. This is due to it combining the best of the only good programming language (Prolog) with the best of the only useful programming language (C). Although the resulting mash-up syntax that results may trigger Objective-C flashbacks, it’s actually valid SWI-Prolog, that is subsequently converted to C for compilation.

Language flamewars aside, the motivation for C+P as explained in the project’s README was mostly the exploring of macros in a system programming language. More specifically, by implementing a language-within-a-language you can add just about any compile-time feature you want including – as demonstrated in C+P – a form of generics. Even as a way to have a bit of fun, C+P comes dangerously close to being a functional prototype. Its main flaw is probably the lack of validation and error messages, which likely leads to broken C being generated.

Also mentioned are the Nim and Haxe languages which can be compiled (transpiled) to C or C++, which is somewhat of a similar idea as C+P, as well as cmacro (based on Common Lisp) and the D language.

How To Use LLMs For Programming Tasks

March 11, 2025 by Donald Papp 59 Comments

[Simon Willison] has put together a list of how, exactly, one goes about using a large language models (LLM) to help write code. If you have wondered just what the workflow and techniques look like, give it a read. It’s full of examples, strategies, and useful tips for effectively using AI assistants like ChatGPT, Claude, and others to do useful programming work.

It’s a very practical document, with [Simon] emphasizing realistic expectations and the importance of managing context (both in terms of giving the LLM direction, as well as the model’s context in terms of being mindful of how much the LLM can fit in its ‘head’ at once.) It is useful to picture an LLM as a capable and obedient but over-confident programming intern or assistant, albeit one that never gets bored or annoyed. Useful work can be done, but testing is crucial and human oversight simply cannot be automated away.

Even if one has no interest in using LLMs to help in writing production code, there’s still a lot of useful work they can do to speed up the process of software development in general, especially when learning. They can help research options, interactively explore unfamiliar codebases, or prototype ideas quickly. [Simon] provides useful strategies for all these, and more.

If you have wondered how exactly glorified chatbots can meaningfully help with software development, [Simon]’s writeup hopefully gives you some new ideas. And if this is is all leaving you curious about how exactly LLMs work, in the time it takes to enjoy a warm coffee you can learn how they do what they do, no math required.

TrapC: A C Extension For The Memory Safety Boogeyman

March 11, 2025 by Maya Posch 53 Comments

In the world of programming languages it often feels like being stuck in a Groundhog Day-esque loop through purgatory, as effectively the same problems are being solved over and over, with previous solutions forgotten and there’s always that one jubilant inventor stumbling out of a darkened basement with the One True Solution™ to everything that plagues this world beset by the Unspeakable Horror that is the C programming language.

As the latest entry to pledge its fealty at the altar of the Church of the Holy Memory Safety, TrapC promises to fix C, while also lambasting Rust for allowing that terrible unsafe keyword. Of course, since this is yet another loop through purgatory, the entire idea that the problem is C and some perceived issue with this nebulous ‘memory safety’ is still a red herring, as pointed out previously.

In other words, it’s time for a fun trip back to the 1970s when many of the same arguments were being rehashed already, before the early 1980s saw the Steelman language requirements condensed by renowned experts into the Ada programming language. As it turns out, memory safety is a miniscule part of a well-written program.

Continue reading “TrapC: A C Extension For The Memory Safety Boogeyman” →

Writing An OLED Display Driver In MicroZig

March 8, 2025 by Maya Posch 18 Comments

Although most people would use C, C++ or MicroPython for programming microcontrollers, there are a few more obscure options out there as well, with MicroZig being one of them. Recently [Andrew Conlin] wrote about how to use MicroZig with the Raspberry Pi RP2040 MCU, showing the process of writing an SSD1306 OLED display driver and running it. Although MicroZig has since published a built-in version, the blog post gives a good impression of what developing with MicroZig is like.

Zig is a programming language which seeks to improve on the C language, adding memory safety, safe pointers (via option types), while keeping as much as possible of what makes C so useful for low-level development intact. The MicroZig project customizes Zig for use in embedded projects, targeting platforms including the Raspberry Pi MCUs and STM32. During [Andrew]’s usage of MicroZig it was less the language or supplied tooling that tripped him up, and more just the convoluted initialization of the SSD1306 controller, which is probably a good sign. The resulting project code can be found on his GitHub page.