My friend developed a tutorial on how to use Win32 API Threads to Freeze Programs.
Care to give it a review perhaps?
It could be a fun prank idea if you were to freeze your friends computer and then use some magic key to unfreeze it hehehe.
Printable View
My friend developed a tutorial on how to use Win32 API Threads to Freeze Programs.
Care to give it a review perhaps?
It could be a fun prank idea if you were to freeze your friends computer and then use some magic key to unfreeze it hehehe.
First thing that came to mind was: Yeah, my Windows machine has this functionality built in...Quote:
Freezing Programs using Win32 Threads
Aside from the sarcasm, it might be noted that privileges are still in effect. If notepad.exe is running with admin privileges, and the freezer is not, notepad won't freeze, of course.
And for grins and giggles, rename the freezer to notepad.exe, or change the name of the app it is freezing to the freezer's name. :)
Interesting piece of code otherwise. You might go a bit more in depth into the specific APIs, and what other (perhaps useful?) purposes they might hold - how you got the process information, for example, and what other useful information you can glean about a process/thread that way. What other stuff I can do to threads (you do a bit of this at the end of the article). Esp the process API - a lot of neat info can be found there. Basically, write something that makes me as a programmer want to fire up an editor and try it.
I'd be terribly amused...Quote:
It could be a fun prank idea if you were to freeze your friends computer and then use some magic key to unfreeze it hehehe.
Apparently, he has just discovered Win32 api.
Tell him to read the Petzold, Richter and Russinovich...
I dislike the topic of the tutorial. You could have shown some harmless use.
That code would be unacceptable if produced in my team for the following reasons;
There is no error checking nor logging/notification.
(If you are teaching people to code, teach them how to find and fix errors and write safe code.
Try to create apps that gracefully handle errors, log them and recover if possible.)
There are no comments.
(When I write code I know exactly what the code does and why I do certain things.
Next person to work on it won't. I don't remember my own code in 3-6 months, I work on too many varied systems.
You must assume your students don't know what each line does and why you are doing it.)
[Used K&R style indentation] (just my opinion)
(I hate the leading brace on the same line style you use.
I prefer the Allman style.
It groups/aligns nested code and is more logical for new coders.)
I honestly see little difference between K&R and allman , at leastr according to wikipedia. I always though K&R started the openming brace on the first line, not after it, but according to wiki I prefer banner style, although i never called it such and such a style, its just 'my style'.
It should have done an error check on OpenThread since that could return ACCESS_DENIED on some systems. But other functions can practically only fail if the system is running out of memory or some malware has broken the system.
I agree that code should generally have comments, but in that case, most lines include a call to an API function that makes the code self-explanatory so comments would look funny there.
Don't be subjective. ;)
K&R puts the { on the same line as the conditional statement, while Allman puts all of them on a new row.
I also like Allman and like K&R less, and absolutely detest the Banner style since it puts the ending } on the wrong level of indentation.
Remember this is a basic tutorial, not designed for experienced coders.
Many other API functions can fail, it is not good practice to trust them. I have seen many apps where 'safe' API calls fail due to trashed memory.
In this case, apart from the OpenThread();
CreateToolhelp32Snapshot() could return an invalid handle and the app would not notice.
Process32Next() could fail if the process has terminated during execution, stopping the app before it finds the right process to pause.
ResumeThread() / PauseThread() will fail if the required access rights have not been specified.
What about the flags used, why that one?
What about the NULLs used, why don't we fill these in?
etc.
I did clearly point out it was an opinion.
Beyond the previous comments:
If you must do this sort of thing, at least make sure that once you have located the thread/process you want to operate on, you remember it's handle, rather than doing another search based on the name. If for some reason you start a second notepad in the 7 seconds that the first one is frozen, and it happens to end up before the one you found in the first case, you will unfreeze another process.
--
Mats
If I where to do this, I would probably get debugging privs, "debug" and hook the application, then evoke an special exception. I know that might be more work, but at least the operating system would be the one freezing the treads; I think it would safer that way.