Is it possible to select and clear several functions without resorting to scripting from the Functions window (i.e right click->clear with options)? Currently I can only do it one-by-one on the Listing window:
I would like to wipe clearly mis-identified/analyzed functions in one go, preferably from the Functions window directly?:
And if I have to resort to scripting, does anybody have a snippet handy?
Related
Ok, it may be a bit difficult to explain:
Suppose someone creates a Windows application (using C# or any other language) that uses the GetDesktopWindow() function on the user32.dll to capture a Screenshot and then sends this image to any online service.
Since it's custom made application, no anti-virus software will be able to determine that it's a virus because it's still an unknown application for it. Also, there are legitimate uses for such API, so it's not necessarily a virus, it can be a harmless window capture tool or some kind of espionage tool.
What I want to know is: Is there any way to see what a specific EXE file does regarding the Windows functions? Can I know if "myapp.exe" uses GetDesktopWindow() of user32.dll?
This is only one example. There are plenty other Windows endpoints that I would like to know when they're used by any application.
Is there a way to do that?
It depends to what lengths you want to go doing that. It's essentially a game of cat and mouse - bad actors will attempt to find new ways to circumvent your detection by jumping through some obscure hoops, you will add more sophisticated detection methods for those tricks, they will think of new tricks, and so on.
Also, it depends on whether you want to statically or dynamically determine that, and whether you actually want to know if GetDesktopWindow is called or if "the program gets a handle to the desktop window" (which can be achieved in other ways as well).
Here is a non-exhaustive list of ideas:
You could statically determine whether the function is imported by looking at the import directory. Research the PE file structure to find out more. This article may help.
This method of detection can be easily circumvented by dynamically importing the function using LoadLibrary and GetProcAddress.
You could scan the file for the string GetDesktopWindow to detect possible usage for dynamic import.
This method of detection can be easily circumvented by packing, encrypting or otherwise obfuscating the name of the dynamically imported function.
You could dynamically observe whether the GetDesktopWindow function gets called by registering an AppInit_DLL or a global hook which is injected into every new process and hook the GetDesktopWindow function from inside the process by overwriting its first bytes with a jump to your own code, notifying your detection component somehow, executing the original bytes and jumping back. (Microsoft Detours can help there.)
This method of detection can be circumvented if the target notices the hook and removes it before calling, since its in its own process space. (You could also do some tricks with acting like a debugger and setting a hardware breakpoint on the first instruction of GetDesktopWindow, but yet again there would be ways to detect or circumvent that since the target could also modify the debug registers.)
You could build a driver that does this from kernel-mode instead, but now we are getting really deep.
Note that until now we focused on the actual GetDesktopWindow function from user32.dll. But what if the target will just use a different way to achieve its goal of getting a desktop window handle?
The desktop window handle for the current thread is stored in the TIB (thread information block) which is accessible via fs:[18] from user mode. You can see this in the GetDesktopWindow source code of ReactOS which is pretty accurate compared to Microsoft's actual implementation (which you can verify by looking at it in a debugger). The target could therefore just access the TIB and extract this value, without even calling GetDesktopWindow at all.
The target could just take a known top-level window such as the shell's hidden compatibility window which you'll get via GetShellWindow() or - to avoid detection of GetShellWindow too - for example FindWindow(NULL, "Program Manager") (or even a newly created window!) and call GetAncestor(hWnd, GA_PARENT) on it to get the desktop window handle.
I'm sure, with some creativity, your adversaries will come up with more clever ideas than these.
Also, if we take this one step further and take a look at the ultimate goal of taking a screenshot, there as well exist other ways to achieve that. First example coming to mind: They could use keybd_event to emulate pressing the PrnSc key and then read the screenshot out of the clipboard data.
So it's all a matter of how far you want to take this.
By the way, you may find the drltrace project interesting - it is a library call tracer.
What I'm Doing
I am currently working on creating a SWI-Prolog module that adds tab-completion capability to the swipl-win window. So far I've actually gotten it to where it reads a single character at a time without stopping/returning anything until a tab character is typed. I have also already written a predicate that returns all possible completions of an incompletely typed term by using substring-matching on a list of current terms (obtained via current_functor/2, current_arithmetic_function/1, current_predicate/2, etc [the predicate used will eventually be based off of context]).
If you want to see my code, it is here...just keep in mind that I'm not exactly a Prolog master yet (friendly tips are more than welcome).
What I'm Thinking
I've long abandoned any efforts at using XPCE to do popup-dropdown-completion in the swipl-win window (I'll eventually try to get that into Pce-Emacs [it won't be as polished as Visual Studio --picture something more like Python's IDLE], but I don't know if that's really even practical since I'm starting to use actual Emacs a lot more nowadays anyway), but is there any way to modify the output color in the swipl-win window? I know syntax highlighting has already been implemented in other Prolog systems' command-prompt windows, but I really just want to have it so that when tabber.pl suggests a completion, it also shows the arity (and perhaps the rest of the partially-typed term) of the suggested term in light gray. I know there is already color output from the system (like when it starts up), but I don't know how to hook into output stuff to control it myself. (Obviously, I'd probably define print/1 but...)
I know I could write my own SWI-Prolog console like one guy has done with C#, but I really wanted it so people (including me) could just load the tabber module somewhere in their config file and continue to use the swipl-win window, rather than having it be a completely different executable... Would I have to use some kind of C API?
Note:
The actual implementation will likely be influenced by the answers that I get to this question, because I'm going to base my decision on the use of strings and/or atoms in this project off of them.
What I'm Asking
Is there a way or something (even if it's really low-level) I can implement to colorize output in the swipl-win window?
AFAIU the question you have to deal with is to avoid calling the fontify-function every seconds as common buffers do. I.e. call it only once when output arrived and restrict fontification to previous prompt in buffer.
I have spent the last few months working on a program in MATLAB. As of now, 1.0 is complete. The program is pretty much autonomous, but requires a few users inputs. I am trying to add a simple GUI interface to enter these paramaters and check off/on options. I know that MATLAB has a GUI format for new files, but I want to know if it is possible to add the GUI to a preexisting program.
Here is what I need the program to have:
a. a few check boxes that change values in the program from 'false' to 'true and vice-versa.
b. a few short fields that allow user entry
c. a start button that runs the program and plots graphs.
How Would you suggest I go about this?
Thank you so much,
-Alex
You need to refactor your program so that it exposes its main functionality as MATLAB functions that can be called from other places.
Some of these functions would perform the main computations taking as input the parameters you mention. Other functions would be dedicated to plotting the result.
Once you do that, designing a GUI to drive the program is as simple as calling the correct functions from the callback routines of the GUI components.
Start guide put all the buttons and fields you need (graphically) and bind the button to your functions.
I recently inherited a VB6 project. It is pretty involved and my issue is that many different functions call this centralized function. Meaning when I do a find I get a ton of different locations in the project that make this call. Is there a way to see in debug mode what function called the function I have a break point on?
For example:
funcA calls funcZ
funcB calls funcZ
funcC calls funcZ
it goes on and on...
If I put a break point on funcZ is there anyway in VB6 that I can see what function called funcZ (A,B or C in my example)?
Just wondering...
Yes. Hit Ctrl+L to see the call stack.
A nice free tool (every VB6 IDE should have it) that amongst its many cool features is one that shows all calling procedures for any sub or function.
http://www.mztools.com/v3/download.aspx
What you seem to be asking about is a stack trace. Memory fails how easy/hard this is so a quick google search brought up this question. Combine that with some output to the immediate window, and you should be good.
Edit: Wim's answer is much better.
I commonly place into variables values that are only used once after assignment. I do this to make debugging more convenient later, as I'm able to hover the value on the one line where it's later used.
For example, this code doesn't let you hover the value of GetFoo():
return GetFoo();
But this code does:
var foo = GetFoo();
return foo; // your hover-foo is great
This smells very YAGNI-esque, as the functionality of the foo's assignment won't ever be used until someone needs to debug its value, which may never happen. If it weren't for the merely foreseen debugging session, the first code snippet above keeps the code simpler.
How would you write the code to best compromise between simplicity and ease of debugger use?
I don't know about other debuggers, but the integrated Visual Studio debugger will report what was returned from a function in the "Autos" window; once you step over the return statement, the return value shows up as "[function name] returned" with a value of whatever value was returned.
gdb supports the same functionality as well; the "finish" command executes the rest of the current function and prints the return value.
This being a very useful feature, I'd be surprised if most other debuggers didn't support this capability.
As for the more general "problem" of "debugger-only variables," are they really debugger-only? I tend to think that the use of well-named temporary variables can significantly improve code readability as well.
Another possibility is to learn enough assembly programming that you can read the code your compiler generates. With that skill, you can figure out where the value is being held (in a register, in memory) and see the value without having to store it in a variable.
This skill is very useful if you are ever need to debug an optimized executable. The optimizer can generate code that is significantly different from how you wrote it such that symbolic debugging is not helpful.
Another reason why you don't need intermediate variables in the Visual Studio debugger is that you can evaluate the function in the Watch Window and the Immediate window. For the watch window, just simply highlight the statement you want evaluated and drag it into the window.
I'd argue that it's not worth worrying about. Given that there's no runtime overhead in the typical case, go nuts. I think that breaking down complex statements into multiple simple statements usually increases readability.
I would leave out the assignment until it is needed. If you never happen to be in that bit of code, wanting a look at that variable, you haven't cluttered up your code unnecessarily. When you run across the need, put it in (it should be a trivial Extract Variable refactoring). And when you're done with that debugging session, get rid of it (Inline Variable). If you find yourself debugging so much - and so much at that particular point - that you're weary of refactoring back and forth, then think about ways to avoid the need; maybe more unit tests would help.