Would someone with a real DEC VT terminal be so kind and help settle, once and for all, the question about how they behave with respect to line-wrapping, exactly? It is something that isn't covered by any standard, nor by any of DEC's manuals, and there is a scarcity of information online that is not vague repetition of folklore.
There are emulators, of course, but these do not agree with one another to the point that they can be trusted, and are probably just copying each other in any case. It seems that some ground truth would be welcome, for the benefit of both application and emulator writers.
First, the problem: A VT100, when in "auto-wrap" mode, will wrap text from one line to the next in a peculiar way, sometimes called "soft-wrap" or "the VT100 glitch". When the terminal receives a printable character with the cursor in the last column, the character is put at that location but the cursor remains in place. Instead, the terminal enters a pending wrap state, which causes the cursor to wrap before next printable character is displayed. This behaviour is widely known.
What isn't widely known are the finer points:
* What control codes will cancel the wrap state?
* What cursor position is reported in the wrap state?
* Do any operations behave differently in the wrap state?
* Is the wrap state saved/restored by the save/restore cursor codes?
and so on. Every emulator programmer seems to have a different answer to these questions.
If you have a VT100, VT220 or later model (compatibles like Wyse are also of interest) and have a spare moment, I'd be most grateful if you would download and run
https://raw.githubusercontent.com/mattiase/wraptest/master/wraptest.c
in that terminal, and send me the resulting output. (Redirect stdout to save the report.)
The test program is not comprehensive but would give us a good idea of the rules.
Current results, right now only from various emulators, are found in
https://raw.githubusercontent.com/mattiase/wraptest/master/results.txt
OK, it's official. I rarely criticize mail interfaces, because they're usually
mostly innocuous. However, today's change makes life a lot more difficult.
In the past, it was simple to direct a reply to an individual instead of to the
list because the originator's address was right there in the From: header. As
of today, the list address is substituted for that, so that it is impossible to
respond privately unless you happen to have a bunch of old messages archived and
the person to whom you want to respond is someone who has written previously.
Is this a conscious choice, or a configurable with a different default setting
in a new mail system than was previously in place? However it came to be, it
greatly diminishes communications quality (IMAO).
Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computers: Museum + Labs
2245 1st Avenue S
Seattle, WA 98134
mailto:RichA at LivingComputers.orghttp://www.LivingComputers.org/
This is probably a long shot, but does anyone have a Sparcbook 3TX hard
drive? I know they're difficult to find.
I have a 3TX in great condition, but no drive.
(hopefully this isn't a repost, I tried this when the list was having
issues and don't think it went through)
--
Ben Sinclair
ben at bensinclair.com
> From: Tony Duell
> I fail to see how anyone can be a good digital designer and not
> understand analogue electronics.
It's easy! As long as your devices are being run in a domain where their
behaviour is purely, well, digital, one can get away with it! :-)
I'm a perfect case in point!
I seem to have some bizarre brain dysfunction where I have a very hard time
understanding even the simplest analog circuits. You, or someone like Brent
Hilpert (whose explanation of core memory drivers I still remember :-) can
explain something with sufficient clarity for me to 'get' it, but I can
almost never work it out on my own.
However, I've designed a number of digital devices, at least one of which
became a product!
Noel
> From: Rich Alderson
> it is impossible to respond privately unless you happen to have a bunch
> of old messages archived and the person to whom you want to respond is
> someone who has written previously.
If you go into the list archive:
http://www.classiccmp.org/pipermail/cctalk/
the email address of the sender, for any given message, is still listed (in
slightly mogrified form).
Noel
So sorry for the temporary email outage on the list. We're moving
datacenters and one of my folks moved several front end mail processors -
not realizing that the classiccmp server which stayed behind was still using
them.
Through the magic of a vpn tunnel between front end mx hosts and the backend
mailstores (classiccmp included), it seems to be back up. I'll talk to the
guy tomorrow to discuss the actual movement of that vm. Yes, IP's will be
changing for the list and all websites hosted therein. But DNS is "a thing",
so should be mostly transparent. Depending on timing, I may go ahead and do
some upgrades and recombine the lists - or may do that after the move.
I'll try to do a better job of coordinating this..
Best,
J
I'm trying to help out Jason Perkins who wants to demo Multiplan on
Xenix 3.0 for the Apple Lisa at the upcoming VCF. While the bits for it
are on bitsavers, it requires a serial number and so far he's had zero
no luck finding one.
So I'm trying to use adb to step through the code and find where it
checks for the serial number, etc.
So I run adb ./brand and then set a breakpoint using :b on "." which is
the start address for the binary, and then I do :r /usr/lib/mp/mp and it
does stop before the 1st instruction is executed (or maybe right after),
however, when I try :s to step to the next instruction it runs the rest
of the program in its whole. I know there's also :e which should step
but skip over any function calls. I've also tried :ss, and got the same
results (whole program runs without stopping).
? and enter does disassemble the non-running binary. $r and $m show
registers and the map.
I'm actually not sure if I'm setting the breakpoint correctly as $b
shows it, but there's also a "command" field next to the address, so if
I do :bfoo, it shows address 0 and foo for the command. So what should
"command" be? and how do I single step through the running code?
Some more details of what I got so far for those with historical interest:
The basic installation is untarring the multiplan disk, which writes to
/usr/lib/mp and /once. In /once there's a script init.mp that runs
brand -s {serial} /usr/lib/mp/inter, but if you enter the wrong serial
number it removes all the files.
brand seems to look for a string starting with SCOSN - there's 4 copies
of the "SCOSN" string inside brand, not sure why. The /usr/lib/mp/inter
binary has only one like this: SCOSNMFO9999990000.
I suspect that brand replaces the stuff after SCOSN with whatever the
properly encoded serial number is. There's some sort of simple
ROT13-like encoding of the string stored in inter. Out of the box
running "/usr/lib/mp/inter /usr/lib/mp/mp" produces output with a
product number and a serial # of NUL-000000 - the "MFO" is decoded to
NUL (basically substitutes A for Z, B for Y, 0 for 9, 1 for 8, etc.) and
ofc it says invalid serial # and quits.
The serial number is checked by both brand and inter, but maybe not the
code in mp.cod (I touched a file called /usr/lib/mp/foo.cod and then it
said /usr/lib/mp/foo.dat missing, so I touched that one too, and when I
ran it, it said invalid serial number. Running inter by itself just
prints a banner without saying invalid serial number.)
I'm guessing the serial number is 3 letters a dash and 6 digits, but
there's maybe 4 more digits that have to be entered, or those 4 extra
digits are generated by brand, not sure. However, so far brand hasn't
accepted any serial number tried.
I suspect inter to be a Microsoft virtual machine that wants to load
mp.cod and mp.dat which are the real code for multiplan. I read
somewhere that early on MSFT was using VMs to do help them from having
to port the same code to lots of targets. This way they could port the
interpreter for the vm and run anywhere, though inter has string saying
multiplan so perhaps there's some customizations to each copy of inter
based on what it's supposed to run?
brand seems to take two more options -m and -n (and -q which I suspect
is "quiet" as the init.mp script uses it). Both -m and -n cause a core
dump but first print "identifier string found at D in"
This is an interesting bit of history that I'd like to reverse engineer
if possible.
brand hasn't been stripped so it's likely a bit easier to disassemble.
inter however is stripped, so would be much harder to reverse engineer.
But it would be very useful to be able to step through one instruction
at a time to find where it's doing a checksum or whatever and try to
figure out what the serial number looks like.
Jason is trying to brute force it assuming it's SCO-###### by running
brand in a loop, but so far no luck either.
Thanks.
