\[Editor's note: Share your NT discoveries, comments, experiences with products, problems, and solutions and reach out to other Windows NT Magazine readers (including Microsoft). Email your contributions (under 400 words) to Karen Forster at email@example.com. Please include your phone number. We will edit submissions for style, grammar, and length. If we print your letter, you'll get $100.\]
In response to this column's invitation for readers to share their experiences with products, I'd like to pass along my excitement about the U.S. Robotics Pilot, a Personal Digital Assistant (PDA). With its of ease-of-use, size, collection of applications, and seamless connectivity, the Pilot not only is cool, but also is useful.
Nearly one hundred applications are available for the Pilot, from freeware to commercial software--for fun, utility, and business. With the Pilot and a modem, you can log on to an Internet Service Provider (ISP) via Point-to-Point Protocol (PPP) and download your email. In addition, several tools are available to let you develop custom applications. Soon, network administrators will stuff Pilots in their shirt pockets while running out the door to the beach. They'll perform all systems administration while lounging in a beach chair.
To get you acquainted with Pilot, I will introduce you to some essential applications. Then I'll talk about application development and warn you of some dangers.
The Pilot's operating system, Palm OS, is great, but it's not perfect, especially if you're a power user. You'll want the HackMaster series, shareware for the Pilot from DaggerWare (the HackMaster FAQ assures users that they have nothing to fear despite the product's name). This series adds some features the Pilot should have. First, go to http://www.daggerware.com and download hackmstr.prc, the engine that all other Hack apps depend on. Next, download MenuHack, which is especially useful because it lets you tap into an app's title bar to access a sticky menu (this saves you at least half a second from clicking on the menu icon--time is money!). If you keep secure information on your Pilot, load PowerHack (go to http://dspace.dial.pipex.com/ jakr/pilot). It locks the Pilot every time it goes off and requires you to log in with a password. Two other Hack programs, SilkHack (available at http://www.mindwell.com/pilot/musthave.html) and DaggerWare's AppHack let you reassign the functionality of the soft and hard buttons--very useful when you exceed the four included apps.
DaggerWare's drawing program, Dinky Pad, lets you use your Pilot to make drawings that you can back up and view on your PC if you also use the Generic Conduit Manager (go to http://cpu563.adsl.sympatico.ca/gcm.htm). This program also fixes a bug related to backup of third party apps.
Cutting Edge Software's spreadsheet, QuickSheet (go to http://www.cesinc.com), connects to both Excel and Lotus spreadsheets. For home and expenses, QMate (available at http://www.wco.com/~johnr/steve/qmate.html), lets you generate .QIF files to import into Quicken.
A couple of email packages cleverly connect the Pilot to Simple Mail Transfer Protocol (SMTP) or Messaging API (MAPI) mail systems. With Palmeta Software's Palmeta Mail (go to http://www.palmeta.com), you can connect to Netscape's email application or Exchange to send and receive mail when you HotSync. A Pilot application usually has two components: the program that runs on the Pilot--the .prc file--and a "conduit" that runs on the PC. The conduit application handles data interchange, including backup, between the PC and the Pilot. The HotSync program is responsible for managing the conversation between the Pilot and the conduits. Be forewarned: Not all applications have conduits; also, like the Calculator, not all applications need conduits.
Also of note is Agenda. This useful calendar application shows you today, tomorrow, the week, and tasks at a glance through a tabbed window. The Pilot gets really exciting when you load Pendragon Software's PilotForms (at http://www.webfayre.com) and Smartcode Software's Pilot HandStamp (at http://www.smartcodesoft.com). As the Pilot progresses from a useful replacement for day-planning calendars to a full-blown business tool, applications such as these will lead the way.
PilotForms lets you design custom forms within Access and upload them to the Pilot for data collection or review. You can download the collected data to Microsoft Excel, Lotus 1-2-3, or ASCII .csv files. PilotForms Developer Kit uses an OLE custom control (OCX) to hook data coming and going into VB or C++ for very sophisticated apps. For example, many physicians use the Pilot to jot down patient notes and information.
Smartcode Software's HandStamp, with a modem connected to your Pilot's serial port, lets you dial in to an ISP (or your local Net) via PPP and read your email. With the U.S. Robotics Pilot clip-on modem, you can log on to your Windows NT network with nothing but the Pilot.
Writing Applications for the Pilot
If the available applications don't meet your needs, you can create your own. Developing a Pilot application, while not an elegant process, is straightforward and requires only a reasonable amount of effort to achieve some very cool results. A variety of freeware, third-party Pilot development tools are available for Windows 95 and NT. A tool set called the Alternative Software Development Kit (ASDK--go to http://www.massena.com/darrin/pilot/asdk/asdk.htm) combines many of these tools. The tools offer command-line Help, and you can integrate the complete development process into a single set of makefiles and procedures. The Windows Pilot emulator, Copilot (at http://www.massena.com/darrin/pilot/index.html), is a very nice piece of work.
When you are ready to download a new application to your Pilot, you must beware of the risks of "unsafe computing." Treat your Pilot application, until proven otherwise, as a deadly infection, and always make sure that you synchronize your pilot before you download any new application. Palm OS is not a protected operating system; if your application messes up memory or doesn't handle an event correctly, you can do significant damage to other applications and data inside your Pilot. To illustrate the danger, let me tell you what happened to me: I had an application that worked marvelously in the simulator, but as soon as it got into my real Pilot, it froze up the little PDA. The only way to regain control of the Pilot was to hard reset it--which also just happens to reset the memory, thereby flushing all data.
The Pilot development environment is a little funky but ultimately effective. The best documentation for learning how to develop Pilot applications is on the CodeWarrior CD-ROM from Metrowerks (at http://www.metrowerks.com).
Turn Off AutoArchive in Outlook
If you have started migrating to Outlook 97, you probably have noticed the AutoArchive feature. By default, the AutoArchive system will wake up every 14 days and, following a brief warning message, scan the Calendar, Tasks, Journal, and Sent Items folders for old items (the cutoff date varies), and then move them to a Personal Folders file in the user's profile directory.
This feature can be very useful if you don't have a lot of space on your mail server and want users to archive old messages to their local hard disks. However, this feature can be very frustrating if, say, you have plenty of space on your mail server and would rather not deal with explaining the AutoArchive feature to users, or would rather keep mail on your mail server where you can back it up easily.
Turning off AutoArchive is easy enough: Go to the AutoArchive page of Tools, Options, and clear the check box. However, unless you clear the AutoArchive option for the Calendar, Tasks, Journal, and Sent Items folders, a user stumbling into the Properties for those folders can accidentally turn on AutoArchive by simply looking at the AutoArchive page and then looking at another page.
A Quick and Dirty Solution
When I contacted Microsoft's Outlook tech support about this problem, a support technician finally confirmed that there is no solution and that support staff had been requesting a solution for some time. I was happy to pass on to them a very dirty solution I hacked up one day. The Outlook tech support people indicated that they intend to polish my solution for external use, but in the spirit of sharing the neat things found in the bowels of the Registry, I pass on the following solution.
I've tested this solution only under Windows NT 4.0 Workstation using Outlook 97 to connect to an Exchange 5.0 server. I recommend you test it extensively before putting it into production. I already have evidence that the keys do not have the same names under Windows 95. The solution uses undocumented Registry keys that store information for the undocumented component object model (COM) objects that Outlook 97 uses to implement much of its dirty work, and these keys may bounce around as configurations change.
As you see in Listing 1, the crux of the solution lies in having the system automatically do the following during every logon:
1. Turn off AutoArchive
2. Set the default AutoArchive period to 60 days (the maximum)
3. Update the timestamp that records when AutoArchive most recently ran
The combination of these three steps makes accidentally turning on AutoArchive difficult for even the most determined users.
The settings for the AutoArchive values (and many other options that you set in the Tools, Options dialog box) are stored in the Windows Messaging System (WMS) section of the Registry. The key of interest here is HKEY_CURRENT_ USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\
* 000b0320 2-byte value; 0 for AutoArchive off, 1 for AutoArchive on
* 00030323 4-byte value; number of days between running AutoArchive
* 00030325 4-byte value; time AutoArchive last ran, in minutes since 0000 on January 1, 1601, local time
To set these values, I wrote a short Perl script, which you see in Listing 1, and this short .bat file to wrap it:
Then I stuck the .bat file in the Startup folder. I developed the script to run with Perl for Win32 Build 110, which is available at http://www.activeware.com. I have not tested this script with more recent builds (I am awaiting the release of 400 to start doing regression testing), but I see no reason it would not work. You could, of course, write a C++ program to implement the same logic, which would let you distribute the fix without installing Perl on every machine. Because we already install Perl on every machine we build (we have numerous other scripts that rely on it), I didn't have to delve into C++.
The only tricky part in the Perl script is computing the time value. The Perl time command returns the number of seconds since January 1, 1970, GMT. Quick calculation reveals that there are 194,074,560 minutes between January 1, 1601, and January 1, 1970. Up here in Alaska, the offset is -9 hours (-8 in the summer), so the computation becomes int(time/60)+194074560+(-9*60). I subtract an additional 120 minutes just to be on the safe side. I have not experimented with how AutoArchive behaves when the last runtime is set to some value in the future, so I feel safer keeping the values firmly in the past. To make the script independent of GMT, I could, of course, use the Time::Local library, which comes with the Perl distribution. But that approach would increase the load time for the script, and I feel comforTable with my solution.
To test the value names, try the following:
1. Set the 000b0320 value to 01 00 (on).
2. Set the 00030323 value to 01 00 00 00 (1-day period).
3. Set the 00030325 value to be-tween 1 day and 2 days ago; that is to the byte-reversed hex version of int(time/60)+194074560-(48*60). For instance, if the Perl time function returns 870716836, the value of the expression becomes 208583627. The hex value for that is OC6EBBCB, which becomes CBBB6EOC in byte-reversed notation. (The NT Calculator in scientific mode is capable of handling decimal to hex conversions on numbers of this size.)
4. Exit Outlook and any other Messenger API (MAPI)-enabled programs, and use Task Manager to watch for mapisp32.exe to exit (roughly 30 seconds).
5. Enter Outlook, and twiddle your thumbs patiently while waiting for Outlook to run AutoArchive.
Outlook takes a couple of minutes to decide to run AutoArchive. If it doesn't ask about running AutoArchive within 5 minutes to 10 minutes, perhaps the values are different. If it does ask, congratulations: You have tricked AutoArchive into running ahead of schedule.
If you can't trick AutoArchive into running, try using REGEDIT to take a snapshot of the 0a0d02... key, setting the period in Tools, Options to 1 day, and then setting the system clock ahead 24 hours. Take another snapshot with REGEDIT, and compare the two, looking for a 4-byte binary value that changes appropriately.
Be forewarned that the value 00030334 is a dead-end. It appears to be set shortly after install and does not change subsequently. My guess is that it represents the time when the Outlook folders and initial messages are created. Once you have found the name of the values that store the period, on/off, and last runtime information, modify the above instructions and test. Then modify the code as needed.
Further exploration of the 0a0d02... key results in several other interesting finds. Apparently, 000b0115 controls whether Deleted Items is emptied when users exit. Whether to allow commas as address delimiters appears to be controlled by 000b0350 and three bytes in the middle of 01020120 (this one is particularly nasty). I'm sure that further detective work can unearth more secrets from the guts of the WMS Profiles section of the Registry, and I encourage readers to share these discoveries. I'm also very interested to see what effect OS choice and mail storage choice have on the value names used by Outlook to store the various settings.