Byblos
 |
This article is a stub. You can help by expanding it. | |||
Byblos is a software development kit developed for Sirius DOS, A* and Unix-based servers, with distinction for MILOTIX and Linux, BSD and Darwin (pan-Unix) support.
System support
The Byblos SDK is multi-platform. Systems are divided into two broad groups: XAA platforms and Unices, with MILOTIX being the only system counting as both. Unix-based systems are supported for the highly economical commodity-level scalability that is out of reach of A*. All XAA platforms are supported for the interests of the XAA initiative. GNU/Linux, FreeBSD and Darwin are supported for their market share, while OpenBSD is supported for the relevancy of its security features and illumos is supported as it is a Unix not based on Linux or BSD like Darwin, but is free software.
Location
Spatial placement of the SDK is a more intuitive ordeal on A*, where programs and data merely have names, as opposed to Unices and DOSes where a file system hierarchy must be dictated for consistency to remain with portability in force. To this end, Byblos defines the following file system hierarchy, the root of which is referred to as $BYBLOS in the chart below. $BYBLOS may resolve to any valid file system path, but normally is set to /opt/byblos on Unices and C:/BYBLOS on DOSes.
| Path | Brief description | Notes |
|---|---|---|
| $BYBLOS/sbin | "script" binaries | |
| $BYBLOS/linux64 | GNU/Linux on x86-64 sysroot | |
| $BYBLOS/linux32 | GNU/Linux on i686 sysroot | |
| $BYBLOS/freebsd | FreeBSD on x86-64 sysroot | |
| $BYBLOS/darwin86 | macOS on x86-64 sysroot | |
| $BYBLOS/darwinm1 | macOS on Apple Silicon sysroot | |
| $BYBLOS/milotix | MILOTIX on x86-64 sysroot | |
| $BYBLOS/win311 | Windows 3.11 Win16 i286 sysroot | |
| $BYBLOS/win95 | Windows 95/98/Me Win32 i386 sysroot | |
| $BYBLOS/winnt32 | Windows NT 4.0 i386 sysroot | |
| $BYBLOS/winnt64 | Windows NT 5.1 x86-64 sysroot | |
| $BYBLOS/pcdos | Real mode IBM-PC-DOS i286 sysroot | |
| $BYBLOS/ibmpc | Real mode non-DOS BIOS direct i286 sysroot | |
| $BYBLOS/agbhb | Nintendo Game Boy Advance homebrew sysroot | |
| $BYBLOS/agbsp | Nintendo Game Boy Advance source-patching sysroot | |
| $BYBLOS/illumos | illumos on SPARC V9 sysroot | |
| $BYBLOS/astar | A* on Anodyne sysroot | |
| $BYBLOS/include | C, C++ and C* header files | |
| $BYBLOS/conf | Configuration settings | |
| $BYBLOS/man | Documentation files | |
| $BYBLOS/system | SDK internal management data | reserved for the exclusive use of the Byblos SDK; outside applications should never assume anything about this directory's contents or even that it exists at all |
"Script" binaries are programs that are, by themselves, architecture independent, usually because they are interpreted or compiled just-in-time on loading. These are separated from native binaries which are, as files, specific to the architecture in use. Byblos does not support any architectures other than the one in use on a given system (more exactly, whichever µarch the running kernel is compiled for). For instance, if a user is running a "multilib" system such as on amd64 with i386 as lib32/, it will only support amd64.
The Byblos SDK operates on the premise that the working development directory can be anywhere, while all tools and support files are either provided within the hierarchy above, or assumed present on the system-level. System-level utilities and libraries should be provisioned using system package managers and treated in full mutual exclusion to Byblos-specific tooling; Byblos stuff is not compiled into /usr/local, and system stuff is never compiled into $BYBLOS. Even if one must manually compile a package from source, it should NEVER be installed with its --sysroot set to $BYBLOS! (Use /usr/local instead.)
When developing new SDK components in a source tree, they should be built and installed into $BYBLOS/local/* for testing and personal use. Packaged SDK software downloaded or installed from elsewhere will be configured to be installed into $BYBLOS/*, where it is versioned and stripped and so on.
Name registration
Byblos maintains a registration system to prevent name collisions inside its root hierarchy. Every project or package has a "master name" by which it is known, and a set of "servile names" inside the bin/, include/, lib/, libexec/, and sbin/ subfolders each. Ordinarily, servile names inside include/ are not provided to third parties. The details of this registry and its governance are to be determined.
Removable media and RAM drives on DOS
What $BYBLOS resolves to and its underlying media are distinguished intelligently on Unices, where the canonical resolution of /opt/byblos and its contents can be mount points or symbolic links to just about anything. This is not the case on DOSes, since drive letters come into play. Fortunately, the variance that we wish to accommodate is limited to those drive letters.
It is important to be able to use Byblos from a floppy diskette, or to have an arbitrary portion of its files on a RAM drive to speed up performance. Byblos could also be located on a network-mapped drive. To support all of this, the $BYBLOS variable is instead defined as an absolute path without its drive letter, and another environment variable, $BYBDRV, contains a comma-separated ordered list of which drives its files may be available on. When Byblos tools look for a program, library or other file, they will search each drive in the list in order, and use whichever path comes up valid first. Here is an example:
Say that Alice has a computer with a 3½" floppy diskette drive A:, a 5¼" floppy disk drive B:, a main hard disk C:, a CD-ROM drive D:, a 2MiB RAM drive E:, and a network-attached storage drive Z:. Her main Byblos installation is at C:/BYBLOS, but she also has a newer minor-version release on a 3½" diskette that contains an updated Oración assembler providing a feature she needs to use no matter what. She also has some extra support libraries she authored on a loaded 5¼" disk, and a huge third-party SDK integrated with Byblos on a CD-ROM. Finally, her workplace provides company-specific headers and project tooling on the network drive. She has Batch scripts that she manually runs at startup to place her most important files onto the RAM drive. She will probably want to have a setup like this:
$BYBLOS= /BYBLOS$BYBDRV= E,A,B,D,C,Z
The SDK, along with any and all programs that use its support library, will have file I/O subroutines that stitch together the base path with the drive letters to try when resolving paths. Byblos will also provide dynamic, hands-free integration with the $PATH executable resolution approach and will know where to look for #includes, libraries and other data automatically, using support library subroutines.
Components
Yellow 〜 boxes indicate eventual support will be given, just not in the initial phases of development (usually due to bootstrapping concerns).
| Component | Sirius DOS | A* | MILOTIX | GNU/Linux | FreeBSD | OpenBSD | Darwin | illumos |
|---|---|---|---|---|---|---|---|---|
| Hinterlib | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Inbound | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Outbound | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Rebound | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Earthbound | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Forerunner | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Precursor | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Simbel | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| VR6 | ✔ | ✔ | 〜 | 〜 | 〜 | 〜 | 〜 | 〜 |
| Sirius C* | ✔ | ✔ | 〜 | 〜 | 〜 | 〜 | 〜 | 〜 |
| Oración | ✔ | ✔ | 〜 | 〜 | 〜 | 〜 | 〜 | 〜 |
| Feeble C compiler | ✔ | ✔ | 〜 | 〜 | 〜 | 〜 | 〜 | 〜 |
| Quindle | ✔ | ✔ | ✖ | ✖ | ✖ | ✖ | ✖ | ✖ |
| Gauntlet | ✔ | ✔ | 〜 | 〜 | 〜 | 〜 | 〜 | 〜 |
| Senusret's browser | ✔ | ✔ | 〜 | 〜 | 〜 | 〜 | 〜 | 〜 |
| Cigarbochs | ✖ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
Petit utilities
chkenc– inspect and validate text encodings of filesliner– inspect and validate line lengths
