Agreed, fileassociations and lookup of hot-pluggable dependencies is about the most problematic hurdle to making all apps purely portable. Difficult to fix, without a standard to mark stuff on a filesystem level, and an OS that understands this. So, doable? Yes. Practically possible right now? Nope, and wont be for quite a while.
Sure, i as a user can come up with my own solution (which here is called total commander), but app devs are not interested in individual solutions - they'd need something that is available for all their users - they need this as an infrastructure.
Why write non-portable software?
Re: Why write non-portable software?
Honestly, I don't understand why you think that OS can't keep information about your apps if they are USB portable.
Keeping a list of startup apps and associations has nothing to do with portability and there are several valid ways of doing it (installers, options inside apps, likely others too).
I use portable apps almost exclusively and have some of them autostarting. Does it break anything? I don't think so.
I could have them associated too but I use portable associations of Total Commander (and before they were implemented, I used a tool that worked in a similar way).
Keeping a list of startup apps and associations has nothing to do with portability and there are several valid ways of doing it (installers, options inside apps, likely others too).
I use portable apps almost exclusively and have some of them autostarting. Does it break anything? I don't think so.
I could have them associated too but I use portable associations of Total Commander (and before they were implemented, I used a tool that worked in a similar way).
Re: Why write non-portable software?
A truly portable app is an app that leaves nothing on a computer once you unplug your device. Having the auto start with your system or assigning them as the associated program for a file type breaks that and also wouldn't work if you unplugged your portable device and put it in to a new machine.
Re: Why write non-portable software?
I disagree with this overall, but at least it's untrue when user explicitly tells the app to modify the system. Otherwise portable registry editors, file managers and such wouldn't make much sense, would they?carbonize wrote:A truly portable app is an app that leaves nothing on a computer once you unplug your device.
Obviously it wouldn't. But you don't want every computer you plug into to do the autostarting. You want your own one to do so and therefore you have to set it up to behave this way. Once I had different computers starting up different things because I used them in different ways. Some features are inherently non-portable because of the way they are used and autostart is one of them. Trying to make them portable would be possible (scanning all devices at startup and reading special-purpose metadata in executables to know if they are supposed to be started up automatically), but it just doesn't make sense.carbonize wrote:Having the auto start with your system or assigning them as the associated program for a file type breaks that and also wouldn't work if you unplugged your portable device and put it in to a new machine.
Re: Why write non-portable software?
Autorun.inf?
I've configured autorun.inf so that launching PStart is the default AutoPlay option when I plug my external hard drive into my computer. (Mind you, PStart isn't launched automatically when I boot the machine and the disk is already plugged in, as it usually is.)
Unfortunately, malware used autorun.inf so extensively that Windows 7 only allows autorun.inf to change AutoPlay options on optical discs.
At least USBDLM will allow me to override the limitation on my own computer...
I've configured autorun.inf so that launching PStart is the default AutoPlay option when I plug my external hard drive into my computer. (Mind you, PStart isn't launched automatically when I boot the machine and the disk is already plugged in, as it usually is.)
Unfortunately, malware used autorun.inf so extensively that Windows 7 only allows autorun.inf to change AutoPlay options on optical discs.
At least USBDLM will allow me to override the limitation on my own computer...My YouTube channel | Release date of my 13th playlist: August 24, 2020
Re: Why write non-portable software?
A solution to the malware problem - and also one that gives the user more immediate control over autostarts - is to just not do "automatic startup" but instead automatically ASK the user to start specific apps.
When autostart would normally happen, show the user a dialog "Automatically start these applications?" followed by a list of apps that request autostart. This also would go a long way in reducing the power of malware autostarting at windows boot.
Drivers and important system services would of course be in a seperate list, mainly because authenticating the entire boot process would be ridiculous (yes, that leaves a hole open for malware - then again, if something requests such deep system integration, the user should be asked anyways imo).
P.S.: To still allow unattended startup for scenarios where there isn't a user to authorize the startup, such a dialog could have a timeout (say, 20 secs - though, as soon as the user clicks the mouse somewhere or presses a key, the timeout is disabled). Upon timeout, the dialog would be "OKed" automatically.
When autostart would normally happen, show the user a dialog "Automatically start these applications?" followed by a list of apps that request autostart. This also would go a long way in reducing the power of malware autostarting at windows boot.
Drivers and important system services would of course be in a seperate list, mainly because authenticating the entire boot process would be ridiculous (yes, that leaves a hole open for malware - then again, if something requests such deep system integration, the user should be asked anyways imo).
P.S.: To still allow unattended startup for scenarios where there isn't a user to authorize the startup, such a dialog could have a timeout (say, 20 secs - though, as soon as the user clicks the mouse somewhere or presses a key, the timeout is disabled). Upon timeout, the dialog would be "OKed" automatically.