Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A600 Memory

AuthorTopic: [C] CLI Window Pointer  (Read 1264 times)

0 Members and 1 Guest are viewing this topic.

Offline Thomas Richter

Re: [C] CLI Window Pointer
« Reply #15 on: February 13, 2018, 08:30:21 AM »
Quote from: nyteschayde;836071
Care to document how and demystify it?
Not really. Look, this is really stuff you should *not* use. It is a deprecated interface, and programs must not depend on this anymore. Only BCPL programs could, and this only due to the Tripos legacy. It was never an official part of the interface.

Just to give you an approximate idea: The GlobVec is something like the collected "global data" of a C program. Every BCPL program comes with it. Now, the way how Tripos is married with BCPL means that the operating system (Tripos) ingests certain of its Os globals into the program area of its executed child processes - pretty much in the same way how we handle shared libraries today. As such, it had access to Tripos "globals" such as the CLI, the file handles, but also service functions Tripos provided to its clients.

BCPL programs did not open "dos.library". It rather got access to the dos.library functions due to its globvec, which was merged by the BCPL standard startup code with the global data of the program such that you could call Tripos functions as if these were your own program functions.

A side effect of this is that dos.library does not (even today) depend on A6 being loaded with the library base pointer (this convention does not exist in BCPL).

The GlobVec contains look-alikes of the functions you find in dos.library today, but also a lot of the "post 1.3" area, even in the old-ages. As such we have rdargs(), but also buffered I/O (fread, fgetc, fwrite, fputc are part of the kickstart 1.2 globvec and not accessible from C), some math helper functions, also co-routine handling (not even available to-day, but for good reason) and a lot of other junk, such as Exit().

One way or another. It's nothing you can depend upon these days, even more so as some of the pecularities of the GlobVec changed - in so far as programs no longer receive a "private copy" of it, but only the "dos.library internal global version" of it.

As a net-result, over-loading GlobVec entries does no longer work, and thus some 1.2 binaries no longer work. Ed v33 is probably the most known example of things that broke.