As you wish.

Mattias

Well, that was just to let off some steam :). Just took me a very long time to track it down...while I was debugging in gdb memory values appeared to change for no reason right in the windows api.

Anyway, I am glad it's fixed and I thank you for the quick response.

Micha.

That's true. But I removed the typecast first to see if the compiler gave me an error. But it didn't so I looked elsewhere. Please try it: remove 'stdcall;' from the TimerWindowProc and you'll see it does not complain, at least it does not on my box. But it does generate different code for the function.

However, a simple unit with a function callback prototype and a non-matching function did give an error, so I can not reproduce the bug easily.

Regards,

Micha.

It does.

-    lpfnWndProc := WndProc(@TimerWindowProc);
+    lpfnWndProc := @TimerWindowProc;

.. only it was disabled here because of the forced typecast !

So this is not really the compiler's mistake...

Anyway, good that it is fixed.

Michael.

Good you found this bug. I have been looking at it before, but was always puzzled, why simple adding a writeln could change the crashing behaviour.

I thought that stdcall was the default calling convention in fpc. Is this not true?

When you are looking at the win32 api, you better check other callbacks (winprocs) as well.

Regards,
Vincent.

causing

Hi,

You owe me one on this one :) !

It seems the compiler does not differentiate between various calling standards? (stdcall, pascal, etc)? AAAARRRGGGHHH.

Anyway, those were wrong on the timer callback window procedure causing some VERY hard to track bugs. Plz apply this patch quickly (after review of course) so we can forget about this hell :).

Regards,

Micha.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bin00032.bin
Type: application/octet-stream
Size: 2064 bytes
Desc: "timerissue.patch"
Url : http://localhost/pipermail/lazarus/attachments/20030625/9043a48b/bin00032.bin

No. FPC uses standard a stack-push strategy, pushing parameters from right to left, callee clears the stack.

stdcall convention is the usual convention for windows DLL functions and windows callbacks.

It is all documented in the programmer's manual.

When you are looking at the win32 api, you better check other callbacks (winprocs) as well.

This might solve some more problems, indeed !

Michael.

I looked it up in the programmers manual:
http://www.freepascal.org/docs-html/prog/progse19.html#x115-1120006.3

Modifier Pushing order Stack cleaned by alignment registers saved

�none� Right-to-left Function default None pascal Left-to-right Function default None
safecall Right-to-left Function default GCC registers stdcall Right-to-left Function GCC alignment GCC registers

At first I didn't see any critical differences between none and stdcall. None also uses a stack-push strategy, pushing parameters from right to left, callee clears the stack. But the difference seems to be that the callback procedure must keep the GCC-registers (ESI, EDI, EBX) unmodified. That explains, why an empty callback function had no problems, but when you added some statements, it crashed.

Vincent