# c/c++ C and C++ are programming languages with documented syntax, semantics, standards, implementations, and development tools. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## В OpenIDE появилась поддержка C/C++ благодаря независимому разработчику DevFeed: [В OpenIDE появилась поддержка C/C++ благодаря независимому разработчику]() Original publisher: [Read original article]() Author: honest\_niceman (Haulmont) Published: 2026-09-16T15:22:55Z Content type: news Language: ru Sources: [Tagir Valeev]() Topics: [c/c++](), [CMake]() Tags: [c](), [c-c-plus-plus](), [c-plus-plus](), [clangd](), [cmake](), [ide-c-plus-plus-5a4cbf95fd05](), [intellij-platform](), [openide](), [rdev](), [tag-a071763eb5bb]() ### AI overview OpenIDE's marketplace has published the C/C++ Support plugin, created by an independent community developer. The beta plugin provides code completion, syntax highlighting, navigation, symbol renaming, project creation, and CMake-based compilation and builds. ### Source excerpt В маркетплейсе OpenIDE появился плагин C/C++ Support, для работы с C и C++. Его написал независимый разработчик из сообщества. Поддержку C++ пользователи просили давно, и автор решил не ждать, а взяться за неё самостоятельно. Читать далее ## Куда уходит память? Семплирующее профилирование колонок с Алисой в проде DevFeed: [Куда уходит память? Семплирующее профилирование колонок с Алисой в проде]() Original publisher: [Read original article]() Author: Cthutq66a (Яндекс) Published: 2026-07-16T07:02:46Z Content type: tutorial Language: ru Sources: [Яндекс - Как мы делаем Яндекс / Статьи]() Topics: [Linux](), [c/c++]() Tags: [arm](), [c](), [c-plus-plus](), [linux](), [memory](), [perfetto](), [perforator](), [tag-2d1d9199270a](), [tag-4004cf5948d3](), [tag-967d8467ce56](), [tag-d346fb5ae499]() ### AI overview The article explains how Yandex analyzes memory consumption in production across Linux smart speakers with Alice. It focuses on inexpensive sampling of dynamic allocations because the devices have limited memory and full allocation tracing is too costly. The article compares tools such as Perfetto with heapprofd and Perforator and describes constraints including memory, flash storage, and 32-bit ARM compatibility. ### Source excerpt Типичная умная колонка с Алисой -- это скромное железо и совсем немного оперативной памяти: у младших моделей её всего 256 МБ на всё устройство сразу. И за каждый мегабайт идёт настоящая борьба между множеством команд и компонентов: бизнес-логикой, обработкой звука, локальными нейросетями. Ежедневно мы собираем и анализируем memory-дампы с миллионов колонок -- нам важно понимать, куда уходят эти драгоценные мегабайты. Меня зовут Сергей, я работаю в команде, которая пишет прикладной код на C/C++ для умных устройств с Алисой (например, колонок, телевизоров и автомобилей). Под катом расскажу, как мы построили и используем инструмент для анализа потребления памяти в проде на нашем флоте Linux-колонок. Читать далее ## Swift 6.3 Released DevFeed: [Swift 6.3 Released]() Original publisher: [Read original article]() Author: Joe Heck Published: 2026-03-24T10:00:00Z Content type: release Language: en Sources: [Swift.org]() Topics: [Swift](), [c/c++](), [cross-platform](), [Android](), [Embedded Software Dev](), [Optimization](), [Tooling]() Tags: [android](), [c](), [c-c-plus-plus](), [cross-platform](), [embedded](), [optimization](), [swift](), [tooling]() ### AI overview Swift 6.3 expands Swift across the software stack with improved C interoperability, cross-platform build tooling, embedded-environment support, and an official Swift SDK for Android. The release also adds module selectors and new controls for compiler optimizations. ### Source excerpt Swift is designed to be the language you reach for at every layer of the software stack. Whether you're building embedded firmware, internet-scale services, or full-featured mobile apps, Swift delivers strong safety guarantees, performance control when you need it, and expressive language features and APIs. Swift 6.3 makes these benefits more accessible across the stack. This release expands Swift into new domains and improves developer ergonomics across the board, featuring: More flexible C interoperability Improvements to cross-platform build tooling Improvements for using Swift in embedded environments An official Swift SDK for Android Read on for an overview of the changes and next steps to get started. Language and Standard Library C interoperability Swift 6.3 introduces the @c attribute, which lets you expose Swift functions and enums to C code in your project. Annotating a function or enum with @c prompts Swift to include a corresponding declaration in the generated C header that you can include in your C/C++ files: @c func callFromC() { ... } // Generated C header void callFromC(void); You can provide a custom name to use for the generated C declaration: @c(MyLibrary_callFromC) func callFromC() { ... } // Generated C header void MyLibrary_callFromC(void); @c also works together with @implementation. This lets you provide a Swift implementation for a function declared in a C header: // C header void callFromC(void); // Implementation written in Swift @c @implementation func callFromC() { ... } When using @c together with @implementation, Swift will validate that the Swift function matches a pre-existing declaration in a C header, rather than including a C declaration in the generated header. Module name selectors Swift 6.3 introduces module selectors to specify which imported module Swift should look in for an API used in your code. If you import more than one module that provides API with the same name, module selectors let you disambiguate which API to use: ## Introduction to Fuzzing ESP-IDF components DevFeed: [Introduction to Fuzzing ESP-IDF components]() Original publisher: [Read original article]() Author: John Lee Published: 2026-01-07T00:00:00Z Content type: tutorial Language: en Sources: [Blog on Developer Portal]() Topics: [ESP-IDF](), [Fuzzing/Fuzz testing](), [Testing](), [Vulnerabilities](), [c/c++]() Tags: [blog](), [c-c-plus-plus](), [c-plus-plus](), [component](), [embedded](), [esp-idf](), [fuzzing](), [how-to](), [security](), [testing](), [vulnerabilities](), [vulnerability]() ### AI overview This article introduces fuzzing for ESP-IDF components and embedded libraries. It explains how to fuzz host-compiled code with sanitizers, compares black-box, grey-box, and white-box approaches, and outlines workflows using a basic mutator, AFL++, and protocol-focused harnesses. ### Source excerpt This article introduces fuzzing -- a technique for finding vulnerabilities -- and demonstrates practical workflows and lessons learned for ESP-IDF components and embedded libraries in general. ## Mitigating a rsync Vulnerability: A Lesson in Compiler Hardening DevFeed: [Mitigating a rsync Vulnerability: A Lesson in Compiler Hardening]() Original publisher: [Read original article]() Published: 2025-03-19T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [Compiler](), [chainguard](), [Security](), [c/c++](), [vulnerability]() Tags: [c](), [c-plus-plus](), [chainguard](), [compiler-flags](), [compiler-hardening](), [cves](), [defense-in-depth](), [hardening](), [linux](), [llvm](), [product-security](), [rsync](), [security](), [x86-64]() ### AI overview Chainguard describes how compiler hardening in its C/C++ toolchain helped protect against an rsync vulnerability before public disclosure. The article presents compiler hardening flags as layers of defense for memory-unsafe software and discusses Chainguard's implementation of recommendations from OpenSSF and GCC. ### Source excerpt Chainguard's defense-in-depth security strategy protected against multiple rsync CVEs before they were even reported. See how we did it, using compiler flags. ## GitHub Copilot Now in Espressif-IDE with Copilot4Eclipse DevFeed: [GitHub Copilot Now in Espressif-IDE with Copilot4Eclipse]() Original publisher: [Read original article]() Author: John Lee Published: 2025-02-13T00:00:00Z Content type: tutorial Language: en Sources: [Blog on Developer Portal]() Topics: [GitHub Copilot](), [AI-assisted coding](), [ide](), [c/c++](), [Artificial Intelligence](), [Extension](), [ESP-IDF](), [ESP32]() Tags: [ai](), [blog](), [c-c-plus-plus](), [c-plus-plus](), [code-generation](), [coding-assistant](), [debug](), [esp-idf](), [esp32](), [espressif](), [espressif-ide](), [github-copilot](), [how-to](), [ide](), [install](), [plugin](), [sign-in](), [subscription]() ### AI overview This article presents Copilot4Eclipse as a plugin that brings GitHub Copilot assistance to Espressif-IDE's Eclipse-based C/C++ editor. It describes code suggestions, completions, refactoring, Copilot Chat, and setup steps including installation and GitHub authentication. ### Source excerpt We all love GitHub Copilot as a powerful AI-powered coding assistant that enhances productivity. However, until now, it has been officially available only for VS Code and a few other editors. But here's some good news for Eclipse users! We have tried the Copilot4Eclipse plugin with the Espressif-IDE LSP C/C++ Editor, and it works amazingly well, helping to write code faster and fix bugs. ## Enhanced Compiler Flags for Building Chainguard's Guarded Images DevFeed: [Enhanced Compiler Flags for Building Chainguard's Guarded Images]() Original publisher: [Read original article]() Published: 2024-11-19T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [chainguard images](), [c/c++](), [Security](), [Compiler](), [Memory Safety](), [Exploit]() Tags: [c-plus-plus](), [chainguard-images](), [compiler](), [compiler-flags](), [compiler-hardening](), [memory-safety](), [openssf](), [secure-by-default](), [security](), [vulnerabilities](), [vulnerability]() ### AI overview Chainguard Images now use enhanced compiler flags for C/C++ projects. The OpenSSF-recommended hardening is implemented through clang configuration files and gcc spec files in Wolfi, helping mitigate memory-safety vulnerabilities such as stack-based buffer overflows and unsafe memory usage. ### Source excerpt Chainguard Images are now built using enhanced compiler flags for C/C++ projects. See how this strengthens the security posture of Chainguard's build systems. ## Accelerate C/ C++ security with Snyk DevFeed: [Accelerate C/ C++ security with Snyk]() Original publisher: [Read original article]() Author: Lauren Place; Marcie Cheung Published: 2023-12-05T14:00:00Z Content type: release Language: en Sources: [Blog RSS Feed | Snyk]() Topics: [C++](), [c/c++](), [snyk-code](), [Security](), [Vulnerabilities](), [Code](), [Tooling](), [CI/CD](), [Command-line interface](), [ide]() Tags: [acquisition](), [blog](), [c-c-plus-plus](), [c-cpp](), [c-plus-plus](), [ci-cd](), [cli](), [code](), [code-security](), [developer](), [ide](), [pmm](), [pull-request](), [security](), [snyk](), [snyk-code](), [snyk-open-source](), [tooling](), [vs-code](), [vulnerabilities]() ### AI overview Snyk announced general availability of C/C++ support for Snyk Code. The feature analyzes C/C++ source code directly without requiring compilation or a build, provides fast feedback, and integrates with IDE, CLI, Git, pull request, and CI/CD workflows. It also detects vulnerable open source packages and non-compliant licenses, with support for Windows, Linux, desktop, server, web, embedded applications, and frameworks such as Yocto, STL, and Boost. ### Source excerpt Today, Snyk is welcoming C/C++ security into the world of modern development with the general availability of C/C++ support for Snyk Code! ## How Async-Profiler's crash handler works DevFeed: [How Async-Profiler's crash handler works]() Original publisher: [Read original article]() Author: Richard Startin's Blog Published: 2023-11-12T00:00:00Z Content type: article Language: en Sources: [Richard Startin's Blog]() Topics: [async](), [c/c++](), [Linux](), [Java](), [JIT](), [Programming]() Tags: [async](), [c](), [c-plus-plus](), [compiler](), [cpu](), [crash](), [handler](), [jit](), [kernel](), [linux](), [memory-safety](), [profiling](), [programming](), [programming-language](), [run](), [safety](), [signal]() ### AI overview This article explains how async-profiler uses Linux signals and signal handlers to inspect thread state and safely dereference arbitrary pointers without crashing the JVM. It introduces signal-based sampling and frame-pointer unwinding, including the role of JIT-compiled code. ### Source excerpt Raw pointers in C/C++ open up entire classes of error that are practically unimaginable in higher level languages. So why does anybody use them at all? Unfortunately, it's impossible to write a profiler without getting close to some of the sharp edges of unsafe memory. The async-profiler code base contains a lot of low level tricks, and it's worth studying how some of them work. ## Application and AI roundup - September DevFeed: [Application and AI roundup - September]() Original publisher: [Read original article]() Author: Adam Published: 2023-10-04T00:00:00Z Content type: article Language: en Sources: [Shostack & Friends Blog]() Topics: [Application Security](), [Memory Safety](), [c/c++](), [open-source-security](), [Zig](), [Artificial Intelligence](), [cisa]() Tags: [appsec](), [c-c-plus-plus](), [c-plus-plus](), [cybersecurity](), [development](), [memory-safety](), [open-source-software-security]() ### AI overview A September roundup covering application security developments involving memory safety, C and C++, Zig, hardware memory tagging, secure-by-design AI guidance, cybersecurity policy for medical devices, and open-source software security. ### Source excerpt September was a big month in appsec for both memory safety and policy ## Smarter C/C++ inlining with \_\_attribute\_\_((flatten)) DevFeed: [Smarter C/C++ inlining with \_\_attribute\_\_((flatten))]() Original publisher: [Read original article]() Author: Andreas Kling Published: 2020-04-27T00:00:00Z Content type: tutorial Language: en Sources: [Andreas Kling]() Topics: [inlining](), [c/c++](), [Optimization](), [clang](), [gcc](), [build times]() Tags: [build-times](), [c-c-plus-plus](), [clang](), [compiler](), [cpp](), [function](), [gcc](), [inlining](), [optimization](), [performance](), [technical]() ### AI overview This post explains how to use the __attribute__((flatten)) function attribute in C/C++ to apply aggressive inlining selectively. GCC and Clang support the attribute, which inlines a function's callees while limiting the program-size, cache-locality, and build-time costs of broader inlining. ### Source excerpt This post describes a compile-time technique for getting the benefits of aggressive inlining in hot code while protecting cool code from its downsides. ## Clang on Windows DevFeed: [Clang on Windows]() Original publisher: [Read original article]() Published: 2020-01-05T22:46:09Z Content type: tutorial Language: en Sources: [Ariya Hidayat]() Topics: [c/c++](), [Windows](), [Package manager](), [make](), [Azure](), [CI/CD]() Tags: [azure](), [build](), [c](), [c-plus-plus](), [cache](), [clang](), [continuous-integration](), [make](), [pacman](), [windows]() ### AI overview A tutorial on using MSYS2 to install and run Clang on Windows for building 32-bit and 64-bit C/C++ applications. It also describes integrating the toolchain with Azure Pipelines and caching downloaded packages. ### Source excerpt Thanks to the MSYS2 project, now there is an easy way to utilize Clang to build C/C++ application on Windows. This works equally well for both 32-bit and 64-bit programs. ## C/C++ Include Guidelines DevFeed: [C/C++ Include Guidelines]() Original publisher: [Read original article]() Published: 2019-10-13T12:14:00Z Content type: tutorial Language: en Sources: [Thomas Young]() Topics: [c/c++](), [C](), [C++](), [Code quality](), [Code](), [modules]() Tags: [c](), [c-c-plus-plus](), [c-plus-plus](), [code](), [code-quality](), [compilation](), [dependencies](), [implementation](), [modules](), [source](), [structure]() ### AI overview An opinionated set of guidelines for organizing include files in C and C++. It covers header and source-file responsibilities, include ordering, repeated-include protection, dependencies, namespaces, naming, and related practices, while noting that C++20 modules change the situation. ### Source excerpt Some (opinionated) guidelines for include file organisation in C/C++. Intro I present a list of points, probably best considered as guidelines, but which I'll refer to as rules throughout the rest of this post, since it trips off the tongue that bit more easily (or perhaps I just have some hidden authoritarian streak). I'll assume the reader knows something about writing code in C or C++, and understands at least the basics about how compilation with include files works. Sometimes I'll say things are obvious to this intended audience, where I think this is necessary for completeness. This is about an ideal way to organise code. For large existing code bases changing the code to follow all of the rules may not be straightforward but it should be possible to make some incremental steps towards the code structure I describe, resulting in some kind of incremental improvements in overall code quality. Many of the rules have exceptions, and it can interesting to explore reasons for these exceptions, as well as the reasons for the rules themselves. Modules As an aside, please note that this is a 'pre-modules' document. If you're using c++ 20 and modules the situation will be different. (At the time of writing I don't have any experience working with modules, and I'm not aware of all the details about how modules will work. I'm hoping that if we follow the rules described here, we should be reasonably well placed for moving to C++20 modules, but if that's not the case, and there are module related details that you think should be taken into account in this document, please let me know in the comments.) The rules 1. Headers are for linkage details, implementation goes in source files. 2. Each source file should have a single matching header. 3. Linkage to a source file should go only through its header. 4. Guard against repeated includes. 5. Each header should be self-sufficient. 6. Each source file includes its own header first. 7. Low level includes come after high level i ## My First GSOC Experience and Introduction to ReactOS DevFeed: [My First GSOC Experience and Introduction to ReactOS]() Original publisher: [Read original article]() Published: 2017-06-13T00:00:00Z Content type: article Language: en Sources: [Front Page on ReactOS Website]() Topics: [ReactOS](), [Programming](), [c/c++](), [Windows](), [Open Source]() Tags: [c-c-plus-plus](), [free](), [gsoc](), [open-source](), [operating-systems](), [os](), [programming](), [react](), [reactos](), [win32](), [winapi]() ### AI overview A personal introduction from a computer science student describing his interest in programming, open-source software, operating systems, and C/C++. The article explains how ReactOS led him toward applying for his first GSOC project and discovering its welcoming community. ### Source excerpt #Introduction: Hi, I am shriraj (aka sr13), currently pursuing my B.Tech in CSE (Computer Science and Engineering) @ National Institute of Technology Goa, India. I am not just studying CSE but I like to play and experiment with CSE. Programming is just another hobby and I knew that its one of my forte the moment I had felt my first 'Hello World!!' with 'C'. (OK, that might be a little exaggeration XD, but yeah you can tell it when you start enjoying the subject so much that you felt code is better art than a poem. ## DDNet Server Statistics with ServerStatus, RRDtool and Nim DevFeed: [DDNet Server Statistics with ServerStatus, RRDtool and Nim]() Original publisher: [Read original article]() Published: 2016-05-13T22:00:00Z Content type: tutorial Language: en Sources: [Dennis Felsing]() Topics: [Server](), [Nim](), [Statistics](), [Python](), [c/c++](), [JSON](), [Programming](), [Linux](), [JavaScript]() Tags: [http](), [javascript](), [json](), [linux](), [nim](), [programming](), [python](), [servers](), [statistics]() ### AI overview This article explains how DDNet monitors its official game servers using ServerStatus, RRDtool, and Nim while keeping resource usage low. It describes collecting server metrics with Python clients, transmitting them over TCP to a C/C++ server, aggregating them into JSON, displaying them through a JavaScript frontend, and recording CPU, network, and memory data in RRDtool. ### Source excerpt About a month ago I set up statistics for the official DDNet servers. My motivations for this are: Monitor the servers more easily Get notified about server problems Have nice graphs to look at The choices for the software used are mainly made to keep resource usage low, a general principle used for DDNet since we run on cheap VPSes all around the world and are limited in CPU and memory resources. In the rest of this post we will explore the 3 major tools used, their purpose in our solution as well as their performance impact: ServerStatus: Gather live server statistics RRDtool: Record and graph data Nim: Favorite programming language for performance and readability Gathering live server statistics with ServerStatus We've been running BotoX's ServerStatus to get live server statistics for some time now. It works quite well to quickly notice major server problems like a high load or incoming (D)DoS attacks, provided that you keep an eye out for it. We use ServerStatus by running its simple Python client on each server to gather interesting information. The client transmits that data by TCP to the C/C++ server, which aggregates it into a JSON file. This JSON file is then fetched and displayed every two seconds by the JavaScript frontend of our Status page. On a regular Saturday morning the end result looks like this: On a quick glance you notice that the DDNet.tw server has high CPU usage (which is totally normal since it runs some hefty cron jobs every 20 minutes) and DDNet RUS is receiving a small DoS attack with just 1.6 MB/s (unfortunately also totally normal). Apart from that everything looks fine. ServerStatus footprint, calculated from Linux /proc statistics as follows (in Nim): import os, strutils, posix, strfmt # CPU and memory usage of process, based on PROC(5) and # http://stackoverflow.com/a/16736599 let pid = paramStr(1) # Clock ticks per second frequency = sysconf(SC_CLK_TCK) # Size of memory page in bytes pagesize = sysconf(SC_PAGESIZE) uptime = readFil ## Understanding Type in Go DevFeed: [Understanding Type in Go]() Original publisher: [Read original article]() Published: 2013-07-12T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Go Language](), [Programming](), [c/c++](), [math]() Tags: [ardan-labs](), [blog](), [c-c-plus-plus](), [code](), [go](), [go-programming](), [golang](), [language](), [math](), [numbers](), [pointers](), [programming](), [types]() ### AI overview This tutorial explains why type information matters when interpreting memory and values in programming. It introduces numbering systems, including binary, decimal, and hexadecimal, and shows how the same value can be represented differently depending on the base. ### Source excerpt When I was coding in C/C++ it was imperative to understand type. If you didn't, you would get into a lot of trouble with both the compiler and running your code. Regardless of the language, type touches every aspect of programming syntax. A good understand of types and pointers is critical to good programming. This post will focus on type. Take these bytes of memory for starters: ## Simplifying LLVM IR for PNaCl DevFeed: [Simplifying LLVM IR for PNaCl]() Original publisher: [Read original article]() Author: Mark Seaborn (noreply@blogger.com) Published: 2013-06-29T19:08:00Z Content type: article Language: en Sources: [Mark Seaborn]() Topics: [LLVM](), [c/c++](), [browser](), [Web](), [x86]() Tags: [browser](), [c-plus-plus](), [clang](), [code](), [encoding](), [intermediate](), [llvm](), [native](), [optimisation](), [portable](), [x86]() ### AI overview This article explains how PNaCl simplifies LLVM IR to create a maintainable, architecture-neutral executable format for native code in web browsers. It describes removing types, names, metadata, and complex instructions, and compares the approach with Emscripten and asm.js. ### Source excerpt Lately I've been working on Portable Native Client ("PNaCl" for short). Native Client (NaCl) is a sandboxing system that allows safe execution of native code in a web browser -- typically C/C++ code compiled to x86-32, x86-64 or ARM native code (with some support for MIPS too). The problem with NaCl has always been that you have to compile your program multiple times, once for each target architecture. PNaCl aims to solve that, so that your program can be compiled once to an architecture-neutral executable which is then translated to x86 or ARM inside the web browser. PNaCl is based on LLVM, and PNaCl's executable format is based on LLVM's IR ("Intermediate Representation") language and its binary encoding, LLVM bitcode. LLVM's IR language is quite complex, so we're pruning out and expanding out a lot of features in order to ensure that PNaCl will be maintainable in the long term and to reduce executable sizes. As an example, consider this fragment of C code: struct foo { int x; int y; }; void func(struct foo *ptr) { ptr->y = 123; } Normally in LLVM this compiles to the following LLVM assembly code: %struct.foo = type { i32, i32 } define void @func(%struct.foo* nocapture %ptr) #0 { entry: %y = getelementptr inbounds %struct.foo* %ptr, i32 0, i32 1 store i32 123, i32* %y, align 4, !tbaa !0 ret void } attributes #0 = { nounwind } !0 = metadata !{metadata !"int", metadata !1} With PNaCl, we strip out the types, names and metadata so that this becomes: define internal void @67(i32) { %2 = add i32 %0, 4 %3 = inttoptr i32 %2 to i32* store i32 123, i32* %3, align 1 ret void } The definition of the struct type goes away. The "getelementptr" instruction is how LLVM handles pointer arithmetic for indexing into structs and arrays -- this gets expanded out and is replaced with pointer arithmetic on integers. The "%struct.foo*" pointer type is replaced with the i32 type. The "inttoptr" instruction remains as a vestige of LLVM's type system: every "load" or "store" instruction in ## Newsletter 23 DevFeed: [Newsletter 23]() Original publisher: [Read original article]() Published: 2007-05-01T00:00:00Z Content type: article Language: en Sources: [Front Page on ReactOS Website]() Topics: [ReactOS](), [Development](), [Kernel](), [Windows](), [c/c++](), [WINE](), [Firefox](), [Content Management System]() Tags: [c-plus-plus](), [compatibility](), [development](), [firefox](), [free](), [kernel](), [newsletter](), [open-source](), [os](), [react](), [reactos](), [technical](), [win32](), [winapi]() ### AI overview ReactOS Newsletter 23 reports on development toward the 0.3.2 branch, including kernel stability, blocking bugs, hardware boot fixes, WIDL compiler integration, WINE library synchronization, and graphical subsystem work. ### Source excerpt Just to make it clear, while we aim for a biweekly newsletter, we only aim for it to be up around Sunday. It can easily be delayed if there isn't enough to talk about. The Road to 0.3.2 For those of you who don't follow the ReactOS scene closely it may be hard to know what exactly is happening in terms of development progress. The technical nature of some improvements also proves confusing to most people.