RISC OS Open to takeover co-ordination of RISC OS resource allocations
With immediate effect RISC OS Open Ltd has taken over all RISC OS allocations requests.
The new address for submissions is mailto:firstname.lastname@example.org
(This is a change of address since the original posting of this Press Release.)
Submissions will no longer be accepted at mailto:email@example.com nor at mailto:firstname.lastname@example.org
Allocations dealt with are:-
To avoid clashes within the system, RISC OS requires many different names to be unique. The categories for these names are as follows :-
Names of Sprites that reside in the Wimp Sprite Pool
Environment (System) variables
ResourceFS directory names
Transient (utilities) names
You will need to ensure that all the names that your software uses are
registered with RISCOS, so that name duplication does not occur. Names
should be registered at the start of product development (not at the
end!) as a reservation request will be rejected if the name is already
being used by somebody else.
N.B. There is usually a flurry of last minute requests just as a show is approaching, and it can throw a spanner if the works if it's only then that a problem is discovered.
Filetypes are allocated to third parties who have developed an application which implements its own file format, where users can save the data out in this form and double click on the file to run/load the data into the application. Filetypes are usually allocated on a one-per-product basis. If you feel that your application needs more than one filetype (because it can save, say, two different internal data formats) then you should look at the file format design and try and integrate the two. You should design your file format with headers and objects (see the format of DrawFiles for a good example).
If a filetype is required then you will need to submit the name of the application that the filetype is for and the desired name for the filetype (Maximum of 8 characters). It is worth noting that filetypes that do not support Double clicking protocols are not usually allocated. You will also be required to submit the sprites to represent the file, a description of the product and its internal file format before an allocation can take place.
SWI Chunks are allocated for modules that require SWI numbers for system extensions. They are allocated in blocks of 64 (&40) and are given on a one-per-module basis.
Error blocks are allocated to developers who need their own unique error numbers (e.g. for a module). They are usually allocation on a block per company basis but can be allocated on a module basis if your module requires lots of error numbers. Error Blocks are allocated in blocks of 256 (&100).
Wimp message blocks
Message blocks are allocated to developers who have developed an application that implements a Wimp Message Protocol. They are allocated in blocks of 64 (&40) and allocated as one block per protocol.
Podule allocations are made for Expansion Cards. Before a RISC OS Expansion Card can be implemented a Podule Id is required and a Manufacturer's Number. If a Manufacturer's Number has not been allocated for your company then you will need to apply for one.
Draw tag blocks are allocated for applications which implement tagged draw objects in accordance with the DrawFile functional specification (found in Volume 4 of the RISC OS 3 Programmers Reference Manual). They are allocated in blocks of &100. A block is allocated to a company, not to an individual product. A new allocation can be requested once a current one has been exhausted.
Draw object blocks are allocated for applications which implement their own objects in draw files. They are allocated in blocks of &40. A block is allocated to a company, not to an individual product. A new allocation can be requested once a current one has been exhausted.
A Filing System number is allocated to a third party when they wish to implement their own RISC OS Filing System.
Device Id's are allocated to third parties who have a device which needs to support the Device Claim Protocol (see the Programmers Reference Manual for more information).
A Service Call block is allocated to a third party who wishes to implement service calls in their modules (see the Programmers Reference Manual for more information). They are allocated on a per company basis. A Service Call Block consists of 256 Service Call numbers.
An application to aid in submitting Allocation requests is available here