IIRC, Scroll Lock stopped the flood until you pressed the space bar or something at which point it would resume scrolling. Break would stop the list and take you back to the command line (as in, I don’t want to read the rest of this stuff, so just bust me out of it).
That’s right Joph.
While we’re on the topic of keyboards, wouldn’t it be useful to have a Tab key on or near the number pad? With all the progs now that use Tab to scroll through options, I would find it very helpful.
Besides usin Scroll Lock/break, most DOS commands have a parameter you can do to make it pause after every screen. For example, if you type “dir” it shows a very fast listing of every file in the directory, but “dir /p” will pause after every screenful of information, so you can actually read it.
FYI: I’m one of the few people who still prefers the command-line interface of DOS over Windows Explorer. (which is funny, because I haven’t been using computers as long as a lot of you have.) I mean, come on, if you want to get to a directory, say, c:\program files\winamp\skins\blahblah, would you rather click on “my computer” then find the C drive then find each directory using the mouse, or just say “cd\progra~1\winamp\skins\blahblah”? I never understood how Explorer got more popular than the DOS command console for file management.
Oops, sorry for not explaining the Print Screen key; thanks to Chronos for letting folk know. I thought that was a commonly known one.
Still, does anyone know how you press Sys Rq? Does it just work as Sys Rq out of windows, and Print Screen needs another key? I can’t seem to get much effect out of it on my Linux box either…
Regarding Access/databases: it’s much better to either use keyboard or mouse instead of having to switch between the two. I suspect that in airports (since they have to use keyboard at some point) they tend not to use the mouse at all. It’s what I’d do given the choice anyway.
Well, There was once a server room with an NT Server sitting next to a MacOS Server…
a) Took screen shots of Desktop on both machines.
b) Took all icons that could be removed from respective Desktops and put them in a folder at the root of the respective hard drives. Moved remaining icons (My Computer; Macintosh HD; etc) almost off-screen so only 2-3 pixels remained at absolute corner.
c) Opened screenshot of NT in Photoshop in full-screen mode. Loaded screenshot of Mac as wallpaper on the NT.
d) Switched monitors. Didn’t MOVE the monitors, just had what used to be the NT’s monitor hooked to the Mac & vice versa. What used to be the NT’s monitor is really a Mac monitor filled with an NT desktop screenshot. The Mac monitor is now really an NT Server monitor except with a Mac desktop for wallpaper.
heh heh heh…
Sorry to jump on this thread so late, but this hit a nerve with me. As a former programmer for the SABRE system (American Airlines’ reservation system) let me just say You’re Nuts! The airline reservations systems are truly a thing of beauty! Written primarily in assembler language for speed. There has NEVER been anything else that can compare to it’s processing speed. I’ve personally worked on two seperate projects to move a reservations system (or part of) off of the mainframe that have both failed because they couldn’t handle the volume of transactions. It’s the largest real time programming environment in the world. TPF (Transaction Processing Facility) has been around since the 60’s. So, is there a lot of typing? Yes, there’s no graphical interface unless it’s layered on top. Is it reliable? Yes. Unless you don’t consider 99% availability reliable. See if you can get that out of any Windows product. The core programs of TPF are bullet proof in terms of bugs. It handles BILLIONS of transactions a year. I don’t think Access is quite up to the task just yet.
The last time I saw United’s system, I thought it looked ancient, but that does not make it bad. I would bet that an experienced user can work faster on those old, character based systems than someone with the same level of experience on a graphical interface. Why? Two reasons:
A. The user’s hands stay on the keyboard rather than going back and forth between mouse and keyboard.
B. Since the screen is text only, there is less overhead waiting for screens to update, (and less network traffic if you’re using some sort of thin client) therefore the character based application is faster.
In addition, dumb terminals are cheaper than PC’s, and have less parts to go bad in dirty environments. And more limited options for relatively unskilled computer users. There is still a place for those ugly, monochrome mainframe terminals.