Middleware, development tools, realtime operating system
software and services for superior embedded design


 
Home
QNX Community Resources
Technical Articles

QNX Technical Articles

QNX Software Systems
Developer Resources
Blogs
Board support packages
Foundry27 projects
Forums
Hardware support listing
Online video tutorials
Product documentation
Technical Articles

 

QNX® Momentics® 6.3.0 Professional and Standard Editions Release Notes

QNX® Momentics® 6.3.0 PE and SE

Date of this edition: November 14, 2008

Note: Changes to these notes since June 7, 2004 are highlighted below with this icon:

New!

Target OS: QNX® Neutrino® 6.3.0

Host OS: Microsoft Windows XP SP1 or 2000 SP4; Sun Solaris 7/8; QNX® Neutrino® 6.3.0; Linux (Red Hat 8/9)

Note:
  • We are now deprecating support for Windows NT hosts. This is the last release of QNX Momentics that you can install on NT. We've tested this release on NT SP6.
  • QNX Neutrino 6.3 supports only the new flash filesystem (FFS3). The older flash filesystem (FFS2) has been discontinued.
  • For the most up-to-date version of these notes, log into your myQNX account, and then go to the Download Center area of www.qnx.com.
  • We highly recommend that you install Service Pack 1 after installing QNX Momentics 6.3.0. For more information, see the Download Center area of our website.
Caution: Make sure that Plug and Play OS is disabled in the BIOS before you run QNX Neutrino self-hosted.

Contents...

Note: Throughout this document, you may see reference numbers associated with particular issues, changes, etc. When corresponding with our Technical Support staff about a given issue, please quote the relevant reference number. You might also find the reference numbers useful for tracking issues as they become fixed.

What's new in QNX Momentics 6.3?

Note: For up-to-date information on what's compatible between the latest two versions, see 6.3.0 and 6.2.1 Compatibility, available on our website.

Here are the main new features in the 6.3 release:

Note: For more details, please refer to the “what's new” sections in the docs.

Momentics

Note: With the release of 6.3.0, some networking utilities and services have been moved from the base product to the Extended Networking TDK:

Managers

  • npm-tcpip-v6.so
  • dhcpd
  • dhcprelay
  • routed
  • route6d
  • rtadvd
  • rtsold
  • snmpd
  • snmptrapd
  • bootpd
  • mrouted
  • named
  • named-xfer

Utilities

  • ndp
  • ping6
  • traceroute6
  • racoon
  • setkey
  • snmpbulkwalk
  • snmpget
  • snmpgetnext
  • snmpnetstat
  • snmpset
  • snmpstatus
  • snmptest
  • snmptranslate
  • snmptrap
  • snmpwalk

Libraries

  • libsnmp

Neutrino

Photon

Note: The Photon Application Builder (PhAB) is available only for Windows and QNX Neutrino hosts.

If you're using a Linux or Solaris host, but you still want to use PhAB, consider installing a QNX Neutrino host to a second partition or an X86 simulator (e.g. VMware).

A word about coexistence

The QNX Momentics 6.3.0 development suite lets you install and work with multiple versions of Neutrino (from 6.2.1 and later). Whether you're using the command line or the IDE, you can choose which version of the OS to build programs for.

When you install QNX Momentics, you get a set of configuration files that indicate where you've installed the software. The QNX_CONFIGURATION environment variable stores the location of the configuration files for the installed versions of Neutrino; on a self-hosted Neutrino machine, the default is /etc/qnx.

QWinCfg for Windows hosts

On Windows hosts, you'll find a configuration program (QWinCfg) for switching between versions of QNX Momentics.

You launch QWinCfg via the start menu (e.g. All Programs-->QNX Momentics 6.3.0-->Configuration).

For details on using QWinCfg, see its entry in the Utilities Reference.

qconfig utility for non-Windows hosts

If you're using the command-line tools, use the qconfig utility to configure your machine to use a specific version of Neutrino:

