They are not discoverable, they’re not syntax checkable, you can’t catch errors at compile and design time, they’re virtually untestable because of no structure, and javascript is just worse than most.

First law of programming is “Do no magic”. But almost everything is magic in javascript.

Want an array of classes?

Sure, go ahead and put them in and name the fields whatever you want, and every element of the array can have a different definition.

Wow this is so powerful!

NOT.

It’s a good way to have typos up your ass, have almost impossible to debug code because you’ll only hit it every once in a blue moon, and you don’t have a class definition that anyone else can work from and understand.

Then there is the magic inline functions and definitions as a result of this stupid array syntax that lets you define a ton of crap all at once.

Sorry, but the only thing about this syntax (see the .ajax function on jquery for examples) is that it’s short. But I type 120 words a minute. I could give a damn about short. I want readable code, that is clear what it’s doing, with no magic and no made up stuff that you have to dig into documentation forever to find.

Oh, and then, because of all of this dynamic late bound CRAP there is no intellisense, so you can’t splunk frameworks at all.

Oh and then there is 0 intelligent error handling in any functions so it normally crashes in minified (or incredibly complex code written by someone else that you can’t possibly understand because of the magic that is going on) code with no way of knowing WHY.

Javascript is a step back to the dark ages. I would say that it was a step back to something that I’ve used in the past 30 years, but you know what? There isn’t anything that I’ve ever written in other than maybe Scheme/LISP on unix in a text editor that is as bad and that was for largely the same reasons, but wasn’t nearly as bad because it still required STRUCTURE instead of made up crap.

And the worst part of this whole thing is that .NET and other real languages are copying this crap and making their languages worse to deal with the mess that is javascript.

End the madness. Give us a strongly typed, fully bound language for web. If script kiddies copying and pasting want to use this crap, let them. For the rest of us, give us a real language.

GRRRR.

PEB 64
http://sites.google.com/site/x64lab/home/notes-on-x64-windows-gui-programming/exploring-peb-process-environment-block

and custom GetProcAdress

https://sites.google.com/site/x64lab/home/notes-on-x64-windows-gui-programming/customizing-the-getprocaddress

Cheers,

6: Afaik no UI framework is capable of modifying the UI from a non UI thread without issues. However, you can use thread marshalling (SL: Dispatcher.BeginInvoke) to update the UI during a background thread process. Best practice is to do it in more small pieces.

7: You can build up documents from the SL primitives, that will be also an UIElement. Furthermore, SL has PostScript Vector printing API.

You can’t unit test for whether a browser quietly places an element 30 pixels to the right of where you told it to place the element, nor can you unit-test for whether an in-memory Image grows and shrinks when you zoom in and out of a page with Ctrl+Scrollbar. Problems like this mean that, contrary to accepted JS wisdom, you have to explicitly check the host browser’s name and not attempt to programmatically check for browser features.

Like you I use a disassembler/code analyzer for proper hooking.

Some comment to other comments:
IAT hooking has it’s usefulness. In particular where you want to control hooking at a module level.
At the same time this is also it’s problem. You have to do it for every loaded module. Existing then an use an internal hook to catch newly loaded modules. And then this doesn’t cover the cases where the API is accessed via “GetProcAddress()”.
Although you can replace the EAT vector too that will at least cover the 2nd case.

This is what madCodeHook does for problem API cases.
If IMHO you want to see an excellent API hooking engine in practice is learn how MCH does it.
It’s been around a long time, and is very complete and robust.

I don’t claim to know all the answers but I feel people should look at each technique for it’s usefulness. Add them to your “toolbox” to use fitting the situations. The main thing is to have an understanding of what they do, what their side effects are, etc.
As in most things science it’s not always “black and white”. Grey area’s where there is more then one solution et al. And some things fitting more then other depending on your choice of paradigms, etc.
For instance if your target is a game and it has an anti-cheat then maybe you have (if it will still work for you) to hook the main exit point/block of a function. Or maybe you can hook the IAT vector because it’s not being checked (when the entry point is).

I prefer the binary hook method as it is the most complete for general purpose use. And the same paradigm applies to general purpose, other then API hooking, too.

From my blog post you will see I made a little program (that has since been expanded) to walk through a single or many DLLs to get some statistics and metrics of some common hooking considerations.

The problem cases are actually pretty rare. So rare that for general purpose you probably don’t even need to compensate for them.
Out of all the DLL exports in a XP 32bit “system32″ folder less then 5% where a problem.
With the size increased to 6 bytes (for absolute jumps, etc.) it’s still only about 10%.
And these percentages are actually less due to various error and special cases.

Just 32bit so far, I haven’t had the need to do actual native 64bit hooks when actually even on a 64bit OS most of my target applications are still 32bit (using the OS WoW64 emulation internally).

Those NOP’s (or the single byte int3/0xCC equivalent) are actually alignment padding bytes. To get the big performance benefit of having function entry points 16 byte (partial cache line) aligned.
Incidentally, you want to have your bridge/trampoline code stubs aligned too. The difference is big between a few cycles for aligned or some ~100 cycles more not aligned. So use “_aligned_malloc(p, 16)” or similar when you allocate those.

What I found in my tests is that it’s fine to assume if you see at least two of these NOPs in series you can assume them to be alignment bytes and overwrite them for hooking.
Example, as you analyze a function entry for hooking and step over a “retn” and see these alignment bytes you can just overwrite them to place your JMP (or what ever) hook there.
It might not always be the case, there is some chance for error here (that will probably result in a crash). But again we are talking a small percentage here and you should have exception handling both in your hooks and setup some exception monitoring in your engine.

Furthermore what I added to my engine is to take advantage of these NOP padding to use them as a “code cave” and place a relative short (2 byte) JMP from the entry point to a NOP space where I can fit my JMP5 hook. It’s an extra level of indirection, although a relativity few extra cycles compared to many alternatives.

Also I have an option to place a single byte int3 instead to form an exception hook for more problem cases (requires your engine to handle exceptions of course).
If there is an actual function, you should be able to put a one byte hook there.
You can also do a HWBP as well (although limited to four per thread).
Although not ideal the as there is some ~100 cycle overhead per exception. Maybe only an issue if the hook is on some very commonly called function. An exception hook handling kernel driver could reduce the overhead quite a bit too.

Finally what my engine tries to do in every case where possible and feasible is to just copy the whole function (at least the first visible block from it anyhow. Another technique borrowed from MH). This works particularly well for those short functions that are usually just a “call xxx” followed by a “retn” et al.
This has a performance advantage where your bridge/trampoline code doesn’t need to branch back to original code space to continue.

These things will get the already low 5% problem area down even smaller to just a few percent. Plus add to the tool box techniques that can be used as needed.

I’m in the middle of reading two great books on the language:

1. Professional JavaScript for Web Developers (Zakas)
2. JavaScript Patterns (Stefanov)

Both of the books are excellent, so nothing against them or the authors at all; but so far I think it’s an ugly, hacked-up and confusing language. The OO techniques are especially so. I need to get above “intermediate” level for professional reasons, but I’m really not having fun. Give me a strictly typed, proper OO language anyday over this bunch of hacks.