DLL calls, the internal working

The internal working of DLL calls in Forth

DLL calls present a problem to Forth because of the large number of parameters needed by most DLL-calls. Juggling those into the correct, reversed order makes for unreadable programs, or a host of named LOCAL's. Then there is the requirement, resulting in tough problems when overlooked , that the parameters for 64 bits programs are to be placed, not at 8 byte boundaries, which would be natural, but at 16 byte boundaries. It goes without saying that preparing the Forth stack pointer for this condition is weird and error-prone.

In ciforth this is solved by reserving an area on the stack well below the Forth stack pointer by CALL[ . So the Forth stack temporarily resides within an area reserved for Windows. Parameters can be placed in the 16 byte aligned (64 bit) or 4 byte aligend (32 bit) MS-window parameter area by Forth words PAR1 ... PAR5 . If there are even more parameters, PARI is available. Meanwhile the Forth stack can be used to calculate the parameters as needed, as long as it stay clear from the parameter area. There is no need to calculate the parameters in order. Once the area is prepared we can do ]CALL . The return value of the call is put onto the regular Forth stack, which is just cell-wide for 32 or 64 bits alike. An added advantage of this method is that the parameters could be made default to zero, which means that in quite a lot of cases very few parameters need to be filled in (not yet), and that there is a scratch area available for e.g. copying strings in behalf of the zero character required by c. This could be accomplished by establishing a default e.g. for 10 parameters

1 PARS 10 CELLS ERASE

Internally in wina CALL[ ... ICALL] is used, referring to the indirection table at the beginning of an executable that is filled in by MS-windows. That works analogously. For OPEN-FILE seven parameters are filled in, in the order 2,1,3,4,5,6,7.

The result is pleasant code, that is portable over 32 and 64 bits and can be easily checked against dll calls documentation.