Chiamare specifiche API Win32 da Delphi - Perché le eccezioni volano senza "asm pop ..."?

Question

Utilizzo Delphi per creare un componente aggiuntivo XLL per Excel, che comporta l'esecuzione di molte chiamate alla funzione Excel4v di xlcall32.dll. Tuttavia, dato che immagino che pochissimi esperti di Delphi abbiano lavorato con quell'API specifica, spero che il problema possa essere stato osservato anche in altre API.

In C, in particolare nel file xlcall.h che viene fornito con il Microsoft Excel 2007 XLL SDK, Excel4v è definito come:

int pascal Excel4v(int xlfn, LPXLOPER operRes, int count, LPXLOPER opers[]); 

In Delphi sto usando:

function Excel4v(xlfn: Integer; operRes: LPXLOPER; count: Integer; 
    opers: array of LPXLOPER): Integer; stdcall; external 'xlcall32.dll'; 

LPXLOPER è un puntatore in una struct (in C) o in un record (in Delphi).

Ho fatto i compiti per dichiarare le funzioni C in Delphi (this excellent article è stato di grande aiuto), e penso di dichiarare Excel4v correttamente. Tuttavia, le chiamate dal codice Delphi in quella funzione causa eccezioni ("violazione di accesso ..." è quello che continuo a vedere) a meno sono seguiti dalla seguente riga:

asm pop sink; end; 

Dove "Sink" è definito da qualche parte come un numero intero

Non ho la minima idea dell'assemblaggio ... Quindi non avrei mai pensato di provare a correggere le eccezioni con "asm pop sink; end;". Ma "asm pop sink, end;" risolve davvero le eccezioni. L'ho visto per la prima volta in this useful article on making XLLs using Delphi. Ecco la citazione più rilevanti:..

"Dal Delphi grande ostacolo con componenti aggiuntivi è il parametro più dopo l'indirizzo di ritorno sullo stack questo viene fornito gratuitamente con ogni chiamata a Excel I' Non ho mai scoperto cosa detiene lo , ma a patto che tu passi via il , il tuo componente aggiuntivo funzionerà bene Aggiungi la variabile asm pop linea, fine; dopo ogni chiamata dove la variabile può essere qualsiasi globale, locale o variabile oggetto che è almeno 4 byte l'intero numero intero è . Per ripetere- QUESTO DEVE ESSERE INCLUSO dopo ogni chiamata a Excel4v. Altrimenti si sta costruendo una bomba a orologeria. "

Fondamentalmente voglio capire cosa sta realmente accadendo, e perché. Quello che potrebbe essere la causa di una funzione Win32 per restituire un" parametro in più, dopo l'indirizzo di ritorno sulla stack "e cosa che in realtà significa?

Potrebbe esserci un altro modo per risolvere questo problema, ad esempio con una diversa opzione di compilatore o un diverso modo di dichiarare la funzione di?

e c'è qualcosa di rischioso a chiamare" asm pop sink; fine: "dopo ogni chiamata a Excel4v ...? Sembra funzionare bene, ma, poiché non capisco cosa sta succedendo, sembra un po 'pericoloso ...

Answer 1

Non credo che sia Pascal vs stdcall - sono convenzioni di chiamata molto simili e non dovrebbero risultare in uno stack non corrispondente all'uscita dalla funzione.

Dalla riferimento article,

Questo sarebbe davvero un bel sintassi, ma non è lo stesso del sopra definizione di matrice. I parametri dell'array-of sono parametri di array aperti. Possono apparire come qualsiasi array e accettano qualsiasi array, ma ottengono un parametro aggiuntivo (nascosto) , che detiene l'indice più alto nella matrice (il valore alto ). Poiché questo è solo così in Delphi, e non in C o C++, avresti un problema reale con lo . (Vedere anche il mio articolo su array aperti), dal momento che il numero reale di parametri non corrisponderebbe a .

Stai ottenendo il parametro extra "indice di array più alto" passato alla funzione. Questo è un int e deve essere ripulito quando la funzione termina in modo da non finire con uno stack corrotto e crash. L'articolo indica come passare gli array alle funzioni C.

Qualcosa di simile:

type 
PLPXLOPER = ^LPXLOPER; 

e superare PLPXLOPER come ultimo parametro.

Answer 2

La maggior parte delle funzioni di Windows utilizza __stdcall per il loro calling conventions

Answer 3

La convenzione di chiamata è errata, in particolare "stdcall".La dichiarazione C è specificata come "pascal"

Stdcall passa i parametri nell'ordine da destra a sinistra, prevede la pulizia della routine e non utilizza registri. Pascal, OTOH passa i parametri nell'ordine da sinistra a destra. Pertanto, le cose non stanno accadendo nel modo in cui l'altra metà del codice si aspetta in entrambi i casi.

Modifica la tua dichiarazione Delphi per essere "pascal" invece di "stdcall".