What interfaces do you feel are important to RISC OS development and testing?

46 posts, 13 voices

Pages: 1 2

Sep 22, 2022 1:02am Charles Ferguson (8243) 427 posts	I’m asking what interfaces people rely on in their development and testing of RISC OS components, DADebug. That’s pretty much what I use. Spew lots of information to the buffer, then call it up in a TaskWindow and read it. Hardly sophisticated. ;) I seem to remember a DADebug which was basically a system output buffer, so that you could see the behaviour of the code you’ve written. Essentially you modified your code to add in tracing and diagnostic output and print it out – ‘printf debugging’ in more general parlance, or ‘code instrumentation’ if you’re being a bit more formal. Assuming that’s the sort of thing you’re meaning, that’s a very rudimentary mechanism for debugging, but one that is still useful to many users. I shall explain what I see as the reasons for using such a module, and either you can add more about why that’s useful or correct any misunderstanding I have. Primarily the reason for doing debuggin by buffered logging within the application is that there is no mechanism to perform any other tracing within the system. There are no interfaces to say ‘I want to know when we get to here, and what the system state is’, or to stop the application and examine it, and even if there were, having a full record of the behaviour of the application is useful. Because the system offers no interfaces to debug your application you’re forced to use your own – and writing to a buffer is safer than writing to the screen (especially when the operations you’re performing are, or may be, within a redraw loop), or in the background. Similar buffered logging solutions exist within other modules – TML, DebugIt and SysLog spring to mind here, but all do the same thing. They provide an out of band logging system which avoids some of the problems with the application being unable to log easily. In most cases you might as well use a regular file on disc for the same purpose. A major down side to it is that you have to modify your code in order to use such interfaces. You have to know in advance that you need such behaviour, and then build in the right code to log things, then run and trigger that behaviour. Usually that’s not a huge deal, but it complicates your code to have extra diagnostics present. So that’s what I see as reasons for debugging that way. I’m not sure that testing code with DADebug would be necessary in many cases though. In most cases you can just log to the screen or to a file and see what’s going on in your test code – no need to introduce another module. But if it makes your life easier then fair enough. How does RISC OS Pyromaniac change that sort of thing. Not too much in some cases, but quite a lot in others – it depends on /what/ you’re trying to see as part of your diagnostics. If what you’re interested in is SWI calls, then it is relatively easy to enable SWI tracing and see all the registers going in and out of a system call. The SWI tracing interface also has special configuration that can help with diagnosing some calls within modules, albeit a little specialised. A small example may help to give you an idea what I mean with that. If you were writing a module which had a SWI which was doing something wrong, you could turn on the SWI Trap for that SWI call. Let’s say you were writing a driver that’s meant to turn on a light – your interface SWI MyLight_On doesn’t seem to work right, but only some of the time. What you might do is to run your application that calls MyLight_On many times, with a SWI Trap configuration of `MyLight_On:trace`. This ‘trace’ specification means that whilst you’re inside the SWI, tracing will be enabled and every instruction executed will be logged to the trace output (which can be configured – either stderr, stdout, or a file). When you leave MyLight_On, the tracing is disabled. Thus we can see everything that happens within that SWI call, and only within that SWI call. Hopefully this then tells you where your code has gone awry. Within Pyromaniac trace operations by default include information about the registers which were being acted on with each instruction. This means that you can see what was going on as it happened. To give a more solid demonstration of this, I’ve tried using the RISC OS Pyromaniac configuration file for running the desktop, with tracing enabled within the Wimp_ReadSysInfo SWI – the following command line: `./pyro.py --config-file wimp.pyro --config trace.switraps=Wimp_ReadSysInfo:trace` During boot the following was produced – apologies for being a little longwinded, but you can skip over it if you like. I’ll give a little explanation of some of the features afterward. 700654c: <SWIin> &400f2 (Wimp_ReadSysInfo) : enable tracing in SWI 3845ef4: STMDB sp!, {lr} ; R13 = &04107f68 3845ef8: MRS lr, apsr 3845efc: STMDB sp!, {lr} ; R13 = &04107f64 3845f00: MRS lr, apsr 3845f04: ORR lr, lr, #3 ; R14 = &60000013 3845f08: BIC lr, lr, #&c0 ; R14 = &60000013, #192 3845f0c: MSR cpsr_c, lr ; R14 = &60000013 3845f10: LDR r12, [r12] ; R12 = &07002c34 3845f14: LDR lr, [r12, #&3f0] ; R12 = &05400014 3845f18: STR lr, [sp, #-4]! ; R14 = &00000000, R13 = &04107f60 3845f1c: LDR lr, [r12, #&340] ; R12 = &05400014 3845f20: STR lr, [sp, #-4]! ; R14 = &00000000, R13 = &04107f5c 3845f24: PUSH {r1, r2, r3, r4, r5, r6, r7, r8, r9, r10, r11} 3845f28: STR sp, [r12, #&3f0] ; R13 = &04107f2c, R12 = &05400014 3845f2c: LDR lr, [r12, #&338] ; R12 = &05400014 3845f30: STR lr, [r12, #&340] ; R14 = &000039c0, R12 = &05400014 3845f34: LDR lr, [r12, lr] ; R12 = &05400014, R14 = &000039c0 3845f38: TST lr, #&80000000 ; R14 = &80000000, #-2147483648 3845f3c: ADR lr, &03846140 ; -> [&01010908, &00010901, &00010101, &00010100] 3845f40: LDRB lr, [lr, r11] ; R14 = &03846140, R11 = &00000032 3845f44: TSTNE lr, #1 ; R14 = &00000008 3845f48: BNE &03845F88 3845f4c: CMP lr, #8 ; R14 = &00000008 3845f50: BHS &03845F64 3845f64: MOV lr, #0 3845f68: STR lr, [r12, #&2dc] ; R14 = &00000000, R12 = &05400014 3845f6c: LDR lr, [r12, #&12c] ; R12 = &05400014 3845f70: TEQ lr, #0 ; R14 = &00000000 3845f74: MOVNE pc, lr ; R14 = &00000000 3845f78: CMP r11, #&3e ; R11 = &00000032, #62 = '>' 3845f7c: ADDLO lr, r11, #&2f ; R11 = &00000032 3845f80: MOVLO r11, r1 ; R1 = &00000000 3845f84: ADDLO pc, pc, lr, LSL #2 ; Table dispatch index #97 3846110: B &0384731C ; -> Function: SWIWimp_ReadSysInfo Function: SWIWimp_ReadSysInfo r0 = &00000007, r1 = &00000000, r2 = &07007b14, r3 = &00000064 r4 = &00000000, r5 = &00000000, r6 = &00000000, r7 = &00000000 r8 = &00000000, r9 = &00000000, r10 = &07007b04, r11 = &00000000 r12 = &05400014, sp = &04107f2c, lr = &00000061, pc = &0384731c CPSR= &80000013 : SVC-32 ARM fi ae qvczN SPSR= &60000013 : SVC-32 ARM fi ae qvCZn 384731c: CMP r0, #&1c ; Function: SWIWimp_ReadSysInfo ; R0 = &00000007, #28 3847320: ADDLO pc, pc, r0, LSL #2 ; Table dispatch index #7 3847344: B &03847418 3847418: LDR r0, &03847414 ; = &00000281 384741c: B &03845FBC 3845fbc: LDR lr, [r12, #&340] ; R12 = &05400014 3845fc0: STR lr, [r12, #&33c] ; R14 = &000039c0, R12 = &05400014 3845fc4: BL &0384F5E4 ; -> Function: pageintask Function: pageintask r0 = &00000281, r1 = &00000000, r2 = &07007b14, r3 = &00000064 r4 = &00000000, r5 = &00000000, r6 = &00000000, r7 = &00000000 r8 = &00000000, r9 = &00000000, r10 = &07007b04, r11 = &00000000 r12 = &05400014, sp = &04107f2c, lr = &03845fc8, pc = &0384f5e4 CPSR= &80000013 : SVC-32 ARM fi ae qvczN SPSR= &60000013 : SVC-32 ARM fi ae qvCZn 384f5e4: PUSH {r0, lr} ; Function: pageintask 384f5e8: MRS lr, apsr 384f5ec: STMDB sp!, {lr} ; R13 = &04107f24 384f5f0: LDR lr, [r12, #&33c] ; R12 = &05400014 384f5f4: CMP lr, #0 ; R14 = &000039c0 384f5f8: BEQ &0384F64C 384f5fc: LDRLT lr, [r12, #&344] ; R12 = &05400014 384f600: CMPLT lr, #0 ; R14 = &000039c0 384f604: BLT &0384F64C 384f608: LDR r0, [r12, #&338] ; R12 = &05400014 384f60c: TEQ r0, lr ; R0 = &000039c0, R14 = &000039c0 384f610: LDREQ lr, [r12, #&378] ; R12 = &05400014 384f614: BEQ &0384F64C 384f64c: LDMIA sp!, {r0} ; R13 = &04107f20 384f650: MSR cpsr_fc, r0 ; R0 = &80000013 384f654: POP {r0, pc} 3845fc8: POP {r1, r2, r3, r4, r5, r6, r7, r8, r9, r10, r11} 3845fcc: POP {lr} 3845fd0: STR lr, [r12, #&340] ; R14 = &00000000, R12 = &05400014 3845fd4: POP {lr} 3845fd8: STR lr, [r12, #&3f0] ; R14 = &00000000, R12 = &05400014 3845fdc: MRS lr, apsr 3845fe0: PUSH {r0, r1, r2, r3, lr} 3845fe4: LDR r0, [r12, #&2dc] ; R12 = &05400014 3845fe8: TEQ r0, #0 ; R0 = &00000000 3845fec: BEQ &03846014 3846014: POP {r0, r1, r2, r3, lr} 3846018: MSR cpsr_fc, lr ; R14 = &80000013 384601c: LDMIA sp!, {lr} ; R13 = &04107f60 3846020: ORRVS lr, lr, #&10000000 ; R14 = &60000013, #268435456 = bit 28 3846024: BICVC lr, lr, #&10000000 ; R14 = &60000013, #268435456 = bit 28 3846028: MSR cpsr_fc, lr ; R14 = &60000013 384602c: LDMIA sp!, {pc} ; R13 = &04107f64 4107f68: SWI &FEED05 700654c: <SWIex> &400f2 (Wimp_ReadSysInfo) : disable tracing in SWI Here’s some features you might be interested in from this… The beginning and end of the log indicate with `<SWIin>` and `<SWIex>` the reason that the tracing has become enabled, as it entered and left the SWI call. Any registers (or constants) which are referenced in the instructions as they are traced are listed in the comment field. The values before the instruction is executed are shown. The code at 3845f78 is part of the SWI entry sequence in the WindowManager, which is deciding whether it can dispatch to the SWI entry point: 3845f78: CMP r11, #&3e ; R11 = &00000032, #62 = '>' The trace shows the value of R11 and the value of the constant, as a decimal and a character, in case that is useful. From this we can see that the SWI offset is &32, and this is less than the &3e that we’re comparing to, which matters in the following instructions. A couple of instructions later the trace recognises that actually this is a table dispatch for offset 97 (because we’ve added some constant): 3845f84: ADDLO pc, pc, lr, LSL #2 ; Table dispatch index #97 This isn’t an especially important annotation in this case, but were we to be going to the wrong place, knowing the index that was being used for the dispatch might explain why you ended up in random code. The following lines then do the actual branch to the SWI handler code. The trace recognises the destination as a branch to a routine with a signature and annotates it: 3846110: B &0384731C ; -> Function: SWIWimp_ReadSysInfo Because we’re now entering that function the trace lists the name of the function and the registers that are currently present: Function: SWIWimp_ReadSysInfo r0 = &00000007, r1 = &00000000, r2 = &07007b14, r3 = &00000064 r4 = &00000000, r5 = &00000000, r6 = &00000000, r7 = &00000000 r8 = &00000000, r9 = &00000000, r10 = &07007b04, r11 = &00000000 r12 = &05400014, sp = &04107f2c, lr = &00000061, pc = &0384731c CPSR= &80000013 : SVC-32 ARM fi ae qvczN SPSR= &60000013 : SVC-32 ARM fi ae qvCZn The remainder of the code is mostly the same sorts of features as were just described, although the code which handles flag setting does make the bits that are being changed clear: 3846020: ORRVS lr, lr, #&10000000 ; R14 = &60000013, #268435456 = bit 28 Of course this is only helpful in this instance if you are looking at the insides of the SWI call. Instead you might be interested in what’s going on between two SWIs. Let’s say that you know that a problem lies between calls to Hourglass_On and Hourglass_Off (yes that’s a little contrived, but it’s not unreasonable). In that case you could use different operations on the SWI traps, setting the configuration to `Hourglass_On:traceon,Hourglass_Off:traceoff`. This would cause the tracing to be enabled from the entry to Hourglass_On, to the entry to Hourglass_Off, with all the code outside the SWI being traced as well at that inside the SWI. If that was your code that you were interested in, you’ve isolated it quite a bit. Of course you might not be seeing problems with a SWI, but with some actual code ranges. There’s more limited support in RISC OS Pyromaniac for tracing code, but it is possible to get reports on the state of the system whenever a function is called. The ‘Trace points’ allow you to specify a location that you want a report to be generated for. The location could be a hex address, or the location of a function in a module or application. The location is given as the name of a function signature, and will be resolved when the code in your application (or module) changes, so your code can be as dynamic as you like. It is actually a wildcarded function name, so you could say that you wanted to trap all calls to `MyList_` and any time you entered a function with that name, a report would be generated to give you information on what the state of the registers was. Let us say, for example, you were concerned with the memory allocation functions in your module. Let us say that the module is called ColourPicker, and the functions that do your memory allocation are called `da_alloc`. I’m choosing this beacuse I know the ColourPicker module has such functions and they’ve got a vaguely interesting call stack. To generate reports on just the calls to those functions you would configure the tracepoints to be `module:ColourPicker:da_`. Then whenever such a function was entered, you would get a report. The report would look something like this: 7055f70: <TRACE> ColourPicker:da_alloc r0 = &0000000d, r1 = &0000000c, r2 = &00000000, r3 = &00000001 r4 = &06802c88, r5 = &04107d98, r6 = &0680317d, r7 = &00000000 r8 = &00000001, r9 = &00000000, r10 = &0410021c, r11 = &04107d88 r12 = &070527bc, sp = &04107d5c, lr = &07052950, pc = &07055f70 CPSR= &80000013 : SVC-32 ARM fi ae qvczN SPSR= &20000013 : SVC-32 ARM fi ae qvCzn Locations: r4 -> [&00000030, &06803570, &00000018, &068032dc] in DA 'ColourPicker workspace' r5 -> "CMYKColour11" in DA 'SVC Stack' r6 -> "Click here to use one of the standard desktop colours." in DA 'ColourPicker workspace' r10 -> [&00000000, &00000000, &00000000, &00000000] in DA 'SVC Stack' r11 -> [&070528ac, &0680317d, &00000036, &04107d98] in DA 'SVC Stack' r12 -> [&e28dd004, &e3300000, &0a000005, &e5940004] in DA 'Module area', module 'ColourPicker' pc is DA 'Module area', module 'ColourPicker': Function da_alloc+&0 lr is DA 'Module area', module 'ColourPicker': Function lookup_insert+&b0 C backtrace: 7055f70 function lookup_insert Arg1: &06802c88 109063304 [&00000030, &06803570, &00000018, &068032dc] Arg2: &04107d98 68189592 "CMYKColour11" Arg3: &0680317d 109064573 "Click here to use one of the standard desktop colours." 70530f8 function resource_messages_alloc Arg1: &06802c88 109063304 [&00000030, &06803570, &00000018, &068032dc] Arg2: &0705744c 117797964 "Resources:Resources.Picker.CMYK.Messages" 705d48c function main_resource_alloc Arg1: &0705744c 117797964 "Resources:Resources.Picker.CMYK.Messages" Arg2: &07052f1c 117780252 Function: resource_messages_alloc Arg3: &07053148 117780808 Function: resource_messages_free Arg4: &07065dac 117857708 [&00000000, &00000000, &00000000, &00000000] 7057374 function cmyk_initialise Arg1: &07065d34 117857588 [&00000000, &00000000, &00000000, &00001220] Arg2: &00000000 0 Arg3: &07065d24 117857572 [&07065d44, &00000000, &00000000, &00000010] 705c9cc function main_initialise Arg1: &07065d34 117857588 [&00000000, &00000000, &00000000, &00001220] Arg2: &00000000 0 Arg3: &07065d24 117857572 [&07065d44, &00000000, &00000000, &00000010] Again, here’s some features of the report that might be interesting… First we open with the report that this is a trace point `<TRACE>` and the function that triggered it. The registers are listed, followed by the locations that those registers refer to, with either a small dump of a few words or the strings they refer to, together with the name of the region that the pointer is within (usually a DA). The pc and lr also include the names of the functions and relative locations. Because we recognise this as a C function call with a frame pointer, we can report the backtrace of how we got there. The backtrace includes the function names and the arguments (if they were placed on the stack and the compiler referenced them consistently, and if they weren’t modified). This makes it easy to see that the allocation here came from `lookup_insert` which was itself processing a messages file for the CMYK messages in `resource_messages_alloc`, etc. Again, some of the arguments to the functions are displayed with dumps of the values pointed to by them, or the fact that they are functions. That’s how a tracepoint could be used to find out about the execution of a specific function, but you could be even more general and ask it to trace `module:ColourPicker:` to know about every call into the ColourPicker module. Or even `` to know about every call to every function in every module or application space. That might be a bit slow, but if you want it, you can do it. There’s also watchpoints, which are a way to get a similar report but when a specific value in memory changes. You can ask for an address to be watched and when it changes a report like the above is generated. It’s also possible to get a trace of the recently executed code leading up to a report like the above, so if you know something about where things are failing but aren’t sure how it got there, you can enable the block tracing and every block of code will be tracked internally and reported when a report is generated. That’s a little more involved so I won’t give an example here. Of course you might not be interested in the code, but just the operations that were performed. For example, if you wanted to know what system variables were being set you might instead enable the `sysvar` debugging. For example turning this on and then issuing a `*IconSprites` command might give you some output like this: SysVar: Lookup 'Alias$IconSprites' after None (expand=3) SysVar: No variable SysVar: Lookup 'File$Path' after None (expand=True) SysVar: VarType = 0, Value = '@.' SysVar: Lookup 'WindowManager$Path' after None (expand=True) SysVar: VarType = 0, Value = 'Resources:$.Resources.Wimp.' SysVar: Lookup 'Resources$Path' after None (expand=True) SysVar: VarType = 0, Value = '$.RomResources.' Or if you wanted to know what OS_File operations were performed you might enable `osfile` debug and get something like this: Read catalogue info with path Filename = '$.demo' Path = None DirEntry = <DirectoryEntryNative('demo'/'demo', 2, &ffffff59, &c19b4256, 0, &33)> Read catalogue info Filename = 'WindowManager:Sprites22' Path = '@.' DirEntry = <DirectoryEntryNative('Sprites22'/'Sprites22,ff9', 1, &fffff958, &178bd2ca, 528468, &33)> (Just a random excerpt from what happens in the desktop start sequence here). RISC OS Pyromaniac doesn’t provide everything when it comes to debugging, but it can make the process of working out what’s going on easier and less intrusive on your code. I’m not sure if any of that is relevant to the type of debugging you might be doing, and I realise that I’ve reiterated some of what I said in earlier comments. But I hope it’s useful to know what you could be doing. However, what I was trying to find was what interfaces and tools you want / need for debugging – I’ve explained how Pyromaniac might help replace some of how I would use such a module as DADebug, but that may not be how you do your debugging and testing. If there’s more specific things that you do that are generalisable into what Pyromaniac can provide, that’s what I’m most interested in.

