This is a continuation of a previous post ...
Disk drives and tape drives
This picture shows the platters of a mainframe disk. These were normally encased in a plastic cover. The operator lifted up the whole unit from a cupboard and then screwed it into the drive which looked something like a top-loading washing machine. Turning it one way screwed it into the drive. Then turning it the other way unscrewed the cover. You then closed the lid and powered the drive up.
Here's a picture with the cover on. The amount of disc space depended on the number of platters. 5 platters would be about 120 Mb. 4 platters would be about 400 Mb. Sounds like a joke right? You can get that on a cheap USB drive these days!
You needed lots of tape drives because you normally needed one input and one output for each job running.
A typical spec. for a Burroughs tape drive would be:
Magnetic 1/4 inch tape drive - 60 Mb capacity - 90 K bytes / second transfer rate - 90 inches / second tape speed.
Here's a picture of a whole row.
And here's a picture of one in close up. You mounted the tape on one side and threaded the tape onto a reel on the other side. Below both reels were vacuum columns and the tape loop moved up and down inside the column depending on the speed and I/O operations. The vacuum columns were needed to even out the load on the tape otherwise it would simply snap. And it did sometimes when the unit was faulty. Spaghetti doesn't even begin to describe it.
A picture of the actual tape. It had a white plastic surround with a clip and a hook to hang it up in a tape cabinet. Each company had their own filing system and the operators had to run to grab the next tape when the mainframe demanded one, And of course, sometimes they were mis-filed which meant searching all the cabinets.
This picture puts it all together. Tapes on the left, disc drives on the right. Console right centre and line printer left centre. Note the tapes left foreground, all ready for a run.
Winsock
"In computing, the Windows Sockets API, which was later shortened to Winsock, is a technical specification that defines how Windows network software should access network services, especially TCP/IP. It defines a standard interface between a Windows TCP/IP client application (such as an FTP client or a Gopher client) and the underlying TCP/IP protocol stack.
Early Microsoft operating systems, both MS-DOS and Microsoft Windows, offered limited networking capability, chiefly based on NetBIOS/NetBEUI.
In particular, Microsoft completely ignored the TCP/IP protocol stack at that time.
Trumpet Winsock was one of the few Winsock 1.0 implementations that could be installed under Windows 3.0, which had no built-in support for Winsock. Trumpet was also the most popular shareware implementation of Winsock for Windows 3.x."
Trumpet was in fact the implementation that we used for a large range of products, mainly on Windows 3.1.
Our main source of reference was sockets.com. If you look at the site now, you'll see it refers to the Winsock 2 standard which does not support 16 bit (i.e. Windows 3.1). This is due to the fact that service providers expressed little interest in developing 16-bit versions of their modules. (Funny that!)
"WinSock version 1.1 has been the standard since its release in January of 1993, and has exceeded its authors' original intent to provide a powerful and flexible API for creating universal TCP/IP applications. Some have argued that it was an unsung hero in the Internet's phenomenal success, as it enabled the creation of a single network application--like Netscape's browser, for example--to run on the many TCP/IP stacks for PC's that existed at the time.
Since those early days, the PC network industry has changed completely. The many TCP/IP vendors have all but disappeared after their software was replaced by Microsoft's free TCP/IP implementations built into the operating systems."
Once again, Microsoft realised they had made a mistake, added a TCP/IP stack and it became mainstream. For most people, there was no reason to ever have to do sockets programming again.
The other main reference site was Stardust. Just to show you how much has changed, this URL now points to a site that sells contemporary furniture.
Another extremely useful site was Stroud's The Consummate WinSock Applications List which listed Forest Stroud's annotated list of popular shareware and public domain WinSock applications. This included an online forum for discussions about the applications.
Nowadays, that URL redirects to WinPlanet which seems to be some kind of portal for small businesses.
Terminate and Stay Resident
"Terminate and Stay Resident (TSR) is a computer system call in DOS computer operating systems that returns control to the system as if the program has quit, but keeps the program in memory.
Many software vendors use the call to create the appearance of multitasking, by transferring control back to the terminated program on automatic or externally-generated events, such as pressing a certain key on the keyboard.
Some TSR programs are effectively device drivers for hardware not directly supported by the operating system, while others are small utility programs offering frequently-used functionality such as scheduling and contact directories.
The original call, INT 27H, is called 'Terminate But Stay Resident', hence the name 'TSR'. Using this call, a program can make only up to 64KB of its memory resident. MS-DOS version 2.0 introduced an improved call, INT 21H/31H ('Keep Process'), which removed this limitation and also let the program return an exit code.
Before making this call, the program can install one or several interrupt vectors pointing into itself, so that it can be called again. Installing a hardware interrupt vector allows such a program to react to hardware events; a software interrupt vector allows it to be called by the currently running program; using a timer interrupt allowed a TSR to be summoned periodically.
By chaining the interrupt vectors TSR programs could take complete control of the computer. A TSR could then cascade with other TSR's by calling the old interrupt vector. This could be done before or after they executed their actual code. This way TSR's could form a chain of programs where each one calls the next one."
We used TSR's extensively for various networking drivers and also because we were a Novel OEM. Novell used TSR's to control the original file servers e.g.
typing
"cd g:"
when drive G was actually a partition on an external Novell file server required a TSR to trap the "Change directory" call and reroute it to the Novell code which then accessed the external drive via Novell's proprietary
IPX / SPX LAN protocol.
TSR's were DOS related and had their heyday during the DOS / Windows 3.1 (which ran on top of DOS) era.
The TSR has now almost disappeared completely as multitasking operating systems such as Windows XP provide the facilities for multiple programs and device drivers to run simultaneously without the need for special programming tricks.
Bulletin boards
"A Bulletin Board System, or BBS, is a computer system running software that allows users to connect and login to the system using a terminal program. Originally BBSes were accessed only over a phone line using a modem, but by the early 1990s some BBSes allowed access via a Telnet, packet switched network, or packet radio connection.
Once logged in, a user could perform functions such as downloading or uploading software and data, reading news, and exchanging messages with other users, either through electronic mail or in public message boards.
Many BBSes also offered on-line games, in which users could compete with each other, and BBSes with multiple phone lines often offered chat rooms, allowing users to interact with each other."
BBS's were how everyone communicated before the WWW. The public message boards were the precursor to the modern day Internet forums.
We used a BBS to provide all our software updates and patches. Customers could dial-in and download our latest software and bulletins. They also used it to upload error reports.
Because access involved a phone call, we had a BBS in each major centre to save our customers from incurring toll fees.
Access was slow - typically 1200 baud modems were used.
Because most terminals were the VT100 green-screen type which were text based, there were no graphics and graphics were simulated by using "ASCII art". You can see an example in the screen above.
(As an aside, there is an entire Star Wars rendered in ASCII art here.)
Personally. I used BBS's to download shareware - mainly games - but some useful utilities. As I recall, one of the earliest I downloaded was PKArc which was a precursor to the far more successful PKZip.
In the late 90's the WWW was well established and BBS's gradually faded away. You could do pretty much the same things from inside a browser.
No comments:
Post a Comment