TaskWindow could do with some improvement

This may not seem very important, but it’s related to the Unicode support I continue to work on.

Each TaskWindow has its own Spool File Handle (OS_Byte 199) – so if you type *Spool foo in one TaskWindow, you don’t end up with desktop plotting or the output of other TaskWindows in your foo file. Good. As you’d expect.

However, TaskWindows do not have their own (and in fact ignore the) Disable Spooling bit in WrchDest (OS_Byte 3/239) because TaskWindow ignores WrchDest completely.

This has the unfortunate effect that if a TaskWindow child tries to temporarily disable its spooling it won’t work… for that child… but it does disable spooling everywhere else. So if you type *FX3 16 inside a TaskWindow, then press F12 and type:

*Spool foo
*Help Spool
*Spool

…you’ll get nothing in the spool file.

UNDER NO CIRCUMSTANCES type *FX3 2 in a TaskWindow. Disappointment will entail.

(And also don’t type *FX3 32 at all, but that’s because of a bug introduced in Arthur and never noticed)

Conclusion: I think TaskWindow should implement a local WrchDest (and, therefore, emulation of the other bits therein… here be dragons) to fix this nonsense.

I’m acutely aware that there is a slippery slope here – the fact that you can’t type *. in a Zap TaskWindow and get sensibly-formatted output is embarrassing, but beggars the question “How far is too far?”.

How far is too far?

When you’re falling off a cliff with your hands over your ears and your eyes shut.

Oh…….Wait…….

Carry on as you were.

Carry On As You Were

With me in the Kenneth Williams role I presume.

To clarify the *. observation: CAT tries to format its output to the text window or mode, but when you’re in a TaskWindow 1) There isn’t a text window, and 2) You’re in VDU5 mode anyway, so the concept of ‘available width’ doesn’t apply.

One might expect TaskWindow to emulate the cursor position (eg Basic’s POS/VPOS) and perhaps a text window to reflect the size of the text editor window… except TaskWindow knows nothing about its Parent’s window size.

