I am writing desktop programs for windows and when I need to put some program to start automatically I always use one of those options:
1 - Put a shortcut to the program in the startup group
2 - Create a value key on Windows Registry ("SOFTWARE\Microsoft\Windows\CurrentVersion\Run")
Which of this options is a best practice?
It depends on how much weight you would apply to the following questions:
As a user, should I be able to deactivate the automatic startup easily, even temporarily?
As a user, should I get the feeling that the developer trusts me to know what I'm doing?
Clarification:
If I have a shortcut in the AutoStart folder, I know that I can quickly disable this part by myself and the developer trusts me to do this.
If I don't have this visual clue, I have to actively look for it using more-or-less arcane tools (speaking from experience here).
If the automatic startup is essential for the correct function of the program, by all means, put it somewhere I can't get to it. But if it's a nice-to-have thing, like a "quickstarter", then please don't.
Related
I would like to know where I could find good resources/documentation on configuring a new Windows10 installation using Powershell scripts. I know bash but I'm completely new to Powershell.
When I search google, all I can find about automatically configuring Windows relates to Windows Deployment Services. But I don't have and don't want a Windows Server and simply running a few scripts after each installation is sufficient for me.
I found a few scripts that solve some of the things I want to do:
https://github.com/FlatlanderWoman/winCleaner
https://github.com/hahndorf/Set-Privacy
But for everything else, when I look into the TechNet Library I find it very hard to find anything useful. And when I do find something, it looks outdated:
https://technet.microsoft.com/en-us/library/hh852115.aspx
The problem is: I known the GUI-way of configuring everything I want, but I don't know how to find the corresponding commandlets to do the same with Powershell.
Is there some kind of event listener I could use to find the Cmdlets? Or does anyone have some resources/documentation to recommend? Is the TechNet Library really the established way to find these commands?
Thank you.
Unfortunately PowerShell was only really implemented in Windows 7 (yes I know it was available for XP but not preinstalled) and even then it was kind of like an addon rather than part of the core OS. Windows 8 and 10 have further improved functionality but still for the most part do not use it for their own settings and functions as most home users would have no use for it.
However there is nearly always a way to do whatever you need to, I have a script that configures servers from scratch, renaming the server, installing requisite software and features, copying files, configuring VSS, right down to putting the Computer icon on the desktop. You just have to make a list of everything you want to do, then Google each one.
For example: https://www.google.co.uk/search?q=powershell+put+computer+on+desktop - at time of writing the first result is a TechNet script pointing at a registry key. Tidy as necessary, whack into your build script and move on to the next item.
As of yet there's nothing I've found I've been unable to do with PowerShell, but the vast majority of it has not been directly with cmdlets. There's a lot of registry tweaking and command line stuff like msiexec or schtasks, some COM objects and an awkward Type I had to create and use to set the DNS suffix.
Overall I think it's still easier to do all this in PowerShell than any other scripting language and it's more flexible than premade tools, not because it has so much functionality built-in but because it can access .NET and COM which gives you broad access to all the half-baked stuff MS have wedged in over the years.
If you've developed a remote control application as I've done, you must know that screen capture doesn't capture the UAC dialog when that dialog is pop up, and as a result the control can't be continued.
Anybody know a solution to this?
From what I understand, I believe what you're asking about is possible.
In addition to remote control software, test automation software and accessibility apps for those with disabilities also need a way to interact with protected UI and the secure desktop.
Regarding the issues UAC presents for remote control software, see:
http://www.uvnc.com/vista/
http://groups.google.com/group/microsoft.public.platformsdk.security/browse_thread/thread/acb3a0ccb7682506/d05b0a3026366423
Those links contain info on how the UltraVNC project works around UAC. UltraVNC is open source, so the code might be a good resource as well.
I think the solution to this type of problem probably always involves delegating high-integrity tasks to a service. I don't think there's any other way around it (besides disabling various UAC settings).
And needless to say, writing an app that has an unusually high level of control over the system is a tricky matter - a lot of care must go into the design to make sure it's safe for use without exploitation. :)
See also:
http://www.codeproject.com/KB/vista-security/SubvertingVistaUAC.aspx
http://www.codeproject.com/KB/vista-security/VistaSessions.aspx
http://social.msdn.microsoft.com/Forums/en-US/windowssecurity/thread/4aadadbd-fc3d-4239-ba0f-4d81f17ec938
That is the entire point of the UAC dialog.
So, to answer your question, "No, nobody knows - because it isn't or shouldn't be possible".
We create a lot of internal tools in order to work with the data we use. Occasionally we'll run into a problem with one of those tools on a designer or artists computer and will need to spend considerable time on there computer to try and diagnose where the problem may be coming from.
This creates problems because while a programmer is trying to diagnose an issue on the user's computer the user is unable to continue with their work. What we'd like to be able to do instead is run an app that will generate a report that a programmer can look at on their own machine in order to at least rule out some of the more common and obvious problems.
Example information we'd need would be all the environment variables, registry info and installed applications. Is there a decent existing tool that will accomplish this or would it be better to just roll our own?
Start > All Programs > Accessories > System Tools > System Information
or
Start > Run "msinfo32"
Then,
File > Export
and you can take the file back to your desk.
Using Windows Powershell setting up a script that can provide the needed information should be relatively easy. The script center is a great starting place to learn Powershell. If you like to listen to podcasts I would recommend The Powerscripting podcast.
This probably should be on ServerFault.com, since it deals with an end user's configuration and is not necessarily a programming issue.
That said, I would think that you should be able to write a WMI script to cover this.
You'd want to start here
http://msdn.microsoft.com/en-us/library/aa394585(VS.85).aspx
I'm working hard on making my product work seamlessly on Windows 7. The problem is that there is a small set of global (not user-specific) application settings that all users should be able to change.
On previous versions I used HKLM\Software\__Company__\__Product__ for that purpose. This allowed Power Users and Administrators to modify the Registry Key and everything worked correctly. Now that Windows Vista and Windows 7 have this UAC feature, by default, even an Administrator cannot access the Key for writing without elevation.
A stupid solution would, of course, mean adding requireAdministrator option into the application manifest. But this is really unprofessional since the product itself is extremely far from administration-related tasks. So I need to stay with asInvoker.
Another solution could mean programmatic elevation during moments when write access to the Registry Key is required. Let alone the fact that I don't know how to implement that, it's pretty awkward also. It interferes with normal user experience so much that I would hardly consider it an option.
What I know should be relatively easy to accomplish is adding write access to the specified Registry Key during installation. I created a separate question for that. This also very similar to accessing a shared file for storing the settings.
My feeling is that there must be a way to accomplish what I need, in a way that is secure, straightforward and compatible with all OS'es. Any ideas?
Do you have to have it in the registry? If not, put it into a simple file, writable by everyone. Writing to HKLM requires additional privileges for a very good reason.
I'm new to here (otherwise i would've left a comment) and i'm not a windows guru, but...
imho the premise is wrong:
there's a reason if a non-elevated user cannot modify registry keys or directories read by all users (like Users\Public by default)
i think that allowing any users to modify a small set of global application settings may be disruptive for the experience of the other users that didn't expect their settings to be modified
on the other hand i don't know your use cases...
could you please specify why all users should be able to modify these settings?
and if indeed all users have to be able to do it... why can't you make these settings user-specific?
Personally I hate auto-created desktop shortcut icons, but some folks seem to think that unless your installer clutters up your desktop, it hasn't worked correctly!
Are there definite guidelines for this (for Windows?)
(Having a "Leave clutter on my desktop?" checkbox in the installer is one option, but to my mind, that's just put MORE clutter into the installer...)
From here: https://learn.microsoft.com/en-us/windows/win32/uxguide/winenv-desktop
If your users are very likely to use your program frequently, provide an option during setup to put a program shortcut on the desktop. Most programs won't be used frequently enough to warrant offering this option.
Present the option unselected by default. Requiring users to select the option is important because once undesired icons are on the desktop, many users are reluctant to remove them. This can lead to unnecessary desktop clutter.
If users select the option, provide only a single program shortcut. If your product consists of multiple programs, provide a shortcut only to the main program.
Put only program shortcuts on the desktop. Don't put the actual program or other types of files.
My take is this: the installer must ask me if I want a desktop icon - to which I can reply yes or no.
Any app that just blindly and without asking installs its icon on my desktop is a bad installation in my opinion.
Ask for permission - if I deem your app important enough to me personally, I might say yes (but most likely I won't). Give your users a choice - don't just assume since it's your app, it's so darn important to everyone that everyone will want to clutter up their desktop with your program icon.
The same goes for the installation directory - unless you have a very good technical reason why you can't install anywhere, allow me to change the program's installation target directory. Not everyone is a big fan of the "c:\program files" folder hierarchy (I'm not, for one - I like to keep my apps in C:\bin for instance).
So in general: any decent installer should ASK the user installing for these things and present sensible defaults - but always give me the option to change the settings to my liking (to my standards).
I don't know of any meaningful guidelines, other than your conscience. As a programmer, I sympathize: I don't want icons on my desktop, either :-) However, having watched non-technical family members struggle with installing software and then trying to run it, I think it's worth noting that
1) There are more non-techies than techies
2) Techies can cope with checkboxes on installers
Based on that, I usually go for having a checkbox on the installer for creating icons, which defaults to on. I don't mind anything other than the "always create icons" approach. (I'm looking at you, Adobe.)
I think that depends on what you see your client doing with the app, the level of the client's expertise with computers and how frequently you see him using it.
If the client is not very well versed with computers he would prefer to have the icon on the desktop where he can access it. If you target market is experienced users you don't need to bother because he can make the icon himself if he wants it.
If the application is for daily frequent use like a web browser the client would want it on his desktop for quick access.
Finally the decision rests on you. If you're being obnoxious you can create 4 icons on the desktop (I've seen apps that do that).
I don't think asking for permission is a bad idea. After all the installation needs to be done only once and it's just one checkbox to tick.
I've no particular love for desktop (or quick launch) shortcut icons either, but I think that you should still give your users the option in the installer to install neither, one or both of these shortcuts.
Depending on how computer literate your users are (if it's possible to determine this) you can default the two options to either enabled or disabled accordingly.