When attempting to install a program as a known image, instally hangs, there is no response, control Y fails and the only way out is to stop the process.
install create logical_path:program.exe/header
Program and subroutines are compiled nodebug and it is linked notraceback.
Logical path is in lnm$system. Directory is owned by system, and has protection rwe,rwe,re,re. program.exe has protection rwed,rwed,re,re. I think the problem lies with program.exe, but what ? There must be a simple explanation. BTW, am logged in as system, with cmknl set.
Many thanks in advance.
I can't comment, so asking as an "answer" (site rule - admins delete this if you want) - installing an image requires free global sections. Not sure why it would ever "hang" trying to do that, but that's the only thing I can think of that would prevent the INSTALL from not working.
Suggest checking free global sections and free global pages.
Well ... its a loooong time ago but it could be the actual name of your exe! I remember a customer problem where they installed a program of their own called ... 'install.exe'. Boy did VMS get its knickers in a twist over that!! So try 'myprogram.exe' instead of 'program.exe' The other reason may be because you shouldn't install a program called abc.exe if abc.exe is already installed. This is because the second abc.exe cannot replace the first abc.exe until the first abc.exe has released all its channels. And if someone is running (the first) abc.exe, or has it open for some other reason, then the install of the second abc.exe won't complete. VMS (because it is a properly written O/S) loves to do things 'in order'. Hope this helps
Related
My goal is to write to a file (that the user whenever the user launches an application, such as FireFox) and timestamp the event.
The tricky part is having to do this from the kernel (or a module loaded onto the kernel).
From the research I've done so far (sources listed below), the execve system call seemed the most viable. As it had the filename of the process it was handling which seemed like gold at the time, but I quickly learned that it wasn't as useful as I thought since this system call isn't limited to user-related operations.
So then I thought of using ps -ef as it listed all the current running processes and I would just have to filter through which ones were applications opened by the user.
But the issue with that method is that I would have to poll every X seconds so, it has the potential to miss something if the user launched and closed an application within the time that I didn't call ps -ef.
I've also realized that writing to a file would be a challenge as well, since you don't have access to the standard library from the kernel. So my guess for that would be making use of proc somehow to allow the user to actually access the information that I'm trying to log.
Basically I'm running out of leads and I'd greatly appreciate it if anyone could point me in the right direction.
Thanks.
Sources:
http://tldp.org/LDP/lkmpg/2.6/html/x978.html (not very recent)
https://0xax.gitbooks.io/linux-insides/content/SysCall/syscall-4.html
First, writing to a file or reading a real file from the kernel is a bad idea which is not used in the kernel. There is of course VFS files, like /sys/fs or /proc, but this is a special case and this is allowed.
See this article in Linux Journal,
"Driving Me Nuts - Things You Never Should Do in the Kernel" by Greg Kroach-Hrtman
http://www.linuxjournal.com/article/8110
Every new process that is created in Linux, adds an entry under /proc,
as /proc/pidNum, where pidNum is the Process ID of the new process.
You can find out the name of the new application which was invoked simply by
cat /proc/pidNum/cmdline.
So for example, if your crond daemon has pid 1336, then
$cat /proc/1336/cmdline
will give
cron
And there are ways to monitor adding entries to a folder in Linux.
I am writing my first WIX installer. The installed application uses various Microsoft standard OCX controls which are installed as merge modules, for example MSCOMCTL.msm, MSFLXGRD.MSM etc.
For some reason, if the target machine has UAC switched on, running the application after installation fails with a message to the effect that "MSCOMCTL is missing or has not been correctly registered...". However, if the application is run once 'As Administrator' it puts up a UAC "can this app make changes" message (so it's obviously changing something) and then runs fine, and what is more runs forever after without admin privs. (Alternatively, registering the relevant controls with RegSrv works as well).
I have monitored the application with ProcMon and it is obviously doing a late registration. It is as if the installer has advertised the contents of the merge module without installing them. I've also looked at the merge module, and my MSI, with Orca, but I can't work out any way of stopping this behavior.
I did wonder if it was anything to do with the versions of the MSMs, but it seems almost impossible to find out what the latest version of these Microsoft MSMs is, or to find anywhere to download them.
Obviously we do not want to make our customers go through this convoluted process when they install our product. Any suggestions would be greatly appreciated.
Thanks Kiran. We also read that bit in the MSDN documentation. The problem is that we can't alter the Advertise attributes on items that are already built into Microsoft's Merge Modules (well, we could using Orca but it would be messy).
However, I think we may have found the source of the problem. The previous release of our product used a kit built using InstallShield. When we compared the .MSI created by InstallShield to the one created with Wix we noticed that the InstallExecuteSequence table of the IS one contains RegisterProgIdInfo, RegisterClassInfo and RegisterTypeLibraries, which do not appear in the Wix-generated MSI. We think some or all of these may be needed to force the MSMs to install. I need to find out how to put these into Wix, and then to try it to see if it works. I will try to remember to post the result here for posterity.
[Following day] Confirmed. For anyone else who has this problem, you just need to put a <RegisterClassInfo/> tag and a <RegisterProgIdInfo/> tag (and maybe a <RegisterClassLibraries/> tag, but I didn't need one of those) into your <InstallExecuteSequence>.
I'm writing a command line application in Mac using Objective-c
At the start of the application, i want to check if another instance of the same application is already running. If it is, then i should be either wait for it to finish or exit the current instance or quit the other instance etc.
Is there any way of doing this?
The standard Unix solution for this is to create a "run file". When you start up, you try to create that file and write your pid to it if it doesn't exist; if it does exist, read the pid out of it, and if there's a running program with that pid and your process name, wait/exit/whatever.
The question is, where do you put that file, and what do you call it?
Well, first, you have to decide what exactly "already running" means. Obviously not "anywhere in the world", but it could be anything from "anywhere on the current machine" to "in the current desktop session". (For example, if User A starts your program, pauses it, then User B comes along and takes over the computer via Fast User Switching, should she be able to run the program, or not?)
For pretty much any reasonable answer to that question, there's an obvious pathname pattern. For example, on a Mac, /tmp is shared system-wide, while $TMPDIR is specific to a given session, so, e.g., /tmp/${ARGV[0]}.pid is a good way to say "only one copy on the machine, period", while ${TMPDIR}/${ARGV[0]}.pid is a good way to say "only one copy per session".
Simple but common way to do this is to check the process list for the name of your executable.
ps - A | grep <your executable name>
Thank you #abarnert.
This is how I have presently implemented. At the start of the main(), I would check if a file named .lock exists in the binary's own directory (I am considering moving it to /tmp). If it is, application exits.
If not, it would create the file.
At the end of the application, the .lock file is removed
I haven't yet written the pid to that file, but I will when exiting the previous instance is required (as of yet I don't need it, but may in the future).
I think PID can be retrieved using
int myPID=[[NSProcessInfo processInfo] processIdentifier];
The program will be invoked by a custom scheduler which is running as a root daemon. So it would be run as root.
Seeing the answers, I would assume that there is no direct method of solving the problem.
The installer I'm writing using WiX 3.0 uses a RegistryValue element to modify an existing registry value (originally written by our main product). I'm trying to figure out a way to restore the registry value when the user uninstalls my utility. I'd like to avoid using a custom action, but that might be the only recourse? TIA.
I did this. The registry value in question was the application associated to a file extension, but it could be any registry value.
My first idea was to use a "custom action" for install and uninstall to preserve
and restore, respectively, the associated regy state. This
seemed simple enough.
I created a setup project in VS2008 and built the CA's as javascript files. The "on install" script grabbed the existing regy value and stashed it into a well-known place. The "on uninstall" script would look in the well-known place, and then put the value found there, back in the original location.
Easy, right?
There were two problems:
the script that ran during install, to preserve the pre-existing registry value,
runs AFTER the registry has already been updated
with the values for the newly installed thing. So it preserved the new setting instead of the setting that was there before the MSI ran. Not useful.
The script that runs during uninstall, runs AFTER the registry values, and in fact the entire directory subtree,
have been deleted. Including the stashed value. So it had lost its state.
To solve that I wrote another script that
re-orders the custom actions so they run at the proper times.
There's actually one more twist. Obviously, the "Restore" script (on
uninstall) won't work if it is run after the registry entries for the app have been deleted. I can't remember now, why... but I also determined that this script could not run before that. Somehow that wasn't working either.
So, I modified the MSI to run the restore script
twice. In phase 1, it transfers the stashed value to a "parking lot" in the registry.
Then the application's Keys and Values in the registry get deleted, but the parking lot remains. In
phase 2, outside the transactional protection, the restore script retrieves the state from the parking lot, restores
the file association, and then deletes the parking lot.
I can't remember exactly why I needed to do this in 2 steps, but I remember fighting with it for a while before coming up with that solution.
The way it works in development:
set the on install and on uninstall CA's in the VS project
build the VS Setup project
run the post-processing script that modifies the MSI.
When using the MSI, it's a little more complicated than I originally thought but it works.
If you are using WiX, you may have more control over the time and ordering of the steps, so may not need that post-processing step.
Finally, you said you wanted to avoid a CA. To me, CA's are avoided because they are painful to produce in C++, and producing them in .NET is often inappropriate. But, it's pretty simple to use Javascript for CA's. Some people think script is the wrong tool for the CA job. I think that's wrongheaded. I think script is a very good tool for this purpose. And once you can accept script as a good tool, then you don't need to hold your nose about creating a custom CA.
The registry table is incapable of writing a registry value during an uninstall so it is correct that this must be done via custom action. I am of the opinion that using script is bad. Whether you choose to listen is up to you. I can tell you that just the other day I was called into to trouble shoot a situation where some wrote a vbscript CA that was failing because the file system object had been unregistered as part of a security lockdown process.
I suggest C++ or C#/DTF depending on your needs.
Faced with similar issue, need to update the registry value on install and restore to previous value on uninstall.
Is the only solution possible is creating a custom action for this purpose?
I found a extension for wix that has fucntions for this purpose
link to wix extensions
I'm working on creating a self updating application and one issue I'm running into on Vista and Windows 7 is needing to have admin privileges in order to update the client. I've run into issues with clients that have their users running under restricted permissions and they would have to have IT log onto every machine that needed to update the client since the users were not able to.
A possible work around I'm considering is to have the launcher application installed into Program Files as normal, and having the real application that it updates installed in the users documents somewhere, so that they could update and run new versions without IT becoming involved.
I'm wondering what potential gotchas I'm missing here or what I should be aware of before heading down this path. I'm aware that click-once does something very similar, and I'd be using it, except I need the ability to do silent updates, without any user interaction.
This is how it is supposed to be. The last thing most IT departments want is a user randomly updating a piece of software. This could have all sorts of unintentional side effects such as incompatibility with the older version's files, new and possibly insecure functionality, etc. This is why IT departments disable Windows Update and do their updates manually in a controlled fashion.
If the users want an updated version of the software they should be requesting it from their IT department. Those computers and infrastructure don't belong to them, they're simply borrowing time on them from the company they work for so they can do their job.
Is there an issue with having only one installation of your program? Is it particularly large, for example?
Do you require admin privileges to run your program?
If not, odds are you don't need the Program Files folder.
I suggest you forgo installing to Program Files entirely and just install your program into the user's folder system at <userfolder>\AppData\ProgramName.
If you happen to be using .NET, look into the ClickOnce deployment mechanism. It's got a great self-updating feature that'd probably make your life a lot easier.
Edit: Just saw your last sentence. ClickOnce can force the user to update.
A couple of things:
If you decide to move your app to some place in documents, make sure that your application writes data transparently to where your program is installed, e.g. if there are hard coded paths anywhere in the code that are pointing to bad places. Perhaps this is not an issue for you, but might be something to keep in mind.
We solved this in pretty much the same way when we decided to implement a "live update" feature. But instead we installed a service which is running with administrator rights. This service in turn can run installers once the program needs to be updated. With this type of solution you don't even have to move your applicaton out of program files.
Cheers !
Edit:
Another neat thing with having a service running as administrator. Is that you could create a named pipe communication with it and have it do things for you, like you wouldn't be able to do as a normal user.
A loader stub is a good way to go. The only gotcha is when you have to update the loader; the same initial problem applies (though that should be pretty infrequent).
One problem that I can think of off the top of my head is that you're stepping outside the entire idea of keeping things more "secure." Since your executable exists in a location that should be completely accessible to a non-administrator, it's possible that something else could slam your exe thus subverting security.
You can probably leverage AppLocker. It may only be for Win7 though I'm not running Vista any more. ;)