Detecting and encouraging removal of obsolescent calls in applications

We are reaching the point where some work has been done (GraphicsV) and some will be done (multi-processor support) which will deprecate a significant number of calls or ways of working in favour of non-blocking calls or where a new API is preferred over an old one.

Through the package management stuff we have made updating these apps relatively painless if they are currently maintained and it is known that changes need to be made.

It would be helpful to take a more pro-active stance to helping application developers with this change. Where calls are deprecated or alternative calls should be used, flagging these calls unobtrusively in a development environment would be useful.

There are various options – a global build switch in the ROM with unobtrusive logging so every time an obsolete call is made it is logged would be one way. Or taking the SWIStat, VectStat type stuff Druck did but presenting obsolete calls only would be another.

The idea would be when components are updated to be thread safe, developers know whether their applications need updating which will hasten the transition before there is a problem with incompatibility later on.

Yes, it might be worth considering a debug/development build of RISC OS which adds a SWI DADebug_Obsolete and then adds code to calls known to be ‘old’ to call this SWI. The end result of this being that the calls would be logged someplace.

I think ‘in source’ with a build switch / assembler macros is the way forward.

You might want to for example, obsolete a particular variant of a call, or particular entry values (a reason code of a SWI for example).

Given a standard global symbol / macro set this would be quite easy – then all that remains is identifying which calls need flagging.

Output would be best to a SWI – this could then allow real time display update or sys logging or both.

How about, when the new SWI is proven, to remove the old one from the ROM and put it in a ‘legacy’ module?

This module (which could contain lots of legacy stuff) could either be started by default by a setting in configure, or rmloaded as needed.

There could be debug versions that records what is being used and by what.