Non-MMX Pentiums may be great deals
- 19 February, 1997 14:20
What do we tell buyers who want to wait for MMX machines?
A There's undoubtedly a "sweet spot" on the cost/performance curve right now. Buying a non-MMX Pentium at the moment should prove to be an especially smart move.
First and foremost, don't worry about performance. MMX can speed certain computationally intensive algorithms, but it's overrated in the area for which it has been most touted: graphics. Why? Because the 30MHz or 33MHz bottleneck between the CPU and graphics buffer obviates the speed boost. The best place to turbocharge multimedia performance is the graphics accelerator - not the host CPU, which is already burdened with multitasking and bloated application software. Likewise, "soft" modems and similar programs require nearly instant response times, and the Intel protected-mode architecture, which is "context-heavy", is not well-suited to such tasks. So other activities will become sluggish and baulky when the software "modem" runs.
Things could be even worse on portables, which slow the CPU clock to save battery power. When they do, MMX instructions will slow down as well. But those that use a graphics accelerator instead will continue to display graphics at full tilt. Also, laptops running time-critical software such as "soft" modems may be unable to slow their clocks while communicating. This could cause dramatic decreases in battery life.
Peripherals that need MMX might also turn out to be useless with your preferred operating system. If history is any guide, vendors that provide MMX software/hardware solutions will target Windows 95 first and perhaps exclusively. If you'd rather run Unix, NetWare, OS/2, Pick, NextStep, Windows 3.x, or even trustworthy old DOS, you may be out of luck.
Some say that MMX systems will gain a performance edge from a feature that's not related to MMX at all: more internal cache. Alas, many manufacturers, knowing they will pay more for the new chips, are planning to eliminate external caches to keep system prices down. And the internal cache alone won't give you the same performance by itself, so performance will suffer. But, hey - at least you'll have the latest technology, right?
Intel's early announcement of MMX did work in favour of consumers in one unexpected way. In a replay of the Osborne Effect (named after computer pioneer Adam Osborne, whose pre-announcements of coming products hurt sales so much that his company folded), many buyers put off buying computers until 1997. Seeing disappointing fourth-quarter sales numbers, dealers began offering bargain prices on remaining inventories of non-MMX computers in late 1996. I took advantage of this myself, snagging an IBM ThinkPad 760E with an MWave multimedia processor.
One of my users doesn't do Windows; he has an e-mail package that receives binary files as blocks of ASCII characters. Is there a DOS application that can convert the ASCII to binary and binary to ASCII?
Windows actually has little to do with this problem. There are many text-based and even graphical e-mail programs that will receive e-mail attachments as jumbles of random characters. Here's what's going on and what to do about it.
The original standards for Internet e-mail were designed to be universal. They accepted only the printable portion of the ASCII character set so that any computer - regardless of make, operating system, or word size - could read a message. (The key standard for Internet e-mail, called RFC 821 and RFC 822, can be found at http://ds. internic.net/ds/dspg1intdoc.html.) By restricting the character set, the Internet standards guaranteed interoperability.
But at the same time, they made it impossible to send a binary file, with arbitrary combinations of bits, verbatim as part of an e-mail message. Instead, the file had to be encoded as a jumble of legal characters.
At first, the most popular encoding scheme for binary files was UUencode, an encoding scheme used by the Unix-to-Unix Copy Program. There are several variants of UUencode, and most e-mail programs and Usenet news readers handle them all gracefully.
But as the Net grew in popularity, several other schemes came into play. These include "just-send-8" (which just sends the bytes verbatim) and the more popular Base64 (which uses one of 64 characters to encode each 6 bits of a binary file). There's yet another called BinHex, which is most common in the Macintosh world. And if the file has been compressed, there may be a second layer of decoding to do: You may have to unzip, un-gzip, un-Arc, or unstuff the file to use it.
Finally, as if the plethora of encodings did not complicate life enough, vendors began to adopt extensions to the Internet e-mail standards. These are collectively called MIME. MIME allows computers to send multipart messages via the Internet, and each part can be in a different format. The development of MIME extensions has been chaotic. No user agent implements all the formats and extensions. Worse still, many popular programs - for example, the mail feature in certain versions of Netscape Navigator - have introduced their own non-standard variations.
Sound like a mess? It is.
Even the Internet gateway on my own cc:Mail system is plagued by incompatibilities. You can sort out this tower of Babel in two ways. The first is to use an e-mail client that understands at least most of these formats. The latest commercial products, as well as Eudora (http://www.eudora.com), do. Two other products to try are Pegasus Mail, which runs on MS-DOS, and PINE, which runs on many platforms but is best on Unix. PINE was based on an earlier program called Elm.
The typically hackerlike acronym stands for Pine is No Longer Elm. To find Pegasus Mail, go to www.simtel.net/simcgi-bin/dosfind.cgi. If you're stuck with an e-mail client (such as cc:Mail Remote), you can use translation programs to decode e-mail attachments yourself. Search the index mentioned above for the name of the format you need to convert. Finally, for a comprehensive overview of MIME and MIME software, see the MIME frequently asked questions site at http:// ftp.uu.net/usenet/news.answers/mail/mime-faq/.
A user has one of those neat little touchpad devices that lets you move the mouse cursor by sliding your finger around on a plastic pad. But it doesn't always respond to the user's finger; even if they press very hard. The problem seems to disappear when they bring the machine in for service. What's wrong?
The touch-sensitive pads on laptops (they're also available for desktops, by the way) don't sense pressure; they sense electrical capacitance. They depend on the notion that your body is grounded or at least shares a common ground with the computer. They may not respond to your touch if you're sitting on a sofa, a bed, or a chair with a plastic cover.
Try this: Touch a grounded surface (or one of the metal connectors on your laptop) while using the pad. Even if the pad is already working, you should see a noticeable improvement in sensitivity and response time.
Our access server allows either dumb terminals or computers with PPP [Point to Point Protocol] to connect; the user enters the command "set PPP" to start a PPP connection. Can I furnish PPP users with a script to issue this command?
Absolutely. However, each user must first install the Win95 Dial-Up Scripting Tool, which is hidden in an undocumented location on the Win95 CD-ROM. If a user has the original floppy disk version of Win95, the scripting tool won't be there; he or she will have to get the scripting tool from the Internet.
To install the scripting tool from CD-ROM, insert your Win95 CD-ROM and dismiss the setup program if it appears. Click on the Start button on the Win95 toolbar. Select Settings, then select Control Panels. Double-click on Add/Remove Programs. In the property sheet, select the tab marked Windows Setup. Push Have Disk. Enter D:\ADMIN\APPTOOLS\DSCRIPT as the path. (If your CD-ROM drive isn't D:, enter the correct drive letter.) Check SLIP and Scripting for Dial-Up Networking and install the software.
To get the tool from the Internet, go to www.microsoft.com/windows/software/admintools.htm and click on the link Dial-Up SLIP and Scripting Support. Download the file dscrpt.exe to a new, empty directory and run it to extract the contents. Then follow the instructions for CD-ROM installation, but tell Windows to install from the new directory.
After it installs, the scripting tool is still tough to find; it doesn't get an icon on the Control Panel or in the Dial-Up Networking window. To use it, click the Start button; select Programs, then select Accessories, and then select Dial-Up Scripting Tool. The dialogue box that appears will let you associate a script with a "connectoid" (an icon in the Dial-Up Networking window).
None of the scripts supplied by Microsoft is likely to be correct for your server, so you'll have to write one. The scripting language is undocumented, but you can learn it by example. Copy Microsoft's Pppmenu.scp to another file with the same extension and modify it. The script can send the user name and password from the "Connect to..." dialogue box with the statements "transmit $USER" and "transmit $PASSWORD," respectively. You can send a carriage-return character with the statement "transmit ^M."