cross platform GUI / 2D software rendering

[nikhedonia]

I've noticed that cosmopolitan supports the creation of gui applications on windows.
I'm curious on your thoughts on how you'd go about extending this to the remaining platforms.
I'd be happy to make contributions in this direction but I'm not too familliar on how things work on Mac & BSD.

[jart]

Cosmopolitan currently has a razor sharp focus on tui interfaces because it's something we're able to do better than anyone else. I think cross-platform GUIs are great, but I need your support to raise the resources it requires.

The way I'd likely approach the problem is by vendoring something like SDL into the codebase to give you a high-performance blank canvas with audio that works consistently across platforms. I think starting off this way makes the most sense, since games need high-performance graphics and therefore can't be written as web guis like most modern software these days.

Please note that even GUI libraries as simple as SDL usually have a treasure trove of hidden dependencies. Cosmopolitan would need to vendor those too in order to uphold its mission of deterministic hermetically-sealed never-breaking behavior. We accomplish that by not making the assumption that the system did the legwork for us. Therefore it would some research to figure out the best way to vendor SDL dependencies and integrate with window management systems. Here's an example of the research that went into figuring out a way to portably integrate with kernels: libc/sysv/syscalls.sh, libc/sysv/consts.sh, and libc/nt/master.sh.

I can make it happen. I believe it should happen. I don't think 200mb Electron hello world binaries are sustainable. Cosmopolitan can do it better than anyone else, if we raise the resources. So please check out https://github.com/sponsors/jart and tell your friends who might be interested in becoming sponsors.

[jart]

If you want to see some examples of the impact Cosmopolitan is already having in the terminal interface realm, then check out:

• printvideo renders .mpg videos in the terminal
• nesemu1 play nintendo games in the terminal
• apelife conway's game of life tui + gui
• memzoom process/file memory monitor
• blinkenlights pc emulating visualizer debugger
• printimage prints png/jpg files in the terminal
• kilo antirez's famous text editor

One of the reasons why we're able to do terminal interfaces so well, is because the technology is so old (teletypes were invented in the 19th century) that corporations have stopped bothering with the whole engineered incompatibility game and a consensus emerged surrounding the VT100 + termios interface that Cosmopolitan makes easy to use.

[sc0ttj]

Rather than SDL, maybe something like these "single header" and/or "ANSI C" GUI libraries might be easier to use:

• https://github.com/vurtun/nuklear
• https://github.com/nakst/luigi
• https://github.com/floooh/sokol (not a single library, but nice resources)
• https://github.com/nothings/stb (not a single library, but nice resources)

[nicholatian]

The nuklear project is a good thing to start with, however it has been moved and the new location was last updated in December.

luigi does not seem to be portable enough, as it only supports the Win32 and X11 APIs.

sokol seems OK for what it is, however it goes whole hog with GPU acceleration through OS APIs, which is a huge load of maintenance for something like Cosmo to vendor on top of the APIs it already takes care of.

It depends on what @jart wants to do, but I would recommend starting with basic provisions without hardware acceleration, like nuklear, and then slowly graduating to advanced things if desirable. It’s really murky waters given the constraints of Cosmo, so it’s not even clear how much of this stuff she will want to put into project scope. I would recommend caution if expanding scope is part of the prerogative.

[jart]

It took five hundred thousand lines of code to get stdio and sockets working across platforms without dependencies. Doing the same for GUIs would probably take 10x times that, which is roughly the size of the Chromium codebase.

For example, there's an STB style header that does only audio integration which has 63,000 lines of code and it depends on lots of system libraries. Cosmopolitan makes it easy to take "the russians used a pencil" approach of just sending the raw audio samples to an ffplay or sox subprocess:

cosmopolitan/examples/nesemu1.cc

