Does anyone know of a utility program, probably written as a DOS extension that will dump the contents of the Mono display to a disk from where it could later be retrieved and merged into another file? This would be especially useful when "menus" and other "works of art" appear during the execution of different programs. One could then use these "pictures" when putting together a training manual, for example. Reconstructing all the "pictures" from the keyboard is a real pain. Thanks in advance to anyone who can point me to such a utility.
With this query, appended at 3:13 PM EST on December 11, 1984 to ISTHERE FORUM on the IBMPC Conferencing Facility, a Tucson, Arizona employee has started a communication event. It is a small event that will encompass less than a dozen dialogue exchanges, but it is an intriguing event for the study of computer conferencing. It is but one of several genres of computer conference interaction. Still, it was a highly productive event that is difficult to describe in terms of existing communication media. Indeed, much of our discussion of this simple query will be devoted to determining just what kind of communication event it was.
The query is highly specific. An answer will require some fairly specific expertise. Indeed, it can be expected that many expert PC users won't know the answer to the question. Its form, however is fairly ordinary. It is a question, and it could easily have been posed, with the same words, via just about any traditional means of human communication. The event it spawned, a series of answers to that question, is fairly ordinary as well. Events like it occur many times each day on the IBMPC conferencing facility. This is perhaps to be expected, as the append is very much in the spirit of ISTHERE FORUM, whose purpose, declared at the beginning of the forum by its founder, is as follows:
The appender wants to know if there is a way to save the information displayed on the screen of his PC so that he can use it later. He has a fairly firm grasp of what he needs to do the job, and the "utility programs" that will be brought to his attention over the course of the communication event will, by and large, be "resident extensions" (programs that keep operating after he exits them to start another program). Indeed, he might have attempted to find this utility in any of several ways.
First, he could looked for a program to do the job on his own. The tool he needs is fairly specialized, however, and he would have had to look fairly hard to find it. Indeed, a careful reading of PC World's 1985 Annual Software Review, which gives capsule overviews of over 1500 different PC software packages, reveals only one program (Sidekick) that will (as best the observer can tell) do the job. Saving a screen image to a file is not, moreover, the primary function of Sidekick, and no mention of this ability is made in either the PC World capsule review of the program or in the large (two page) advertisement for Sidekick that appears near the front (pages 18 and 19) of the nearly 400 page issue.
He might also have attempted to capitalize on the knowledge of other people that he knows. Telephone calls to local computer stores and conversations with friends and acquaintances that also use PC's are all possible ways of finding the utility he needs. If one of these people can point him to a useful utility or to someone else who can point him to the utility, his problem is solved. The need is specialized, however, and it is likely that he will have to do a substantial amount of "networking" to get the information he needs, if he can get it at all. The enemy, once again, is the number of different software packages that are out on the market. It is difficult for anyone to understand the full capabilities of even a large fraction of what is commercially available. Hence his only real hope here is to find someone who has had the same problem and has solved it.
It is unlikely that an extended search, either in the library or through his personal network, will turn up the utility that he is looking for.
He could, of course, build the utility himself. Indeed, his append makes a good case for building such a tool if no similar tool can be found. It is possible to save a lot of time and effort in preparing documentation for a program by capturing the screen images of that program to a file of "figures" that can later be incorporated into the document without re-keying. The tactic will also substantially reduce the probability of errors in the documentation. The observer notes this from experience, having reconstructed program screens while writing documentation.
In order to write the program, the appender would need to:
The program will not require a pretty, and expensive, in implementation time, user interface. The cost of writing this utility will probably not be very great for a highly skilled IBM PC programmer. A highly skilled PC programmer might complete the project in between six and sixteen hours. Hence if the appender is sufficiently skilled, it should be possible for him to recover the cost of building the utility after only 12 to 25 screen images. The cost will be far higher, however, if these programming skills remain to be mastered, however. A moderately skilled programmer might need a week or more to do the job. An inexperienced programmer might never pick up the requisite skills.
Picking between these two approaches and the third option, continuing to do the job by hand, is a matter of weighing the relative costs and benefits:
If the appender only has to transcribe a few screens, it will probably pay for him to continue doing the job by hand. If there are many screens to duplicate, however, spending the time to find or build a utility that does the job will be worth the investment. If he cannot program well enough to complete the program in a reasonable amount of time, and cannot delegate the job, a fairly exhaustive search will be justified. If he is a skilled programmer or can delegate the job to a skilled programmer, then the programming effort will be justified.
Computer conferencing offers him a fourth, and potentially far less costly, alternative, however, as the responses he received clearly show.
The simple query was received by the IBMPC conferencing facility at 3:13 PM EST on December 11, 1984. The first response, submitted by a Santa Teresa, California employee, was received by ISTHERE FORUM at 4:07 PM EST. Less than an hour had passed since the posting of the query.
The product Sidekick from Borland International will do what you want. You hotkey into Sidekick, edit any file using the Notepad facility, and notepad lets you re-display the current DOS screen and copy any part or all of the DOS screen into the notepad file. The notepad file may be saved to disk at any time and another one activated. The format of a notepad file is an ordinary text file such as that created by PE.
A second response appears nine minutes later (4:16 PM EST). The response points to a second utility that will do the job. This append to ISTHERE FORUM, by one of the IBMPC administrators in Yorktown Heights, NY, is rather terse:
"PSRD" (on PCLIB) allows saving a copy of the current screen on disk.
At 5:22 PM, a Poughkeepsie, NY employee provides pointers to two other utilities in a third ISTHERE FORUM append:
Another program for capturing screen output is TEE COMTBH on this disk. SNAPSHOT.COM is another, but it seems to have disappeared from IBMPC.
Barely two hours have passed since the posting of the first append, and the appender has no less than four options to choose from. Three of the programs suggested (Sidekick, PSRD, and Snapshot) are exactly what has been asked for: resident extension programs that can capture full screen PC images to a file. The fourth (TEE), is a filter that will do the same job for line output. All of the suggested programs will do the job under at least some circumstances, and although the Poughkeepsie employee has lost track of one of them, at least three of the four utilities are immediately available. PSRD, TEE, and Snapshot are all distributed on IBM's IBMPC or PCLIB software distribution facilities, and he can download these programs directly to his PC.
Of the four, Sidekick is the only utility that might have been found without access to the IBMPC conferencing facility or PCLIB, an IBM Internal Use electronic software publishing facility. As has been already noted, however, Sidekick is not designed specifically to do the job. It will be hard to discover the program as a solution to the stated need unless the appender knows someone who knows that Sidekick can do the job, and that person knows of the need. Reviews of the product are unlikely to make much of the "print screen to file" capability that is needed. Fortunately, computer conferencing provided a way for him to let a lot of people, including an awful lot of people that he doesn't know, aware of his need for this utility.
The other three programs -- PSRD, TEE, and SNAPSHOT -- are all IBM Internal Use Only programs that have been developed by individual programmers within IBM. They are shared with others within IBM via IBMPC and other computer conferencing and electronic publishing facilities, including PCLIB, as a service to others in the company who may need the capabilities provided by each program. The benefits of this are obvious. Those that don't have the programming talent to write one of these programs can take advantage of the efforts of others. Those that do have the talent can avoid reinventing tools that have already been built. Those that write the programs get, moreover, to benefit from the kind of program testing that can only be obtained from people who really need their programs and therefore test them in real applications.
At the time of the simple query, IBMPC and PCLIB published (electronically) over 600 different programs that can be used on the IBM PC. Today, the contents of both repositories have been shifted to a third, PCTOOLS, that distributes over 2000 different programs. Since the appender has access to both PCLIB and IBMPC, and the functions of all of the IBM Internal Use Only programs are fairly specialized, there is a fairly high probability that he will be able to find them with a limited amount of effort. If he reads the availability notices individually, he should be able to find a program that meets his need in less than a day -- probably a great deal less. If moreover, he picks some good key words and takes advantages of the file searching capabilities that are already available on the IBM mainframe computers that IBMPC and PCLIB operate on, he will probably find one of the three programs with less than two hours effort.
Two hours of computer conferencing have been even more effective, however. Four programs have been identified that will do the job in a little over two hours, and that time has not cost the appender anything. Once he posted the query, he was free to do other work and almost certainly did. Other people who already knew of solutions to his need were doing his search for him, at little cost (one suspects that that the IBMPC administrator read the query and sent out his append in less than a minute). The appender doesn't need to think about the problem again until he returns to read ISTHERE FORUM. When he does, the information and three of the program solutions proposed will already be there waiting for him.
As a side benefit, many other people around the company will read the simple query and the solutions offered. Many of these people will be made more productive by one of these utilities but may not have even considered the benefits of using a program that prints a screen image to a file. Some of these people will immediately try one or another of these utilities and become more productive as a result. Still more will remember the discussion and will be able to direct themselves or others back to it at some point in the future.
The response to the query did not end with the replies on ISTHERE FORUM. A series of individually addressed electronic letters point out still more options. The first of these, from an employee in Uithoorn, the Netherlands, arrived at 8:07 EST the next morning:
Hello ...,I saw your question today.
Maybe I can give you a HINT. I did not succeed to APPEND, that's why I sent you this MSG directly.
We are producing Computer based Training Courses (CbT) on the PC, on Common Finance Systems, that run on Main Frames. To pull "pictures" of the IMS Application Screens onto a PC Diskette we successfully used TAS. Terminal Auto Session (See PCDISK TAS NOTICE). This programming language allows you to write little routines that pull 24 lines from the Main Frame Application through an IRMA or ANR Card and write them on a PC Diskette in the format you like. We add commands Private Tutor uses to imbed these Screen Pictures in the courses.
Another nice little tool from the PCDISK is called FSDPC EXEBIN, AVAIL, SCRIPT. You can make pictures easily but you can also modify existing 24 lines of text by reading these files in. You would need to change the File.EXT in the one FSDPC uses. You can also save that modified Screen in BSAVE format.
I hope this is of some help, Good Luck,
This note is re-enforced later in the day (6:55 PM) by another letter, also from the Netherlands:
We have a program called Terminal Autosession (TAS) that works with the IBM 3278 Emulator card and E78.COM to read any host 3278 screen data and write this information to a diskette.
TAS can read as little or as much of the screen as you define. Our course writers here use it to capture an actual host screen when they want to put an example in a text. They run a little TAS procedure to read 1920 bytes and write this to a diskette on which they have been developing their manual or course.
TAS can do much more in fact it is a complete facility for handling the host screens from the PC. I will send you a copy of the manual and if you are interested, will send the program.
Regards,
Between them, these letters detail a fifth program that will do the job. The first also identifies a program that might be useful in editing the screens he has saved. The letters describe TAS as a utility for saving "host" screens (screens that were generated on a second computer) on a PC. This description echoes the requirements of the notes author's, as this is exactly what they are doing. There is a clear implication that the program can be applied more generally, however, and the implication is correct.
FSDPC, on the other hand, is a drawing program (FSD stands for Figures, Sketches, and Drawings). It may be a good place to recreate screens, but it is not designed to capture screens from other programs. Although the suggestion is not a solution to the stated problem, it should probably be regarded as an extension to the TAS solution that this writer proposes. TAS allows you to save screens of information. FSDPC allows you to edit them.
A third message, received at 10:41 on December 12th from an employee in Irving, Texas, misses the mark:
Greetings!SUBJECT: Routine to save MONO screens
There is a package I have used to create screens on the monochrome display and save to disk. The package is called PANGEN and is available on the PC disk (or at least it was the last time I checked). There is also a routine in one of the TURBO PROCS files that allows you to load that screen in a TURBO program. I have used this combination to write a tutorial which has been very effective. The only thing I object to is that it has to load the screen to the monochrome display. I haven't figured out how to do it to the color though I'm sure it's possible.
This suggestion is in the opposite direction of the need. The program suggested allows you to design screen images and save them in such a way that they can be used by a program. Unfortunately, it provides little aid to the initial appender, who wants to capture the screens of existing programs to a file. The message demonstrates that computer-mediated communications media are not immune to the problems of misinterpretation that plague all communication. However productive computer-mediated communication may be, it is not a panacea. It is simply another way of communicating, and occasionally miscommunicating.
The error in interpretation of the initial query is understandable. After all, the first two sentences of the query ask for:
... a utility program ... that will dump the contents of the Mono display to a disk from where it could later be retrieved and merged into another file? This would be especially useful when "menus" and other "works of art" appear during the execution of different programs.
It is possible to read these two sentences as a request for a program that generates screen images that can be used in another program. This seems to be this writer's reading of the query. The kind of miscommunication that has occurred here, a simple misreading of an append to a forum, is hardly unusual. The writer got some of the message and missed some of the message, much as might have happened in any conversation.
This form of miscommunication should have been made less likely by the characteristics of computer-mediated communication. Computer-mediated messages can be transmitted to a destination with perfect accuracy. Once there, they can be reread and even permanently saved by the person who receives them. These two characteristics should make computer media less prone to this kind of substantive error than transient media like the telephone and face-to-face communication. But even a computer cannot assure that a person will correctly interpret a message. Indeed, given the complexities of human interpretation, it seems unlikely that any medium will ever be able to ensure accurate interpretation on the part of a person who receives a message.
While computer media may discourage some forms of miscommunication, moreover, it should not be inferred that such media are universally superior to other forms of communication from the standpoint of misinterpretation. Indeed, it seems likely that some forms of miscommunication are encouraged by computer-mediated communications media. This is particularly likely when a message can easily be read two or more ways, as is the case for irony and sarcasm. The kinds of subvocal and nonverbal cues that we often use to communicate the correct interpretation of such double-edged messages do not always translate to the written word. Because ironic and sarcastic messages are persistently misinterpreted, participants in the IBMPC computer conferencing facility are discouraged from using such devices at all.
These factors are not operative in the misreading of the initial append. The Texas respondent simply misreads the query. It is interesting, however, that he transmits his reply as a private message instead of appending it to IBMPC. ISTHERE FORUM is a public conference. Appends to it will be read and referenced by many people for a long time to come. Electronic mail, on the other hand, will probably only be read by the addressees (one person in this case) and may or may not be saved. Hence the forum is the ideal place to append messages when you are sure of yourself. Mail is to be preferred when you aren't sure of yourself. One suspects that, unsure of how useful his answer would be, he selected private electronic mail over an append to ISTHERE FORUM out of underconfidence. A good answer will probably get positive feedback from the recipient. A bad answer will be read by only one person.
At 6:30 PM EST on December 11, just a little over 3 hours after posting his initial query to ISTHERE FORUM, the appender sends another message to the forum:
Thanks to everyone who answered my query about a utility to write the display screen to disk. That was real quick.
The Tucson employee is impressed with the results of his query, and with good reason. As he writes this note he has seen three related appends to ISTHERE FORUM and has received "one local phone call on the subject". Two of these appends are from people in New York; one is from someone in California, and a fourth originates in Tucson. After just three hours, he has pointers to four different utilities that can do the job that he would like done. Three of them can, moreover, be tested immediately. All that he has to do to make use of any one of these three utilities is to download it from the host system to his PC. Within a day, moreover, he will receive additional replies from the Netherlands and Texas.
A full computation of costs and savings is difficult here, as a variety of factors are involved. The cost to IBM depends, at least in part, on the amount of time spent reading the append by other individuals. The savings will be increased if this reading saves time for others with the same problem. The savings may be wiped out entirely if enough people spend enough time following the interaction. If 10,000 IBMPC participants spend 15 seconds average following the exchange, the cost to the company is 42 hours. If only 1000 individuals follow the exchange, the cost is only 4 hours. If enough people follow ISTHERE FORUM and no one else benefits from the exchange, the result may be a net loss of productivity across the company.
It is certainly the case that computer conferencing will save time for the individual who asks the original question. He has obtained the information he was looking for, information that probably would have cost him at least several hours work by any of the other available methods, at almost no cost in time or effort. More important, he has a better answer than he would probably have obtained with the alternatives.
Instead of simply knowing that Sidekick will do the job, he has a description of how to do the job with Sidekick. Instead of having information about a single tool that will do the job, he has information about at least four different tools that will do the job. Instead of having information about tools that he can obtain elsewhere, he has immediate access to three of those tools.
Much of the information received in response to his append is available to and will be read by other people. Some of these people will become more productive simply by becoming aware of another way of moving screen images into program documentation. Others will learn of faster ways of doing things they already do. The Santa Teresa employee, for instance, may well discover that PSRD does a better job of capturing a screen image than Sidekick. Another subset of readers will make others more productive by pointing them to these tools. All of these people can take advantage of the description of how Sidekick can be used. All have immediate access to the other three tools.
There is no way to guarantee that every append to ISTHERE FORUM will have this kind of secondary impact, even if it were possible to measure it accurately. Some exchanges may be a net loss to the company. Others will be a net gain. It seems probable, even given the fairly high levels of participation that are currently associated with IBMPC, that conferencing results in a large net gain for the company. User assessments of the various impacts of IBMPC, which will be reported in coming chapters, appear to support this view.
This event does not appear to be at all exceptional. Indeed, it appears to be fairly representative of the kind of communication that occurs daily on ISTHERE FORUM and elsewhere. Some queries to ISTHERE FORUM never get answered, but most get at least one answer fairly promptly. Sometimes an answer will be posted within fifteen to twenty minutes, and well over half of the queries posted are answered at least once before two hours have passed.
There was, of course, no reason for the event to be anything but representative. It was simply the first transcript of a computer-mediated communication event that the observer attempted to recover and analyze. Its selection had little to do with anything except the readiness of the observer to take on a transcript when it presented itself. On the surface, it looked rich. Any query that attracts three public replies in two hours is likely to attract at least that many private replies. But the query itself is fairly run of the mill by the standards of ISTHERE FORUM.
As it starts, the simple query looks like a fairly everyday communication event, a query for information. The query might have been executed in any several ways without computer conferencing. Each of the alternatives is time consuming, and none provide any guarantee of a reasonable return on investment. His options include library research, a survey of local computer stores and his personal network of friends, and building the utility he needs himself.
Instead, he places his query on ISTHERE FORUM, a computer conference on the IBMPC computer conferencing facility. The results are impressive:
The performance of computer conferencing in this event is impressive. Indeed, at least within the constraints of the initial appenders objective, it may be difficult for other communications media to match:
Computer-mediated human communications media aren't perfect. If people misinterpret messages, as must inevitably happen, there will be miscommunication. No human communications medium can be any better than the people who use it. At least in this case, however, computer conferencing offers clear advantages over other communication media. Before the existence of computer-mediated communication systems like the ones described here, the primary options would have been to search for the utility, develop the utility, or continue to do the job by hand. With computer conferencing, however, it is possible to complete tasks that entail obtaining information from others faster and better than has been possible before.