I am currently trying to make an application portable.
Where are the common places that an application puts its settings in a windows machine?
do you know know of any other places besides
-registry
-Currentuser/Application Data
-app folder
?
After you go over all the places you could think of, try running your app with Process Monitor in the background. Using the right filters, it will show you which registry keys and files have been accessed. And, it will show the exact stack trace of every operation, so you won't have a hard time finding the source of those calls.
Just for completeness - There are a couple of places within the registry (current-user and local-machine).
It depends how the developer stored it.
As sean has said in comment, this also depends on the application framework and windows version. (Thanks sean)
Related
( Hi, everyone. I'm very new to Windows programming, so I apologize in advance if this has already been asked and I just didn't know what to search for, but this problem has been driving me crazy and I know someone could probably answer this really easily. )
My company has an application that runs as a service in Windows 7. I have been tasked with writing code to change display settings, but I apparently cannot do this from a system service. I created a small executable that changes the color depth to 8bpp in about 5-10 lines of code, but when I place this code in my application, it returns success yet does not actually succeed (nothing changes).
Without a commanding knowledge of how Windows programming works, I have managed to try a MILLION different things to get it to work but with no avail. Can somebody PLEASE help me find what I need to do to make this code function?
On Vista and upwards services run in a different session (session 0) and are isolated from the interactive desktop(s). This means that code that you run from the service is simply unable to make the changes you want. The obvious conclusion is that you need to run code in the interactive desktop.
Now you can do this, but it's not exactly easy to achieve. What you will need to do is arrange for your service to launch an process that runs on the interactive desktop: Launching an interactive process from Windows Service in Windows Vista and later. That process, rather than the service, is what will have to make the changes.
Whilst it is possible to achieve what you want, I think you should regard the difficulties involved as a signal to review whether or not your proposed approach is the best solution to whatever your underlying problem is.
this may very well be a stupid question, but when i was asked something much simplier then this, i didn't have much of an answer...
why are most programs installed via some several step process of adding and changing and whatnot? we have programs that can be ran straight from a self contained executable, but a large portion of programs cannot. why is this? is it due to the programs growing exponentially by needing to include everything within itself? if that is the case, it is so difficult to design an OS from the ground up to be completely modular... ie. having an OS with a standard set of modules, that can be accessed and used from any 'standalone program' that doesn't require a lengthy install.
thanks
David Kirsch.
It's really a question of how complicated your program is. Many windows programs have dependencies on Visual Studio C++, .Net, Java etc. runtimes that are not delivered by the substrate OS. This means that for your programs to work those components must already be on the system.
If those prerequisites are missing, then your program won't even load, so you can't even get your program to check for them and tell the user to go and get them. This is where an installer comes in, as it generally doesn't have any prerequisites, but is able to sniff out the ones your progam needs and can either tell you to go and get them, or try to install them for you.
Also many programs need some logical, as well as physical, installation work to be done as part of deployment. This might mean registry changes (such as COM registration), changes to IIS (setting up a web application and virtual directory), or changes to the Service Control manager (setting up Windows Services).
In short, unless your program is extremely self-contained and has no external dependencies, an installer is the only way to get your application on the desktop.
I am a newbie and not familiar with the setup environments and stuck at some point. I am developing a very simple database application using visual studio 2010. I want to release a demo program and want the demo setup to be executed just one time for a specific computer hardware. For example when one user downloads the demo and installs the setup, the demo setup content, a simple configuration file embedded in the setup or "what so ever I do not know" should be changed, so that setup (when coppied to another computer) could not be used in other computer hardwares.
The sollutions or design ideas for this specific problem should not include any online services checking that the user executes that install or not. All the problem should be solved locally if possible :) and be as generic as possible.
Any design ideas or a starting point
will be very appreciated.
Thanks in advance
This is not possible of course. Whatever breadcrumb you leave to record that the program was ran has to be left on the same machine. Leaving any user with sufficient skills or good enough tools (like SysInternals' ProcMon) to find out where you dropped it and remove it again. Assuming they care enough about making the effort.
The simple solution is to intentionally cripple your demo so that an important feature is missing that would make it useful. Like File + Save. Not just disabled, completely missing in the code as well so hacking the demo program doesn't work either. Easy to do with an #if directive in your source code.
There's lots of questions about installers but I haven't seen one about whether or not to actually use one in the first place.
What is the logic behind using them in the first place? Can't the user just extract it somewhere? But I guess it depends on the target user.
And on the subject of the actual setup: Can't that be done on the first startup?
It very much depends on your target audience, and what your installer needs to accomplish.
If your audience is technically savvy, and the installer just has to extract some files, and create shortcuts, I probably wouldn't bother.
If you need to modify system variables, register services, etc, definitely create an installer to make life easier for your users - regardless of how technically savvy they are.
You can always offer the option of installer / no installer, and let your users decide what they want. The number of downloads and resulting support requests will tell you whether you should utilize one or not.
And on the subject of the actual setup: Can't that be done on the first startup?
uTorrent used to do this (I'm not sure if it still does... I update automatically) and I found it a little confusing at first, since I'm used to installers. For users that are possibly clueless though, it's perfect.
For more complicated applications that have multiple files installed to several locations, I think it's better to have an installer. For a series of products we produce where I work, we have several 'flavours' of installer for each product: auto-update installers can be smaller as we know the user already has prerequisites. New users, though, get a larger installer.
I can't see any reason not to use an installer. When you use something like Inno Setup, creating the installer is no more difficult than creating a zip file, and you don';t have to explain to the user how to install.
Having an installer will help your users a lot.
The application will be installed at the right place
The user won't have to set links in program files himself, or copy the extracting content you suggest in a directory
Your application will looks more professionnal
Moreover:
The user will know that using the uninstall system of windows will safely remove your application without affecting the system
You need something which can set up the registry and install prerequisites before starting the app, that's why you need an installer :)
Including a well designed installer can also add value over the lifetime of the application by enabling the application to be updated and enabling the application to be uninstalled cleanly. Eventually the user will want to uninstall the application, and the ideal is to leave their computer in the same state as prior to installation.
I would like to create events for certain resources that are used across various processes and access these events by name. The problem seems to be that the names of the events must be known to all applications referring to them.
Is there maybe a way to get a list of names events in the system?
I am aware that I might use some standard names, but it seems rather inflexible with regard to future extensibility (all application would require a recompile).
I'm afraid, I can't even consider ZwOpenDirectoryObject, because it is described as needing Windows XP or higher, so it is out of question. Thanks for the suggestion though.
I am a little unsure about shared memory, because I haven't tried it so far. Might do some reading in that area I guess. Configuration files and registry are a slight problem, because they do tend to fail with Vista due to access problems. I am a bit afraid, that shared memory will have the same problem.
The idea with ProcessExplorer sounds promising. Does anyone know an API that could be used for listing events for a process? And, does it work without administrative rights?
Thank you for the clarification.
There is not really a master process. It is more of a driver dll that is used from different processes and the events would be used to "lock" resources used by these processes.
I am thinking about setting up a central service that has sufficient access rights even under Vista. It will certainly complicate things, but it might be the only thing left facing the problems with security.
No, there is not any facility to enumerate named events. You could enumerate all objects in the respective object manager directory using ZwOpenDirectoryObject and then filter for events. But this routine is undocumented and therefore should not be used without good reason.
Why not use a separate mechanism to share the event names? You could list them in a configuration file, a registry key or maybe even in shared memory.
Do not mix up the user mode ZwOpenDirectoryObject with the kernel mode ZwOpenDirectoryObject -- the kernel mode API (http://msdn.microsoft.com/en-us/library/ms800966.aspx) indeed seems to available as of XP only, but the user mode version should be available at least since NT 4. Anyway, I would not recommend using ZwOpenDirectoryObject.
Why should configuration files and registry keys fail on Vista? Of course, you have to get the security settings right -- but you would have to do that for your named events as well -- so there should not be a big difference here. Maybe you should tell us some more details about the nature of your processes -- do they all run within the same logon session or do they run as different users even? And is there some master process or who creates the events in the first place?
Frankly, I tend to find the Process Explorer idea to be not a very good one. Despite the fact that you probably will not be able to accomplish that without using undocumented APIs and/or a device driver, I do not think that a process should be spelunking around in the handle table of another process just to find out the names of some kernel objects. And, of course, the same security issues apply again.
ProcessExplorer is able to enumerate all the named events held by some specific process. You could go over the entire process list and do something similar although I have now clue as to what API is used to get the list...