Sep 23, 2022 2:41am Rick Murray (539) 13840 posts	that’s a very rudimentary mechanism for debugging Yes. Coming from a world where it was a luxury to spit bytes to a serial port or fiddle with on-screen colours, the ability to dump formatted text into a buffer is a big thing. However I fully understand if people used to the features available elsewhere run away screaming. ;) A major down side to it is that you have to modify your code in order to use such interfaces. I tend to write it in as I’m going, wrapping it in ifdef blocks. Then one only needs to retrofit specific output around things that aren’t working correctly. Because the system offers no interfaces to debug your application you’re forced to use your own Yes, DDT is not terribly reliable, rather lacking in features, doesn’t properly multitask, slightly broken (), and useless for modules. Oh, and code built for debugging is fundamentally different to code built for release, you’re simply not comparing like for like – it’s rare, but sometimes (such as overrunning a string declared local and thus on the stack) behaviour can be notably different purely down to how the app is built. - One that annoys me is the memory access checking is a binary thing. Either on or off. There is no third option that permits access to legitimate out-of-app memory areas while faulting obviously duff things like &0 accesses. Because, recall, RISC OS is quite fond of passing around memory pointers, stuffing things into the RMA, and of course the use of DAs. All of which are “out of application workspace” and will cause a fault. So turn off the checking and suddenly all the unwanted null pointer errors are completely ignored. Not too much in some cases, but quite a lot in others DADebug only answers part of the question. It shows where we ended up. Depending on the level of output, it can be a fairly concise step by step account of the path the code took and the state as it happened (my logging tends to be rather verbose for that reason). What it can’t always say is why* this code path was taken. That is usually sorted out by adding more and more output until the reason manifests itself. Pyromaniac, on the other hand, offers what nothing on RISC OS can provide – that is a full unobtrusive trace of what actually happened (as opposed to what the code thinks actually happened). It’s essentially what Debugger ought to be able to do, taken up to eleven and dipped in chocolate.

