AutoRun LWMenu
Re: AutoRun LWMenu
Technically yes, but it's unlikely such a heavy software doesn't touch the registry, drivers, etc. You'll have to do a through investigation.
BTW, did you know they have a dedicated forum thread for this? It's very old so you might want to bump it and show people still care.
If you're a paying customer, you should also contact their support and ask for for a portable version.
You should also know a PortableApps fan released a PortableApps version years ago, I wonder why the fan stopped since there were positive feedbacks.
What I can tell you though is that this fan's launcher is full of custom code for some reason, which is harder to convert to a simple settings' file. But since it's so old, I don't know even know if it's worth to decipher that custom code.
BTW, did you know they have a dedicated forum thread for this? It's very old so you might want to bump it and show people still care.
If you're a paying customer, you should also contact their support and ask for for a portable version.
You should also know a PortableApps fan released a PortableApps version years ago, I wonder why the fan stopped since there were positive feedbacks.
What I can tell you though is that this fan's launcher is full of custom code for some reason, which is harder to convert to a simple settings' file. But since it's so old, I don't know even know if it's worth to decipher that custom code.
Re: AutoRun LWMenu
Ok, I'll look into that. Thanks.
Btw, that's me that created that KVR thread. MuLab itself is fully portable. But I had wondered if creating a wrapper for MuLab would enable VST's to become portable as well. A quick test says yes, as settings for the VST's I tried were in fact saved within the MuLab directory instead of the system AppData one. So I'm thinking this could work for other folders too, but I don't really know how to use AutoRunMenu to do this. I looked at X-Launcher first, but that's harder as there's no longer any support, it's great for simple stuff, pretty much does it all itself.
I have purchased a license for MuLab, but it's hard getting the dev to do anything out of the ordinary. It's understandable as he is the only dev on this project, which is huge.
I'm afraid that the PortableApps version was also requested by me too. There was an issue with accessing the folder if in use, it deleted the entire User directory, settings and Projects if you had a folder open and open or closed the app. It was abandoned.
I was only looking to portablise the stuff within the system folders really. I don't feel confident messing with the registry. So a partial portablisation would be suitable for this case.
Btw, that's me that created that KVR thread. MuLab itself is fully portable. But I had wondered if creating a wrapper for MuLab would enable VST's to become portable as well. A quick test says yes, as settings for the VST's I tried were in fact saved within the MuLab directory instead of the system AppData one. So I'm thinking this could work for other folders too, but I don't really know how to use AutoRunMenu to do this. I looked at X-Launcher first, but that's harder as there's no longer any support, it's great for simple stuff, pretty much does it all itself.
I have purchased a license for MuLab, but it's hard getting the dev to do anything out of the ordinary. It's understandable as he is the only dev on this project, which is huge.
I'm afraid that the PortableApps version was also requested by me too. There was an issue with accessing the folder if in use, it deleted the entire User directory, settings and Projects if you had a folder open and open or closed the app. It was abandoned.
I was only looking to portablise the stuff within the system folders really. I don't feel confident messing with the registry. So a partial portablisation would be suitable for this case.
Latest X-Launcher_x64 update - Compiled with Aut2exe_x64.exe v3.3.16.1
Latest X-Launcher_x64 v1.5.4 update - Compiled with Aut2exe_x64.exe v3.2.12.1
Latest X-Launcher_x64 v1.5.4 update - Compiled with Aut2exe_x64.exe v3.2.12.1
Re: AutoRun LWMenu
You really are a portable veteran 
Whichever program you choose won't spare you going through that "through investigation" link. The safest and quickest way in my opinion is using Sandboxie (which has a portable version - please vote for it!). Sandboxie has a built-in tracker for files/folders (not for registry though), so you can easily track changes. You can experiment various launcher settings, and each time close the sandbox (don't forget to mark to auto delete it on closure) to get rid of any anything that got broken by the experiments.

