As part of an experiment, I wanted to see what would happen if I printed more text in a Dialog status bar than could fit—specifically on the Z-machine, where there’s a defined limit (on the Å-machine it comes down to well-documented CSS). So I compiled this program:
(style class @status)
height: 3em;
(program entry point)
(status bar @status) {
alpha bravo charlie delta echo foxtrot golf hotel india juliett kilo lima mike november oscar papa quebec romeo sierra tango uniform victor whiskey xray yankee zulu alpha bravo charlie delta echo foxtrot golf hotel india juliett kilo lima mike november oscar papa quebec romeo sierra tango uniform victor whiskey xray yankee zulu alpha bravo charlie delta echo foxtrot golf hotel india juliett kilo lima mike november oscar papa quebec romeo sierra tango uniform victor whiskey xray yankee zulu
}
(get input $)
alpha bravo charlie delta echo foxtrot golf hotel india juliett kilo lima mike november oscar papa quebec romeo sierra tango uniform victor wh
se ryyne uuapabaocaledlaeh oto ofhtlidajletkl iamk oebrocrpp ubcrmoser ag nfr itrwikyxa akezl lh rv hri et cofxrtgl oe ni uit iolm ienvme sa a
aqee oe iratnouiomvco hse ryyne uu
I assume this cannot possibly be the intended behavior. What’s going on here? I’d expected it to simply stop when it reached the right edge of the screen, not continue and output nonsense.
I assume the status line text normally fills up some sort of buffer, and it’s assumed that within that buffer there will be a terminator, but since there isn’t, the status line drawing routine is continuing to decode and output the contents of arbitrary memory? The nonsense on your second line looks similar to what you get when you treat a bunch of random bits as a Z-encoded string.
Seems weird that the contents of the status line would be stored as an encoded string though since it’s dynamically generated, so I could be way off.
Looking at the z-file, the compiler seems to store the string correct, it splits it up in two high strings, 255 characters and 239 characters.
01864 S0001 "alpha bravo charlie delta echo foxtrot golf hotel india juliett kilo lima mike november oscar papa quebec romeo sierra tango uniform victor whiskey xray yankee zulu alpha bravo charlie delta echo foxtrot golf hotel india juliett kilo lima mike november os"
01910 S0002 "car papa quebec romeo sierra tango uniform victor whiskey xray yankee zulu alpha bravo charlie delta echo foxtrot golf hotel india juliett kilo lima mike november oscar papa quebec romeo sierra tango uniform victor whiskey xray yankee zulu"
The garbled text is probaly interpreter dependent, because if I run it in Windows Frotz so is the first line printed correctly, but line two and three are empty.
(If it’s an unterminated string, the interpreter would run off and try to decode bytes that are not meant to be string data. Surprises follow, but it would be the game file’s fault.)
I don’t think it’s an unterminated string, because that’s approximately how much text should be printed, and it’s repeating with the correct period—the decoding is just going wonky somewhere in there.
On Å-machine there’s only one reference interpreter and its behavior is straightforward: it obeys whatever CSS “overflow” property you specify. (In other words it just sticks all the text in a div and lets the browser handle the details.)
Haven’t tried with I6 yet; I’ll see if I can get the compiler for that working later.
[Main;
@split_window 3;
@set_window 1;
style fixed;
style reverse;
@erase_window 1;
@set_cursor 1 1;
print "alpha bravo charlie delta echo foxtrot golf hotel india juliett kilo lima mike november oscar papa quebec romeo sierra tango uniform victor whiskey xray yankee zulu alpha bravo charlie delta echo foxtrot golf hotel india juliett kilo lima mike november oscar papa quebec romeo sierra tango uniform victor whiskey xray yankee zulu alpha bravo charlie delta echo foxtrot golf hotel india juliett kilo lima mike november oscar papa quebec romeo sierra tango uniform victor whiskey xray yankee zulu";
@set_window 0;
];
This give the exact same output as the Dialog code.
Most interpreters doesn’t wordwrap in the upper window, instead it prints as much text as fits with current width of window. Unix Frotz seems to attempt a wordwrap (as Parchment, but does something wrong and loses track when decoding the z-chars after the wrap. I would say that this is a bug in Unix Frotz.
[Main;
@split_window 3;
@set_window 1;
style fixed;
style reverse;
@erase_window 1;
@set_cursor 1 1;
print "alpha bravo charlie delta echo foxtrot golf hotel india juliett kilo lima mike november oscar papa quebec romeo sierra tango uniform victor whiskey xray yankee zulu alpha bravo charlie delta echo foxtrot golf hotel india juliett kilo lima mike november oscar papa quebec romeo sierra tango uniform victor whiskey xray yankee zulu alpha bravo charlie delta echo foxtrot golf hotel india juliett kilo lima mike november oscar papa quebec romeo sierra tango uniform victor whiskey xray yankee zulu";
@set_window 0;
style roman;
print "alpha bravo charlie delta echo foxtrot golf hotel india juliett kilo lima mike november oscar papa quebec romeo sierra tango uniform victor whiskey xray yankee zulu alpha bravo charlie delta echo foxtrot golf hotel india juliett kilo lima mike november oscar papa quebec romeo sierra tango uniform victor whiskey xray yankee zulu alpha bravo charlie delta echo foxtrot golf hotel india juliett kilo lima mike november oscar papa quebec romeo sierra tango uniform victor whiskey xray yankee zulu";
];
I have also always thought that the upper window don’t wrap. Unix Frotz’s behaviour with garbage chars is strange, but even with my fix it doesn’t do word-wrap, instead it just cuts the string mid-word and continues on the next line. I think this wrapping is the behaviour of the curses library (for screen handling, not the game).
I was hoping it would work, for some upcoming projects, because Dialog doesn’t let user code access the screen width to do the wrapping manually. But I’m sure I can find a workaround.
)