Sep 23, 2022 2:55am Rick Murray (539) 13840 posts	but it would be a hack because the introduction of UTF-8 is incompete, rather than a solution to the problem. […] Personally I see this as kinda a no brainer. Certainly, and I completely agree with you. However be aware we are looking at it from two different angles. You are taking the approach of “doing it correctly” which is admirable, but means making some potentially fundamental changes within the OS itself – that of application contexts. I absolutely do not disagree here, replacing the system wide context with ones unique to each application could solve a lot of the peculiar quirks that crop up from time to time. However it’s a pretty big modification and is, therefore, about as likely to happen as a 64 bit version of RISC OS – that is to say, never. The approach I am taking is an Elastoplast in order to ease the transition from an eight bit character set to a global one. Yes, it is a hack, but it is a hack for a very specific purpose (and note that no font renderer can produce meaningful output from broken UTF-8 sequences), and given that it may only invoke some fiddling with the existing sources, it is doable. Could even be hidden within a switch like `Configure FontF*WithOutput On` ;) Certainly it is not a proper* solution to the problem, however given the lack of resources and developers (especially those with the knowledge to implement such a thing), a sticky plaster is our next best option. Or, you know, we can always just ignore the issue for another decade while the rest of the world moves further and further onwards. It’s a little embarrassing that a cheap MP3 player can handle non-Latin text in filenames and id3 tags while my preferred operating system struggles and falls over like a drunk old man.