Note: In the above command, you must use the “back tick” character (`), not the single quote character (').

When you start the IDE, it uses your current qconfig choice as the default version of the OS; if you haven't chosen a version, the IDE chooses an entry from the directory identified by QNX_CONFIGURATION. If you want to override the IDE's choice, you can choose the appropriate build target. (For more information, see the section “Version coexistence” in the Concepts chapter of the IDE User's Guide.)

Note: Coexistence of 6.3.0 and 6.2.1 is supported only on Windows and Solaris hosts.

Environment variables

Neutrino uses these environment variables to locate files on the host machine:

QNX_HOST
The location of host-specific files.
QNX_TARGET
The location of target-specific files on the host machine.
QNX_CONFIGURATION
The location of the qconfig configuration files.
MAKEFLAGS
The location of included *.mk files.

The qconfig utility sets these variables according to the version of QNX Momentics that you specified.

Changes

Here are the main changes in 6.3 (in alphabetical order):

Note: You'll find a list of fixes at the end of this document.
Note: For more details on changes in 6.3, including references to our Change Request Database, see the “What's Included” section of the online Welcome Message that gets installed along with the software.

BSPs and DDKs

Note: For more information on BSPs and DDKs, see the installation notes and release notes (under /etc/readme/bsp|ddk/*.html).

Compiler and tools

Environment variables

The SDK now requires that QNX_HOST, QNX_TARGET, QNX_CONFIGURATION, and MAKEFLAGS be set. On Windows and QNX Neutrino hosts, these are set automatically; on Solaris and Linux, they're set interactively.

In previous releases of the SDK, make knew where to find included *.mk files, but no longer. You must set MAKEFLAGS to:

MAKEFLAGS=-I${QNX_TARGET}/usr/include

QNX_HOST and QNX_TARGET used to have default values if they weren't set, but no longer. You must set these to wherever the SDK host and target files are located. For example: 

QNX_HOST=C:/QNX630/host/win32/x86
QNX_TARGET=C:/QNX630/target/qnx6

QNX_CONFIGURATION gives the location of the qconfig configuration files. The default is /etc/qnx.

Note: Please remember to use forward slashes (/) when setting environment variables on all hosts, because many of the tools in the SDK will interpret a backward slash (\) as an escape character and will simply remove it.

GCC

make

If you're using the QNX recursive makefile hierarchy, make needs to be able to find the makefile fragments (.mk files) with the rules for building QNX projects. These are stored in $QNX_TARGET/usr/include.

The environment variable MAKEFLAGS gives extra command-line flags to make; by setting it to -I$QNX_TARGET/usr/include, these .mk files will be found.

Note: Microsoft's nmake also uses MAKEFLAGS, so if there's a mixed environment, you can use GNUMAKEFLAGS, which is an extension to standard make and exists only in the QNX-supplied version.

mkifs

Linker

Core OS

Asynchronous messaging

Note: Asynchronous messaging is an experimental feature in 6.3.0; its implementation may change.

Asynchronous messaging is a communication model that relies on a store-and-forward technique. Compared to regular reply-based communication in client-server systems, the messaging infrastructure ensures delivery, even if a participant is temporarily offline, busy, or unobtainable. In this technique, the sender doesn't need a response from the recipient. This provides more flexibility and scalability as the senders and receivers are de-coupled and are no longer required to execute in lockstep.

More and more customers are demanding such fast, nonblocking message-passing mechanisms. In some real-world scenarios, the client doesn't have to wait in a blocking state for the server to finish servicing its requests; rather, it can improve its performance by carrying out some tasks while waiting. Multiple asynchronous messages can also be sent out within a short period of time. Buffering those messages and sending them out as a bunch can reduce the frequency of entering the kernel and thus improve system performance.

Asynchronous messaging in Neutrino provides an event-driven system model that complements our traditional message-passing architecture of synchronous messaging. Its main feature is high throughput and nonblocking message passing. You can now design systems where the OS can react in a timely way to asynchronous events generated externally or internally. Asynchronous messaging also provides a convenient and efficient mechanism to deliver asynchronous events and their associated data among system components.

We provide several asyncmsg_*() APIs and encourage you to use these interfaces to implement your own application using asynchronous messaging:

To: Use this function:
Create an asynchronous message channel asyncmsg_channel_create()
Destroy an asynchronous message channel asyncmsg_channel_destroy()
Establish a connection between a calling process and a channel asyncmsg_connect_attach()
Detach the connection asyncmsg_connect_detach()
Flush all the messages asyncmsg_flush()
Return the original connection attributes asyncmsg_connect_attr()
Take message(s) from a buffer or an array of buffers asyncmsg_put()/asyncmsg_putv()
Receive an asynchronous message from the channel asyncmsg_get()
Free a message buffer asyncmsg_free()
Allocate a message buffer for sending asyncmsg_malloc()

 

C++

New! Some class definitions are stricter in 6.3.0. For example, the set class requires unique keys; you can no longer modify keys that you've already added to the set, because you could create duplicates. This change could cause code that compiled on 6.2.1 not to compile on 6.3.0. (Ref# 21773)

dinit

In 6.3, dinit now creates long filenames by default. You can disable support for long filenames by specifying the -N option. (Ref# 17642)

Note: This is the reverse of the behavior of 6.2.1; the -N option formerly enabled support for long filenames.

fcntl()

We fixed problems with side-channel connections and errnos reported. (Ref#s 16959; 16960)

Note: The OS now prevents _NTO_SIDE_CHANNEL connections from being dup'd (via dup(), dup2(), or fcntl(F_DUPFD)). This is to maintain consistency with the concept of side-channels forming a separate file-descriptor space that isn't subject to normal process-inheritance rules.

If you are dup()ing side-channels, then they must now be attached as normal file descriptors.

Note also that the low-level ConnectAttach() doesn't allow the specification of a specific side-channel index, which is required by dup2().

FD_SETSIZE

The value of FD_SETSIZE has changed from 32 to 256. This affects the size of the fd_set objects that you pass to select().

This means that by default the highest allowable fd number for FD_SET(fd, &set) is 255.

Any use of fd_set within data structures will therefore cause a change in structure size, so you should do a global recompile.

Note: The global recompile should include all application code, as well as library code that would be referencing fd_set or structures containing fd_set. If you don't recompile, you may see random corruption and crashes.

To make the value higher, #define FD_SETSIZE before including <sys/select.h>. But make sure this is done consistently throughout your modules.

If you don't want to cause a global compile, you can #define FD_SETSIZE 32 before including <sys/select.h> (or -DFD_SETSIZE=32 on the command line) to set it back to the old size, but make sure this setting is consistently applied to all your code.

Instrumented kernel

The instrumented kernel (procnto-instr) is now the default kernel for QNX Neutrino self-hosted systems.

LD_LIBRARY_PATH

For security reasons, the path(s) specified by LD_LIBRARY_PATH for setuid/setgid binaries will no longer be searched when loading shared objects.

Instead, only the path(s) defined by the _CS_LIBPATH configuration string will be used. You can examine or modify the value of _CS_LIBPATH using the getconf and setconf utilities.

Note: In a buildfile, you can set the initial value of _CS_LIBPATH via the LD_LIBRARY_PATH= part of the “procnto” line. For example: 
PATH=/proc/boot:/bin:/usr/bin LD_LIBRARY_PATH=/proc/boot:/lib:/usr/lib:/lib/dll procnto

libpm and libpmm

pidin

The pidin utility now has a format code (l) to show the last CPU a thread was run on.

poll()

The poll() function has been added. Initial support is limited to the first three event types: POLLRDNORM, POLLWRNORM, and POLLRDBAND.

POSIX Message Queues

The 6.3.0 release ships with an optional alternate implementation of POSIX message queues. This implementation uses the new asynchronous messaging facility of the kernel to buffer the messages within the kernel itself, and eliminates the (context-switching) overheads of using an external server (mqueue) in each message-queue operation, thus greatly improving the performance of POSIX message queues.

Note: New! In earlier versions of QNX Neutrino, mqueue managed message queues and named semaphores; now, procnto handles named semaphores. If your embedded system uses named semaphores but not message queues, you don't need to include mqueue in your OS image. (Ref# 21823)

By default, the implementation of the mq_*() routines in libc is the old style, using the mqueue server to broker each transaction. To use the new-style implementation, the application(s) must be linked against the libmq library. In a manual build, specify the -l mq option; in automatic/recursive builds, use this setting in your common.mk file: 

LIBS += mq

Since both variants adhere to the POSIX 1003.1 Message Passing API, no code-level changes are required in conforming applications.

The new server /sbin/mq must also be started. Although this server is not involved in each mq_send()/mq_receive()/mq_notify() operation, the server is necessary in order to maintain the queue names and create the corresponding kernel message queues. The server also presents all created queues in the /dev/mq/ directory, allowing the use of ls and rm for administration purposes (although the queue contents can't be manipulated via shell utilities). This directory could be changed to union over the directory exported by the old mqueue server by using the mq -N/dev/mqueue option, but this isn't recommended, because it may cause some user-namespace confusion.

The two POSIX message queue implementations may coexist but are disjoint. Queues created with mq_open() from libc aren't accessible to mq_open() from libmq and vice versa. When relinking applications to use the new implementation, be sure to change all affected components. We require such explicit intervention to use the alternate implementation because of potential incompatibilities if your code isn't strictly POSIX conforming.

Message queue descriptors (mqd_t) are no longer file descriptors in the alternate implementation. The POSIX 1003.1 standard makes no claim as to the underlying type of an mqd_t, and provides a specific set of functions to manipulate a message queue and its attributes based on an abstract mqd_t type.

For example, the following code modifies the nonblocking attribute of an open message queue: 

mq_getattr(mq, &attr);
attr.mq_flags |= O_NONBLOCK;
mq_setattr(mq, &attr, NULL);

And this example attempts to obtain the count of messages in a queue: 

mq_getattr(mq, &attr);
nmsg = attr.mq_curmsgs;

Other examples include the historic interchangeability of mq_send() with write() and of mq_receive() with read(). There's no direct counterpart to select() when used on a mixed set of queues and file descriptors or for the transition from a full queue, although mq_notify() may be used to register an event against a message queue on transition from empty.

Note: The alternate implementation doesn't support the DCMD_MISC_MQSETCLOSEMSG QNX extension to inject a canned message when a queue descriptor is closed.

The default configuration of a message queue created by mq_open(O_CREAT) with a NULL mq_attr structure has been changed, because kernel buffers for the messages are now created up-front rather than on-demand. To create a queue with a specific configuration, simply provide a non-NULL mq_attr. To force the NULL default to match that of the old implementation, use the mq -m1024 -s4096 options (which isn't recommended, because this will consume 4MB of system memory for each such queue!).

Since the kernel primitives supporting the asynchronous message-queue facilities are non-orthogonal with respect to native QNET networking, the alternate implementation allows for message queues to be manipulated only from the local machine. Of course, distributed access and the network-qualified naming of message queues is undefined by POSIX.

The following table summarizes the main differences between the alternate implementations:

Style Server Library Pathname mqd_t implementation Qnet
Old (6.x) mqueue libc /dev/mqueue/ int (file descriptor) Yes
New (6.3.0) mq libmq /dev/mq/ int (internal index) No

 

PPC startups

Priority levels

The OS now supports 256 priority levels.

Note that non-root processes can use only priority levels 1 to 63. Only root processes (i.e. those whose effective uid is 0) are allowed to set priorities above 63.

You can change the allowed priority range for non-root processes with the procnto -P option: 

procnto -P priority

Here's a summary of the ranges:

Priority level Owner
0 idle thread
1 through priority − 1 non-root or root
priority through 255 root

resmgr_handle_tune()

This is a new function that you can use to tune some of the parameters used internally by the resource manager layer when performing the client fd - ocb mapping. For more information, see the Neutrino Library Reference.

select()

The select() function used to make use of the functions _select_event() and _select_block(). The latter two functions weren't doc'd (other than being prototyped in /usr/include/sys/select.h.)

As of 6.3, these two functions are no longer used internally. However, they've been left in libc for the time being, but may be removed altogether in a future release. For reference, here is the old implementation of select(): 

/*
Copyright 2001, QNX Software Systems Ltd. All Rights Reserved
 
This source code has been published by QNX Software Systems 
Ltd. (QSSL). However, any use, reproduction, modification,
distribution or transfer of this software, or any software
which includes or is based upon any of this code, is only
permitted under the terms of the QNX Realtime Platform End
User License Agreement (see licensing.qnx.com for details)
or as otherwise expressly authorized by a written license
agreement from QSSL. For more information, please email
licensing@qnx.com.
*/
#include 
#include 
#include 
#include 
#include 
#include 
#include 
 
/*  The routine implements the Unix select call.  When 
 semantics differ the BSD
 semantics defined in APUE (pg. 396-400) are followed.
*/
 
int select(int nfds, fd_set *readfds, fd_set *writefds, 
fd_set *exceptfds, struct timeval *tvptr) 
{
     struct sigevent            event;
     struct timespec            ts;
 
     if(tvptr) 
     {
         if (tvptr->tv_sec < 0 ||   /* don't bother 
                         checking upper ends, roll over will catch really bad overflows */
             tvptr->tv_usec < 0)
             return errno= EINVAL, -1;
         
         ts.tv_sec= tvptr->tv_sec ;
         ts.tv_nsec= tvptr->tv_usec * 1000L ;
     }
 
     event.sigev_notify = SIGEV_SIGNAL_THREAD;
     event.sigev_signo = SIGSELECT;    /* This signal is     
      always SIGBLOCKed */
     /* event.sigev_value will be modified as needed by 
      select_sigevent() */
     event.sigev_code = SI_NOTIFY;
     event.sigev_priority = -1;
 
      return _select_event(nfds, readfds, writefds, exceptfds, tvptr ? &ts : 0, &event, _select_block, 0);
}

Shared memory on ARM processors

New! The behavior of the SHMCTL_GLOBAL and SHMCTL_PHYS flags has changed for ARM processors.

On ARM, you can use shm_ctl() to create shared memory objects that can be mapped outside the regular process address space to overcome the 32MB address-space limitation.

In 6.2.1, these objects, when mapped, weren't protected and were potentially accessible via their global virtual addresses from any suitably privileged process. This access was restricted to processes that had performed ThreadCtl(_NTO_TCTL_IO), so in general, this was restricted to drivers or other system processes. The SHMCTL_LOWERPROT flag lowered this restriction so that any user process could potentially access these mappings without having to use ThreadCtl(_NTO_TCTL_IO) first.

In 6.3.0, these global mappings are protected, so that only the process that performed the mmap() of the shared memory object can access it. If you have any code written for 6.2.1 that relies on the implicit access allowed by these global mappings, you must modify it to use the flags to explicitly remove the per-process protection:

In addition to the per-process protection, 6.3.0 changes the alignment of the virtual addresses where these global mappings are placed:

In 6.2.1, mmap() mapped separate objects similar to the following:

In 6.3.0, mmap() maps these objects as:

If you have any code written for 6.2.1 that makes assumptions about the alignment of mappings or uses MAP_FIXED with non-1MB alignment, you must modify it to comply with the new behavior.

64-bit “large file” libc/filesystem support

QNX Neutrino 6.3 now implements the X/Open Largefile Support extensions. For details, see the 6.3.0 and 6.2.1 Compatibility note posted on our website.

Startup library

The startup library now supports 64-bit physical addresses for the MIPS, PPC, and X86 architectures. Two versions of the libstartup.a are built:

By default, startup programs will compile and link with the 32-bit version. If a board needs 64-bit physical addresses, add the make macro PADDR_SIZE=64 to the board's pinfo.mk file (see startup/boards/440rb/pinfo.mk for an example).

stat()

swapctl

Support for swapping (experimental on x86) has been removed with the 6.3.0 release. It was introduced to help compile and link large projects on memory-constrained hosts, but is no longer required using current PC configurations.

System page

User's Guide

We've developed a Neutrino User's Guide covering a broad range of topics to help users as well as system administrators work with a Neutrino system.

Flags for ChannelCreate()

New! We've corrected the behavior of the _NTO_CHF_COID_DISCONNECT and _NTO_CHF_THREAD_DEATH flags for ChannelCreate(). For descriptions of the new behavior, see the entry for ChannelCreate() in the Neutrino Library Reference. (Ref# 15480)

Math functions

New! The following math functions are deprecated:

Instead of: Use:
drem() remainder()
dremf() remainder()
finite() isfinite()
finitef() isfinite()
isinff() isinf()
isnanf() isnan()
significand() scalbn( x, -ilogb( x ))
significandf() scalbnf( x, -ilogbf( x ))
scalbf() scalbn()

Drivers

Audio (deva-)

Block (devb-)

New drivers:

Graphics (devg-)

Driver Controller Target CPU
devg-chips.so (replaces devg-chip_hiqv.so) Chips & Technologies 65550 and greater MIPSLE, PPCBE, SHLE, X86
devg-coral.so Fujitsu Coral B & Coral P ARMLE, PPCBE, SHLE, X86
devg-i830.so Intel 82830, 82845, 82865 X86
devg-orchid.so Fujitsu Orchid PPCBE, SHLE, X86
devg-ravin.so NEC RavinE MIPSLE, PPCBE, X86
devg-sis630.so SiS 300 & 630 X86
devg-smi7xx.so Silicon Motion 712, 722 & 731 ARMLE, MIPSLE, PPCBE, SHLE, X86
devg-smi5xx.so Silicon Motion 501 ARMLE, MIPSLE, PPCBE, SHLE, X86
devg-tvia.so (replaces devg-igs5300.so) TVIA 52xx and 53xx MIPSLE, SHLE, X86

 

Polygon acceleration

Network (devn-)

USB (devu-)

Flash filesystem

A new version of the NOR flash filesystem library offers significantly improved resistance to power-loss corruption. However, this improvement isn't backwards-compatible with the older version of the library.

The older library (libfs-flash.a) has been removed from this release. All flash drivers (devf-generic, devf-ram, etc.) now link against the version 3 library, i.e. libfs-flash3.a.

If your existing code links against libfs-flash.a, you must now use the version 3 library. For more information, please refer to the documentation on the new version 3 flash filesystem as well as the migration technote.

Installation

Photon-specific

Image loading

Helpviewer

Photon File Manager

Photon Library (libph.so)

PxConfig* API

The new API has been reworked to lift some of the restrictions of the old API. The old API can hold only one config file open at a time, seriously limiting its practicality (particularly for use in a library).

All existing PxConfig* calls (from pre-6.3) continue to be supported in the form of macro wrappers around the new API.

Note: You need to recompile your applications if you're moving to 6.3 — we encourage you to migrate to the new API, particularly for new projects. But apps that worked with the old API should continue to work with the new.

For details on the new API, see the PxConfig* entries in the Photon Library Reference.

Voyager and IDE docs

If your connection configuration includes a proxy server, remember to add the following in the Proxy Overrides field in the Connection tab (Edit-->Preferences):

127.0.0.1, localhost

This will allow the IDE's help system to locate the files it needs.

Application Builder

Shelf (Launch menu)

phfont

The design architecture has evolved from 6.2.x. Under 6.2.x, io-graphics was able to load the font server into its own data segment in order to speed up rendering services. This interface has been taken to a new level, through libfont, by allowing several system configurations:

  1. An external font server and a client font instance within io-graphics.
    Benefit:
    Increased speed.
    Cons:
    Increase in memory footprint. Although io-graphics instantiates a client font instance, it can use greatly reduced resources, since it isn't concerned with other application requests.
  2. A server font instance within io-graphics. This is the same behavior as 6.2.x. If an external font server isn't started, io-graphics will attempt to start a server font instance.
    Benefits:
    Good speed; middle memory footprint.
    Cons:
    Slower than option 1, since the graphics driver may have to wait for an outside client font request to complete.
  3. An external font server only.
    Benefit:
    Minimal memory footprint
    Cons:
    Slowest option

Client applications may also load a private client font instance, resulting in maximum speed when making font requests. Please read the new documentation for phfont, fontadmin, and libfont (Font Library Functions, specifically Pf*Dll() API calls).

Under the 6.3 architecture, rendering plugins are utilized by phfont. These DLLs are located in /lib/dll/font. Each rendering DLL has an embedded use message; just type use dllname.

The following binaries are no longer required:

Please read the documentation on phfont for further details. Options for the DLLs are set via the fontopts file; see the docs on fontadmin for further details.

Due to the new library (libfont), when linking against a static libph you must also link against libfont.

embed_font

This script can be used to copy all the font system binaries and libraries to a target build image. Usage is simple: 

embed_font target_root_directory

fontopt is now fontopts

The fontopt configuration file is now deprecated and no longer used. Use the fontopts file instead. See the docs for phfont and fontadmin for further details.

fontview

The fontview program is a font-viewer application that can display glyphs from any font format supported by phfont, without having to install the font file. For more information, see the usage message (type use fontview from a pterm).

The fontview utility uses the same rendering plugins as phfont.

mkfontdir

This utility now uses the same rendering plugins as phfont to process index files.

io-graphics

Now has a new command-line format; supports configuration file, and multi-headed display.

TrueType fonts

Fixed a problem where PhAB for Windows wouldn't recognize and render user-supplied TrueType fonts. (Ref# 19865)

To install a TrueType font:

  1. Use the Windows Control Panel to install the font.
  2. Add the .ttf file to the following directory:

    %QNX_TARGET%\usr\photon\font_repository directory

  3. Run mkfontdir so that the font appears in the font index file (fontdir).

Pg*() functions

Most Pg*() functions have Cx* versions, which are context-specific.

Note: Since the Pg*() versions are implemented as macros based on their *Cx() counterparts, they no longer have symbols in the new libraries; you'll need to recompile your code if you use these functions.

The macros are defined in the <PhProto.h> public header file.

New window frames

The window frames have been updated with a new look and new decorations. You can revert to the 6.2-style window frames by moving or removing /usr/photon/dll/winframe_updated.so.

You can have the new window frames on the desktop and have the old window frames in PhAB by launching PhAB with the -D option (ab -D) or with any other style of window frame by using the -F framestyle option.

Photon hook

You can pull in and execute a block of user code during the initialization of Photon applications. For details, see the widget styles section of the Managing Widgets in Application Code chapter of the Photon Programmer's Guide.

Photon clipboard

The Photon clipboard has been enhanced with added security. You can no longer get access to another user's clipboard files, unless you're running as root. Clipboard files are no longer compatible between 6.3.0 and previous releases. This also means that Photon applications built against libph.so.2 can't share the clipboard with Photon applications built against libph.so.3.

Note also that in 6.3, you're no longer limited to 64K when you cut-and-paste text. The limit is now your system RAM.

Clipboard Changed Event

Starting in 6.3.0, clipboard changes cause a new event to be emitted. The event will be a Ph_EV_INFO, with a subtype of Ph_CLIPBOARD_CHANGED. The data associated with the event will contain the input group number and the “clip type” string, so that the listener can call PhClipboardRead() to paste the data just copied. The old region changed event has been deprecated, but for now will still be emitted when the clipboard changes.

Multimedia

phlogin

The default login application is now phlogin2, which provides a user icon that you can select to log in. If you remove phlogin2 from the path, phlogin (the original GUI login from 6.2) is used automatically.

savercfg

PtExit()

The PtExit() function no longer causes individual threads to exit. See the docs for details.

Pt_CB_NUMERIC_CHANGED

If the PtNumericInteger and PtNumericFloat widgets have the Pt_CALLBACKS_ACTIVE bit set in the Pt_ARG_FLAGS resource, these callbacks are also invoked when your application changes the Pt_ARG_NUMERIC_VALUE with a call to PtSetResource() or PtSetResources(), or if the Pt_ARG_NUMERIC_VALUE is changed indirectly by a change to Pt_ARG_NUMERIC_MIN or Pt_ARG_NUMERIC_MAX.

Qnet

For 6.3, we're shipping two versions of Qnet:

Note: The new Qnet (npm-qnet-l4_lite.so) is not compatible with the pre-6.3 versions.

The default version is the new lightweight Qnet (npm-qnet.so is a link to npm-qnet-l4_lite.so). If you wish to use the older version of Qnet, have npm-qnet.so link to npm-qnet-compat.so and restart io-net.

Note:
  • You can't have an instance of npm-qnet-l4_lite.so and npm-qnet-compat.so active at the same time on the same node.
  • You can't unmount Qnet (either version) from io-net in 6.3.0.

TCP/IP

dhcp.client

SCTP (in Extended Networking TDK)

IPFilter (in Extended Networking TDK)

IPFilter (lsm-ipfilter-[v4|v6] can be used only with the matching TCP/IP stack (i.e. lsm-ipfilter-v4.so with npm-tcpip-v4.so; lsm-ipfilter-v6.so with npm-tcpip-v6.so).

Full TCP/IP stack and other updates

Note: IPv6 is now part of the Extended Networking TDK.

rpcbind

By default, rpcbind executes in “secure” mode and uses Unix Domain Sockets for local communication.

If you wish to use an older RPC application with rpcbind or to use rpcbind in combination with the Tiny TCP/IP stack, you'll need to refer to the -L and -i options to rpcbind.

Note: The service rpcbind must be defined for both UDP and TCP in the /etc/services file. While the default /etc/services provided has these modifications, if you choose to use the current /etc/services file at installation time, these definitions will be missing and rpcbind will fail to function. The required lines are: 
    
sunrpc    111/tcp        rpcbind portmap 
sunrpc    111/udp        rpcbind portmap

RPC library

Timeouts for clnt_broadcast() have changed. In 6.2 and earlier, timeout and retransmission occurs at 4 seconds and increases by 2 seconds for every timeout after that to a max of 14-second timeouts, resulting in 6 retransmissions.

In 6.3, timeout and retransmission occurs at 4 seconds and doubles after that to a max of 8 seconds, resulting in 2 retransmissions. You can alter timeout values by calling the lower-level call rpc_broadcast_exp().

Global Name Service Manager (gns)

The name_open() function used to be a silent operation for the server in that it wouldn't know when a client called name_open(). This behavior is changed to allow operation over the network.

The server will now always receive an _IO_CONNECT message when a client calls name_open(). (For more information, please refer to the gns entry in the Utilities Reference.)

rcp

New! This utility sets its user ID to root. It was reported that you can overrun the source/target file argument buffers in the utility, giving yourself root access. Under QNX Neutrino, rcp spawns the cp utility for local file-copying operations; it's the cp utility that faults. When rcp spawns cp, it does so with the credentials of the user who launched rcp, rather than root's. (Ref# 22002)

Windows-specific

We now provide two shells:

You'll find these executables under ${QNX_HOST}/usr/bin (e.g. C:\QNX630\host\win32\x86\usr\bin). You may want to create desktop shortcuts for these or other executables you'll use often.

Documentation

Experimental items

Caution: Experimental software is primarily provided for customers and the community to try out, and perhaps to get a glimpse of what might be in store for the future. For information about the use of experimental software, see the Commercial Software License Agreement (CSLA) or Partner Software License Agreement (PSLA) in the Licensing area of our website, http://www.qnx.com/legal/licensing/.

The experimental items in QNX Momentics 6.3.0 are:

Known issues

The 6.3 release contains known problems in these areas:

BSPs and DDKs

For more information about specific BSPs and DDKs, see the release notes that accompany them.

Uninstalling BSPs

GCC

At this time, we recommend that you use the GCC 2.95.3 tool chain to compile the source for the BSPs and DDKs. (Ref# 19949)

DBPXA250DP (Lubbock)

The system crashes when using intensive memory allocations. (Ref# 17929)

Drivers

Audio

deva-ctrl-ymfds1.so
New! QNX Momentics 6.3.0 should have included this shared object, but didn't. (Ref# 24662)

Block-oriented

devb-doc, devb-doc3, dformat, dformat3
New! The Disk On Chip drivers were provided by the vendor. If you run use -i on them, the state is given as Experimental. (Ref# 23101)

Graphics

Networking

Compiler & tools

Core OS