PSVUNT - proof of concept

You probably haven’t missed that I have strong feelings about Store’s inability to highlight changes (and no, having to log in is not an option, such a thing shouldn’t be necessary).

So, this afternoon/evening I wrote a module from scratch that keeps an eye on what Store is up to, and keeps track of your downloads and Store’s catalogue updates.

PSVUNT stands for PlingStore Version Update Notification Tool. When it spots an update, it will get a textfile listing them opened in your editor. You know, until Store finally gets the ability to do the bleedin’ obvious for itself.

http://heyrick.ddns.net/psvunt/

The module name (and *commands) are not registered, this was just a hack I did today. The code is licenced EUPL v1.1 so you get the source.

I hope it proves useful to somebody, and moreso if it convinces the author of Store to highlight available updates as a matter of course from the outset, logged in or not.

Hey Rick,
useful I would say, I actually noted the “issue” in Store… Right now I am under a lot of more work (from day job due promotion) plus a bunch of certifications that I need to renew, but I’ll give it a try next weekend for sure!

Thanks a lot! :)

A short while ago, when talking about self-terminating modules, I was asked to give an example of a use case.

Well, there’s one right here. Because of how the setup works, it has to be implemented as a module. Yet, while there is no harm in leaving the module running once Store has been quit, there’s also no point in doing so. As such, it would be useful to hook into ServiceCall &53 to self-terminate when Store exits. Only… there’s no clean pleasing API way for a module to quit itself.

So, there. A use case.

I see your problem!

Can you link to the previous thread?

I guess the question is, when would your module die?

But also, where do you go afterwards?

Can you link to the previous thread?

https://www.riscosopen.org/forum/forums/2/topics/15434

when would your module die?

As explained above – when it is no longer needed.

where do you go afterwards?

What do you mean?

To answer the ‘where do you go’ I would say that you (the module) remain in memory but no longer being pointed to by anything. As other programmes request memory you (the module) will suffer a slow and agonising death, slice by slice. In space no-one hears you scream. The point is that you cannot kill the module whilst executing it. You have to find some external routine that will remove the module from the list of modules.

I mean ‘where’ after you call the OS to terminate your module in the service call handler. If it happens immediately, you can’t return to your service call handler, because you’re not there any more. ‘When’ means, would it happen right there and then during your service call handler and then somehow return into the kernel service call broadcasting code, or at some other point, like in a callback.

That is the most graphic description I’ve ever seen of a module’s death :-o

in memory space no-one hears you scream….

@ Stefano Bertinetti

in memory space no-one hears you scream….

Not true! 0xAAAAAAAA … ;)