Oct 2, 2022 8:09pm Charles Ferguson (8243) 427 posts	Because the system offers no interfaces to debug your application you’re forced to use your own Yes, DDT is not terribly reliable, rather lacking in features, doesn’t properly multitask, slightly broken (), and useless for modules. Your comment appears to be following the somewhat common assumption that what Acorn did is the way to do things and There Can Be No Other Way. It’s not quite what I was meaning by my statement. Specifically DDT is not part of RISC OS. DDT is a botch of epic proportions to work around problems in the system and subvert some parts by colluding with the system to inject itself. As you say it doesn’t work well. The reason is that it cannot* work well, even within the domain in which it is targetted. The system – RISC OS – does not offer the interfaces to debug the application. This was more where I was going with the statement. DDT is Not Fit For Purpose. And the reason that it’s not fit for it is that RISC OS does not provide any mechanism to allow it to do so. There are no interfaces within the system to allow you to interpose and provide diagnostics of an application in the manner in which DDT attempts. The comment about not being able to debug modules is moot – it would be a complete inversion of control to have a user mode application debugging a OS component, and whilst within RISC OS the idea of control is somewhat loose, that’s an architectural decision that would be difficult to manage. In the same way that GDB cannot debug an in system kernel module, neither can DDT. And you wouldn’t really want to. DADebug only answers part of the question. It shows where we ended up. Depending on the level of output, it can be a fairly concise step by step account of the path the code took and the state as it happened (my logging tends to be rather verbose for that reason). What it can’t always say is why this code path was taken. That is usually sorted out by adding more and more output until the reason manifests itself. This is why I didn’t ask ‘how do you debug things?’, but instead asked ‘what features and functions do you want to have to make debugging and testing easier?’. I was trying to work from your answer that you used DADebug by inferring why you did that, and explaining how you would do similar things under RISC OS Pyromaniac, in order to address the question. Were my inferrences correct? And are there more things that you would want in order to be able to debug and test?