Lines 1704 to 1720 in d934f38

	if ((ffplay = commandvenv("FFPLAY", "ffplay"))) {
	devnull = open("/dev/null", O_WRONLY | O_CLOEXEC);
	pipe2(pipefds, O_CLOEXEC);
	if (!(playpid_ = vfork())) {
	const char* const args[] = {
	"ffplay", "-nodisp", "-loglevel", "quiet", "-fflags",
	"nobuffer", "-ac", "1", "-ar", "1789773",
	"-f", "s16le", "pipe:", NULL,
	};
	dup2(pipefds[0], 0);
	dup2(devnull, 1);
	dup2(devnull, 2);
	execv(ffplay, (char* const*)args);
	abort();
	}
	close(pipefds[0]);
	playfd_ = pipefds[1];

I think TUIs deserve more love. Modern terminal emulators make them better than they've ever been. I've recently used ANSI color for ASAN memory dumps. Here's a screenshot of the latest build of Blinkenlights which is an emulator TUI that's hosted in the Cosmopolitan codebase:

Behold the paneling algorithm that makes it possible:

cosmopolitan/tool/build/lib/panel.c

Lines 28 to 155 in d934f38

	/**
	* Renders panel div flex boxen inside terminal display for tui.
	*
	* You can use all the UNICODE and ANSI escape sequences you want.
	*
	* @param fd is file descriptor
	* @param pn is number of panels
	* @param p is panel list in logically sorted order
	* @param tyn is terminal height in cells
	* @param txn is terminal width in cells
	* @return -1 w/ errno if an error happened
	* @see nblack's notcurses project too!
	*/
	ssize_t PrintPanels(int fd, long pn, struct Panel *p, long tyn, long txn) {
	wint_t wc;
	ssize_t rc;
	size_t wrote;
	struct Buffer b, *l;
	int x, y, i, j, width;
	enum { kUtf8, kAnsi, kAnsiCsi } state;
	memset(&b, 0, sizeof(b));
	AppendStr(&b, "\e[H");
	for (y = 0; y < tyn; ++y) {
	if (y) AppendStr(&b, "\r\n");
	for (x = i = 0; i < pn; ++i) {
	if (p[i].top <= y && y < p[i].bottom) {
	j = state = 0;
	l = &p[i].lines[y - p[i].top];
	while (x < p[i].left) {
	AppendChar(&b, ' ');
	x += 1;
	}
	while (x < p[i].right || j < l->i) {
	wc = '\0';
	width = 0;
	if (j < l->i) {
	wc = l->p[j];
	switch (state) {
	case kUtf8:
	switch (wc & 0xff) {
	case '\e':
	state = kAnsi;
	++j;
	break;
	default:
	j += abs(tpdecode(l->p + j, &wc));
	if (x < p[i].right) {
	width = max(0, wcwidth(wc));
	} else {
	wc = 0;
	}
	break;
	}
	break;
	case kAnsi:
	switch (wc & 0xff) {
	case '[':
	state = kAnsiCsi;
	++j;
	break;
	case '@':
	case ']':
	case '^':
	case '_':
	case '\\':
	case 'A' ... 'Z':
	state = kUtf8;
	++j;
	break;
	default:
	state = kUtf8;
	continue;
	}
	break;
	case kAnsiCsi:
	switch (wc & 0xff) {
	case ':':
	case ';':
	case '<':
	case '=':
	case '>':
	case '?':
	case '0' ... '9':
	++j;
	break;
	case '`':
	case '~':
	case '^':
	case '@':
	case '[':
	case ']':
	case '{':
	case '}':
	case '_':
	case '|':
	case '\\':
	case 'A' ... 'Z':
	case 'a' ... 'z':
	state = kUtf8;
	++j;
	break;
	default:
	state = kUtf8;
	continue;
	}
	break;
	default:
	unreachable;
	}
	if (x > p[i].right) {
	break;
	}
	} else if (x < p[i].right) {
	wc = ' ';
	width = 1;
	}
	if (wc) {
	x += width;
	AppendWide(&b, wc);
	}
	}
	}
	}
	}
	rc = WriteBuffer(&b, fd);
	free(b.p);
	return rc;
	}

Thanks to Cosmopolitan this emulator works exactly the same on FreeBSD, OpenBSD, Mac, and Windows. Here's a screenshot of it running a Linux ASAN binary on the Windows 10 DOS command prompt:

Cosmopolitan also makes it easy to build offline web applications that can be distributed as a single file web server binary. See https://justine.lol/redbean/index.html which is hosted in the Cosmopolitan codebase.

Those are just some examples of things we're already able to do better than anyone else. That's the best place to focus the 80% of attention: becoming better at the things we're already the best at. GUIs could be fruitful. I love STB style headers and this project has stb_image checked-in to third party. Although if I wanted to pursue GUIs then, based on what I just researched I'd probably try to find a way to build Chromium with Cosmopolitan. I've already borrowed a few things from their codebase, such as their zlib fork. It's astonishingly high quality code.

[nicholatian]

What is the path of least resistance towards getting a no-hwaccel canvas running with the APE polyglot in use? Is this something that needs attention to specifics of the various platforms with fallbacks? If you believe this to be true @jart, I can get to work on that, going as far back as the original VGA spec, or even older if anyone cares. There sure is some novelty in Hercules and composite CGA, if nothing else.

Also, what is the right approach towards having different codepaths depending on system features? In the basic sense, different windowing systems and old VGA-level stuff seems straightforward, but expanding that notion to the graphics APIs is something of a holy grail in this sense. It will be helpful to be able to detect details in a quasi-runtime state, even if that state is only known to the glue code provided by Cosmo, not the application itself.

[jart]

Cosmopolitan can already create a blank canvas on WIN32. If we can do the same thing for X11 then that will cover all our bases. Although on Mac it'd be a little ugly since the user would have to start the X11 program which IIRC comes included with Mac OS.

The way I would probably approach the problem is to build the hello world x11 program from Rosetta Code and then use strace to reverse engineer the protocol. It appears the way it works is you need to open a UNIX domain socket to /tmp/.X11-unix/X0 and then you just send a bunch of binary frames back and forth. Here's what I got on Debian:

socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path=@"/tmp/.X11-unix/X0"}, 20) = 0
getpeername(3, {sa_family=AF_UNIX, sun_path=@"/tmp/.X11-unix/X0"}, [124->20]) = 0
access("/home/jart/.Xauthority", R_OK)  = 0
openat(AT_FDCWD, "/home/jart/.Xauthority", O_RDONLY) = 4
fstat(4, {st_dev= etc. etc.
read(4, "\1\0\0\6debian\ etc. etc.
read(4, "", 4096)                       = 0
close(4)                                = 0
getsockname(3, {sa_family=AF_UNIX}, [124->2]) = 0
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="l\0\v\0\0\0 etc. etc.", iov_len=12}, {iov_base="", iov_len=0}, 
           {iov_base="MIT-MAGIC-COOKIE-1", iov_len=18}, 
           {iov_base="\0\0", iov_len=2}, {iov_base="\211\32 etc. etc.
recvfrom(3, "\1\0\v\0\0\0\303\t", 8, 0, NULL, NULL) = 8
recvfrom(3, "\240*\267\0\0\0\300\4\377\377\37\0\0\1\0\0\24\0\377\377\1\7\0\0  \10\377\0\0\0\0The X.Org Foundation...
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="b\0\5\0\f\0\0\0BIG-REQUESTS", iov_len=20}], 1) = 20
etc. etc.

So yeah I would be pretty happy if we could talk to X11 directly without needing to touch Linux distro shared objects. X11 is a really old protocol that's been around since the 80's so I can't imagine its wire format will be changing anytime soon.

Once we're able to talk to it, we just need to figure out what the magic numbers are to:

1. Get the size of the window
2. Blit an RGB plane onto it

Then what you do with Cosmopolitan is you have if statements ilke this:

if (IsWindows()) {
  mdc = CreateCompatibleDC(ps.hdc);
  mbm = CreateCompatibleBitmap(ps.hdc, r.right, r.bottom);
  BitBlt(ps.hdc, ps.rcPaint.left, ps.rcPaint.top, r.right, r.bottom, mdc, 0, 0, kNtSrccopy);
  // etc. etc. win32 mode
} else {
  fd = socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 3
  rc = connect(fd, &(struct sockaddr_un){AF_UNIX, "/tmp/.X11-unix/X0"}, sizeof(struct sockaddr_un);
  if {rc != -1) {
    // etc. etc. x11 mode
  } else {
    for (y = 0; y < yn; y += 2) {
      if (y) printf("\r\n");
      for (x = 0; x < xn; ++x) {
        printf("\033[48;2;%hhu;%hhu;%hhu;38;2;%hhu;%hhu;%hhum▄",
               rgb[y + 0][x][0], rgb[y + 0][x][1], rgb[y + 0][x][2],
               rgb[y + 1][x][0], rgb[y + 1][x][1], rgb[y + 1][x][2]);
    // etc. etc. ansi terminal mode
  }
}

The last part for ANSI terminal mode is what I'd imagine would happen if the program can't figure out how to connect to the X11 server. See https://gist.github.com/jart/7428b2b955dfd6eff7b6d31e00414508 for an elegant explanation of how that's done.

[nicholatian]

If Cosmo supports running from BIOS, doesn’t that necessitate VGA support?

[nikhedonia]

one simple approach on linux is to write directly into the active framebuffer: /dev/fb0. To draw you just write a bytestream where each pixel is represented by one RGBA integer.
However that requires root permissions, is completely unmanaged and any application can override your pixels.
If one doesn't run any GUI at all, this might be a very pragmatic solution.

http://seenaburns.com/2018/04/04/writing-to-the-framebuffer/

[nicholatian]

Writing to /dev/fb0 is a lot more viable than you say it is. It seems that all is really needed is to ensure the user is part of the video group, and to be outside the X11 instance, on another TTY. The console will overwrite, but only upon program exit anyway, so cleanly exiting is a matter of blanking the buffer out and a call to clear. sudo is not necessary.

[jart]

Framebuffer is totally doable. Cosmopolitan already has support for it too. See PRINTVIDEO.COM which should still be able to play MPEG videos in the framebuffer even though that support was never fully fleshed out, since I normally only use Linux via SSH.

cosmopolitan/tool/viz/printvideo.c

Lines 1391 to 1463 in e345b42

	if (!isempty(getenv("FRAMEBUFFER"))) {
	fb0_.path = strdup(getenv("FRAMEBUFFER"));
	} else if (strcmp(nulltoempty(getenv("TERM")), "linux") == 0) {
	fb0_.path = strdup("/dev/fb0");
	}
	if ((fb0_.fd = open(fb0_.path, O_RDWR)) != -1) {
	CHECK_NE(-1, (rc = ioctl(fb0_.fd, FBIOGET_FSCREENINFO, &fb0_.fscreen)));
	LOGF("ioctl(%s) → %d", "FBIOGET_FSCREENINFO", rc);
	LOGF("%s.%s=%.*s", "fb0_.fscreen", "id", sizeof(fb0_.fscreen.id),
	fb0_.fscreen.id);
	LOGF("%s.%s=%p", "fb0_.fscreen", "smem_start", fb0_.fscreen.smem_start);
	LOGF("%s.%s=%u", "fb0_.fscreen", "smem_len", fb0_.fscreen.smem_len);
	LOGF("%s.%s=%u", "fb0_.fscreen", "type", fb0_.fscreen.type);
	LOGF("%s.%s=%u", "fb0_.fscreen", "type_aux", fb0_.fscreen.type_aux);
	LOGF("%s.%s=%u", "fb0_.fscreen", "visual", fb0_.fscreen.visual);
	LOGF("%s.%s=%hu", "fb0_.fscreen", "xpanstep", fb0_.fscreen.xpanstep);
	LOGF("%s.%s=%hu", "fb0_.fscreen", "ypanstep", fb0_.fscreen.ypanstep);
	LOGF("%s.%s=%hu", "fb0_.fscreen", "ywrapstep", fb0_.fscreen.ywrapstep);
	LOGF("%s.%s=%u", "fb0_.fscreen", "line_length", fb0_.fscreen.line_length);
	LOGF("%s.%s=%p", "fb0_.fscreen", "mmio_start", fb0_.fscreen.mmio_start);
	LOGF("%s.%s=%u", "fb0_.fscreen", "mmio_len", fb0_.fscreen.mmio_len);
	LOGF("%s.%s=%u", "fb0_.fscreen", "accel", fb0_.fscreen.accel);
	LOGF("%s.%s=%#b", "fb0_.fscreen", "capabilities",
	fb0_.fscreen.capabilities);
	CHECK_NE(-1, (rc = ioctl(fb0_.fd, FBIOGET_VSCREENINFO, &fb0_.vscreen)));
	LOGF("ioctl(%s) → %d", "FBIOGET_VSCREENINFO", rc);
	LOGF("%s.%s=%u", "fb0_.vscreen", "xres", fb0_.vscreen.xres);
	LOGF("%s.%s=%u", "fb0_.vscreen", "yres", fb0_.vscreen.yres);
	LOGF("%s.%s=%u", "fb0_.vscreen", "xres_virtual", fb0_.vscreen.xres_virtual);
	LOGF("%s.%s=%u", "fb0_.vscreen", "yres_virtual", fb0_.vscreen.yres_virtual);
	LOGF("%s.%s=%u", "fb0_.vscreen", "xoffset", fb0_.vscreen.xoffset);
	LOGF("%s.%s=%u", "fb0_.vscreen", "yoffset", fb0_.vscreen.yoffset);
	LOGF("%s.%s=%u", "fb0_.vscreen", "bits_per_pixel",
	fb0_.vscreen.bits_per_pixel);
	LOGF("%s.%s=%u", "fb0_.vscreen", "grayscale", fb0_.vscreen.grayscale);
	LOGF("%s.%s=%u", "fb0_.vscreen.red", "offset", fb0_.vscreen.red.offset);
	LOGF("%s.%s=%u", "fb0_.vscreen.red", "length", fb0_.vscreen.red.length);
	LOGF("%s.%s=%u", "fb0_.vscreen.red", "msb_right",
	fb0_.vscreen.red.msb_right);
	LOGF("%s.%s=%u", "fb0_.vscreen.green", "offset", fb0_.vscreen.green.offset);
	LOGF("%s.%s=%u", "fb0_.vscreen.green", "length", fb0_.vscreen.green.length);
	LOGF("%s.%s=%u", "fb0_.vscreen.green", "msb_right",
	fb0_.vscreen.green.msb_right);
	LOGF("%s.%s=%u", "fb0_.vscreen.blue", "offset", fb0_.vscreen.blue.offset);
	LOGF("%s.%s=%u", "fb0_.vscreen.blue", "length", fb0_.vscreen.blue.length);
	LOGF("%s.%s=%u", "fb0_.vscreen.blue", "msb_right",
	fb0_.vscreen.blue.msb_right);
	LOGF("%s.%s=%u", "fb0_.vscreen.transp", "offset",
	fb0_.vscreen.transp.offset);
	LOGF("%s.%s=%u", "fb0_.vscreen.transp", "length",
	fb0_.vscreen.transp.length);
	LOGF("%s.%s=%u", "fb0_.vscreen.transp", "msb_right",
	fb0_.vscreen.transp.msb_right);
	LOGF("%s.%s=%u", "fb0_.vscreen", "nonstd", fb0_.vscreen.nonstd);
	LOGF("%s.%s=%u", "fb0_.vscreen", "activate", fb0_.vscreen.activate);
	LOGF("%s.%s=%u", "fb0_.vscreen", "height", fb0_.vscreen.height);
	LOGF("%s.%s=%u", "fb0_.vscreen", "width", fb0_.vscreen.width);
	LOGF("%s.%s=%u", "fb0_.vscreen", "accel_flags", fb0_.vscreen.accel_flags);
	LOGF("%s.%s=%u", "fb0_.vscreen", "pixclock", fb0_.vscreen.pixclock);
	LOGF("%s.%s=%u", "fb0_.vscreen", "left_margin", fb0_.vscreen.left_margin);
	LOGF("%s.%s=%u", "fb0_.vscreen", "right_margin", fb0_.vscreen.right_margin);
	LOGF("%s.%s=%u", "fb0_.vscreen", "upper_margin", fb0_.vscreen.upper_margin);
	LOGF("%s.%s=%u", "fb0_.vscreen", "lower_margin", fb0_.vscreen.lower_margin);
	LOGF("%s.%s=%u", "fb0_.vscreen", "hsync_len", fb0_.vscreen.hsync_len);
	LOGF("%s.%s=%u", "fb0_.vscreen", "vsync_len", fb0_.vscreen.vsync_len);
	LOGF("%s.%s=%u", "fb0_.vscreen", "sync", fb0_.vscreen.sync);
	LOGF("%s.%s=%u", "fb0_.vscreen", "vmode", fb0_.vscreen.vmode);
	LOGF("%s.%s=%u", "fb0_.vscreen", "rotate", fb0_.vscreen.rotate);
	LOGF("%s.%s=%u", "fb0_.vscreen", "colorspace", fb0_.vscreen.colorspace);
	fb0_.size = fb0_.fscreen.smem_len;
	CHECK_NE(MAP_FAILED,
	(fb0_.map = mmap(NULL, fb0_.size, PROT_READ | PROT_WRITE,
	MAP_SHARED, fb0_.fd, 0)));

cosmopolitan/tool/viz/lib/writetoframebuffer.c

Lines 22 to 41 in e345b42

	void WriteToFrameBuffer(size_t dyn, size_t dxn, unsigned char dst[dyn][dxn][4],
	size_t syn, size_t sxn, float src[syn][sxn][4],
	size_t yn, size_t xn) {
	int ipix[4];
	float fpix[4];
	unsigned y, x, k, upix[4];
	for (y = 0; y < yn; ++y) {
	for (x = 0; x < xn; ++x) {
	for (k = 0; k < 4; ++k) fpix[k] = src[y][x][k];
	for (k = 0; k < 4; ++k) fpix[k] *= 255;
	for (k = 0; k < 4; ++k) ipix[k] = fpix[k] + .5f;
	for (k = 0; k < 4; ++k) upix[k] = MAX(0, ipix[k]);
	for (k = 0; k < 4; ++k) upix[k] = MIN(255, upix[k]);
	dst[y][x][0] = upix[2];
	dst[y][x][1] = upix[1];
	dst[y][x][2] = upix[0];
	dst[y][x][3] = 0;
	}
	}
	}

As for BIOS VGA that's equally simple to do. By default BIOS loads programs in teletype mode. With two lines of assembly e.g. int $0x10 you can put it in VGA mode and then just blit the pixels to a fixed memory address. There are some demo programs in the Cosmopolitan codebase that do this for CGA which is almost the same thing as VGA. Blinkenlights can even emulate it.

make -j8 MODE=tiny o/tiny/tool/build/blinkenlights.com o/tiny/tool/build/emubin/spiral.bin
o/tiny/tool/build/blinkenlights.com -rt o/tiny/tool/build/emubin/spiral.bin

[hippi777]

hi all! :)

i just came to suggest some nice gems to check them out:

• tekui: it is designed to be embedded on the 1st place, it has an isolated driver layer with linux fb, raw fb, direct fb, x, and w*ndos support included, it is c99, and it knows kinda much all i want for graphics, even if i wanna redesign it in the future to align it to a currently private project. see the last few messages on its mailing list for more info, and their website http://tekui.neoscientists.org/screenshots.html
• arcan: this has really nice features, however its not really mature, and its codebase is kinda ugly (ymmv) https://arcan-fe.com/about/
• tiny core linux: it has a thinned-down x that is just enough to run fltk
• temple os: it has a hypertext tui interface, while it has 3d graphics, but it is 16 colors only (Terry misunderstood God, the restriction of having only 16 colors was only for him, just to keep the code base simple, and to keep him away from wasting too much time on playing... btw, worry none, he went to heaven after all, cuz of his mission! :) ) fwiw, it supports fat, and there was a decompressor around, that was written to work on linux, so it should be possible to extract the plaintext codes

btw, u r about to go for x, but it can be considered to be depricated besides wayland, even if it will stay for a long while...

(ps: im only around to learn some nice hacks, and cuz the c lib benchmarks are impressive, but multi platform stuffs are actually out of my interest. i might have a high latency, cuz of an extreme amount of todo...)

bests, have fun! :)

[jart]

I'm closing this because Cosmopolitan intends to cater to the needs of people building online production services who want standard interfaces like serial / sockets / stdio / termios and tools like Wayland / X11 / Unity / TempleOS are the last thing they'd want going near production instances, although of the four TempleOS would probably be the least impactful since it uses VGA and SGABIOS is able to VGA displays back into SERIAL UART which effectively makes it headless once more. That said you can expect a change real soon where I'll be adding a linux kernel style negative memory managemer to your αcτµαlly pδrταblε εxεcµταblεs so that they'll be able to call C standard library functions like malloc() when you boot them on BIOS or UEFI.

[hippi777]

i didnt mean for those to be used as they are, on the 1st place, but basically as good resources... otherwise feel free to do whatever u want! :)