Tired of looking for fixes for bugs in your off-the-shelf software? BugNet may have the answer for you. BugNet comes in various forms. First, you can go to their World Wide Web site at http://www.bugnet.com/bugnet. I recommend starting here. The Web site contains an overview description of BugNet, a BugNet ALERT, which changes frequently, and subscription information. The BugNet ALERT for September 4 reported that installing Windows95 disables CompuServe NetLauncher and provided a workaround.
BugNet produces a traditional monthly newsletter, which is also available for downloading to subscribers in Adobe format. (You must have the Adobe Acrobat Reader to take advantage of this feature.) The August issue that I reviewed contained 16 pages of bugs and fixes for all of the software products that we all know and use. I suspect future issues will be full of Windows95 bug reports.
BugNet has also published special BugNet Reports on particularly buggy products like WordPerfect for Windows 6.X and Peachtree Accounting for Windows. These reports are available for $29.95 in a combined searchable hypertext electronic format and thumbable paperback package.
Subscriptions to BugNet range from $25 for the hardcopy version of the newsletter to $200 for a Full Corporate subscription to the complete searchable, hypertext version of BugNet, which can be downloaded and viewed from the Web, plus the entire BugNet database in searchable, hypertext form plus one site license.
In addition to the Web site, you can reach BugNet at any of the following:
The other on-line resource that I've found useful is Peterson's Education Center at http://www.petersons.com/. This site has descriptions of schools taken from Peterson's college guides, but what drew me to it was the on-line application forms. There are freely downloadable applications on disk for a number of colleges. The applications are often in DOS, Windows, and Macintosh formats and are about 1 to 2MB compressed.
No citizen of Earth can escape the dreaded Start button. Just like the Pod People, it's everywhere: on TV, on the radio, in newspapers, and in magazines. Worst of all, it's right there on your Windows 95 taskbar. Gone are the familiar comforts of Program Manager groups, those spacious boxes full of colorful icons. In the name of user-friendliness, all your applications are squashed into endless hierarchical trees. Orderly maybe, but does the font really have to be that small?
In all honesty, the idea behind Groups wasn't such a bad one. A PM Group could hold, for example, an application and its documents, or perhaps all the files related to a single project. Under Windows 3.x, all Program Manager icons were pointers to actual files on disk (pointers that Win95 calls "Shortcuts"). Apparently, this confused some people: they weren't able to distinguish between a pointer to an object and the object itself. [Author's aside: Kind of like people who confuse burning a piece of cloth with burning America.] Microsoft, accordingly, abandoned the group metaphor in favor the more regimented Start button.
Fear not. Windows 95 can do practically everything, if you can figure out the right approach. It can even provide you with nice Program Manager groups, just like the good old days. Since everything has to have a new name under the new regime, I propose "Document Palettes"; it sounds so much more upscale. You and I will know the truth. We just won't tell Bill.
Let's take a concrete example. Suppose that I wanted to create a Document Palette to contain my most frequently used bitmap-editing tools. Then I could open the Palette and leave it sitting on the desktop, ready to summon Photoshop whenever I need it. If Adobe's heavyweight pixel-mangler were overkill, other bitmap-related tools would be right at hand.
Even better, I could create a menu of Palettes at the top of the Start menu. I could close Palettes that I don't need at the moment and recall them later. Close all the Palettes, and you have a clean desktop (except for the things, like "My Computer," that Microsoft won't let you move). Need a Palette? Just punch the maudite Start button, pick from a menu, and you're in business! As your tasks change, change Palettes!
Now open the Palette folder, and create a new folder inside it. For our example, let's call it "Paint." This will be the actual Paint Document Palette. Open the Paint folder. You can close the Palette folder at this point.
Though the Paint folder can theoretically contain documents, it will behave more like the Program Manager of yore if you fill it with Shortcuts only. In Program Manager, remember, everything was a pointer, not an actual document. I use only Shortcuts in my Palettes to prevent confusion and to make things easier to find. If you dare, you can also create new folders inside a Palette, but this may somewhat defeat the purpose.
To add Photoshop to the Paint Palette, open the Windows Explorer and navigate to the Photoshop directory. Select the Photoshop program (distinguishable by its tiny Photoshop icon) and drag it to the Paint folder we just created. As the "outline" of Photoshop hovers over the Paint folder, it should acquire a "Shortcut" flag (the little Northeast-pointing arrow); this means you are creating a shortcut to Photoshop, not copying the program file itself. If this doesn't happen automatically, hold down <Ctrl>+<Shift> before releasing the left mouse button. Presently, a "Shortcut to Photoshop" will appear in the folder. I always delete the words "Shortcut to" since they're redundant.
Continue in this way until the Palette contains all the items you want. You can always revise the contents of the Palette later; this is just to make a start.
Doing this requires a Windows 95 trick that seems underhanded but is really a result of very elegant design by Win95's programmers. Quite deliberately, they made Windows 95 build the Start menu from a series of folders. This means you can use regular tools like the Explorer to edit the Start menu just like any other directory tree on your disk.
If you use the Explorer to open the Windows 95 directory, you will see a folder called "Start Menu." That's really it, right there: if you look through the folders inside the Start Menu folder, you will see they exactly mimic the hierarchy of your Start Menu tree.
In the Explorer, select the Start Menu folder itself, then create a new folder inside it called "Palettes." Open this new folder, then, using the same technique described above, place a Shortcut to the Paint folder in the Palette folder. The trick won't work if you copy or move the Paint folder to the Palette folder. You must create a Shortcut!
Once you've done that, click the Start button. Voilà! Notice the new "Palettes" item at the top of the Start menu. If you move the pointer up there, you will see a second-level menu appear containing a single item, "Paint." Select the Paint item and the Paint Document Palette will open. Try it a few times: close the Paint Palette, and the desktop is clear. Click on Start / Palettes / Paint, and the Palette reappears!
You can create as many Document Palettes as you want with this technique. As I mentioned above, you can even nest Palettes inside of Palettes. If you create folders inside the Start Menu / Palettes folder, they will become next-level-down menus, as long as you fill all the folders with Shortcuts instead of documents.
Never think you have to live as Bill says you must. Take back your Desktop! Think "Program Manager Group" but say "Document Palette"!
If your copy of Win95 seems to be slowing down, or your hard disk's access light is always on, you may want to defragment. You can use the defragmenter supplied with Win95 or a commercial product like Norton's Speed Disk for Windows 95.
Win95's built-in defragmenter lives in the Drive Properties dialog box: open "My Computer," then click on a drive icon with the right mouse button. Change to the "Tools" page and click "Defragment Now."
Commercial defragmenters will often process multiple drives without user intervention. They may also be faster and run better in the background than Microsoft's does. Norton, in particular, provides a utility called System Doctor that monitors a whole list of system statistics, including disk fragmentation. This utility can remind you to defragment or launch the defragmenter automatically.
Remember! NEVER use a DOS or Windows 3.x defragmenter on a system that runs Windows 95!
One of the most disastrous things that can happen to a Windows 95 user is a damaged Registry. Having a safe backup of this key resource can save you countless hours in the event of a catastrophe. Since many new Windows 95 users aren't aware of the danger, herewith a little history and some preventative measures.
For those happy people who aren't too concerned about the infrastructure underlying Windows 95, the Registry is a set of database files that store a great deal of information about your system and its configuration. The Registry also contains things like preferences and options set inside Windows 95 applications.
Under Windows 3.x, this sort of configuration and preference information was stored in INI files, so called because they had the extension .INI. These files were generally found in the Windows directory. By convention, INI files are always in plain ASCII and have a very simple "section and keyword" structure.
There is no doubt that the Windows 3.x INI file system was clunky and inefficient. Lots of tiny files conspired with DOS's ugly space-allocation system to consume megabytes of disk space for kilobytes of information. INIs had no direct method for storing binary data, which had to be laboriously converted to and from ASCII. There was no way to implement more complex information structures, such as nested keywords. Modifying an INI meant reading the entire file and writing it out again. Key INI files, such as WIN.INI, were limited to 64K in size. There were also programming concerns, such as maximum line lengths and INI filenames: with only eight characters to name the files, you ran the risk of having two applications with the same INI name. Since INIs were shared among all the users of a system, there was no simple way to provide different preferences for different users.
Microsoft's solution to these problems was to implement a binary database with a tree structure, called a Registry, which first appeared late in Windows 3.1's lifetime. The early Registries were very simple, containing only some information linking file extensions to applications and a little OLE data. Even after the appearance of Registries, Windows 3.x core features all ran on INIs.
Windows 95 jumped completely to the Registry model. All Windows 95 applications are supposed to store their option and preference information in the Registry. Win95 itself uses the Registry to store your hardware configuration, driver setup, network information, and much more. For Windows 3.x applications, Win95 provides some vestigial support for INIs, but Microsoft has decreed that the future is INIless.
Though the Registry is faster, more elegant, and more efficient than INI files, it has one major weakness: it places all the eggs in one basket. If the Registry is damaged, all your system's key configuration data can disappear.
INIs were flawed, but they were relatively safe. You could make a copy of an INI file before undertaking some risky step. If the worst happened, you could boot DOS and hack the offending INI with a text editor. You could comment out lines that you suspected were causing trouble. And you could easily restore a single INI from a backup.
The Win95 Registry system won't allow you to do any of these things. The Registry is protected by a checksum, and any unauthorized tampering will cause Win95 to reject the database. Microsoft didn't completely forget the technically-minded user: they provided a suitably arcane tool called the Registry Editor for those of us who like to hack. But this tool is useless unless Win95 itself will boot, which may not happen if the Registry is damaged.
Microsoft was well aware of the problems that could result from a damaged Registry database. They implemented a simple but generally effective protection scheme for the Registry. After a successful boot, Win95 makes a backup copy of the current Registry. During the next startup cycle, if Win95 detects that the working copy of the Registry is damaged, it will try to restore the backup and restart.
The overt symptom of this problem is an error box that says "Windows 95 has detected a problem with the Registry... Restore from the backup and Restart." You can elect to restore and restart if desired. Though Win95 doesn't seem to have started (there's no taskbar), you can actually launch programs at this point by pressing <Ctrl>+<Esc>, which will bring up the Task Manager, from whence you can run other applications. It's risky, though, since the Registry is damaged, which may cause the system to misbehave or your applications to act strangely. One thing you can't do is get rid of the Registry Problem warning box, at least until you restart.
With a little bit of luck, restoring the backup and restarting will get you back on track, though some settings and changes you made during the last session may be lost. Sometimes, though, after the restart, the dreaded Registry Problem error box reappears. Then what? You've already restored the backup, and that didn't work! Restoring it again isn't likely to solve the problem.
At this point, your options are very limited. You are basically forced to use your Startup Disk or provoke Safe Startup mode, in which case you will lose the vast majority of the information in the Registry. Your devices may not work. Your applications may not work. All the settings and customizations you have made over the previous weeks or months will be lost. Disaster!
Unless you have a backup.
I know, I know, you've been lectured before about backing up. Everybody knows they should do it, and nobody does it as often as they should. But backing up the Win95 Registry is simple, doesn't take long, and could save you a lot of time later on.
The Registry is made up of two hidden, read-only, system files in your Windows 95 directory: SYSTEM.DAT and USER.DAT. The backups created by Win95, supposedly from the last successful boot, are called SYSTEM.DA0 and USER.DA0. Since these files have all the "magic" bits set, they are invisible to normal Explorer windows and DOS commands.
There are two basic ways to back up the Registry. One is to open the Registry Editor and use the Export Registry command to save the entire Registry to a backup file. This works, but has a weakness: in the event of a crash, you need to be able to open the Registry to import the save file. If Win95 won't come up, you're out of luck. Also, if the Registry is corrupted badly enough, the Import operation may not work.
The second way is to save the Registry files themselves. They aren't normally visible from the Explorer, but you can see them by going into the View / Options dialog box, clicking the "Show all files" radio button, and clicking Apply. You could then copy the files to another location. This works and is very safe.
IMPORTANT! If you use the Explorer to copy the Registry files, make sure you are really copying the files, not moving them. You should see a little plus sign below the mouse cursor as you drag over the destination folder. Hold down the Ctrl key while releasing the mouse button to be sure you're creating a copy. God knows what would happen if you moved the Registry while Win95 was running, but it certainly wouldn't be pleasant.
To use xcopy to save your Registry to a directory called C:\REGSAVE, the commands (from your Win95 directory) would be:
xcopy /k /h system.dat c:\regsave
xcopy /k /h user.dat c:\regsave
The restore commands (again from the Win95 directory) would be:
xcopy /k /h c:\regsave\system.dat system.dat
xcopy /k /h c:\regsave\user.dat user.dat
XCOPY will automatically transfer the magic bits, so you can avoid manually setting and resetting the attributes. Remember that if you do a directory of C:\REGSAVE, or peek in there with the Explorer, it will appear to be empty, but your Registry files are really there.
You can also mix and match methods. For example, you could use the Explorer to save (copy, not move!) the Registry files to C:\REGSAVE from time to time, which would give you the convenience of familiar drag-and-drop operation. Then, in the event of an emergency, you could boot DOS and restore the Registry using XCOPY.
Parenthetically, I advise backing up your Registry from DOS, if possible, not from within Win95. The theory says there's no way for you to copy a Registry file while Win95 is updating it, but I prefer to be extra safe. Even so, it's much better to back up from within Win95 than to not back up at all.
I take this so seriously that I actually wrote a small C program that runs during Win95's startup (from AUTOEXEC.BAT). This program automatically maintains a stable of ten compressed backup copies of the Registry, adding a backup each time Win95 starts. This means I always have a recent Registry backup, without having to remember to do it. I also have several backups to choose from, a serious advantage when you test as much prerelease software as I do. The extra few moments spent compressing the backup are scarcely noticeable during Win95's rather lengthy startup process.
PkZip 2.0 normally ignores files with magic bits set, but it can compress and extract hidden and system files, as long as you use the right command-line flags. To save your Registry from the Win95 directory, you might do something like this:
pkzip /a /whs c:\regsave\950918 system.dat user.dat
This command will add the Registry files to a ZIP archive called 950918 (the current date) in the directory C:\REGSAVE. Though DOS programs are usually not case-sensitive, the `w' in the /WHS option must be in lower case. This tells PkZip not to ignore hidden and system files. A capital 'W' is the default, ignore hidden and system files.
To restore the files saved above, you would use the command:
pkunzip /Jhrs c:\regsave\950921
In this case, the /JHRS option tells PkUnzip not to ignore the system, read only, and hidden bits stored in the archive. Again, the 'J' must be in upper case; a lower case `j' will tell PkUnzip to use its default procedure, which is to mask magic bits during decompression.