Oct 2, 2022 10:13pm Charles Ferguson (8243) 427 posts	You are taking the approach of “doing it correctly” which is admirable, but means making some potentially fundamental changes within the OS itself – that of application contexts. … The approach I am taking is an Elastoplast in order to ease the transition from an eight bit character set to a global one. It’s a hack, but also it’s another instance of ‘yeah, we can’t do it well, so we’ll throw something else in that tries to make it better’. I keep stating that the most fundamental thing holding back RISC OS (other than an almost fanatical devotion to defending and repeating Acorn’s mistakes ¹) is that the system has a complete inversion of control to that of ‘modern’ systems, to which most of the complaints about the system can be resolved. And sometimes that’s fine – but the problem will be that it’s not like you’ll get it accepted into the standard FontManager as it’s undesireable as a standard way of doing things. So you will now have a ‘solution’ that’s neither good, nor adopted. However, feel free to prove me wrong about that… it shouldn’t be hard to produce a prototype algorithm that does what you need, demonstrate that it will work in the cases that you need it to and show that it isn’t disruptive. All before you even try to plumb it into the real system. I have tried to take the approach of ‘where do we need to get to and what steps are necessary to get there’, rather than ‘this solves a part of the problem but is ultimately a dead end’. ¹ … and a decreasing user base ² – The 3 major things holding RISC OS back are … :-D ² Due to the difficult of using the system and it’s limited relevance to modern software development. And the rest of the reasons.

Oct 3, 2022 6:21am Rick Murray (539) 13840 posts	the most fundamental thing holding back RISC OS (other than an almost fanatical devotion to defending and repeating Acorn’s mistakes) And there I was thinking it was a lack of developers. You know, the people who could make a UTF8ISH extension to bridge the gap without mucking with the real UTF-8… but the problem will be that it’s not like you’ll get it accepted into the standard FontManager Hmm, so does Font_Paint raise a service call or otherwise vectored? I suppose it must be for Printers to work (although I did note the collusion between FontManager and Printers). Perhaps ultimately a dead end, yes. But the problem is, lack of developers, lack of resources, etc etc. That kind of rules out major changes unless some motivated individual takes it on as a pet project.

Oct 3, 2022 9:06am Charles Ferguson (8243) 427 posts	And there I was thinking it was a lack of developers. You know, the people who could make a UTF8ISH extension to bridge the gap without mucking with the real UTF-8… “The 4 things holding RISC OS back… I’ll come in again.” The lack of developers is a problem, yes ¹. But these problems have existed for a long time – the lack of addressing the former results in the latter. However, a lack of developers is not the reason why the problem remains, but is a symptom – it is a lack of focus on the things that are actually important for the maintainability and longevity of the system. Most of the system is still in assembler – badly organised and badly named (eg Kernel and Wimp for a start, but others as well). Components collude with the rest of the system (eg any use of OS_ReadSysInfo 6). Components haven’t been replaced where they are no longer fit for purpose, and continue to be hacked upon (eg, keyboard handler, window manager). Components haven’t been split up where they perform different purposes and could be managed better in different parts (eg, Kernel subsystems, and the trend away from driver modules). Parts of the system that should have been abstracted years ago continue to be hacked upon with no end in sight and needing increasing understanding of the system to allow it to work (eg, the graphics systems and block devices). Plus there is my particular bug-bear that testing is near non-existant, still (eg, every single component in RISC OS ). Many of these things follow from the adherence to the belief that how Acorn did things is right and we cannot change things (which might be in approach, or in implementation). Many things were good, but there were missteps which are paid for later. We are living in the technical debt of those mistakes – and interest has been acruing for years with no attempt to pay it down. One of the reasons for this is the result of a difference in focus – one which has been wrong headed and is perpetuated to this day. The focus has been on outcomes, to the exclusion of design. The process of ‘we want to get X feature added’, which results in the necessary steps being taken from the outside of the system to add that feature and only that feature, usually by hacking parts of the system around to get them to work with the new features and not providing lower level plumbing to make them useful. Of course the UTF-8 introduction is a product of that – UTF-8 was desired for the STBs and so was added to the system. Within those closed confines that was fine being added to the Wimp and the FontManager. However, for wider adoption the system cannot work in that manner unless everything is aware that the language is UTF-8 – not an issue for the STBs because they were controlled systems without legacy. So small changes have been made to the system to make it functional and then… nothing more. The feature isn’t complete, but it’s met the basic goal of being able to render things in UTF-8. Trying to focus on the outcome and not the design of how you get there results in faster gains but ones that are not sustainable, and not manageable within a general purpose operating system. Hmm, so does Font_Paint raise a service call or otherwise vectored? I suppose it must be for Printers to work (although I did note the collusion between FontManager and Printers). FontManager can be vectored. The options exist, and it would be trivial to make do so. But I repeat what I’ve said in the last few posts, and back it up with my above argument. Don’t try to work out how you get it integrated into the system, and how you plumb it in first. Work on the algorithm first. Prove that it can work without even touching the complicated assembler code. Write it in a language that makes sense to you and is good for trying stuff out. Once you’ve proven that the idea works you can begin to think about how you might get it in. Otherwise you waste huge amounts of time trying to work on integration problems, stupid assebler issues and all the other miriad of problems that come with trying to add that experimental things to the insides of the FontManager, which might be fundamentally flawed before you get there. ¹ It would be remiss of me to not cite the explicit duplication of effort that is the Internet stack. Significant effort has gone into updating the stack, and to provide a more sustainable approache to supporting the system by making it updatable from the upstream source. This took considerable time and manpower. And then that work is being duplicated by separate people. This definitely backs up my belief that there is an attitude problem which persists – and definitely weakens the argument that there aren’t enough developers. If work that has been completed, is functional and is an improvement on the current system is discarded and reimplemented, rather than working with it, and moving to more important things, then clearly people have different views about what is important than I.

