Shoutbox

you are the man!

* matty wonders when we can expect 4.51...

* Patchou wonders too....

Don't worry Matty, I'll bother you soon enough with aome private build to test.

and fix some skinny stuff to <3 :->

What about SetWindowLong and SetWindowsHook? I want callbacks for those.

Technical answer: When C++ is compiled native, it means that the compiler basically converted the code to assembly code. This code is much more low-level, and very difficult to read by humans (but quite easy to understand), this is also why you cannot read the source-code of any program you've downloaded. You can say it's the language your processor is reading. Different functions have different calling conventions, they are called differently in the assembly code. You won't notice this when coding C++, but the outcome is different. The compiler stores the function signature (what address, calling convention, parameters) the function has, and if your line doesn't match, the compiler prints an error. To make programming more sorted, you put these often signatures in your header file (*.h/hpp), and then include that file on the top of the actual code (*.c/cpp). For example (this is the function signature):

code:

---

int myfunc(int a);

---

Mostly compilers use the __cdecl calling convention by default (C/C++ compilers). So the compiler would read it as:

code:

---

int __cdecl myfunc(int a);

---

If you change calling convention to, let's say, __stdcall, you won't notice any difference, the function will get called as you wanted, but the assembly code is different.
When you call it in your code you'll probably use something like this:

code:

---

myfunc(1);

---

But if you do anything wrong like: (this code is wrong since the myfunc-function only has 1 parameter.)

code:

---

myfunc(1,2);

---

What I wanted to show was that the compiler check for the signature when a callback function is called. When you apply yourself to a hooking-chain or another callback function, you simply leave an address in the memory to the function you want them to call, but they cannot find your calling convention, so Microsoft said:

quote:

---

Let's use the __stdcall calling convention for Win32 functions.

---

There's a way to bypass the signature check, because you cannot get the signature (well if you know assembly, you could figure it out) after the compilation, but when Windows wants to call your function, it simply uses __stdcall. When you call an API-function with a callback (when you want Windows to call your function), you leave an address to the function position in the memory it's loaded into. It knows which parameters the function must have, because you're using a technique called function-pointers, they defined the signature of the function in Windows code, so when they call it, the signature of your function must be the same as the signature they defined for your function. If the calling convention is wrong, you'll probably get a crash or something, it won't work simply.
And JScript isn't compiled code, it's not read by your processor, it's read by an emulator executed by the processor, the JScript-code is getting parsed in real time. The JScript functions aren't stored in memory, and they cannot be because they're not actually compiled code (assembly), so Windows cannot call them without knowing how to call them, and that's quite advanced, the JScript emulator doesn't allow this (this could probably be done with a lot of research and a very hacky result, but the Win32 library isn't written for scripting). Also different parameters in a function-call have different sizes, JScript doesn't because the function doesn't actually exist (this is one of the biggest reasons JScript is easier), it changes the function when it gets called, differently depending on what size of the parameters.
Now what Patchou is going to do, is that he creates the callback in his C/C++ code (he needs to know the signature before comiling!), and when his callback gets called he's going to call the JScript emulator, because he's the one with access to it.

Awesome explanation, vikke! Many thanks for clarifying this!

Thanks. I was bored.

SetWindowLong and SetWindowsHook won't be supported by the new callback system. The restriction is that only synchronous calls made by the callee (like EnumWindows) are allowed.

I was actually hoping for that, but yeah, I understand the restriction, and even if it would be implemented, it would cause a lot of delay to Messenger's windows-messages, since they have to get parsed through JScript before getting handled by the window.

yep, it would cause lots of delays and I tend to assume that if you want to go that low level, you'll prefer creating a DLL for that.

Sorry for 'reviving' this thread, but i wonder if DdeCallback can be done with 4.51

Edit:
i'd like to implement a small DDE client