|Powered by QM on a Rpi server|
If you an open source user and have a new source component or a modification that you would like to contribute to the standard source, email details to email@example.com. Please be aware of the following...
We make no guarantee that modifications submitted to us will be incorporated into a future OpenQM build. We reserve the right to reject or further modify the submitted components entirely at our discretion.
We ask you to indemnify us from any cost or actions arising from claims that your submission is partly or wholly someone else's intellectual property.
Where appropriate, unless otherwise requested, we will include the contributor's name in the history data for the relevant modules and in the readme file.
Modifications are more likely to be accepted if they follow the same general style as existing code.
All submitted modifications become the property of Ladybridge Systems Limited and may be included by us in a future release of the commercial QM product.
You need to send a completed version of the submittal document with your source submittal.
To make it easier for you to reintegrate your changes into a new version and to maintain compatibility between applications, it is helpful to adopt a few basic rules about how you make changes. No one will enforce these. They are here simply to make your life easy (and ours, if you submit your changes for inclusion in the standard product).
QMBasic coding style
Software developers all have their own personal style. We accept this but some consistency is desirable. In particular, the following rules should help, especially if you might submit your changes for integration into the master source.
C Coding Style
File System Changes
Changes in file formats are likely to cause serious problems with cross-version compatibility. It is strongly recommended that developers intending to make such changes discuss these with Ladybridge Systems beforehand if the change might be submitted for inclusion in the standard source.
QMClient Packet Types
The QMClient interface uses packet type numbers to identify the action to be performed. There could be serious data corruptions or other effects if mismatched versions of QM and the client application are used. The chances of this can be reduced significantly if developers use packet type numbers in a separate range from standard components of QM.
Note that regardless of the machine on which the software is run, QMClient packets always use low byte first representation of numeric data.
Some QMBasic operations are restricted for use in internal mode programs. An internal mode program can only be compiled on an internal mode version of QM.
The concept of internal mode was invented to protect features that should not be widely available, either because they potentially allow a user to perform undesirable actions or because the interface to the protected operation is likely to change.
Developers should respect the concept of internal mode and not just open up these features of the system to everyone.
Adding New VOC Entries
Most developments are likely to require new VOC entries. Try not to make assumptions about the VOC item name in case it clashes with a standard entry in a future release.
New keywords should be assigned numbers over 10000 as these will never be used by Ladybridge Systems. Alternatively, register your keyword with us and we will reserve a value even if we do not implement it in the standard source.
Extending The QMBasic Opcode Set
If your development requires a new opcode, there are a set of 16 opcodes (0xCFF0 to 0xCFFF) reserved for GPL developer use that will never be used in the standard source. Alternatively, create a new extended opcode set in a similar manner to the existing PREFIX opcode (0xCF).
The QM object code stream is byte order independent so that it is possible to execute code on machines with the reverse ordering. This is essential for use of compiled dictionary entries in mixed byte ordering networks. The object code header is not byte order independent but is automatically converted, if necessary, when a program is read into memory.
The file system is byte order specific and is not dynamically converted because access to any file on a remote QM server should always be via QMNet which will hide all aspects of byte ordering.
QM includes a tool, qmconv, to convert the byte ordering of a program or data file. In its normal mode of operation it takes a list of file pathnames, including wildcards, and converts these files to the byte ordering of the host machine. The -b or -l options force conversion to big or little-endian respectively, regardless of the byte ordering of the host system.