Home
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running QNX Neutrino 7.1.
Programming
Programmer's Guide
The QNX Neutrino Programmer's Guide covers a variety of topics that might interest developers who are building applications that will run under the QNX Neutrino RTOS.
Programming Overview

QNX Momentics IDE User's Guide
This User's Guide describes version 7.1 of the Integrated Development Environment (IDE) that's part of the QNX Momentics tool suite.
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running QNX Neutrino 7.1.
- Quickstart Guide
- OS Components & Operations
- Audio & Graphics API
- Multimedia
- Networking Middleware
- Programming
  - Getting Started with QNX Neutrino
    Getting Started with QNX Neutrino: A Guide for Realtime Programmers is intended to introduce you to the QNX Neutrino RTOS and help you develop applications and resource managers for it.
  - Programmer's Guide
    The QNX Neutrino Programmer's Guide covers a variety of topics that might interest developers who are building applications that will run under the QNX Neutrino RTOS.
    - Compiling and Debugging
    - Programming Overview
      - An application as a set of processes
        This idea of using a set of cooperating processes isn't limited to the OS system processes. Your applications should be written in exactly the same way. You might have some driver process that gathers data from some hardware and then needs to pass that data on to other processes, which then act on that data.
      - Some definitions
        Different operating systems often have different meanings for terms such as process, thread, task, program, and so on.
      - Priorities and scheduling
        Although there's a good discussion of priorities and scheduling policies in the System Architecture manual, it will help to go over that topic here in the context of a programmer's guide.
      - Scheduling policies
      - Why threads?
      - Talking to hardware
      - Summary
        The modular architecture is apparent throughout the entire system: the QNX Neutrino RTOS itself consists of a set of cooperating processes, as does an application.
    - Processes
      As we stated in the Overview chapter, the architecture of the QNX Neutrino RTOS consists of a small microkernel and some number of cooperating processes. We also pointed out that your applications should be written the same way—as a set of cooperating processes.
    - Multicore Processing
    - Working with Access Control Lists (ACLs)
      Some filesystems, such as the Power-Safe (fs-qnx6.so) filesystem, extend file permissions with Access Control Lists, which are based on the withdrawn IEEE POSIX 1003.1e and 1003.2c draft standards.
    - Understanding the Microkernel's Concept of Time
      Whether you're working with timers or simply getting the time of day, it's important that you understand how the OS works with time.
    - Transparent Distributed Processing Using Qnet
      Transparent Distributed Processing (TDP) allows you to leverage the processing power of your entire network by sharing resources and services transparently over the network. TDP uses the QNX Neutrino native network protocol, Qnet, to link the devices in your network.
    - Writing an Interrupt Handler
    - 32- and 64-Bit Architectures
      QNX Neutrino 7.1 or later supports 32- and 64-bit versions of ARM (armle-v7 and aarch64le) and 64-bit versions of x86 (x86_64).
    - Working with Memory
      (or The Persistence of Memory, with a nod to Salvador Dali)
    - Power Management
      A major contributor to the power consumption of a CPU is the frequency at which it is clocked. The power-management API allows you to manage this.
    - Freedom from Hardware and Platform Dependencies
    - Conventions for Recursive Makefiles and Directories
      In this chapter, we'll take a look at the supplementary files used in the QNX Neutrino development environment. Although we use the standard make command to create libraries and executables, you'll notice we use some of our own conventions in the Makefile syntax.
    - Glossary
  - The QNX Neutrino Cookbook: Recipes for Programmers
  - Writing a Resource Manager
- Sensor Framework
- System Security Guide
  The QNX System Security Guide is intended for both system integrators who are responsible for the security of a QNX Neutrino RTOS system and developers who want to create a QNX Neutrino resource manager free from vulnerabilities.
- Utilities & Libraries
QNX Hypervisor
The QNX Hypervisor allows you to run multiple OSs on a target system so you can separate critical and non-critical functions, support a wide variety of applications, and reduce hardware costs.
QNX Software in the Cloud
QNX Software in the Cloud enables developers to use the QNX software in Amazon Web Services (AWS) and Microsoft Azure (Azure).
QNX Advanced Virtualization Frameworks User's Guide
This User's Guide is aimed at all systems integrators and developers who want to design and build embedded systems using the QNX Advanced Virtualization Frameworks.
Typographical Conventions, Support, and Licensing
This section describes the typographical conventions used throughout the documentation and explains how to obtain technical support.

Programming Overview

The QNX Neutrino RTOS architecture consists of the microkernel and some number of cooperating processes. These processes communicate with each other via various forms of interprocess communication (IPC). Message passing is the primary form of IPC in QNX Neutrino.

Software bus with IPC — Figure 1The QNX Neutrino architecture acts as a kind of software bus that lets you dynamically plug in/out OS modules.

The above diagram shows an application sending a message to the GUI manager, and the GUI manager responding.

Page updated: March 12, 2026