And this is why !Edit TaskWindows are the width of the screen, BTW. :-(

So if you type *FX3 16 inside a TaskWindow, then press F12 and type:

*Spool foo
*Help Spool
*Spool

…you’ll get nothing in the spool file.

I was curious enough to check the effects. Works perfectly and the file “foo” contains a copy of the help output.
Maybe StrongED does things properly where the normal default doesn’t?

the fact that you can’t type *. in a Zap TaskWindow and get sensibly-formatted output is embarrassing, but beggars the question “How far is too far?”.

That too formats nicely – in a StrongEd TaskWindow – or were you expecting it to format to the same width as the window rather than have the window generate a scroll bar? There’s an off chance Rick might tweak the Zap source and sort that I suppose.

I suppose it might be nice if the default system editor – Edit – did such things.

With me in the Kenneth Williams role I presume.

I have a horrible feeling that Wiley Coyote is the role Rick cast you in.

I was curious enough to check the effects. Works perfectly and the file “foo” contains a copy of the help output.
Maybe StrongED does things properly where the normal default doesn’t?

I’ve tested it with Zap & Edit on RO4/6, and Edit on RO5, and it fails in the way I described. I think you must have done the spooling inside the TaskWindow instead of at the F12 command line.

The point is that disabling spooling inside a TaskWindow doesn’t disable it inside but does disable it outside. As I’ve said, I’m using spooling as a convenient indicator of a more general point.

were you expecting it to format to the same width as the window rather than have the window generate a scroll bar?

If the text editor creates a window that is the width of the screen, then the result will be inconvenient rather than badly formatted. Zap has a fixed-size window (say 80 chrs) but the TaskWindow child doesn’t know that, so the result is messy.

Even if you use a graphical task window like VMode by Brian Brunswick (circa 1992), *. can’t work correctly. TaskWindow provides very little in the way of simulated environment, and the host can’t augment that simulation because it isn’t a party to the context switch.

When I wrote *Elastic I resorted to only using the screen/textwindow width if the screen is in VDU4 mode – if it’s VDU5 mode (eg a Desktop TaskWindow) then it resolutely sticks to 80 chrs a line.

I don’t think there’s much that can be done for *CAT other than re-implementation in a similar vein.

Wiley Coyote

Which would make RISC OS an Acme product. I’m content with that analogy.

I think you must have done the spooling inside the TaskWindow instead of at the F12 command line.

Misread and did another Ctrl-F12 to generate another TaskWindow although logically that should be outside the original (still open) TaskWindow shouldn’t it? I should really be asking Fred about that one I suppose.

Anyway, you’d say RISC OS is generally fine, apart from the command line and the whole Wimp and keyboard handing and language and character sets and…?

logically that should be outside the original (still open) TaskWindow shouldn’t it?

These kind of wrinkle is always so difficult to describe without resorting to the Power of Pedantry – a language of which I appear to be supremely fluent. :-/

TaskWindow is breaking the rules. This affects everything else… but not other TaskWindows because TaskWindow is breaking the rules.

And just to emphasise that, this is the contents of an ironic TextWindow:

*help spool
==> Help on keyword Spool
*Spool <filename> opens a new file and causes subsequent VDU output to be
directed to it, subject to the current *fx 3 status. *Spool with no filename
causes the spool file to be closed.
Syntax: *Spool [<filename>]
*

You lie, TaskWindow… you lie.

you’d say RISC OS is generally fine

I have a great deal of affection for this big pile of stuff. And pertinently, if there’s part of Windows you don’t like: Tough. Trying to output UTF-8 in a Command Window? Ho ho ho, no. No that’s not going to happen. Ha ha no. Here, we’ve fixed it with PowerShell. But I wanted to… Shame. PowerShell. Oh, OK. I’ll just send UTF-8 to this API… Nope. You can have an 8bit codepage, or you can have 16bit UTF-16. Don’t use multibyte sequences, use a single 16bit word! But I wanted to do emoji… Use multi-word sequences. But, you said… Multi-word. MULTEEEEWUUUUURD.

I have a great deal of affection for this big pile of stuff.

Me too (I’ve waited ages to use that phrase)

And pertinently, if there’s part of Windows you don’t like: Tough.

A part, hmm. How old are you? I’d to get started on the list and have you die of old age before I finish or expire myself.

Mind you, its existence has created a situation where I’ve been in employment for years and nearly paid the mortgage – even if I did slide sideways into networking (which always gets the blame, including for system processes stopping or crashing)

networking

Gaaah! Hissssssssssss.

True story: Sitting in office of multinational with world-spanning VPN. Can’t access hard disc of PC on the next desk. Can. Not. Access. IT Support drone about workgroups, domains or something. Don’t know. Don’t care.

Install VirtualRPC on both machines; mount hard discs; share using ShareFS; instant disc sharing. IT wonk: “That shouldn’t be possible. My firewall!”

Can. Not. Access. IT Support drone about workgroups, domains or something. Don’t know. Don’t care.

Quite right, that’s their problem to sort out. Mind you, if they’d given you access to a server share that the data should sit on (backups etc) that really wouldn’t be an issue in a work environment.
If you’re just visiting and have no rights on any server you wouldn’t have the rights to do what you say next:

Install VirtualRPC on both machines; mount hard discs; share using ShareFS; instant disc sharing. IT wonk: “That shouldn’t be possible. My firewall!”

Isn’t set up correctly. If you’re in the same subnet then the firewall he’s bleating about is on the PC and the famous Windows Firewall is famously good at blocking things it shouldn’t (DHCP¹) and not bocking malicious traffic.
If you’re in different subnets then he’s only blocking unicast on the VLAN gateway and has multicast forwarding on.²

¹Just do a web search for that one. There’s a supposed default rule to allow DHCP, it randomly doesn’t work.

Nope. You can have an 8bit codepage, or you can have 16bit UTF-16.

Don’t get me started on VB5/VB6 (proper VB, not this .Net stuff).

It is double-byte internally (so could handle UTF-16) but it talks to Windows using the 8 bit “ANSI” API. Basically, “it could be cool, but we’re going to hang a noose around your neck to troll you all”.
<sigh>

Don’t get me started on VB5/VB6 (proper VB, not this .Net stuff).

But .Net programmes are so much more efficient and no one except losers begrudge the 700MB+ of disc space it occupies. :^) Winding action.

