It’s not so different from primary school days: given a huge collection of varied, interlocking blocks, Joe Random can build a neat aeroplane, a car which can be zoomed to stunning velocity until it disagrees with a wall or door & explodes into a shower of plastic components.
Add just a touch of wit & the most amazing devices can be assembled.
Zoom forward 40 years, push a DVD into a computer, 5 minutes later it’s running Kubuntu with an office suite, graphics app plus suite of tools for altering images, audio editing & conversion app, video disintegrators & assemblers, two full-fledged SQL databases, name it.
Now a challenge arises: you have an app (written from the glass-teletype level, evidently, then steadily kinda-upgraded), thankfully written using gcc but on <ghasp!> SCO Unix, which is driving a specific brand of dot-matrix impact printer on a specific device node under the control of Wyse-brand VT-100B-clone terminals (apparently by a top-gun cross-dressing bloke who enjoys red heels), the owners of which are struggling to find anybody who will admit that SCO Unix even exists in order to make some small amendments, eventually with a view to selling it to others involved in the same form of business as themselves.
The escape codes & such are hand-coded into the source (does “printf ("\33[%d;%dH", row, col);” seem familiar?) for both terminal & printer — evidently, curses was still a myth when this was started, & remains conceptually mything.
Untangle a score of printer escape codes, quasi-cloned into at least a dozen different sections of code, to inflict the same process on a modern laser printer?
No.
Thank.
You.
So step 1 (after the mini amendments) was: copy the whole shebang across to the above Linux box, alter the printer-related code to write a text file with familiar-looking attributes like <B> or <U>, write everything inside <PRE> containers, & then feed the lot to HTMLDOC to turn it into PDFs.
Step 1A is grow weary of editing a bazillion instances of “fprintf (filehandle, "Total %9.2f for %s\n", value, desc);” & invent a new function (pprintf) which knows which file-handle to print to, saves specifying an argument (& saves more than a few typoes) & can be convinced that “\n” should (as HTML) be represented as “<br>\n” instead.
We’re a few dozen reports away from being robust enough to run the sucker from our netbook in Singapore airport via SecureSHell, & to simplify operations, it may be useful to email the PDFs to clients rather than printing them out & snail-mailing them. So...
Step 2: Konsole, sudo su -, then apt-get install mutt, add half a page of C code to the app, viola! Email!
I’m guessing it’ll be about a month before the reports are stable/robust enough for the owners to toss the SCO Unix box aside, pretend that the impact printer never happened, & get on with their lives.
The next step will then be to replace the flat files (unindexed, identical records often stored multiple times in different files in specific orders) under the application with a PostgreSQL instance.
This will (at least) eliminate much unnecessary locking conflict, speed the living daylights out of some operations, & allow sane/automated backup procedures (at the moment, rsync is king, thanks Tridge).
With this all in place, a huge number of hosting services worldwide will be easily able to support their app, allowing them to offer it to others in their industry as either plug-this-box-into-your-LAN or install-Putty-save-this-to-Registry machinery-lives-in-Neverland mode.
Perhaps ambition will set in, & the app will be ncurses’ed then GUI’d & webbed for universal access from Internet-Cafe-of-your-choice? Some systematising of the terminal stuff has already been done en passant with this in mind.
Add just a touch of wit & the most amazing devices can be assembled.
Zoom forward 40 years, push a DVD into a computer, 5 minutes later it’s running Kubuntu with an office suite, graphics app plus suite of tools for altering images, audio editing & conversion app, video disintegrators & assemblers, two full-fledged SQL databases, name it.
Now a challenge arises: you have an app (written from the glass-teletype level, evidently, then steadily kinda-upgraded), thankfully written using gcc but on <ghasp!> SCO Unix, which is driving a specific brand of dot-matrix impact printer on a specific device node under the control of Wyse-brand VT-100B-clone terminals (apparently by a top-gun cross-dressing bloke who enjoys red heels), the owners of which are struggling to find anybody who will admit that SCO Unix even exists in order to make some small amendments, eventually with a view to selling it to others involved in the same form of business as themselves.
The escape codes & such are hand-coded into the source (does “printf ("\33[%d;%dH", row, col);” seem familiar?) for both terminal & printer — evidently, curses was still a myth when this was started, & remains conceptually mything.
Untangle a score of printer escape codes, quasi-cloned into at least a dozen different sections of code, to inflict the same process on a modern laser printer?
No.
Thank.
You.
So step 1 (after the mini amendments) was: copy the whole shebang across to the above Linux box, alter the printer-related code to write a text file with familiar-looking attributes like <B> or <U>, write everything inside <PRE> containers, & then feed the lot to HTMLDOC to turn it into PDFs.
Step 1A is grow weary of editing a bazillion instances of “fprintf (filehandle, "Total %9.2f for %s\n", value, desc);” & invent a new function (pprintf) which knows which file-handle to print to, saves specifying an argument (& saves more than a few typoes) & can be convinced that “\n” should (as HTML) be represented as “<br>\n” instead.
We’re a few dozen reports away from being robust enough to run the sucker from our netbook in Singapore airport via SecureSHell, & to simplify operations, it may be useful to email the PDFs to clients rather than printing them out & snail-mailing them. So...
Step 2: Konsole, sudo su -, then apt-get install mutt, add half a page of C code to the app, viola! Email!
I’m guessing it’ll be about a month before the reports are stable/robust enough for the owners to toss the SCO Unix box aside, pretend that the impact printer never happened, & get on with their lives.
The next step will then be to replace the flat files (unindexed, identical records often stored multiple times in different files in specific orders) under the application with a PostgreSQL instance.
This will (at least) eliminate much unnecessary locking conflict, speed the living daylights out of some operations, & allow sane/automated backup procedures (at the moment, rsync is king, thanks Tridge).
With this all in place, a huge number of hosting services worldwide will be easily able to support their app, allowing them to offer it to others in their industry as either plug-this-box-into-your-LAN or install-Putty-save-this-to-Registry machinery-lives-in-Neverland mode.
Perhaps ambition will set in, & the app will be ncurses’ed then GUI’d & webbed for universal access from Internet-Cafe-of-your-choice? Some systematising of the terminal stuff has already been done en passant with this in mind.
Comments