Oct 3, 2022 4:53pm Rick Murray (539) 13840 posts	The 4 things holding RISC OS back… Oh, I’m sure we can easily get that to double digits… Many of these things follow from the adherence to the belief that how Acorn did things is right and we cannot change things (which might be in approach, or in implementation). I feel that you are being rather unkind here. I don’t imagine there are many who are beholden to the idea that Acorn could do no wrong. The amount of bodge-words (TASK, WIDE, etc) scattered around the API, plus the lack of extensibility of the API (like, say, adding pen pressure to OS_Mouse’s coordinates) because it was written in stone for assembler programmers ought to have both been clues that there would be problems in the future. However, the real issue is the lack of developers. However you may care to spin it, there are fewer and fewer people capable of even understanding the source (due to all of that assembler) and also there are fewer and fewer people maintaining software. So we have an API from an OS that is increasingly an opaque black box that has to support a not insubstantial amount of functional software that is unlikely to ever be meaningfully updated. So it’s not a belief in Acorn being right, it’s simple mechanics of “breaking changes” being considered extremely poor form. However, a lack of developers is not the reason why the problem remains, Yeah, it kind of is. Unless you happen to be working on an AI bot to write code that can be used to fix all of the deficiencies… it is a lack of focus on the things that are actually important for the maintainability and longevity of the system. Ditto the above, over and over. You did a lot of this work when employed by a company that was actively maintaining the OS to paying subscribers. It’s an enormous shame that the enhancements that you provided haven’t made it over to this branch, but let’s just say “things were a bit shit in the past” and leave it at that. For this branch of RISC OS, none of that work has been done. We still have god-knows-what kicking around in the kernel, and bits poking and fiddling with other bits in ways they really shouldn’t. And I get the feeling that while there are bounties for doing things like fixing networking and whatever, there isn’t much appetite for messing with the underlying system that much because it’s a lot of tedious work to arrive at a situation where the system is more or less exactly the same as it is now. Well, not exactly the same, but from the outside it’ll be as if nothing has changed because there’ll be no visible enhancements. Just some mumble about better stability, which doesn’t count for a whole lot when ShareFS can lose its marbles and bring down the entire machine (as, cough, it just bloody did since it wasn’t going to handle opening a large (129MiB tar file)). I am sure that people would like a lot of things to be fixed. It’s fun to talk about rewriting the basis of RISC OS in C or something as a step towards an AArch64 version, but realistically the chance of that happening is about the same as me scooping the lottery jackpot the next time is passes 80mil… Most of the system is still in assembler Yes. With ever fewer people who are both proficient enough to wade through it, and motivated enough to want to do so. badly organised and badly named Oh god so very much yes. Components haven’t been replaced where they are no longer fit for purpose, and continue to be hacked upon (eg, keyboard handler, window manager). Let’s not talk about the keyboard handler, eh? I’m enjoying tea and cake and don’t really feel like throwing my plate across the room while swearing in multiple languages, which is kind of how I feel when going anywhere near that horrible mess. Components haven’t been split up where they perform different purposes Yup. Should WindowManager be responsible for tasks and task switching? It’s only sort of recently (in major OS releases, 3.7) that WindowManager stopped fiddling the memory itself to shuffle things around. Really, it only ever should have done that in RISC OS 2, and got split into logical units in RISC OS 3, but alas… Plus there is my particular bug-bear that testing is near non-existant, still (eg, every single component in RISC OS ). Perhaps because of the sheer difficulty of performing said testing on a live system. Certianly this is something Pyromaniac could help with, but before that it was… SysLog, spewage to a serial port, etc. Methods of debugging from the Dark Ages. The focus has been on outcomes, to the exclusion of design. Or perhaps adding features without disrupting too much other stuff? Of course, this isn’t always plain sailing. It’s been several weeks now that the machine habitually fails to shut down because the desktop shutdown closes down all active tasks and then uses WimpTask to do some final things, which causes the Clipboard Manager to be restarted as the lonesome task leaving the user staring at a blank grey screen. [ hmmm, didn’t you mention something about lack of testing? ;) ] The feature isn’t complete, but it’s met the basic goal of being able to render things in UTF-8. Yup. As you say, it’s fine for a closed system. Not so great for the ~~thousands~~ hundreds Latin1 apps kicking around. Prove that it can work without even touching the complicated assembler code. Oh, I don’t plan to go near FontManager. May well have a crack at writing a module in C to hook into the vector. As to how it’ll work, well, something like this: If we’re not in UTF-8 mode, exit without doing anything. If we are in UTF-8 mode, scan the string being passed to check for high bit characters. If any are found, are they legitimate UTF-8 sequences? If yes, then exit without doing anything. If we’re still here, then we’re in UTF-8 mode with a string that is not UTF-8 but does have high bit characters. So copy byte by byte to an alternative string buffer, expanding the top bit set characters into proper UTF-8 sequences – usefully there’s a table available, so one can simply look up the character in the table and translate the result to a UTF-8 sequence (though, most of the upper range of 8859/1 is the same in UCS, only using two bytes to express it). Once that has been done, fudge the string pointer to point to our fixed copy instead of the original. Complications: Random crap in the string – IIRC you can introduce colour sequences and such which may include high bit set characters, so this will need to be handled. Disabling all of this when printing is happening, this is only intended for desktop/UI use. That’s off the top of my head. Obviously a lot more work would be involved in actually designing and making something that, you know, works. But it’s what I’m thinking of. Otherwise you waste huge amounts of time trying to work on integration problems, Yeah… uh… is any Service Call raised when the alphabet is changed? I can see one (&43, 6) for when the keyboard changes, but not one for just the alphabet? stupid assebler issues Yup. Don’t plan to go there if I can help it. It would be remiss of me to not cite the explicit duplication of effort that is the Internet stack. I believe there’s a recentish topic where we all said the same thing. It… really doesn’t make sense to me why this situation arose. If work that has been completed, is functional and is an improvement on the current system is discarded and reimplemented, rather than working with it, and moving to more important things, A new stack is available, it works, it’s pretty much a drop-in replacement for the existing (nothing needed recompiling or whatever) plus it includes an open source reimplementation of the Resolver so… …anything else to do with networking that is any of the above is, frankly, crazy. In the 21st century there’s a lot that can be added to things like Resolver. mDNS, Service Lookups (those .local addresses people might have stumbled across), secure DNS (including over HTTP, or whatever brainfarts came out of Google recently) etc etc etc etc. Helping to add any of this sort of stuff to the new stack would be vastly more useful than……writing a new new stack. Personally, I would like to put this down as the result of a big miscommunication and believe that we’re not really going to end up with two entirely separate new stacks, because that just makes no sense at all. The work’s been done. Move on to what’s next on the ridiculously long checklist.