Running for the exit…

I should also point out that I was using my modified version of Freeway with the working remote net functionality.

I was using my modified version

Share, provide a patch, or stop trolling us, m’kay? ;-)

Don’t get me started on VB5/VB6

And to add insult to injury, Windows has had a UTF-8 codepage for a very long time.
It just didn’t work.

stop trolling

Damn, rumbled.

I have a patched version of 0.26. I don’t know what the status of Freeway is now, but back then it was not documented so I had to reverse it to some extent. I do remember it was C and not pleasant. Although there was some remote net code, I couldn’t get it to do anything useful until I patched its broadcast loop to use the remote net list too. That list seemed to be populated by network messages, but I didn’t understand how it was supposed to be configured in the first place. (The panspermia theory)

So I patched 0.26 and wrote a utility to manage its remote net list (*FWRemote). That worked fine, so I forgot all about the details until RO4 with its 0.53. I think I didn’t have to patch the broadcast code in that one, but it still needed the remote net configuration tool.

It may be that I misunderstood it all and fitted a perfectly functioning athlete with a peg leg, but I don’t think so. I’m not aware of people routinely getting Access to work across different networks.

So *FWRemote works with the patched 0.26 and the stock 0.53 but nothing else… because I don’t have anything else. And though I do have an RPCEmu with RO5 for testing, it doesn’t have networking.

I have to stress, I know significantly more about Econet than any proper networking, so I may be talking through my hat. It worked for me, but Programming By Coincidence is not to be recommended.

I don’t think there’s much that can be done for *CAT other than re-implementation in a similar vein.

I patched FileSwitch to do the same thing that *Elastic does: If it’s in VDU5 mode it sticks to an 80 chr width. Normally it reads VduVariable &100 (the text window width) and formats to that. This is rather unpleasant with 16:9 monitors at the F12 command line and completely useless in Zap TaskWindows.

