Tidying Window Manager code

I’m currently working on a translation of the Window Manager from assembler to C (originally started somewhere back in 2008.)

As a first set of changes to the assembler code to make it somewhat easier to work with I’m intended to submit some changes to do the following:

• Move data structure definitions out of .s (mostly Wimp01.s) files into .hdr files so they can be referenced by independently compiled .s files.
• Eliminate conditional compilation of some features that are now a standard (eg. ChildWindows)
• Eliminate long dead experimental code (eg. swapping to disk support – my hope is that if RISC OS gets paging support in the future it will be done in a much nicer manner.)
• Separate chunks of functionality into (hopefully) helpfully named files that are separately built and linked (rather than performing a mass include into a single compilation unit.)

Does anyone have any objections to any of these proposed changes?

Cheers,

Dave

Sounds good to me.

Eliminate conditional compilation of some features that are now a standard (eg. ChildWindows)

Be careful – there’s some old stuff which is still needed by PlingSystem (the !System distribution for pre-RISC OS 5 machines). Check the PlingSystem components file to see what versions it builds.

I’m currently working on a translation of the Window Manager from assembler to C (originally started somewhere back in 2008.)

I wonder how much glue will be needed to match the very-non-APCS API to a C module? Might be useful to extend the API to allow for lazy pre-emption.

Move data structure definitions out of .s (mostly Wimp01.s) files into .hdr files so they can be referenced by independently compiled .s files.

Sounds good.

Eliminate conditional compilation of some features that are now a standard (eg. ChildWindows)

Be careful. One of the nice things about the RISC OS code is that you can customise the build with numerous options and opportunities. I have looked at this in the code myself and I rather suspect removing such things would be “detrimental” in the long run.

Eliminate long dead experimental code (eg. swapping to disk support – my hope is that if RISC OS gets paging support in the future it will be done in a much nicer manner.)

Yeah, I saw some of that. I wonder what vintage it is – given the older machines had floppies and ST506 drives, neither of which were terribly fast. Or Acorn’s IDE interface (which was never fast)…

Separate chunks of functionality into (hopefully) helpfully named files that are separately built and linked (rather than performing a mass include into a single compilation unit.)

For the love of god, somebody – anybody – liberate us from the horror that is Wimp01, Wimp02, Wimp03… I made a start on this myself, but got bored and watched TV instead…
[in the “diaries”, you’ll see one of the first things JF did was make the source files indicate what their function was]

Does anyone have any objections to any of these proposed changes?

Possibly removing the plethora of options, but otherwise – “Like!”. ;-)

Don’t worry about me eliminating all of the options. I’m only planning to remove a select few that I believe are going to be impractical to maintain. I highlighted the ChildWindows option as a specific example of an area of code that I don’t believe is useful to disable (it’s been a standard feature in builds for all platforms since ~1997.) I wouldn’t be at all surprised if disabling it didn’t work any more, I doubt anyone has been too careful to maintain the old code path in the meantime (nor do I believe that it’s an effective use of development time to continue maintaining it assuming that it does still work.)

This sounds like an extremely worthwhile project. It’d be nice to get some progress updates as you go. Good luck to you!

* Move data structure definitions out of .s (mostly Wimp01.s) files into .hdr files
* Eliminate conditional compilation of some features that are now a standard (eg. ChildWindows)
* Eliminate long dead experimental code
* Separate chunks of functionality into (hopefully) helpfully named files

Moving the workspace definitions and deleting experimental code sounds good.

I’d prefer to leave in those switches that may appear to be always “on”, not because they’d be turned off (see Jeffrey’s note about PlingSystem) but because they’re useful to see which areas are touched by which switches. Case in point: I recently was hunting for a problem which only occurred in a UTF8 build, so I knew that only those bits inside UTF8 switches needed investigation, similarly if you’re rewriting things in C it’d be easier to get a basic system working then go back and add ChildWindows support – you can see from the ChildWindows switch which bits that implicates.

Renaming files in CVS doesn’t really work that well as the history remains with the original. But if you’re creating new files naming them sensibly is a must!