Oct 3, 2022 7:00pm André Timmermans (100) 655 posts	It would be remiss of me to not cite the explicit duplication of effort that is the Internet stack. Significant effort has gone into updating the stack, and to provide a more sustainable approache to supporting the system by making it updatable from the upstream source. This took considerable time and manpower. And then that work is being duplicated by separate people. This definitely backs up my belief that there is an attitude problem which persists – and definitely weakens the argument that there aren’t enough developers. If work that has been completed, is functional and is an improvement on the current system is discarded and reimplemented, rather than working with it, and moving to more important things, then clearly people have different views about what is important than I. Not only duplicated work, but the additions they make in their own corner are incompatible, and when you signal that to both sides, you get responses like “the structure follows the linux & bsd implementations” on one side and “the structure follows freebsd implementation and the RFC” on the other side, so both use “standard” implementations and the don’t even attempt to discuss together to resolve the issue. Are we seeing a new RISC OS war in the making?

Oct 3, 2022 8:04pm Charles Ferguson (8243) 427 posts	In the 21st century there’s a lot that can be added to things like Resolver. mDNS, Service Lookups (those .local addresses people might have stumbled across). I’m pretty sure we had that 15 years ago? charles@laputa ~/projects/RO/pyromaniac (joystick-experiment)> pyrodev --common --load-module modules/ResolverMDNS,ffa --command gos Supervisor help resolvermdns ==> Help on keyword 'ResolverMDNS' (Module) Module is: Multicast Resolver 0.04 (28 Jul 2019) Oh, apparently I updated it since then. charles@laputa ~/pro/RO/mod/ris/Sou/Net/ResolverMDNS (master)> git log \| tail -20 commit f3e18b90271cd8e3537aa2933c1f2c49bf0bddd8 Author: justin <> Date: Sat Dec 11 01:05:20 2004 +0000 Summary: Import of the multicast resolver client. Detail: * We can now resolve over mDNS. Admin: Tested locally and on build machine and appears to be working just fine really. Tag: ResolverMDNS-0_01 commit e3dcd50394cecafc96ae486d481d30f9dfcae427 Author: justin <> Date: Sat Dec 11 01:03:32 2004 +0000 Created VersionNum file It’s great to see RISC OS start to catch up but seriously, don’t for a moment think that any of this stuff is in any way special.

Oct 3, 2022 9:18pm Dave Higton (1515) 3525 posts	Where would I get a copy of the mDNS module and the documentation required to use it? I had no idea it existed. I must have duplicated at least some of its functionality very recently, through ignorance that this particular wheel already existed rather than a desire to re-invent it.

Oct 4, 2022 8:34am Chris Hughes (2123) 336 posts	Are we seeing a new RISC OS war in the making? No. No and again No. The two network stacks have come about for various reasons, this has been explained by both ROOL and ROD repeatedly. Basically ROD had a business customer who required a new network stack with IPv6 etc., and were prepared to pay for the work to be done in a certain time. No one at that time had taken on the bounty at ROOL, So ROD paid someone to do the necessary work to get in done in time. Both ROD and ROOL are working together and always have been. We now have a new network stack working now! and available to nearly everyone for free as a result of the business customer paying for the work. Let’s not start any more remours of RISC OS wars, its does not help the platform at all. Oh as an aside ROOL will be doing a Zoom talk to WROCC in November.

Oct 4, 2022 12:17pm Rick Murray (539) 13840 posts	So ROD paid someone to do the necessary work to get in done in time. Yup, this we know. And the second stack….? more remours of RISC OS wars Now now. These days not so much a war as two old geezers shouting at each other in a pub. ;) Where would I get a copy of the mDNS module Remember who you’re talking to. through ignorance that this particular wheel already existed Not a surprise. Pretty much the only references to mDNS in the entire forum are your thread on printing. We’ve mentioned the lack of an mDNS service and your implementation of it numerous times and only now does it appear that there’s such a module but…not for us. Helpful. don’t for a moment think that any of this stuff is in any way special. Well, Dave’s hard work has opened up the ability to print to AirPrint/IPP printers, that is to say just about everything modern that works via WiFi. And “it just works” without a lot of headaches. Frankly, I’d call that pretty f**king special.

Oct 4, 2022 1:04pm Chris Hughes (2123) 336 posts	So ROD paid someone to do the necessary work to get in done in time. Yup, this we know. And the second stack?.? Personally I can’t see the point in ROOL carrying on with their version of the stack. I assume there is a special reason. rather then ROOL prefer it in BSD and ROD have done it in FreeBSD instead. But they have to sort it out between them and they do talk to each other on a regular basis. Dave’s hard work has opened up the ability to print to AirPrint/IPP printers, that is to say just about everything modern that works via WiFi. And ‘it just works’ without a lot of headaches. This is very good news, opens up a world of new printer options hopefully.

Oct 4, 2022 8:59pm David J. Ruck (33) 1635 posts	Personally I can’t see the point in ROOL carrying on with their version of the stack. I assume there is a special reason. If the performance is better than the ROD stack, it’s well worth doing. If you haven’t noticed any difference, just try to VNC in to a RISC OS machine with vncserver and the old and new stacks.

