Asm and BASIC Fun: SmWM
Home RISCOS News Docs CBM128 Files Links Apple2
Page last updated on Jan 26th of 2021.
Simple Micro Window Manager:

SmWM
Began as a simple toy Window Manager..
Now has evolved to be a Window Manager that can replace the one,
that is part of RISC OS. This was not the initial goal.
Goal is to keep it simple and small while being functional.

This began with the intent of making a very simple Window Manager toy program, just something small and fun to play with different Window Management methods, and concepts. As the idea got bounced around it evolved into the insane project it now is, to replace the RISC OS Window Manager with a version written in compiled BASIC V (with some of the task switching code in ARM Assembly). It should use AMBControl on RISC OS 3.6 and newer to manage task-slots, if all goes to plan that is.

The intent as it stands is to implement a window manager that can run 95% of WIMP based RISC OS programs correctly. No significant extras, just a bare working system is the goal. Once the Window Manager is working correctly I may add some support for NewLook type sprite themes.

I am doing most of the testing on RISC OS 3.11, so that I do not have to reboot my primary system with each test (can use an emulator to test). Though I do periodically test the current state in RISC OS 5.2x, just to be sure it works correctly there.

The level of feature compatibility is intended to be equal to that of the Window Manager in the RISC OS 3.5 ROM, as this is a reasonable level to target with modern software. I am not doing any of the nested WIMP stuff, and I do not know if those modules can be used with this small Window Manager, it is outside the goal. I chose to target functional compatibility with RISC OS 3.5 as that is a good balance point to target for modern RISC OS applications, and many WIMP based applications run well with that Window Manager. The Nested WIMP is convenient, though not absolutely needed for anything for which it is used (there are other ways to implement the same thing in the older WIMP), and I am aware of very few applications that require the Nested WIMP (exactly two that I use, maybe a few more that others use). Besides this is mostly a Toy, unlikely to be used as a regular Window Manager replacement by anyone, more of a curiosity than anything.

There are likely to be rarely used features of the RISC OS Window Manager that are missed out by this replacement, the goal is to keep it simple and get it working so I hope this can be forgiven. It feels a bit crazy to be writing a set of modules of this low level of a nature in BASIC V, though it will definitly show that BASIC V is a much more capable language than people give it credit for.

For the time being I am compiling with !ABC, as it does the job needed. In the future if a better BASIC V compiler exists, and I can get it I will use that, as some of the limits of !ABC can make some things more interesting.

When I get this complete there is a high probability that I will begin working on rewriting it in Assembly, then rewriting it again in C. The Assembly version I will try to make usable by anyone that wants to play with ideas for implementing replacement WindowManagers for RISC OS. The C version is to provide a RISC OS API compatible Window Manager that can be ported to non-RISC OS operating Systems (though not much use without also porting a few other modules).


When things get far enough, and I do not have too many simultainious projects, I intend to see what it would take to implement a RISC OS ROM that starts the WindowManager much earlier in the sequence, even before the Superviser CLUI that runs the !Boot application. This should make it possible to (with the aid of a module to add some commands) run parts of the boot process in parallel, as some things could be multitasked and work well. This would also call for a rework of the TaskWindow module as well, though likely to be well worth it.

This could be looked as a kick in the back side to get some proof of the fact that it is possible for people to rewrite parts of the OS, and there is nothing wrong with having multiple alternitives available for a given component. Different people can write replacement parts of the core OS with different useful extra features, and it would likely inprove the draw of RISC OS to those new to the platform. This is a large part of why Atari TOS compatible systems are still going strong today, people were not afraid to write and distribute replacements for major parts of the OS, with different extra features. In RISC OS this lends a lot of possibility, especially as we look at the ways to improve multicore support (which we have had at least since 2016), and accessing SWIs provided on the OS core from secondary cores (it has already been shown that different people have differing ideas of the best way about this).