PreOutpost and Address Book (Win7 -- Unicode, WinXP -- Ansi)

Update (11/19/19

With the advent of various new forms, some of which are not SCC forms with Routing Information. So to aid the operator the Routing Slip and Routing (Cheat Sheet) Information documents have been added to th Outpost Address Book document as a menu items (i.e. Routing/Form and Routing/Help). The first invocation of either menu item will take a few minutes as the program searches for the Adobe Reader. Subsequent invocations will be faster.

The developers of Outpost (for the Santa Clara Valley) declared that Win2K will no longer be supported. In addition this version does one other thing that is troubling to the operator: Forms are have an address and Outpost has an address. The downside of this is that there is a disconnect from the form's representation of the address (a "virtual" address) and Outpost's "actual" address. To address that issue, OPaddress was created.

OPaddress "captures" the two types of address from the log that is created during a transaction between the radio and the BBS. This information is displayed in a window and the operator may choose to copy any part of the record to the scratch pad to "paste" into a form or an Outpost dialog box.

A pdf file captures the PreOutpost Help file and is available here. The OPaddress book is described in more detail therein.

PreOutpost (Win7, WinXP and Win2K Version)

Update (5/17/19)

When compileing PreOutpost with Visual Studio 2017 for Windows XP my initial attempts required compiling the MFC library directly into PreOutpost. This made the program about 2MB. Today I discovered (isn't google wonderful) that one can find vc_redist.x86.exe by searching Microsoft.com for "MFC 140 dll redistributable". This loads enough on a Windows XP machine to run PreOutpost compiled with dll access to MFC. The resulting PreOutpost program becomes 145KB. And it runs too.

Update (5/10/19)

Outpost has had a major update and the first thing I noticed is that a message box appeared when changing profiles warning that the changes weren't saved. This was caused by PreOutpost storing the Subject Line configuration in the Profile file. The prior Outpost did not notice this imposition on its profile file but the current one does. The solution is to move the Subject Line configuration to the PreOutpost "iniFile".

The Master Profiles for PreOutpost must be created again. The easiest way to do that is to use the DOS Box (Command Prompt), cd to the PreOutpost directory and type the command (where X is "7", "XP" or "2K"):

PreOWinX /MakeMaster

Update (05/05/19)

Upgraded to Visual Studio 2017 which made things interesting to recompile. The zip file contains a tested Win7 and WinXP version. The Win2K version is as yet untested.

A recent change in Outpost required a corresponding change in the Subject Line creation. Now The Security setting is not going to part of the subject line. This is only applicable to the "New" message in Outpost as far as PreOutpost is concerned. There is an option to allow or disallow the Security setting to be part of the subject line.

Added nmake file for compilation of the help file.

Update (12/13/18)

Since November when the State wide Hospital drill occurred I have been working on other things. However, it occurred to me yesterday that it would be nice to have a version that would install normally on a Win2K machine (Regional San Jose has a Win2K machine). During the drill I used a copy that was just copied to the desktop.

I tried to include the Win2K version into a WIX installer and do the install on the Win2K machine but that did not work. So there is an PreOWin2Kinstaller.msi in the zip file. I also made the PreOWin7Installer.msi choose between two versions, a WinXP and a Win7 version. They are both compiled with VS13 C++, but the WinXP version uses an WinXP library. The WinXP version runs on Win7 so it should run on everything between WinXP and Win7 inclusively.

The Win2K version has some quirks that are not present in the other versions. The order of the profiles in Outpost is W3, W4, W1, W2. This is a bit odd but does not otherwise affect Outpost as I was able to access all four BBSes using the PreOupost prepared profiles.

Update (11/28/18)

Since August there have been some changes in the SCC packet world. A conversation by reflector about the subject line ultimately sparked some changes. The subject line was just complicated enough that I thought it would be a good idea that I try not to remember exactly what the format should be (because I would pretty nearly always get it wrong...). So a feature has been added to PreOutpost to place a subject line on the scratch pad (i.e. "copy"). The subject line is dependent on several factors:

• Emergency, Urgent or Other
• Immediate, Priority or Routine
• Weekly Practice (Form or New), Std Check-In/Out or Plain Vanilla
• Practice Night: Monday or Tuesday

The choices are managed by radio buttons which are sticky (are set the same as the "value" in the last invocation of PreOutpost). When Outpost starts up the subject line may be "pasted" into any place that will accept a paste. Right click the mouse and select "paste". Note the Weekly Practice has two choices: paste into a form in which case the severity and handling need not be included or paste into a "New" message (raw non-ICS form) in which case the severity and handling must be included. The form version is used more frequently so it is first.

Update (8/31/18)

Add a feature to allow the user to pick the suffix that identifies a specific BBS. It only need to be used once since the BBS are physical devices and rarely change. However, this feature allows PreOutpost to be customized to the local geography.

Update: Added current date and time and instructions of how to update same.

Update: Version 1.1.0 includes changes to emphasis in the dialog box (tactical is first group of IDs and ICS 309 Report parameters are also shown first). Multiple ID (see below) files are kept and they can be found by changing the FCC/Tactical call sign and changing focus. Editting the ID group will be saved when OK is pressed.

Outpost is the software that sends and receives packet messages using X.25 protocols and rf transmission on Amateur Radio frequencies. A message is prepared using Outpost and when it is sent it is transformed from a digital form to an analog form using a modem (modulator/demodulator) which is also called a Terminal Node Controller (TNC). To assist the operator in performing his task a set of configuration parameters may be saved in a file. The file is given a name and is called a “profile”. Once a profile is created and then selected any change made in the configuration parameters of Outpost may be saved in the profile. The latest version of Outpost allows the user to change the "save" behavior of profiles. But the mere fact that it is possible to save changes to a profile make them unreliable in the long term for Packet stations that are not under a single person's management.

The latest version of Outpost has introduced another kind configuration file: [callsign].usr or [tactical ID].tac. There is one of these files for each callsign or tactical ID used with Outpost. Over time with a packet station used by many different operators there will be many operator ID files generated. The operator ID files contain the "human" name of the operator, the message prefix and an optional "signature" to be used in each message.

Profiles contain a whole host of configuration parameters:

• Operator Identification
• Tactical Identification
• Report Information
• Modem Type
• Baud rate between computer and modem
• Buad rate between modem and radio
• Message Settings
• Etc…

Now picture a situation where a trained Outpost operator approaches a computer/modem/radio/antenna which is not his, which has been just taken from storage and arranged for use. Perhaps he is the one setting it up for use this time. Everything is connected, turned on and a message is prepared. Wait, in order to be legal his identity information must be entered into Outpost. Furthermore, the tactical situation may require a tactical ID be entered. Reporting information may also be required so that reports printed during operation give a complete picture of the station.

There are four (at the time of this paper) BBSes on mountain tops and buildings any one of which may be used to send messages. Each city has two designated as primary and backup.

So, here is the dilemma. The station has been in storage since the last event. We don’t know how it was configured the last time it was used. We don’t know if it was operational the last time it was used. There are 109 parameters stored in a profile. Some of them, perhaps many of them can prevent Outpost from performing as needed. In a rapidly developing event, having a proven starting point for an Outpost configuration would be a useful thing. Since a profile may be modified by any change, a profile cannot be relied upon to provide a good starting point.

PreOutpost will allow the user to produce a master profile which is hidden from view and cannot be modified. Then, later when PreOutpost is envoked it will allow the user to provide the identity information once and it will produce a profile for each of the BBSes. PreOutpost will then start Outpost.