When I started, I just wanted a decent GUI FTP for OS/2, and to play around with a neat, new programming environment for OS/2 -- VX-REXX from Watcom. The project soon took on a life of its own as users started making suggestions for features (and reporting bugs). I had ideas of my own that I wanted to see implemented. Some were extremely easy via REXX (interface with other programs such as unzip, Web Explorer), others were difficult, and others were downright impossible (a real transfer progress indicator).
I'm not a true programmer by nature, as I can't sit evening after evening in front of a computer monitor, having just done that all friggin' day! I don't like how programming takes hold of your life, distracting you from other, more interesting objects, events, and people in your life. I think I have the skills to be a programmer, just not the endurance, which explains why I chose a 'lite' programming language like REXX: no C pointers to debug (though occasionally, they would've been real handy) and no compiling (!).
Regarding the code, I've made a decent attempt to insert comments. I think for its organic growth, it is pretty coherent. I only used real paper to design at the beginning, not for later features such as the directory cache. This fact will show up every once in a while. Also, as I go back over the code, I'll think "Why the hell did I do it that way?" When I remember the strange constrictions REXX sometimes puts on you, I'll say, "Oh yeah."
Starting up and Logging In:
When VxFTP starts up, it spawns a thread that will handle remote operations. The remote thread loads the RXFTP functions. Meanwhile, the main thread obtains settings from the VXFTP.INI file via multiple VRGetIni() calls. It creates default values if there is no INI file or if the file doesn't include all settings. The main thread also spawns the LocalDir thread to gather up local directory information into two arrays, dirList and fileList. A separate thread for this operation was necessary because REXX is too slow to make the user wait while it scans a directory.
Once the Remote thread has set up, it tells the local thread to call GetLoginInfo() to obtain login information. If the user specified parameters on the command line, GetLoginInfo() parses the parameters and packages them for delivery to the remote thread. Otherwise the Login dialog box is diplayed for the user to fill in. (The user can also simply select an alias that has all the login info.) GetLoginInfo() packages up the login info and passes it to the remote thread. The main thread then tells the Remote thread to LogonToHost(), which then calls the appropriate RXFTP functions.
The Remote thread has a number of similarly-named functions, distinguished by the OS name appended to the core name. Depending on the kind of host the user is logged into, Remote receives different formats of CWD (current working directory) info and directory listings. Fortunately, I work at the University of Texas Computation Center (fortunate in this case anyway) and had accounts on a VM machine, VAX VMS, UNIX, Netware, Macintosh, and NT so that I could log in and test the directory formats different OSes give. (VMS was the most obnoxious.)
Once the user logs in, the Remote thread gets and parses out the CWD, then DownloadNParse()'s the directory listings. It parses the file name, size, date/time, adding each piece of information into the appropriate array:
remote_file.x // Names of files in CWD
remote_size.x // Size of files
remote_date.x // Date stamp of files
remote_time.x // Timestamp of files
remote_dir.y // Names of subdirectories in the CWD
If the user has chosen to view Date and/or Size information in the Remote File List, then AddFileInfo() adds the selected info to the values in the remote_file array. (I don't know if this is the smartest way to do it, but the local side was already structured to pop the info contained in remote_file into the Remote File List. This method didn't necessitate a change on the local side.) PostRemoteFiles() publishes these arrays to the main GUI thread via VRMethod "PutVar" calls. It then notifies the local thread to update the remote file lists.
If directory caching is turned on, the remote thread adds the directory info to an entry in the cache table. The cache table looks like so:
Table.Dir_Name.x // Name of directory whose contents are cached
Table.Freshness.x // Whether a cache entry is dirty (STALE) or not (FRESH)
Table.CreateTime.x // Time that cache entry was made
Table.dirs.x.y // Subdirectories in the directory Table.Dir_Name.x
Table.files.x.y // Names of files in this directory
Table.dates.x.y // Date of files in this directory
Table.times.x.y // Timestamps of files in this directory
Table.sizes.x.y // Size of files in this directory
TableIndex // Index into the Table
TableSize // Size of the Table
An entry is considered STALE once VxFTP knows that the directory contents have changed and a refresh should occur, or if sufficient time has passed that the cache entry should be refreshed. The user can set how long to wait to refresh an entry, up to one hour.
Transferring Files:
If you've used VxFTP, you know that there are a variety of ways to Get and Put files. You can click the buttons; you can double-click on files; you can select a file and choose the pop-up menu; you can press Ctrl-G for Get and Ctrl-P for Put; or you can select from the menu-bar menus. The user can also choose whether or not to rename the file before s/he transfers it. Multiple files can be done at once, or just a single file.
Since there are so many choices in transferring, I think this is a good point to explain the naming convention for the menu code handlers:
MI_Lname_Click // Handles items from the menu-bar's Local menu
MI_PopupLname_Click // Handles items from the Local side's Popup menu
MI_Rname_Click // Handles items from the menu-bar's Remote menu
MI_PopupRname_Click // Handles items from the Remote side's Popup menu
The Popup menus simply call their menu-bar counterparts. I originally had one function that both menus shared, but VXREXX didn't like that. It wouldn't properly dismiss the popup menus.
All requests to Get a file (without renaming it) will eventually call MI_GetWithoutRename_Click(). All requests to Put a file (without renaming it) will eventually call MI_PutWithoutRename_Click(). These two functions determine which files were selected, put them in an array (even if it's only one file), notify the Remote thread, and disable parts of the interface (via XferInProgress() ).
The Remote thread calls the appropriate RXFTP function. If the action is a Get, then the get function (either GetFilesNoRename() or GetFilesRenamed() ) may also spawn the XferProg thread, which will monitor the size of the file as it's transferred. Once the file is successfully transferred, information is placed in the file's .COMMENT extended attribute. Once all the files in the getFiles array have been transferred, the local thread is notified ( "call GetComplete" ).
The local thread then fills the file lists. If a Put was done, the Remote file list may be updated. If a Get was done, the local thread spawns a LocalDir thread to scan the new directory contents. Some persons may argue that the new file names should simply be added to the local list after a Get, rather than executing the expensive REXX process of scanning a directory. I maintain that since OS/2 is such a multi-tasking environment, VxFTP can't know what actions other processes may have taken in that directory. Thus VxFTP should "re-touch" its local environment often, not just account for actions that it itself completed.
This sequence of events is nearly identical for all operations on remote files and directories:
1. The main GUI thread determines which files/directories the user selected and puts them in an array.
2. The array is published via the VRMethod "PutVar" and the remote thread is told to act. Certain GUI elements (list boxes and menu items) are then disabled until the operation completes.
3. The remote thread obtains the published array and uses an RXFTP function to process each item in the array.
4. If the action changes the content of the remote file system (such as a Put or a Delete), the remote file list may be downloaded and parsed again (unless the user has said not to in the Settings notebook), the cache may be updated (unless the user doesn't use the cache, also specified in the Settings notebook). The new file and directory arrays would then be published to the main thread for it to update the contents of the Remote File and Directory lists.
5. If the action changes the content of the local file system (such as a Get), the remote thread tells the main thread to spawn a LocalDir.
6. Once all changes have completed, the main thread then re-enables the interface elements that were disabled.
The list of functions that follow this pattern include:
MI_RChDir_Click MI_RDel_Click
MI_RMkDir_Click MI_RRen_Click
MI_RRmDir_Click MI_RView_Click
MI_GetWithoutRename_Click
MI_GetWithRename_Click
MI_PutWithoutRename_Click
MI_PutWithRename_Click
MI_RView_Click is different in that Steps 4 & 5 above aren't followed.
Notebook Settings:
The Notebook is where users make all the configuration choices that will be kept in the VXFTP.INI. The Notebook window is non-modal, so that the user can continue doing stuff while the notebook is open. It is not set to load all the pages at once; only after the user chooses its tab will the page be loaded.
The Create function for each page checks the values in the VXFTP.INI via a call to VRGetIni(), sets the values or checkboxes for the various information in the window, then shows the page. If a user changes the value or status of the GUI elements (checkbox, entry field, etc.), the change takes place immediately (such as turning off hints, adding file dates to the Remote File List, etc.) and is recorded immediately in the INI file by a VRSetIni() call. (None of this damned Windows or Macintosh "make changes, then click OK for something to happen" behavior.)
These are the broad strokes of the program. The code itself hopefully contains comments that hint at what is happening when, and why. Please be kind in your judgment of the code's quality as this was a project that happened in the evening and on weekends over the period of two years, amid all the ups and downs that love and life will bring. Note also that I wasn't doing it for the money either.
Best regards to those who take the code and make something more of VxFTP. Long life to OS/2 and REXX!
