ReactOS 0.4.15 Released With Major Improvements

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)
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

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

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

[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

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

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.

Screenshot of the REPL running on the Flipper, importing the flipper API library and calling infrared receive function out of it with help of autocomplete

A MicroPython Interpreter For Flipper Zero

Got a Flipper Zero? Ever wanted to use a high-level but powerful scripting language on it? Thanks to [Oliver] we now have a MicroPython application for the Flipper, complete with a library for hardware and software feature support. Load it up, start it up, connect over USB, and you’ve got the ever-so-convenient REPL at your disposal. Or, upload a Python script to your Flipper and run them directly from Flipper’s UI at your convenience!

In the API docs, we’re seeing support for every single primitive you could want – GPIO (including the headers at the top, of course), a healthy library for LCD and LCD backlight control, button handling, SD card support, speaker library for producing tones, ADC and PWM, vibromotor, logging, and even infrared transmit/receive support. Hopefully, we get support for Flipper’s wireless capabilities at some point, too!

Check out the code examples, get the latest release from the Flipper app portal or GitHub, load it up, and play! Mp-flipper has existed for the better half of a year now, so it’s a pretty mature application, and it adds quite a bit to Flipper’s use cases in our world of hardware hacking. Want to develop an app for the Flipper in Python or otherwise? Check out this small-screen UI design toolkit or this editor we’ve featured recently!