I need to append a certain check to an existing exe I don't have the sourcecode of. The existing exe calls a certain DLL. The program may only be started when the calculated CRC matches that of a known good DLL. If the CRC does not match a message needs to be displayed.
Let's assume I am able to write a short exe that does the check. Is it possible to "concatenate" these two exe and only execute the second exe when the first confirms the correctness of the dll ?
I did similar things with a readymade program that may only be started when some criteria is met. In my case this is the membership in a certain Active Directory group but the same approach can be applied to your problem.
Rename the existing exe (I will name it so) to ensure it can not be run directly:
ren existing.exe existing.ldr
The dll stays like it was before:
file.dll
Now create your own exe and name it existing.exe, effectively replacing the previous exe. This exe has to do several things:
contain the crc of a valid file.dll as a constant
calculate the crc of the dll which can be found in its working directory
execute existing.ldr when the crc matches
output an informational message when the crc matches and exit the program
Related
Working with Pure Data, trying to record audio output from a patch I've made, and am 1) unable to create a file within pure data to write to and 2) attempting to use the writesf~ object causes the program to freeze after about two to three seconds. I suspect the two things are related- perhaps the program is attempting to write data somewhere, somehow, but it's going in the wrong place or some such and causing the program to freeze?
I've uninstalled the latest Pure Data release (0.51-1) and installed an earlier stable release (0.5-2) and even tried an alternative called "purr data (latest release)" all with the exact same result on my windows 10 acer laptop: no file created, and program freezes after a few seconds.
I'm testing with this patch:
I first click on the message that reads "open rec.wav" then the start then the stop, and if I take longer than three or so seconds to click on "stop" the program freezes, otherwise nothing at all happens.
I have performed system wide search for the audio file, including the folder that the patch is in, all to no avail.
Any trouble shooting hints will be carefully attempted.
Are you sure you have write-permissions on the target directory?
If your example you use rec.wav which has no explicit target directory (and is just using the "current", so it's hard to tell from outside what this directory would be).
#max-n's answer suggests to use /tmp/foo.wav which is an illegal directory on Windows. Due to a known bug, using an illegal (or otherwise non-writable) path will lock up Pd.
If your "current" directory happens to be your system root (aka C:\), you might well lack the permissions to write there.
You could check by starting the Pd from the cmdline and see whether the terminal spits out any weird errors:
⊞ Win+R
type cmd and hit Enter
in the opening terminal type the full path to your Pd-executable, e.g.:
C:\Program Files\Pd\bin\pd + Enter
(ideally leave out the extension (that is: use .../pd rather than .../pd.exe)
If the problem is indeed a permission problem, you can simply work around it by specifying the full path of the output file (and make sure that it is in a writable directory).
The easiest way to do this is by using a file-selector to choose the output file:
[bang(
|
[savepanel]
|
[open $1(
|
[writesf~]
There might be a reason why the helpfile uses a [delay 1000] to schedule a stop message in a predefined time.
I am trying to merge two exe file using ILMerge. When I execute the merged exe, it is only execuing the primary exe..Could any one tell me how an ILMerge can be used for merging the exe files
Based on information from here and here, what you want is not possible. Only one EXE can run.
For ilmerge.exe, the first file argument is treated as primary, others will be packaged as DLLs. How the primary file will work is something you can control using a command line argument t (you need /t:exe, but it will only run one file, the first one).
The t parameter is used to set output type: exe for Console app, winexe for Windows forms, librarys for DLL.
Consider I have the following :
An Excel workbook, which generates a .txt file (through a macro).
An executable file (.exe) which can parse this .txt file.
My objective here is to program the following algorithm :
Get the user to enter his data in the worksheets.
Prepare the .txt file according to what the user entered.
Pass the newly created .txt file to the external program (.exe).
Now, the first two steps work perfectly, I can generate the proper .txt file. The problem comes when I need to pass it to the external executable. Here's what's tried and observed :
Calling Shell() with : "C:\path\to\program.exe" "C:\path\to\file.txt" (EDIT : as a single string) ; simple enough, yet this does not work : the external .exe doesn't like being given a path. I have also tried entering the command directly into Windows' Execute utility : same. It seems like giving the program a path to the .txt isn't enough.
Dragging the .txt file onto the program's .exe works! The external executable does its work correctly. Here, it is as if I had passed the "file" to the program, not just its path. As a UNIX user, this sound like quite a non-sense to me (without a notion of stream or pipe), so maybe I'm missing something here...
Now, here's my question. When dragging-n-dropping a file onto an executable, how does Windows "translate" it ? Obviously, it does not translate it to "pass the file's path as the program's first parameter". How can I pass the .txt file to the executable program, without just passing its path like I did with my first Shell() call ?
A few other notes :
I am using Microsoft Office Excel 2010 on Windows 7. I'm already dying from it, thanks for your concern.
This external .exe I'm talking about cannot be modified and recompiled (which would be awesome), that's the tricky thing. I have to use it as it is, whatever happens.
Using Shell() is not a problem, if you give me the proper command/fix. I have also tried calling Run on a VBA.CreateObject("WScript.Shell"), same result.
Now, here's my question. When dragging-n-dropping a file onto an
executable, how does Windows "translate" it ? Obviously, it does not
translate it to "pass the file's path as the program's first
parameter".
It does exactly that. Create a batch file:
#echo off
echo You passed parameter: %1
pause
Save it as test.bat
Browse to it in file explorer, and drag/drop something onto it:
Previous comments:
Looks like you have to send the path and filename as one parameter, e.g.:
Shell("C:\path\to\program.exe C:\path\to\file.txt")
or if the paths have spaces in them, maybe:
Shell("""C:\path\to\program.exe"" ""C:\path\to\file.txt""")
http://social.msdn.microsoft.com/Forums/en-US/a3a3d1a7-5c9a-4c91-ab96-41d367eac2fb/using-shell-function-in-vba-how-do-i-pass-a-parameter?forum=accessdev
I'm having trouble using macros in my .inf file that I'm using to create my cab, specifically when setting the InstallDir string. If I do something like this:
InstallDir=\<PathToProgramFiles>\MyAppName
then everything works fine. However, if I do this:
InstallDir=%CE1%\MyAppName
then I get the following error when trying to install the cab (double tapping it on my device): "MyAppName was not installed successfully. Please run Setup again."
This only seems to apply to the built-in macro strings. I can use %AppName% without any problems. Maybe there is some registry setting that isn't properly set that would normally resolve the %CE1% macro?
Any ideas about what is going on?
Edit: My device doesn't have a \Program Files directory. It seems the %CE1% macro always resolves to that path and if the InstallDir specified in the inf file doesn't exist (with the exception of the last directory portion then the install fails. Manually creating \Program Files fixed the issue. Since a lot of the devices I'm working with have different paths for their Program Files directory, is there a generic way to get the installer to default to the actual Program Files dir? I guess my only other option is to not specify a path and force the user to choose one?
First, in this link you can find the shortcuts and their meaning (the %C..%), goto appendix B. The Windows CE5 MSDN link.
You can add a Setup Dll to your CAB installaer that will check the directory structure and will create a folder in case it does not exist. You may find this SO question useful.
A warning: If you are targeting regular Windows CE devices, beware where you place the files as it can be to a RAM based file system and then the files will disappear after reboot.
I wanted to write an NSIS script, let's call it for now setup.nsi, and check
if several required dll files already exists in $SYSDIR
Let me emphasize on the word "several"
What I understand from nsis IfFileExists documentation is that if I type in:
IfFileExists $SYSDIR\blabla.dll +2 +1
then it checks if blabla.dll is in $SYSDIR .. but what if I want to know if *.dll from where setup.nsi copies the file (i.e. the *.dll's that I am interested in installing in.. and they are a lot of them.. so I can't just go around checking for all the names) exists in $SYSDIR
During uninstallation I want to then be able to delete them from $SYSDIR (using some uninstall.log to see if I really copied them in $SYSDIR.. and again the wildcard question).
Please be patient with me as I am really new to NSIS scripts.
Is it REALLY necessary to write and delete in $SYSDIR ? Unless yours is a system file, there's no reason for it to be in $__SYS__DIR. If you need to use a specific version of a library, consider DLL redirection (put your DLL in your app dir and use the .local feature) - see the MSDN article on DLL redirection and Side-by-side assemblies.
Plus, you are one typo away from wrecking the user's computer ("Deleted: C:\Windows\System32\user32.dll").
As Piskvor mentions, I don't think you should be worrying about deleting system DLLs in the uninstaller. In case you want to overwrite system DLLs with an updated version, you may want to look at the SetOverwrite command. It lets you overwrite files if what you've got is newer.
Windows XP (SP2?) and up has file protection for system32, so you can't overwrite system critical files in there.
Do try to stay away from that.
Also, to check for your file specifically, see if there's a plugin for NSIS that can calculate checksums and compare that on uninstall. That's probably the safest, IF you really need to do it.
I'd suggest install files somewhere else and add that to PATH.