search

CoreNGS / api

Custom API's to work with CoreNGS and derivatives
2 stars 0 forks source link

Is CoreNGS/Potabi dead? #9

Open Curculigo opened 1 month ago

Curculigo commented 1 month ago

This repository is the only one that is still active and I admit I have no idea what it's about.

time-killer-games commented 1 month ago

Hi,

The lead developer is attending to other things in life right now beyond her control. She said she might return to it in several years if she hasn't totally lost interest by then, but in the meantime I am providing updates to the CoreNGS/api repository which I am the current maintainer for apart from Kai.

Sorry for the inconvenience, Samuel

time-killer-games commented 1 month ago

Oh I didnt read until just now that you didn't know what this repository is for.

It is a set of cross-platform API's meant to be used in Potabi and CoreNGS and was intended to be built-in to the OS and used by a lot of its internal components, in particular the custom Desktop Environment developed for Potabi. The API's are cross-platform with the intent to make it easy to port software originally developed for Potabi to also work on other platforms or vise versa.

apiprocess is, as you could've guessed from the name, the CoreNGS/Potabi process API. It simplifies the developer's ability to write code for executing and managing application processes, sending signals like suspend, resume, and terminate, and getting and setting process information such as standard input, standard output, standard error, environment variables, command line arguments, child process ID's, parent process ID, current working directory, and executable path, from a give process ID.

apifilesystem is the CoreNGS/Potabi filesystem operations and file I/O api, things like file copy, file rename, file delete, reading / writing / appending / seeking / truncating to/from text files, directory create, directory copy, directory rename, directory delete, get file size, get directory size, directory iteration, etc.

apisystem is the newest API addition to CoreNGS/Potabi and is still in the early stages, close to being complete however, it gets system-wide information like CPU logical processor and physical core count, CPU vendor, CPU model name, GPU manufacturer, GPU chipset name, Dedicated Video Memory, get whether the OS is running as a guest in a virtual or emulated environment, Kernel Name, OS / Distro Name, Kernel Version, Kernel / OS architecture, RAM usage statistics, SWAP usage statistics, etc. More things will be added in the future such as getting CPU usage percent after a certain number of ticks defined by the user, Uptime, used/free/total space on a given mounted storage device, etc.

Right now, this repository, and all its api's only target Potabi/CoreNGS, Windows, macOS, Linux, FreeBSD, DragonFly BSD, NetBSD, OpenBSD, Solaris, and illumos.

There are two exceptions: 1) getting the number of physical CPU cores is not supported by OpenBSD OS-level, and while it could be done with inline assembly regardless, that would be very fragile and unlikely to work consistently across devices, even with a best effort. 2) getting whether the OS is being run in a virtual or emulated environment is only supported by Windows apps run through WINE, x86 applications run in VM or some other virtualization / emulation method (regardless of platform), x86 macOS apps run in Rosetta 2, Linux apps run in WSL or WSL2, and Linux apps of any architecture which is on a system with systemd-detect-virt installed (pretty much any Linux distro with systemd). No other platform / architecture combinations are currently implemented for virtualization / emulation detection.