Whichever program you choose won't spare you going through that "through investigation" link. The safest and quickest way in my opinion is using Sandboxie (which has a portable version - please vote for it!). Sandboxie has a built-in tracker for files/folders (not for registry though), so you can easily track changes. You can experiment various launcher settings, and each time close the sandbox (don't forget to mark to auto delete it on closure) to get rid of any anything that got broken by the experiments.
Re: AutoRun LWMenu
Yep! I like to reduce the usage of system folders as much as possible. Registry isn't really an issue for the most part. I've yet to find an app that heavily relies on it for settings etc. Hence why I haven't learnt about it, except when it has been necessary.
When it comes to portable software, I am as thorough as I can be to find solutions to forcing them into being portable. I've just used portable software for so long that it's become "my way" of doing things. I just don't know how people cope with buying a new PC and having to install hundreds of apps with all their settings, passwords, files, data, without worrying they will lose something. Backup programs aren't a secure way of doing it as they introduce user error. I do use FreeFileSync-DonationEdition as it's portable. That does a fine job of copying all those files from the C drive for backing up VST's, but if i can get that data made portable, ie, saved to D drive with all my other apps an data, it would save me having to faff about with backing that up, as it would be done as part of my normal backup solution.
I do have SandBoxie-Portable set up on my system already, but I've had issue with settings not being saved when changed via it's settings interface. Plus I would really rather it be a permanent solution. It's possible SandBoxie introduces latency, yet to test for that. Also, there is the risk, however small, that I accidentally delete that specific sandbox used for saving the data for those VST's.
So, how about AutoRunMenu, do you think it is capable of doing what I want? Basically, I need it to portablise several apps folders located in:
ProgramFiles (both 32 and 64 bit versions and CommonFiels),
ProgramData,
Documents,
AppData (Roaming and Local),
User Public/Documents
I think that covers it all.
When it comes to portable software, I am as thorough as I can be to find solutions to forcing them into being portable. I've just used portable software for so long that it's become "my way" of doing things. I just don't know how people cope with buying a new PC and having to install hundreds of apps with all their settings, passwords, files, data, without worrying they will lose something. Backup programs aren't a secure way of doing it as they introduce user error. I do use FreeFileSync-DonationEdition as it's portable. That does a fine job of copying all those files from the C drive for backing up VST's, but if i can get that data made portable, ie, saved to D drive with all my other apps an data, it would save me having to faff about with backing that up, as it would be done as part of my normal backup solution.
I do have SandBoxie-Portable set up on my system already, but I've had issue with settings not being saved when changed via it's settings interface. Plus I would really rather it be a permanent solution. It's possible SandBoxie introduces latency, yet to test for that. Also, there is the risk, however small, that I accidentally delete that specific sandbox used for saving the data for those VST's.
So, how about AutoRunMenu, do you think it is capable of doing what I want? Basically, I need it to portablise several apps folders located in:
ProgramFiles (both 32 and 64 bit versions and CommonFiels),
ProgramData,
Documents,
AppData (Roaming and Local),
User Public/Documents
I think that covers it all.

Latest X-Launcher_x64 update - Compiled with Aut2exe_x64.exe v3.3.16.1
Latest X-Launcher_x64 v1.5.4 update - Compiled with Aut2exe_x64.exe v3.2.12.1
Latest X-Launcher_x64 v1.5.4 update - Compiled with Aut2exe_x64.exe v3.2.12.1
Re: AutoRun LWMenu
I, for one, did... (direct jump: https://www.portablefreeware.com/?id=3129).lwc wrote: ↑Sandboxie (which has a portable version - please vote for it!).

Likewise -- it's the main reason I stuck around TPFC like forever (Oh, look, this is my post 7000!).sl23 wrote: ↑I just don't know how people cope with buying a new PC and having to install hundreds of apps with all their settings, passwords, files, data, without worrying they will lose something. Backup programs aren't a secure way of doing it as they introduce user error.

Re: AutoRun LWMenu
And yet we're a niche. The slowdown of modern computers is less felt like it used to, so for most a little slowness is good enough.
Of course, it's only a last resort when you give up on something ever being portable. In your context I meant use it for experiments until you get the right settings right, then do it without Sandboxie.It's possible SandBoxie introduces latency, yet to test for that. Also, there is the risk, however small, that I accidentally delete that specific sandbox used for saving the data for those VST's.
It will bypass any environmental variable you want. The only limitations are:So, how about AutoRunMenu, do you think it is capable of doing what I want? Basically, I need it to portablise several apps folders located in:
- As discussed here before, if the launched program doesn't even use environmental variables to begin with (look back at the example of Unity).
- The launched program actually launches another program and perhaps even more, e.g. x.exe launches y.exe which launches z.exe. In that case, x.exe will be fooled by environmental variables, but y.exe, etc. won't (I've recently encountered it when portabilizing a freeware program called Cheat Engine - ended up always launching y.exe directly - luckily there were only 2 levels, basically the central EXE checked if the system was 32 or 64 bits and launched the relevant EXE). I don't track what x.exe does, just waiting till it gets closed. Actually tracking it is way overboard (e.g. see what happened to RegFromApp, which was the only program I've ever known that could monitor launched programs for live registry usage), even more so as nothing but monitoring endless levels will be good enough.
Re: AutoRun LWMenu
Places like this are a godsend! I for one can't thank you enough for creating and maintaining this site for so long!Midas wrote: ↑Sat Mar 15, 2025 8:17 amI, for one, did... (direct jump: https://www.portablefreeware.com/?id=3129).lwc wrote: ↑Sandboxie (which has a portable version - please vote for it!).
Likewise -- it's the main reason I stuck around TPFC like forever (Oh, look, this is my post 7000!).sl23 wrote: ↑I just don't know how people cope with buying a new PC and having to install hundreds of apps with all their settings, passwords, files, data, without worrying they will lose something. Backup programs aren't a secure way of doing it as they introduce user error.![]()

