https://github.com/lwcorp/lwmenu
A control menu, application launcher and portabilizer - all in one application!
https://github.com/lwcorp/lwmenu
autorun launcher menu portability windows
Last synced: 9 months ago
JSON representation
A control menu, application launcher and portabilizer - all in one application!
- Host: GitHub
- URL: https://github.com/lwcorp/lwmenu
- Owner: lwcorp
- License: gpl-3.0
- Created: 2020-08-08T20:27:50.000Z (over 5 years ago)
- Default Branch: main
- Last Pushed: 2025-03-11T13:21:13.000Z (10 months ago)
- Last Synced: 2025-04-13T21:13:27.371Z (9 months ago)
- Topics: autorun, launcher, menu, portability, windows
- Language: AutoIt
- Homepage:
- Size: 655 KB
- Stars: 27
- Watchers: 3
- Forks: 1
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- Funding: .github/FUNDING.yml
- License: LICENSE
Awesome Lists containing this project
README
This is portable program that lets you control menus via autorun.inf files.
It also serves as a portable enforcer for semi-portable programs that don't need installation but do otherwise leave leftovers forever
(i.e. it portabilize non portable apps).
Inspired by the late 2002 **Net-burner's AMenu**, only with a user-customized menu, unlimited buttons, control over special buttons, native support for "working folders", an ability to delete leftovers by the launched programs, and much more.
You can even submit your own ideas.
## Usage
### Basic use
All you have to do is launch **AutoRun_x64.exe** or **AutoRun_x32.exe** (see [difference](#what-is-the-difference-between-the-32-bit-and-the-64-bit-version)).
This presents a (multilingual) menu based on an **autorun.inf** file in the same folder. One of the menu's options is to edit this file and thus control the menu.
The program includes a sample menu with various button configurations.
### Special use cases
One user especially developed a way to mass deploy the launcher in various PCs that serve as a **payment (POS) terminal** ([see Wikipedia](https://en.wikipedia.org/wiki/Payment_terminal)) - their method was graciously [detailed here](https://github.com/lwcorp/lwmenu/discussions/10).
If you made a special case too, please do [show and tell](https://github.com/lwcorp/lwmenu/discussions/categories/show-and-tell)!
### Advanced use
* Command line parameters can be used, use the help menu to show them or run the launched with `/?`.
* Present a menu from another folder using `/ini=c:\another folder\` - the path can even contain environment variables (e.g. `/ini=%USERPROFILE%\subfolder\`).
* For those who don't like menus, you can uncomment `;skiptobutton=X` to choose a pre-defined button instead of opening the menu. For example, `skiptobutton=4` will always launch button 4 without opening the menu. It can also be done with a command line parameter `/skiptobutton=X`, meaning you can keep all settings in 1 file, but use multiple shortcuts, each for a another button.
* A filename can be passed as a command line parameter, to be passed tothe launched program. This can work well with `skiptobutton=X` when associating the launcher to certain file extensions.
* Alternatively, you can define an alternate default button using `focusbutton=X` (e.g. `focusbutton=5`) instead of the first button. It can also be done with the command line `/focusbutton=X`.
* For those who don't like tray icons, you can uncomment `;hidetrayicon=1` to run without it.
* You can define registry values, folders and files (even using wildcards), services and drivers to delete after the launched program exists. If that program expects certain registry values/folders/files to exist before it runs, you can have blank entries created automatically by appending the values with `+` (e.g. registry=+HKCU\Software\Test) or also use `backuppath=some_folder` (e.g. `backuppath=.` or `backuppath=c:\folder\backup`), which will automatically backup and restore before/after running the program.
* For registry entries specifically, you can skip a whole backup and just create basic entries like `registry=+HKCU\Software\advanced,accept,1`
* Services can also be created before the program launches.
* If you like to just trick a non portable program, you can define (multiple) `symlink=symlink|target` to link a non portable file/folder into writing into a portable path. This spares the extra write action and possible data loss of backup and restore! Likewise, you can define (multiple) `setenv=variable|value` to fake environmental variables during the session.
* Use the menus's toolbar or start with `/listenv` to get a list of all environment variables.
* Use an extra `|` so that `setenv=folder|path to folder|` will turn relative paths into absolute ones (as required by certain environment variables)
* You can run a program after another program by using `buttonafter=X` (e.g. `buttonafter=4` will run button 4 after another button) and it's possible to chain multiple buttons like that - you can use `hidefrommenu=1` to hide such buttons from the menu
* You can enforce a single instance of launched programs by using `singlerun=1` (either globally or per button).
* You can use `blinktaskbarwhendone=1` (globally or for individual buttons) to blink the taskbar upon completion of the launched program.
* You can use `netaccess=0/1` (globally or for individual buttons) whereas 0 will block network access from the launched progrram from, while 1 will give it one-time network access.
* If an external settings file doesn't exist, a default one will be created.
* If you like to launch progras as admin, you can define `admin=1` (globally or for individual buttons).
* If you like to experiment, you can define `simulate=1` inside entries or run the whole launcher with `/simulate` command line parameter). Clicking buttons in that mode will just report what would have happened instead of actually doing anything.
## System requirements
Windows 200X, Windows XP, Windows Vista, Windows 7-11
## Screenshots
## Comparison
| Feature / Benefit | AutoRun LWMenu ([latest](/../../releases/latest)) | PortableApps.com Platform 29.5 | yaP 0.7.1 | PStart v2.11 | Net-burner's AMenu v1.1 |
|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------|
| Last updated |  2024 |  2024 | 2016 | 2011 | 2002 |
| Button style | Large/3D |  Iconic/2D |  No Menus |  Iconic/2D | Large/3D |
| Deleting programs' registry leftovers | Yes | Yes | Yes |  No |  No |
| Deleting programs' file/folder leftovers | Yes | Yes | Yes |  No |  No |
| Can backup/restore apps' registry/folders/files | Yes | Yes | Yes |  No |  No |
| Can work without menus (skip to a specific button) | Yes |  No | Yes |  No |  No |
| Can specify which button to initially focus on |  Yes | No |  No Menus | No | No |
| Accepting user-defined menu properties |  Yes |  Yes |  No Menus | No | No |
| Accepting user-defined button properties |  Yes | No |  No Menus | No | No |
| Regular buttons |  Unlimited |  Unlimited |  No Menus | Unlimited, but with scrolling | 1-8 |
| Special buttons |  1-3 | No |  No Menus | None | 2 |
| Sub-menus |  Unlimited |  1 level |  No Menus | Yes, but with scrolling | No |
| Reloading an updated menu dynamically (i.e. without having to relaunch it) | Yes | Yes |  No Menus | Yes |  No |
| Support for closing the menu after launching a program | Yes |  No |  No Menus | Yes | Yes |
| Commands are stored in |  autorun.inf (even when blocked by the OS, plus compatible with AMenu's autorun.inf and instantly editable via a special button) | Nowhere, they're just automatically loaded from sub-folders | An additional folder and INI file for each and every launcher (as there's no menu) | An additional XML file | autorun.inf |
| Support for OS paths (e.g. "notepad" instead of "%windir%\notepad.exe") |  Yes | Not relevant since they're loaded from sub-folders | No | No | No |
| Support for "working folders" (i.e. "run from") | Yes |  No | Yes | Yes |  No |
| Support for relative folders (e.g. "..\..\") | Yes | Yes, because they're loaded from sub-folders of the launcher, wherever it is | Yes |  No |  No |
| Support for creating temporary symlinks i.e. symbolic links (tricking a non portable program to write to a portable path) - requires running as admin plus defining `backuppath=` | Yes |  No | Yes |  No |  No |
| Support for environment variables (e.g. "%SystemRoot%\notepad.exe") | Yes | Not relevant since they're loaded from sub-folders | Yes |  Partial, from a closed list |  No |
| Support for draft buttons |  Yes | Not relevant since they're loaded from sub-folders | No | No | No |
| Support for chaining together a sequence of commands | Yes |  No | Yes |  No |  No |
| Support for enforcing a single instance of launched programs |  Yes | No |  Partial, by making them close first through a separate command | No | No |
| Allow running without a tray icon |  Yes |  Yes | No | No | No |
| Writing to the disk on each use / tracking usage | No |  Yes |  Yes |  Yes | No |
| Graying out buttons that refer to non existing programs |  Yes | Not relevant since they're loaded from sub-folders | No, as there's no menu. But a warning pops up | No | No |
| Support for blinking the taskbar upon completion of the launched program |  Yes | No | No, as there's no menu. But a warning pops up | No | No |
| Embeddeding a default settings file in case of a missing external file |  Yes | Not relevant since they're loaded from sub-folders | No, as there's no menu. But a warning pops up | No | No |
| Can launch programs as admin |  Yes |  Yes | No | No | No |
| Can either block or allow network access |  Yes | No | No | No | No
| Can launch multiple configurations with a single launcher |  Yes | No | No | No | No |
| Can create or delete services |  Yes | No | No | No | No
| Can delete drivers |  Yes | No | No | No | No
## FAQ
### General
#### How is it different from other similar apps?
It offers a unique combination of usually standalone features. See [comparison](#comparison).
#### Is the program portable?
Yes, no installation is involved. You need to run the main program, see [usage](#usage).
#### What is the difference between the 32-bit and the 64-bit version?
There are no intentional differences. Even more so, the 32-bit version can still be used in 64-bit operating systems. But the 64-bit version is compiled specifically for such systems.
#### Can I restore a launched program's settings before launching it?
Yes, this will allow you to portabilize completely non portable programs. See [usage](#usage) how to backup/restore all kinds of settings.
#### Is there a way to try out deleting/creating leftovers without actually deleting/creating anything?
Yes, see [usage](#usage) on how to activate simulation mode per item or per the entire launcher.
#### Must I use menus?
No, you can avoid menus altogether either by the command line parameter `/skiptobutton=X` or just uncomment `;skiptobutton=X` to choose a pre-defined button instead of opening the menu. For example, `skiptobutton=4` will always launch button 4 without opening the menu.
#### Can I create sub-menus?
Each menu displays a link to its parent menu (if such exists). Also, each menu can detect menus in its sub-folders. Alternatively, specify `relativepathandfilename=folder` to load that folder's menu (if it lacks a menu, the folder would be launched regularly).
Until v1.1, it had to be done indirectly by spreading autorun.inf and autorun.lnk (which calls the actual program) files all over your system, then use `relativepathandfilename=folder\autorun.lnk` to call one menu from another.
### Misc
#### Can the menu open automatically in anything other than DRIVE_CDROM?
While outside of the scope of program, it's understandable why users of this program would want the menu to open automatically in DRIVE_FIXED and DRIVE_REMOVABLE (e.g. USB flash drive). Therefore, here's a summary (based on [Inf handling in Wikipedia](https://en.wikipedia.org/wiki/Autorun.inf#Inf_handling)):
| Version of Windows | Inf handling of autorun.inf's [AutoRun] section |
|-------------------------------|----------------------------------------------------------------------------------------------------------------------------|
| **Windows 9X/Me** | |
| DRIVE_CDROM |  "open" command is executed automatically |
| DRIVE_REMOVABLE / DRIVE_FIXED |  "open" command is executed automatically |
| **Windows XP/XP SP1** | |
| DRIVE_CDROM |  "open" command is executed automatically |
| DRIVE_REMOVABLE / DRIVE_FIXED |  "open" command is disabled |
| **Windows XP SP2/SP3+** | |
| DRIVE_CDROM |  "open" command is executed automatically |
| DRIVE_REMOVABLE / DRIVE_FIXED |  "open" command can be enabled by "**action=My menu**" |
| **Windows Vista** | |
| DRIVE_CDROM |  "open" command can be enabled by "**action=My menu**" |
| DRIVE_REMOVABLE / DRIVE_FIXED |  "open" command can be enabled by "**action=My menu**" |
| **Windows 7+** | |
| DRIVE_CDROM |  "open" command can be enabled by "**action=My menu**" |
| DRIVE_REMOVABLE / DRIVE_FIXED |  "open" command is disabled |
**Conclusion:** Starting from Windows XP, Microsoft tried to limit the "open" command support to DRIVE_CDROM. While later versions did back down somewhat, Windows 7 once again completely disabled it. So if your audiences use Windows 7 and above, you'll have to teach them how to browse for autorun.exe manually. For older audiences or CDROMs, you can still use the "action" trick.
### License
#### Is the program free?
Yes, it's open source (as of version 1.3.4).
Prior to that, it was a freeware (starting in version 1.3.1).
Originally it was a time unlimited shareware with a possibility to register.
#### Registered version (no longer needed)
##### What were the benefits of registering?
These features are now free, but originally they only worked for registered users:
* No "trial mode" in the title.
* Support for deleting leftover files/folders (including re-creating empty folders).
* Ability to hide special buttons.
* Supporting future development.
##### What was the definition of "Life" in Life license?
Before the program was free, users could choose between 1 year and Life. The latter meant the life of the product. That is, updates for as long as there are updates.
Choosing the license showed dedication and support for future versions. The price was not too expensive anyway, so there was no a big loss even if there were no more updates.
##### Did it phone home?
Before the program was free, it didn't phone home per se. But it did validate one's license key every once in a while. Product activation ([see Wikipedia](https://en.wikipedia.org/wiki/Product_activation)) is the only way to combat crackers. It's not the best way so much as it's the only realistic way. Validation only occurred seldom and was quick and automated. It did alert to its presence to maintain full disclosure. Precautions were made so only abnormal long Internet connection dropouts would result in the need to re-register one's license key (once the connection was finally back).