Sadly the only place I could find in FileSwitch for the patch was over a page away from the code that had to change, so I’m currently using 8K RAM for a ROMPatch to make *Cat format nicely in Zap TaskWindows. The actual functionality is about six instructions. :-(

Before and After

I should really be asking Fred about that one I suppose.

StrongED’s TaskWindow handling is still a bit behind Zap’s so I doubt it would perform better. The results I got were the same as nemo’s: empty spool file and bad formatting with *.

Nemo pointed out that the TaskWindow child doesn’t know about the server’s window but the converse is also true, the server knows nothing about the child and its output. The only safe recourse is to display it as it is presented, not ideal but there you go.

TaskWindow was (in part?) created so that single-tasking programs would play nice with the desktop but with both sides knowing next to nothing about the other side issues are to be expected.

As for TaskWindow bugs, there’s this old chestnut: %TaskWindow -Display -Ctrl

Run an editor, quit it then run the above command. Oops. It works fine when an editor is running. It also works fine when the editor is not running and you leave out the -Ctrl switch.

Note that the preceding % is important as both Zap & StrongED set up aliases call to support modules to avoid this very problem (which dates back to at least RO 3.1).

Fred wrote

The results I got were the same as nemo’s: empty spool file and bad formatting

The bad formatting is unintended consequences, but the empty spool is a bug. Especially because *Help Spool specifically states it honours *FX3 (as if it needed reiterating).

My more general point about WrchDest is that as TaskWindow is replacing the Kernel’s Wrch handling, TaskWindow ought to be outputting to the serial port and printer too. (The precise details of which are ancient, arcane, not fully documented and in some cases unintended – which is why if you switch on VDUXV you get stuff coming out of the printer. Oops.)

Related – this program produces different results in and out of a TaskWindow:

10 VDU23:*FX218
20 PRINT"It's not wrong"

the server knows nothing about the child and its output

TaskWindow seems to be aimed more at “C utilities” that use stdin and stdout and nothing more, rather than RISC OS (or even BBC) utilities that are aware of Wrch, VDU etc. However, that could have been improved if there was a context switch hook to allow the server to augment the environmental emulation that TW implements – a callback or service call (I hate the misuse of service calls for specifics like this, but that’s another story).

However, less ambitiously, I wonder if TaskWindow should at least try to simulate a “MODE 3” style environment – no graphics, but a simulated cursor position, screen width etc. The host could inform TW of changes to its window width by a message which, if an older TW was present, would be harmlessly ineffective but which in a new TW would enable the “screen width” and cursor position emulation?

As for TaskWindow bugs, there’s this old chestnut

I can’t get that to fail on RO4.39, but it certainly falls over on RO5.

Interesting reading: http://gerph.org/riscos/ramble/desktop-support.html#TaskWindow

However, less ambitiously, I wonder if TaskWindow should at least try to simulate a “MODE 3” style environment – no graphics, but a simulated cursor position, screen width etc. The host could inform TW of changes to its window width by a message which, if an older TW was present, would be harmlessly ineffective but which in a new TW would enable the “screen width” and cursor position emulation?

I built a BASIC (serial port) terminal display that responded to feedback from a headless bsd RaspPi. The VDU commands were useable for character operations such as /E[&D to move/delete 7 characters but things related to lines got messy.
A ZapTW will respond to VDU11 (upline) but other editors were only translating horizontal cmds.
An expanded set of VDU commands that could do lines, or even just handle deleting to the end of a wrapped command would have made it reasonably functional.
There are of course, ascii emulator programs available, It was just something I tried.
Edit:
looking back at my newsgroup post the following may have helped but were only working at F12.
VDU 23,8,5,6| deletes from the cursor to the end of the same line
VDU 23,8,4,5| deletes from the start of the line to the cursor
VDU 23,8,4,6| deletes from the start to the end of the line the cursor is on
VDU 23,8,0,5| deletes from (0,0) to the cursor position
VDU 23,8,5,10| deletes from cursor position to end of viewport
I noted that the Zap Taskwindow source has an emulated text window set using VDU28

I realised there may be a simple way around some of this. I knocked up a module that uses Post & Pre Filters to localise some of the VDU and MosVar environment around TaskWindows.

In other words, localise the environment in which TaskWindow itself operates… and therefore also its children.

This fixes the *FX3 issue immediately, and it also responds to a new TW_* wimp message which allows the host (say Zap) to tell the filter what its window width and cursor position is, which can then be reflected in the localised environment inside the TaskWindow.

This doesn’t cause TaskWindow to implement Wrch correctly (it’s nowhere near), but in principle it ought to be possible to get the Filter to implement Wrch itself (spool, serial, print, suppression) and treat TaskWindow’s brain-dead WrchVHandler is if it was the VDU code (minus the returns-C api which would hopefully be superfluous).

I can also see how it would be possible to arrange for every TaskWindow to have its own UDGs if it wanted.

Funny this topic has arisen recently. I have a friend who is quite familiar with the BBC range, and upon my prompting had a go with RISC OS.

I don’t think he has entirely gotten the hang of the multitasking stuff, so we compromised upon him doing BASIC programs in a TaskWindow.

One of first things he tried (after noting that MODE 7 doesn’t) was MODE MODE, upon which point it all went a bit wrong. Not being familiar enough with RISC OS, he power cycled to restore normality. It’s not an unreasonable sequence of events.

Shouldn’t TaskWindow disallow MODE changes from within itself like that?

I suspect that the change might have arisen circa 3.5 when extended screen modes were introduced. TaskWindow filters VDU sequences (try VDU 22,28) but for anything >256, BASIC used to issue *WimpMode (ugh!) but now issues an XOS_ScreenMode instead [source code], so I’m guessing TaskWindow isn’t able to trap this.

Would it be possible for TaskWindow to hang onto Service_PreModeChange, and if the current task is TaskWindow itself, to just silently object to suppress the mode change?

Shouldn’t TaskWindow disallow MODE changes from within itself like that?

Ah, the overloading of BASIC operators. Once upon a time MODE did a VDU22 and that was that. Then mode descriptors arrived and the MODE operator was overloaded to do other things.

For some reason I have a VDUMode module that implements VDU23;22,flags,x;y;depth; (where x=y=0 means current dimensions). It must have seemed like a good idea at the time.

Would it be possible for TaskWindow to hang onto Service_PreModeChange, and if the current task is TaskWindow itself, to just silently object to suppress the mode change?

At what point does TaskWindow become an entire virtual sandbox? Aren’t there 27,000 other calls it should also trap just-in-case? Yes, it could suppress the mode change by claiming the call, having apparently “taken alternate actions” (such as a CLS at least, or a VDU22 that’s near-enough… or even defining a transient ‘old’ mode with the extended dimensions so that VDU22 would act as a proxy…).

However, TaskWindow’s parent may well be a graphical taskwindow type thing, in which case it will/may have redirected output to a sprite and be doing that kind of cleverness. So really it isn’t TaskWindow’s responsibility. Perhaps it ought to be switched by -ctrl.

Sadly there’s a major omission: There’s no way of telling the Wimp it no longer has control of the screen. If one was pre-empting something in a graphical taskwindow, one might want to be able to go full-screen (while still pre-empting).

The biggest impediment is a lack of VDU/Screen/Display contexts (sprite save areas aside).

Then mode descriptors arrived and the MODE operator was overloaded to do other things.

I don’t think that’s accurate. MODE still changes MODE, but given that numbered modes are not really relevant these days, it needs a different mechanism.

So really it isn’t TaskWindow’s responsibility.

You make a good point regarding graphical TaskWindows. However in the standard TaskWindow, something is filtering the VDU output so it doesn’t break the desktop, but that isn’t aware of the new way of changing mode.

Aren’t there 27,000 other calls it should also trap just-in-case?

Well, that depends. There are probably plenty that are desired to use from a TaskWindow, and the Wimp rejects attempts to Wimp_Initialise, so that’s okay. ;-)

There’s no way of telling the Wimp it no longer has control of the screen.

Yeah. I mentioned before about the ugly hack necessary to get the Wimp to behave when starting up a module that outputs redirected to a sprite, and the Wimp only sees it as VDU output…

It’s weird that there’s a call to claim ownership of the screen palette (Message_DeviceClaim,3), but not the whole screen.

in the standard TaskWindow, something is filtering the VDU output so it doesn’t break the desktop

Yes, TaskWindow, but only because it’s been asked to by being started without the -ctrl switch. There is an argument that in that case it ought to be suppressing mode changes too. I’m not espousing that, just acknowledging it. There’s also an argument that in that case the TaskWindow client should not be able to plot sprites all over the screen.

It is at this point one would need a unified graphics context, encompassing everything that outputs graphics. And that would have to include SpriteOp, Draw, Font, AWRender, all the movie players, blah blah blah. At least SpriteOp, Draw and Font have vectors. For the others you’d need VectorExtend in order to intercept their SWIs too (and only allowing output when redirected to a sprite). This is an OS-level thing, not a TaskWindow thing, IMO. It’s missing functionality.