Latest X-Launcher_x64 update - Compiled with Aut2exe_x64.exe v3.3.16.1
Latest X-Launcher_x64 v1.5.4 update - Compiled with Aut2exe_x64.exe v3.2.12.1
Latest X-Launcher_x64 v1.5.4 update - Compiled with Aut2exe_x64.exe v3.2.12.1
Re: AutoRun LWMenu
Well, that's what I was expecting on first test, but it seems that MuLab is the only EXE and it runs VST plugins that are just dll files or the new formats VST3 and CLAP. Which I'm not sure about yet. More testing needed.
Thanks
Thanks
Latest X-Launcher_x64 update - Compiled with Aut2exe_x64.exe v3.3.16.1
Latest X-Launcher_x64 v1.5.4 update - Compiled with Aut2exe_x64.exe v3.2.12.1
Latest X-Launcher_x64 v1.5.4 update - Compiled with Aut2exe_x64.exe v3.2.12.1
Re: AutoRun LWMenu
Apologies, thank you Andrew! 

Latest X-Launcher_x64 update - Compiled with Aut2exe_x64.exe v3.3.16.1
Latest X-Launcher_x64 v1.5.4 update - Compiled with Aut2exe_x64.exe v3.2.12.1
Latest X-Launcher_x64 v1.5.4 update - Compiled with Aut2exe_x64.exe v3.2.12.1
Re: AutoRun LWMenu
So, if I use this and it doesn't work, there's nothing I can do?
Code: Select all
[BUTTON1]
buttontext=V-Station
relativepathandfilename=V-Station.exe
setenv=PROGRAMFILES|User/ProgramFiles/
Latest X-Launcher_x64 update - Compiled with Aut2exe_x64.exe v3.3.16.1
Latest X-Launcher_x64 v1.5.4 update - Compiled with Aut2exe_x64.exe v3.2.12.1
Latest X-Launcher_x64 v1.5.4 update - Compiled with Aut2exe_x64.exe v3.2.12.1
Re: AutoRun LWMenu
You can try checking if V-Station.exe opens another EXE file or if it calls program files via another method rather than environmental variables, worst of all if it calls it hardcoded...
If you just want a proof of concept it actually changed the variable, the easiest way is probably using relativepathandfilename=cmd and running set programfiles or just set.
Try with and without setenv and you should see the difference.
If you just want a proof of concept it actually changed the variable, the easiest way is probably using relativepathandfilename=cmd and running set programfiles or just set.
Try with and without setenv and you should see the difference.
Re: AutoRun LWMenu
V-Station.exe is actually a program called NanoHost.exe.
What this does is make the VST a standalone app, ie, the VST no longer needs to be opened in a large app like a DAW, you just rename NanoHost to the name of the VST and it auto opens that VST.
NanoHost is a small portable app which is a single EXE file, nothing more. It doesn't call anything else other than the dll file of the VST itself.
I chose V-Station as it is also a single dll file but needs the graphics from a resources folder in Program Files. Nothing else is called upon.
Thanks for the tips, but I've gone for the Junctions method. I created a PS1 powershell script that can make Junctions of those files, allowing me to force every VST to be portable, in a way. I mean, it's not, but likely the easiest and closest I'll get, and it works for everything. I just have to run the script each time I reinstall or get a new PC, which isn't often and is easy to do.
What this does is make the VST a standalone app, ie, the VST no longer needs to be opened in a large app like a DAW, you just rename NanoHost to the name of the VST and it auto opens that VST.
NanoHost is a small portable app which is a single EXE file, nothing more. It doesn't call anything else other than the dll file of the VST itself.
I chose V-Station as it is also a single dll file but needs the graphics from a resources folder in Program Files. Nothing else is called upon.
Thanks for the tips, but I've gone for the Junctions method. I created a PS1 powershell script that can make Junctions of those files, allowing me to force every VST to be portable, in a way. I mean, it's not, but likely the easiest and closest I'll get, and it works for everything. I just have to run the script each time I reinstall or get a new PC, which isn't often and is easy to do.

Latest X-Launcher_x64 update - Compiled with Aut2exe_x64.exe v3.3.16.1
Latest X-Launcher_x64 v1.5.4 update - Compiled with Aut2exe_x64.exe v3.2.12.1
Latest X-Launcher_x64 v1.5.4 update - Compiled with Aut2exe_x64.exe v3.2.12.1
Re: AutoRun LWMenu
If by "junctions" you mean symlinks in general (in Windows junctions is an alternate method for folder symlinks), then you can just define one of more symlink in the launcher, which will create those symlinks before the program starts and delete them on closure.
Re: AutoRun LWMenu
Killer feature, if you ask me -- I don't recall any other launcher being able to explicitly deal with symlinks...lwc wrote: ↑You can just define one of more symlink in the launcher, which will create those symlinks before the program starts and delete them on closure.
