Version v0.4.1 presents no new functional enhancements over v0.3.x, but
many bugs have been eliminated.
The program, AddMenu, is designed to let you add options to your system
menus. For example, if you use the File Manager all the time and you get
tired of always double clicking on the appropriate icon, this program
allows you to put the File Manager on your system menus. Thus, you can
access the desired programs from any menu. I am eager to hear what people
think, especially any problems encountered, comments about any affect that
it might have on system performance, etc. Please send comments to[email protected]
or at any of the other e-mail addresses below.
The general idea of the program is that you specify some menu text (i.e.,
the text that will show up on the menu) and then specify the command line
(i.e., the program name plus any options, if any). When you select
"Save", AddMenu will add that command to all of you system menus. AddMenu
is a Windows 3.x program which is intended to be placed in your "load="
line of your WIN.INI file (or, if you have Windows 3.1, to be placed in
your "StartUp" group with the "Minimized" box checked). When running, it
"hooks" into the system menus to add the specified options to all menus
and execute them when you select them from the menu. Note that if you
exit AddMenu, it will remove all of the new options from your system
menus. It is recommended that you simply minimize AddMenu when you're
done making changes and want to go on working on something else. Note: If
it is minimized with a hidden icon and you want to "restore" (i.e.,
un-minimize) simply run it again. All of its settings are stored in
Program requires COMMDLG.DLL, which comes with Windows 3.1. According to the
3.1 documentation, this DLL can be distributed with applications that require
it (such as this one) but cannot be distributed separately. I haven't
included it in this package, but if I get any requests to do so, I will in
future releases. This program is fully compatible with Windows 3.0.
This program also requires AMFILTER.DLL (included) which installs the two
filters and handles the menu events and posts the appropriate private
messages to this program.
Finally, this program also comes with RUN.EXE. This is a very small program
designed to mimic the behavior of the Program Manager's "Run..." command. It
is included so that you can have the functionality of the program manager's
"Run..." command from all system menus. To take advantage of it, you would,
using AddMenu, add the program RUN.EXE to your system menu (presumably with
some menu text along the lines of "&Run...").
This program is copywrite of Robert M. Ryan, 1992. It is provided without
warrantee of any sort. This program is FreeWare, and can be used and
distributed for non-commercial use without fee providing that:
a) it is not altered without permission of the author (me);
b) my name remains on the package at all times;
c) if you ever use any of my source, I must be credited in your source
d) no fee is ever charged for the distribution of the program.
If you want to use it for commercial purposes or have any questions about
these policies, do not hesitate to contact me. While I do not ask for money,
I am eager to hear what people think of the program. I'm especially
interested in hearing about any problems, incompatibilities, etc. that you
might encounter with this program. But I'm also keen to hear if you just
like it, too.
COMMDLG is copyright Microsoft 1992.
Robert M. Ryan, 7 July 1992
internet: [email protected]
bitnet: [email protected]
Known Program Bugs/Limitations:
There are several notable limitations/problems with the program as it
1.No real control of the order of items on the menu (well, sort'a:
it puts them on the menu in the order you add them).
2.Program currently uses both WH_CALLWNDPROC and WH_GETMESSAGE hooks.
Reportedly, the first adversely affects system performance. (Can
anyone substantiate this claim?)
3.This program rather arbitrarily uses menu id's starting at 0xE120.
This is intended to minimized conflicts with existing system menus
(0xF000 and higher) and likely ids used by other programs. It is
possible that these could conflict with other programs. By manually
adding a line "First Id=n" to the [AddMenu] section of the profile
file, where "n" is some number, you can control what ids should be
used. I didn't know how else to get around possible conflicts.
If you specify "n", make sure it's big (say, bigger than 0x2000),
but not too big (less than 0xEF00) and that the last hexidecimal
digit is zero (e.g. 0xE001 is not permitted).
4.This program is notably inefficient insofar as every change that is
save is written to the profile file. Granted, now that we all use
disk caches that's not really a problem, but I admit that it isn't
great programming technique. I'm lazy.
5. There's no help file.
6.And more, as of yet undiscovered, problems ...
Changes since AddMenu v0.3.0:
1. The program RUN.EXE is now included. Additionally, a bug in RUN.EXE
was giving the focus back to the application from which the system
menu was pulled, putting the new application that was run in back-
ground. RUN.EXE now manually gives the new app the focus back when
RUN.EXE, itself, finishes.
2.The list of File Types in Browse (in both RUN.EXE and ADDMENU.EXE)
now has both "Programs" and "All Files (*.*)"
3.The RUN program now handles the change in focus better.
4. Fixed bugs in the WinExec() procedure.
5. Added error messages.
6. Both RUN and ADDMENU both deal with changing drives and directories
better (at least more like the Program Manager's Run command).
7. These weren't compatible with Windows 3.0 (I never tested it). They
are now (though the user must supply COMMDLG.DLL).