Longs are just 32 bytes of ram. Unless you are doing math on the value, a long is preferable to a ulong for performance reasons.
For example a lot of Windows APIs return a 32bit value. Sonetimes referred to as a handle or Long or whatever. You can store it in a Long, and pass it back when required. The actual type isnt as important (unless youre doing math on it) - the length is the key.
So a Long is faster than using a Ulong in nanosecond timescales then.
Thanks.
Does anyone know where I can find the .h files like winnt.h, basetsd.h refered to in this link and others?
Google is only showing the wine and mingw .h files.
The most I got taught about .h was to always include stdio.h and that was it, no explanation why, and our computer science teacher was the spitting image of Little Enos Burdette from Smokey and the Bandit which kind of detracted from his teachings.
As he was also in charge of the computers for the school one of my classmates hacked the school network to show how useless he was but got suspended for it.
He just used a trojan logon screen program to gain access!
Thanks.
Edit.
Think I’ve found it in the windows sdk so downloading the ISO.
Nothing on github from microsoft from what I can find.
To answer your questions in no particular order…
Look at the documentation for the API call.
the last parameter, lParam, is “A user-defined value that is passed to the callback function.”. So I use 42, because I can.
If you want the Windows .h files you have to download the Windows SDK and install it
I didn’t make the PDFs, they came like that on the Clarion 4 CD
I went 1.5, 5, 5.5… and had I known back then each release would contain code extras not shipping in subsequent releases, Id have held onto them.
So is your loader3 CallDLL 32bit/16bit encapsulated assembler just messing around code? I havent run it in the debugger yet, but I cant see the point in pushing some of those registers onto the stack unless Im missing something?
It looks like Clarion is a cut down rehash/copy of MASM.
For example, does the Clarion assembler even have Assume?
Edit. I thought this was just a msg and not public so edited some terminology from french to english.
Parameters to API calls have to go on the stack.
The clarion calling convention passes parameters in registers if it can, on the stack if it can’t.
The C & Pascal calling convention always uses the stack for everything, the difference is which order they go on (first param first, or last param first).
But another part of the clarion docs says C is the param cleaner and pascal is your program cleans the params which is useful when passing by address.
I havent got to the point of following everything in the stack yet, havent even looked for the Stack Pointer in the debugger yet. Just documenting everything and testing it bit by bit.
Eg
Clarion vars with the Auto attrib seem to be a data segment with unintialised data vars.
Clarion vars not using Auto appear to be a data segment with initialised data.
And clarion code is a code segment.
But need to test all this.
I should add this was never taught to me at GCSE aka O level equiv or A level, partly because the UK education was pushing UK platforms BBC Acorn & Nixdorf Siemens and MS DOS wasnt quite the dominant player, when thinking of things like OS/2, IBM AS 400’s and other OS’es were knocking around. Not once was a stack ever discussed in any context at gcse or a level.
Edit.
I should also add, understanding this is a gap in my knowledge I now need to fill and its only become as Ive need to get somethings working better.
Whats the fix stack prototype for in your VDM prj example? Is this something in the clarion runtime like some of those C functions that can be called for?
Clarion vars with the Auto attrib seem to be a data segment with unintialised data vars.
Clarion vars not using Auto appear to be a data segment with initialised data.
And clarion code is a code segment.
Yes, that all seems reasonable and expected.
This here sums up the mess of calling conventions.
“x86-64 calling conventions take advantage of the added register space to pass more arguments in registers. Also, the number of incompatible calling conventions has been reduced. There are two in common use.”
Im sure all these different calling conventions had their reasons to exist, considering the hardware changes I saw in pc’s from the 8088 onwards, but it was never taught to me, I’m entirely self taught, and gave up education out of sheer frustration. Plus you couldnt complain about teachers or the curriculumn back then.
One ex military teacher assaulted me outside the staff room when a group of us went to complain!
Thats what school was like back then.
Teachers assaulted pupils at primary schools and secondary schools frequently and its all covered up!
Anyway interesting to see the delphi com object calling convention mentioned on this wiki page.
And the ABI is also worth a read but Ive only scanned it so far.
Just need to do a tldr at this stage.
x86-64 is irrelevant, because you don’t have a 64bit compiler and you can’t take advantage of the extra registers that a 64bit CPU has.
The only 3 you care about on that page are cdecl (C), Pascal and Topspeed/JPI.
Agree on the x86-64 compiler point, but looking at how these calling conventions work, I think it would be possible to write some assembler function to use the delphi/COM calling convention and also make my own calling convention.
This would compensate for when the C or Pascal attribute cant be used.
Just been summarizing the heap.
Yuck but neccesary.
Default Heap controlled by heap manager, optional Private heap controlled by process/program.
32bit have 8byte allocation granularity (AG), 64bit have 16byte AG.
Two types of front end layer, look aside lists and low fragmentation heap.
Etc etc.
Edit.
When thinking about writing own assembler code to call delphi/COM, actually I cant see no reason why it wouldnt be possible to write a 64bit calling convention in assembler to bolt onto a 32bit clarion app, so the need for a 64bit compiler would be negated.
This jmp eax is like the start of a calling convention in some respects, just a bit more complicated than a single line of assembler.
Interfacing to a 32bit delphi app would be possible, if you’re willing to put in the work.
But x86 and x64 assembler are completely different beasts, hence the reason why there’s not been a native 64bit compiler in the last 20 years. So I’m not sure that’s possible.
Plus is 64bit too wide for the performance seen with hardware, forcing a distributed data model to be used?