I'm having a difficult time figuring out why RegOpenCurrentUser has a samDesired parameter at all. Surely it's always going to be KEY_ENUMERATE_SUB_KEYS or even 0?
A subsequent call to RegOpenKeyEx is required to do anything meaningful in the impesronated user's registry profile. Wouldn't you pass the specific samDesired value to that call? Are there any access requirements for the first parameter (hKey) to RegOpenKeyEx?
RegOpenCurrentUser returns a handle to the root of a registry hive. I can't think of any scenario other than installing Windows or creating a brand new user profile where anything is done at a hive root. And if you're running a program as another user, presumably all of that is already done.
RegOpenCurrentUser: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724894(v=vs.85).aspx
RegOpenKeyEx: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724897(v=vs.85).aspx
Related
Alright, so, I'm working on a script to execute some commands in an MMC Snapin, and I'm not very experienced with doing this kind of scripting, but i've made a lot of progress...the problem I am having, is if I create a new object every time the script runs, it will massively delay my overall script while the snapin and everything in it loads(which can take as long as five minutes). If it could load the snapin content once and then just take control of it as needed, and only create a new object IF there's not one open already, I'll save a massive amount of time when I run the script sometimes 100 times in a day.
The problem is, I'm not entirely certain how to achieve this. I thought, after some research, that it would be GetObject, but when I do
Dim objMMC
Set objMMC = GetObject("", "MMC20.Application")
It seems to create a new mmc window with no snapins loaded, rather than get the existing one with snapins loaded that I want.
Any advice? Am I just totally off base here, using completely the wrong command, or is there some simple change that I can make to fix this?
Edit:
Is there some weird workaround way I could achieve this, like storing an object to a temporary file so i can at least reuse it through a single session.
I'm in a weird situation where I am trying to add functionality to a powershell script and couldn't find a way to do it directly in powershell, so i'm setting up a vbscript to do one piece of it and calling the vbscript from powershell. I already had to do a lot of research to figure out how to do it in vbscript(and i'm still not sure about all of it) so i guess before i go any further, I'll try to figure out if this is even viable(in vbscript or c# or c++ or any other language someone could suggest)...
What i want to do, overall, is check if an MMC window is open that contains a DHCP snapin. If so, assign it to a variable. If not, create one.
Then it will read from a csv or txt file, and use the values to determine what node to navigate to within the snapin(DHCP>ServerName>IPv4>ScopeName>Scope Options).(I've mostly solved this part in vbscript, but don't know how to do it in C++ or C#)
Finally, I need to be able to execute a right-click menu item to "configure options", navigate the tabs of the popup that comes up, enter a value, and apply the changes/hit ok to close the popup. Worst case, If I can't do it "normally" by actually sending commands to the objects themselves, this part I can do with imitating keystrokes, but i don't want to do that if it's avoidable because it's sloppy.
Then, I basically will just need to somehow alert the powershell script that i'm "finished" so it can continue, or give an alert if there's an error.
I'm not asking anyone to walk me through all this, I just want to know if any of those steps aren't viable as i've described them, especially if I'm going to have to switch to c++ or c# to achieve the first part and therefore relearn the commands needed.
... and only create a new object IF there's not one open already ...
No, this is not possible in VBS, you need to do
Dim objMMC
Set objMMC = WScript.CreateObject("MMC20.Application")
if I create a new object every time the script runs, it will massively delay my overall script
In this case is the VBS the wrong language, you need to use C# or C++ executable.
We have a PDF document processing system, implemented in AppleScript (where we call the scripts from the shell using osascript). In some of the scripts, we call Acrobat Preflight Droplets from the Applescript.
This does usually work without problems. However, in some cases, where the processed document is big or/and complex. the droplet returns control to the script before the report is written and the document is moved to the "success" or "failure" folder. The consequence is that the process continues, but without the moved file, it eventually fails.
The workaround so far has been to add a delay after those droplet calls. This does help, but it is a waste of time for small documents, and there will always be a document big and complex enough to take longer than the delay.
We also found out that the time needed for finishing writing the report and moving the document depends on the speed of the system (had to be expected…).
The workaround would be to calculate the delay from the document size, its number of pages, and a machine-dependent parameter. Document size, and number of pages are no big deal; they can be retrieved in the Applescript.
The problem is the machine-dependent parameter, which can be determined experimentally. But how do I make that parameter available to all the scripts needing it?
Incorporating it into the scripts is not an option, because we have a number of systems installed, and if we would do that, we'd end up in a maintenance nightmare. Passing it as an argument in the initial system call is also not possible, because the calls are many, and again would lead to a maintenance nightmare.
So, is there a way to set up a place where that machine parameter can be stored and easily called from any Applescript, no matter how it itself is called.
Thanks a lot for your advice.
You might find the Property List Suite in System Events useful. It’s a standard means of storing and then retrieving such information. Property List files themselves are simply XML files, so you can even create them outside of AppleScript and then read them within your scripts.
There’s a description with examples at https://apple.stackexchange.com/questions/58007/how-do-i-pass-variables-values-between-subsequent-applescript-runs-persistent
A simple suggestion if you only have one paramater to keep track of would be to just have a text file in a known location on each machine. The only content of the text file would be the machine paramater. I like to use the Application Support folder this kind of thing.
Assuming your machine parameter is CPU speed. You can save a text file in /Library/Application Support/Preflight Scripts/machinecpu.txt with the contents:
2.4
Then in Applescript, you would just read the text file.:
set machineParam to read file "Macintosh HD:Library:Application Support:Preflight Scripts:machinecpu.txt"
I have a VB6 application that I'm trying to make log out differently. What I have is a flag in the registry (existing) which states if the application is set to Debug mode so that it would log out.
Within my code I then have lots of if statements checking if this is true. This means that there is a lot of processing time checking if a statement is true, which maybe not much really but as it does it so often it's an overhead I would like to reduce.
The code is full of statements like this
If isDebug = True Then
LogMessage("Log what is happening")
End If
So what I'm looking for is a better way to do this. I know I can set a debug mode within Project Properties -> Make, but this needs to be set prior to building the .exe and I want to be able to set this in production via the registry key.
Consider using a command line argument to set debug mode. I used to do this.
Dim sCommandLine() As String
sCommandLine = Split(Command$)
For I = 0 To UBound(sCommandLine)
' do something with each arg
Next I
You can also persist command line args inside the IDE, so you always have them when debugging. When running outside of the IDE, make a shortcut to the compiled application with the arguments in it.
I do something almost identical to what you have in mind in a lot of my code. Add this:
Sub LogDebug(ByVal strMsg As String)
If (isDebug) Then
LogMessage(strMsg)
End If
End Sub
Then just call LogDebug in your main program body, or call LogMessage directly if it's something you always want to log, regardless of the debug flag.
I'm assuming isDebug is a boolean here. If it's a function call, you should just create a global flag that you set at the beginning of the code, and check that instead of looking at the registry over and over. I don't think checking a boolean is that much of a processing load, is it?
You want to call a function if a runtime flag is set. The only thing I can see that could be faster is:
If isDebug Then
LogMessage("Log what is happening")
End If
But I doubt that either would be the cause of performance problems. Most logging frameworks promote code like that and even put the flag/log level as a parameter to the function. Just be sure that you don't have other places where you needlessly compute a log message outside of the conditional statement.
You might evaluate why you need logging and if the logs produced are effective for that purpose.
If you are looking for a problem that can be trapped using VB error handling, consider a good error handling library like HuntERR31. With it you can choose to log only errors instead of the debug message you are now doing. Even if you don't use the library, the docs have a very good description of error handling in VB.
Another answer still:
Read your registry flag into your app so that it's a session based thing (i.e. when you close and restart the app the flag will be checked again - there's no point in checking the registry with every single test).
Then (as per Tom's post) assign the value to a global variable and test that - far faster than a function.
To speed up logging you may want to consider dimensioning a string buffer in your app and, once it has reached a specific size, fire it into your log file. Obviously there are certain problems with this approach, namely the volatility of the memory, but if you want performance over disk access I would recommend such an approach.
This would, of course, be a lot easier if you could show us some code for your logging process etc.
For example, on the one hand, I can check
if a file can be written to by building up a security identifier for a user,
establishing a trustee,
getting a discrete access control list and
then getting the access mask
finally checking if it contains the FILE_GENERIC_WRITE bit.
On the other hand I could just
call GetFileAttributes and
see if the returned value == FILE_ATTRIBUTE_READONLY
For the latter case if this attribute is set, I guess it means I don't have to bother with the ACL stuff. Or is there some other subtle point that I am missing?
Is it that the GetFileAttributes returns DOS information while the access control list function is newer windows api? Should I be checking for both?
Cheers,
Ben.
The file attributes have no relation to ACLs.
You can have a "read only" file that you can have full permissions to, and non read only files that you have no access to at all.
You can also have non read only files with full access that you still can;t write to due to read only media.
Further more, the read only flag can also be removed by anyone with (write) access to the file.
The best way to see if you can write to a file is to try and write to it (or at least open it for writing).
Let's take for example notepad. How can I in my application be 100% sure whether notepad is running or not?
By 100% I mean, if there is another process whose name is "notepad.exe" which in fact is not a real notepad but for example an imitation, I don't want to detect it. Only real notepads.
I've already thought about reading the process memory but it's more difficult than it appears to be, because of memory displacements etc.
The standard way is by name, right? But for me it is really important, that it is not any other program since I want to interact with it what would critical fail if I found a wrong process.
Does anyone know a good way of doing this?
PS: There is no specific programming language to do it in. If possible I would prefer an indipendent solution. But if required, I specifically use .Net/C#.
The only way to be 99.9%1 sure you're looking at the right executable is to validate the file's digital signature. For example, you'd ensure that the notepad.exe in question was signed by "Microsoft Corporation".
I'd do something like this:
Get the list of running processes.
Filter down to name of interest (notepad.exe)
Get each process' image [executable] path.
Validate that the Authenticode signature is valid and trusted.
Compare the name of the signer to the expected value.
Success! You can be very certain this is the correct file.
This method avoids issues like having to know ahead of time where the file should be located (which is nearly impossible – Notepad is installed in two locations), what its hash value should be (obviously bound to change), or strange user behavior (replacing Notepad with some other text editor).
1 - of course, it's impossible to be 100% sure. Someone really determined could self-sign an executable with the expected signer name and add the certificate to their machine's root store, causing the signature to appear valid.
Well, I haven't been confronted to that kind of problem, but you can first check if the process is running by searching by name (in your case, that would be notepad.exe), parse the Process.GetProcesses() list for that, then get
Process.StartInfo.FileName
and see if this is the path to the Notepad executable, that would do the deal, right ?
What exactly do you know of the executable we want to be running? If you knew the filesize that could work as a "hack". Use #josh3736 's method, but replace point 4 and 5 by comparing the filesize with the one you know [different versions will have different sizes, but if there are not too many you can hardcode them]. Calculation a Md5-Hashtag would look more professional, but would do basicly the same thing.
**
If your process has a GUI: you could use EnumWindows for the children to get Edit-Boxes etc. Find something destinctive for your "notepad.exe" and check if it's there.