Oct 4, 2022 9:18pm Charles Ferguson (8243) 427 posts	Where would I get a copy of the mDNS module and the documentation required to use it? I had no idea it existed. I must have duplicated at least some of its functionality very recently, through ignorance that this particular wheel already existed rather than a desire to re-invent it. You can basically assume that I’ve played with most things, even if I’ve not done many of them well. Ok that’s a huge exaggeration, but meh… Some of the things that reached the point of being allocated can be found here: https://usenet.gerph.org/Allocations/Allocations.txt – that’s my ancient a file tracking the allocations that I’d made. There’s way more than that which weren’t interesting enough to make it to allocations. But the ResolverMDNS was one component that I was expecting to be in the later Select release – probably 5 or maybe 6 – as it needed some polishing, testing and some service call work. Plus the MDNSService toolbox object gadget wasn’t that nice to use for browsing, and it could really have done with some more options, like the printer dialogue has so that you can turn parts of the object on and off, and supply more information, like when you’re browsing a particular printer, it could tell you what the printer was and its protocols before you attached it. The TXT record format for the various browsed objects differs depending on the service type, IIRC (can’t remember the details as it’s been a long time, but I remember there’s a big list of the properties used by the protocols in the mDNS documentation). Similarly, although I am sure that I updated Resolver to support using the ResolverMDNS, alongside Freeway Hosts, and NetBIOS names from LanManFS, it doesn’t appear in the source I have here, so it’s likely that got lost at some point in the past. The ZeroConf and ResolverMDNS modules, together with the RouterDiscovery module (and improvements to Resolver to handle rebalancing DNS servers, using Freeway and LanMan for its name services) were all intended to allow easier use in a dynamic network environment – ie mobile networks. The GenericPPP module was intended to allow connections which were tunneled using PPP such as some VPNs and the PPPoE module provided PPP-over-Ethernet (and together with the authenticator also allowed RISC OS to perform as a PPPoE concentrator service). Together with the Wifi interface that STD produced it made a good foundation to use with a portable device. To bring that back to the reason that I was explaining this earlier… these components and the way that they dovetail together were part of the network side of the solution to ‘RISC OS should be able to work in a portable’. There was a goal in mind. There were structured steps and system was updated across the board to move in that direction. You build on the foundations, you fix and restructure things, and you create new things in a structured way so that they can be used in an general environment. I guess my point I’m trying to return to is that if you have a goal in mind and you build the parts that you need to get there in a general way and you step slowly towards the goal you’ll get there. And this was just me doing that work – ok that’s a bit unfair as there were other people I worked with but still, all the things mentioned above were things that one person did ¹. Having the right goals and working towards them in a structured and steady manner means that you solve problems. Maybe not always the problem that you set out to solve, but still… If you’ve got no clear aim and if you’re just hacking stuff around the edges and not putting the work in that you need to do, then you’re going to… well, end up where you are. ANYHOW…. I’ve just dumped some of the parts of the module into an archive – I don’t have the original release and in any case you couldn’t use the !mDNSBrowser application because it relies on the ScrollList table extensions. You’ll find it at https://usenet.gerph.org/Internet/ResolverMDNS.zip – it appears I never got around to writing proper documentation for the API, although the test code shows the principles. Some of the interfaces aren’t that great. For reception you require an Internet stack that supports IP_RECVIF and IP_RECVDSTADDR. The latter is supported by Internet 5. The former requires the version from Select, or a suitably updated stack. You will find some information about the ResolverMDNS module here: https://gerph.org/riscos/ramble/internet.html#ResolverMDNS You will find information about the IP_RECVIF here: https://gerph.org/riscos/ramble/internet-core.html You will find the documentation for IP_RECVIF here: http://www.riscos.com/support/developers/riscos6/networking/internetmodule.html I’ve found another archive that has the !mDNSBrowser and the !WebJames modified to announce itself, but they’re both 26bit… I don’t know where the sources are off the top of my head. There’s also a ToDo file sitting alongside it saying: ToDo: Additional TXT records Ability to generate notifications (services ? UpCalls ?) for browses? So at least my recollection about the services was correct. Date on all these files is Dec 11-20 2004. Oh, I wasn’t looking far enough inside Resolver. Although it doesn’t issue requests to the module, it does announce itself as a DNS server, over MDNS – the `server_init` ends with: /* Try to register our name with ResolverMDNS / port = ntohs(sp->s_port); _swix(ResolverMDNS_RegisterService,_INR(0,6), 0, 0, / name is host name / "_domain._udp", NULL, / Local domain / port, NULL, 0 / No TXT data /); And the `server_close` includes: err = _swix(ResolverMDNS_DeregisterService,_INR(0,6), 0, 0, / name is host name / "_domain._udp", NULL, / Local domain / port, NULL, 0 / No TXT data */); ¹ People I have worked will certainly say that keeping me on track and not getting distracted by other little things is sometimes a challenge, but that’s a slightly different issue.

Oct 4, 2022 11:13pm Charles Ferguson (8243) 427 posts	Perhaps because of the sheer difficulty of performing said testing on a live system. Certianly this is something Pyromaniac could help with, but before that it was… SysLog, spewage to a serial port, etc. Methods of debugging from the Dark Ages. Which is why you don’t write tests for the live system first. Doing system integration testing as your only way of testing is madness. Yes, it’s still better than no testing at all, but people need to stop using the argument that it’s hard to test on RISC OS because it’s inherently broken in design, so they won’t bother. In exactly the way I suggested to you in a number of my replies. DON’T TEST IN THE LIVE SYSTEM. Abstract the thing you want to test. Make it isolated. Bring it down to a level where you CAN test it reliably. And stop building systems that are inherently difficult to test in the first place. If you build your code in a way that can be tested, then you can test it better and the mechanism you use for debugging is near irrelevant because your tests will tell you where to look and how things are failing. Yes, there will be complicated cases that become intractable withouty a time travelling debugger, but when you have no tests and argue that it’s hard to test and just want to write stuff to run in-situ, you miss the point and your statement that you cannot test in a live system is self fulfilling – you cannot test because you’re not even trying to do things the right way to make it possible to test.

Oct 5, 2022 8:09am Chris Hall (132) 3554 posts	I think either a SATA interface or an m.2 SSD interface, either of which gives fast storage. Don’t think RISC OS is fast enought for a USB 3 interface. Perhaps also the eMMc interface on the CM4.

Oct 5, 2022 8:22am Chris Hughes (2123) 336 posts	If the performance is better than the ROD stack, it’s well worth doing. If you haven’t noticed any difference, just try to VNC in to a RISC OS machine with vncserver and the old and new stacks. I don’t seem to have any issues doing that with the new stack, and found it faster then before. I have used three different VNC viewer on other machines to access RISC OS running vncserver.

Oct 5, 2022 8:53am Andrew McCarthy (3688) 605 posts	If possible, can we move the network stack comments to either here or here, or create a new thread to keep this one relevant to the question raised at the start of this thread? Thanks.

Oct 5, 2022 3:00pm Charles Ferguson (8243) 427 posts	I think either a SATA interface or an m.2 SSD interface, either of which gives fast storage. Don’t think RISC OS is fast enought for a USB 3 interface. Perhaps also the eMMc interface on the CM4. My question was about RISC OS interfaces. Not hardware interfaces. RISC OS Pyromaniac only provides access to devices at the RISC OS interface level. So if there were a RISC OS interface for accessing SATA devices, a SATA emulating driver could be created. But interfacing the actual hardware in different forms is something that is best managed with actual harder. Only the RISC OS interfaces are dealt with in RISC OS Pyromaniac. For example, the CDFSSoftPyromaniac module provides access to a CD-like device, because the CDFSDriver interface exists. Or the IIC module provides emulations of certain hardware so that drivers can work to it, because the IIC module provides the driver interface. There are actually a few hardware accessing devices in RISC OS Pyromaniac, but they’re not actually drivers in the sense that RISC OS deals with them, but implementations that provide access through to hardware. So if you had a hardware device that you wanted to expose through that mechanism you certainly could. Indeed, that’s how you might implement a driver model – it’s easier to implement a driver model using an emulated device.