Version 9 (modified by Gregg Young, 13 years ago) (diff)


Please do not delete anything from this page. Add comments under the requirement or add requirements if necessary. Must means it is essential to the upgrade. Should means it would be a nice feature to have.


  1. The new format must provide an easy upgrade path for the user's commands.
    1. A keyword system appears to be the best option.
    2. Something like
   ; FM/2 commands file -- 3 lines: title, cmd line, flags[[BR]]
   version = 2

   Name = Unlock exe or dll
   Command = unlock -v %a
   Icon = 4096
   MenuId = 2100
   IconName = areallygoodicon.ico[[BR]]
  1. The format must be easily expandable while remaining backward compatible.
    1. A keyword system appear to be the best option
  1. The format must lock in the resource number for each command.
    1. A keyword system appear to be the best option
  1. The menu structure of the commands should be under the control of the user.
    1. Should the user be able to name the sub menus or should a limited number of sub menu options be provided?
    2. Should all user added and FM/2 provided commands be movable to all potential sub menus?
  1. The user should be made directly aware of new FM/2 command options and have access for adding FM/2 command options at anytime.
  1. Under a keyword system. The rules would be that each definition much start with the name keyword.

The other keywords could follow in any order. See example under 1 above.

  1. The (an) ini file should be considered for the storage medium.
  1. A version keyword would allow us to add features while retaining backward compatibility. If we know the file is version 2, it's trivial to provide default values for a version 3 file.
  1. We should provide a drop down of the icons that were unused because their command is not being used and we should include extra icons in FM2RES.DLL for use on toolbars.
  1. An FM2PATH for use with commands, associations, archivers, etc to reduce the need to include full path names & without cluttering up OS/2's PATH should be developed.
    1. FM2PATH is probably just another settings page item. Probably needs to be presented as a listbox with reordering support.
  1. The file structure used should be adaptable to the associations and archivers to allow for the same basic code to parse all of them.
  1. The resource number must be clearly displayed somewhere or adding to the toolbar must take care of this issue internally to make it easy for the user to add commands to toolbars.
  1. The ability to set a modified environment should be included.

Code Modifications

Data Structures

typedef struct
typedef struct LINKCMDS
  CHAR *pszCmdLine;
  CHAR *pszTitle;
  ULONG flags;
  USHORT usToolId;
  struct LINKCMDS *next;
  struct LINKCMDS *prev;

// flag masks
#define SYNCHRONOUS   1
#define DETACHED      3
#define SEPARATE      4
#define WINDOWED      16
#define MAXIMIZED     32
#define MINIMIZED     64
#define FULLSCREEN    128
#define INVISIBLE     256
#define BACKGROUND    512
#define WAIT          1024
#define PROMPT        2048
#define KEEP          4096
#define ONCE          8192
#define DIEAFTER      16384
#define SEAMLESS      32768
#define CHILD         65536

typedef struct TOOL
  CHAR *pszHelp;
  CHAR *pszText;
  INT flags;
  struct TOOL *next;
  USHORT id;             // 
  CHAR *pszIcon;         // icon name or icon resource number in #icon format
  USHORT usMenuId;

// flag masks
#define T_DROPABLE    0x00000001
#define T_EMPHASIZED  0x00000002
#define T_INVISIBLE   0x00000004
#define T_SEPARATOR   0x00000008
#define T_TEXT        0x00000010
#define T_MYICON      0x00000020       // This can go away maybe

Source code


Refactor structures to command.h