The Sinclair QL Forum

Hi,

I have thinking about Things recently, I am wondering if a Thing creates a new Thing, does that new Thing belong to the Thing that created it?

I see no one uses the Thing system in the Extended Evironment 2.

I was going write a simple drawing program that can be enhanced with plugins, which would a Thing.

When I can get away from the hardware, I get something in assembler written

Derek_Stewart wrote: Tue Feb 21, 2023 3:51 pm I see no one uses the Thing system in the Extended Evironment 2.

Everyone who uses non-prehistoric SMSQ/E uses Things all the time:

• HOME_DIR, RECENT and so one are all extension Things that you call (for example) from S*BASIC
• using Fileinfo II? It provides a whole bunch of Things that you constantly use
• You use the ButtonFrame or the Scrap? All Things.
• None of the above? Well, you use SBASIC. That's a Thing as well.

If you don't want to simply use a Thing but rather create one yourself, create a program with EasyPtr - It makes your Menu into a Thing to be able to find it from SBASIC.

George Gwilt (anyone heard of him, recently, BTW?) has written a set of excellent articles in QL Toady on Things' usage and creation.

tofro wrote: Tue Feb 21, 2023 11:54 pm George Gwilt (anyone heard of him, recently, BTW?)

George seems to have vanished off the planet. I've not had a sight nor sound since well before Covid. I hope he's alright.

Cheers,
Norm.

tofro wrote:- George Gwilt (anyone heard of him, recently, BTW?) has written a set of excellent articles in QL Today on Thing usage and creation.

I thought I would see how many things are created by one of my QPC/SMSQE setups. The answer is 47. I know what 36 of them do but not the rest, and I have no idea how to create one. I do not want to use EasyPtr, but do want to learn more about Things. I would like to read George Gwilt's articles. Are you able to list them?

As Derek remarks: Things do not seem to be a thing of interest on this forum and in the absence of a reply to my post I have spent a few hours collating all that I could find on the subject. The results might prove to be useful. I have scanned through the documents and have succeeded in creating an executable Thing written in SBASIC. I have also managed to create an executable Thing the creates another executable Thing.

My answer to Derek's original question - " If a Thing creates a new Thing, does that new Thing belong to the Thing that created it? " is , in the case of executable Things, no. I see no evidence of ownership on my setup.

I Know very little about Things, but, as shown in my previous post, I use them, and this may be true for other forum members. I thus attach the following documents:-
1. An extract from Stella documentation outlining TT's concepts of ownership and usership. - ownership.pdf
2. Four documents probably written by TT on the release of SMS2 - Thing entry, ext,procedures and vector .rtfs in .ZIP form
3. All the articles I could find on searching for thing in QLtoday - ql today things.pdf in .ZIP form

Many years ago, I was writing Assembly Language articles in QL Today and I decided to take a look at things. Back then, it seemed that the only person writing Things was Jochen Merz, I emailed Jochen and suggested an article for QL Today would be nice, on the matter of writing Things. He did this, but as far as I was concerned, and remember, it didn't cover anything like what I would have expected.

The SMSQ/E Reference Manual, available from Wolfgang, is equally as devoid of information that would make it "easy" to write a Thing. Subsequently I gave up on the idea of writing about these Things!

Bear in mind, I'm getting on in years, and it could be that the problem is me, and not the articles!

Cheers,
Norm.

Norm wrote:-Many years ago, I was writing Assembly Language articles in QL Today and I decided to take a look at things. Back then, it seemed that the only person writing Things was Jochen Merz, I emailed Jochen and suggested an article for QL Today would be nice, on the matter of writing Things. He did this, but as far as I was concerned, and remember, it didn't cover anything like what I would have expected.

TT's four documents might help, but they were written for SMS2 which was the first OS with Things embedded in the system. The information might not be applicable to SMSQ and SMSQE. I do not know how many copies of SMS2 were distributed, but I think it was about the same as the number of Q68s sold to date, ie not many. The total number of Thing users in the world may number less than 500.

Another reason for the lack of interest in Things may be because the majority of forum members do not use SMS.

I don't know who wrote the 47 Things listed in my recent post (but I will find out). I think that JM wrote only a few of them.

Hi Derek!

A couple of thoughts, though not necessarily authoritative...

1. Ownership of 'sub-things': From my own reading (mostly, Jochen's documentation), the concept of ownership of Things expands upon QDOS's usual sense of a Job owning a resource (or other Job), in that, if managed correctly, Things also maintain their own 'Usage' list of the Jobs currently USEing them, in addition to the ownership of the Thing itself (which is really just a memory allocation). There doesn't appear to be any 'ownership hierarchy' maintained beyond the usual QDOS Job tree.

Like any QDOS memory allocation, you can explicitly specify the (Job) owner of the Thing at creation time and thus, if a code-type Thing goes and creates a new Thing, the same ability to explicitly specify the new Thing's owner is available. If specified as '-1', then the (Job) owner of the original Thing will be applied to the new memory allocation/Thing, like any other resource.

The subtlety comes-in when a Thing itself is (force) removed - it will trigger the currently owning Job to also get killed (because the Job IDs are recorded in the Thing's Usage list) - along with any child Jobs in the usual QDOS way. If one of those Jobs happens to own the new Thing, then that too will get removed, and so on. Setting the Thing owner to '0' at creation time will, as with other resources, protect it from getting removed except from an explicit (force) Remove call.

[EDIT] Reading that back to myself, I see it could be more concisely stated as "Things have no ownership hierarchy of their own, but simply inherit the ownership of the Job that created them, or else was specified at creation time. In this regard they are no different from any other resource owed by a Job, e.g. a file, and, like a file, don't 'own' anything for themselves."

Not sure if that helps at all???

2. Creating a Thing: depending how you do it, its actually pretty straightforward and can be easily coded even without the help of HotKey System2 or SMSQe. A good example of creating (and later finding) a Thing can be found in SimonNG's DIYToolkit 'FlexiNet' (Vol. Y) - and with a bit of adaptation, I was able to use his approach successfully in the ND-MQ Net driver (for the QLUB.) The adaptation was to make it interact nicely with SMSQe, which, as a more recent extension, also adds (and expects) a simple byte-hash of the Thing name to be recorded in its linkage block. The ND-MQ Thing is a simple sort of creature, rather than a code-type thing, but creating them 'by hand' shouldn't be any different, or difficult. I used SnG's code as a base as I wanted the ND-MQ driver to run in both SMSQe as well as legacy QDOS without relying on the presence of HK System2.

Good luck

Hi Martyn,


It looks like I am getting Jobs confused with Things.

So, a Job can create a child Job, which can be removed without any influence to the Parent Job?

That said, if the child Job creates a Thing, and the Thing is removed, the child Job would be removed, what effect to the Parent Job?