When we run a *.vbs file, in processes, we used to get "wscript.exe". We can change this "wscript.exe" to our custom name by creating a shortcut and executing the shortcut.
Is it possible to display the current *.vbs file name in process, without using shortcuts?
No. Your script is running in an interpreter, and it's the interpreter executable name that is being displayed in the process list.
While it's not impossible to change the process name, you'd need admin privileges to be able to do this, and you'd need to rewrite the interpreter (wscript.exe) to actually do it. See this answer to a similar question.
Related
So I'm doing a GRETL script where the users writes his Operating System (Windows/Linux), his path to a gretl workdir and the .gdt file to open (saved from a previous exercise).
This passes on string variables. One of such variables is gdt_file which before opening should be /path/to/file/file.gdt
Now, reading GRETL documentation, the open command will by default look for file.gdt inside the $workdir.
Now, what I want to do is open gdt_file, but of course it doesn't work because it's looking for gdt_file.gdt inside $workdir, instead of open /path/to/file/file.gdt
I've played a bit with it, but I'm unable to find a workaround, IDK if this is even possible, the documentation isn't very clarifying.
Thank you for your time.
here's the thread with the reply from the Gretl team, in case anyone is wondering: https://sourceforge.net/p/gretl/bugs/247/
Basically, use command "#variable" as in string substitution in the gretl guide.
I have a single command line windows executable that has many options built into this exe file.
Eg:
(It can take screenshot)
ToolGo.exe printscreen c:\temp\filename.jpg yyyymmdd
(It can show up)
ToolGo.exe showIP machineA
I want to write another command line application, possibly in .net , where it can embed/build a wrapper around this ToolGo.exe file into my application without the user be able to use the ToolGo.exe, and also users can only access one function of this main exe file.
In the example I want this other tool to access only the print screen function in this new exe file.
The new application will have this:
Tool2go.exe printscreen c:\temp\filename.jpg yyyymmdd
But if someone types the following, it will not work:
Tool2go.exe showIP machineA
Or
ToolGo.exe showIP machineA
Any ideas how I can write this code to do this in a .net command line application?
This is a multi-part question, so I'll just give the main part of the issue as the answer with suggestions on handling the rest.
You can embed a .exe into your program by clicking on Properties and navigating the the Resources section, and adding that .exe to it.
After that, it's just a matter of extracting it locally so you can pass your commands to it, and handle it's responses. (I'm not really aware of any way to do so w/out first extracting the. exe; the .exe itself needs to run somehow after all).
To extract the embedded .exe, you do this:
' Extract the MyProgram resource (i.e. your .exe)
Dim b() As Byte = My.Resources.MyProgram
' Write it to the user's Temp folder
File.WriteAllBytes(Environment.ExpandEnvironmentVariables("%TEMP%\MyProgram.exe"), b)
By extracting it to the user's Temp folder, you can pass it your commands, and since it's 'out of sight' the user probably won't even know it's there to directly use it themselves, unless they're a bit more advanced and visit their Temp folder often. You can slightly help to avoid this, but extracting the .exe when your program starts, and then deleting it when it exits, so it only exists on the user's system while your program is running.
As far as what the user can and cannot type in order to pass to the program, you can simply handle the filtering with your program; since your program is the one passing the commands to the .exe, just don't pass any commands that you don't allowed, and pass the ones you do want allowed.
I've written a Python program with some UI and froze it using PyInstaller. The program writes to an xml document in the same directory, but not all of the users on the network have write permissions to this file. Rather than give everyone permissions to write to this file, is there a way to set the program's permissions to enable it to write there? That way regardless of who runs it the program will write to the xml, but any user who didn't originally have write permissions won't be able to go manually change any of the data in the file.
A stated by #c_str in the comments you can run the process as another user on windows.
On Linux you can also use setuid and setguid to let process have his owner´s permission instead of runner user permissions.
Even though this works, both methods are questionable as stated by #c_str in the comments above.
I have a VB.NET application that is essentially a front end for a NSIS script. The script is called with all of the files and variables given on the commandline. The purpose of the application is to search and find these files on a persons computer, then format the commandline and call the NSIS script to create the installer.
I want to be able to distribute this program and protect NSIS script source code. What I was looking for is a way to "read" the script from memory within the application. My idea is that the contents of the script would be saved inside of the application, then whenever it is needed the script could be loaded and called without ever having to actually write it to the users computer.
Is this possible? If so what should I look for to accomplish it. I don't need step by step (not that you could provide one with such a skeletal outline) just what is the major concept or functions inside VB that would allow me to do this.
I assume you are using the official NSIS compiler and not a custom .dll version? If that is the case then someone can just replace makensis.exe with something that writes stdin to a file. NSIS 3 also supports dumping the preprocessed script to stdout or a file so if you allow your users to modify the switches passed to makensis then this would be a easy way to recover most of your script.
Even if we take NSIS out of the equation you are stuck with a problem that is hard to solve. I would suggest that you just encrypt the script with a simple XOR cipher, this should stop most people just looking at your .exe in a hex-editor. You can of course use stronger encryption if you want.
When you are about to call makensis you would retrieve the encrypted script resource as a memory stream or array, decrypt it and then pass it as the stdin for makensis by using ProcessStartInfo.RedirectStandardInput...
I created a protocol generation tool that reads some data from a websource, allows the user to filter some of the fields an generate a protocol based on given filterdata. The protocol is generated as a word document that is edited multiple times, on multiple layers, before shown to the user.
For some users the line:
Process.Start(pathtowordfile)
does not open Word, for others it works fine.
Even more strange: if the useres try to generate the protocol the first time it opens. if they change one of the filters and generate again, the file does not open. But it is generated correctly, you are able to open it manually.
We are using Windows 7 on all machines and, in general, the User has no administrativ privileges on the machine.
Are there any alternatives to
Process.Start()
?
Not sure how the code can sometimes work, but the critical bit I think would be to make sure you set UseShellExecute=true when you are trying to Process.Start a file that is not an executable.
https://msdn.microsoft.com/en-us/library/system.diagnostics.processstartinfo.useshellexecute%28v=vs.110%29.aspx
I haven't looked into it in quite awhile, but last I checked shell execute relies on the Word application to be properly registered with DDE so Windows knows what to do with a .doc(x) file. Word may not be installed "properly".
after trying varios things, including Wonko's hint, I dicided to use the interop.Word.Wordapplication to display the document. It doesn't explain why process.start not does the job but anyway, now everybody of the users is happy^^