---

Hej,


Kan nogen forklare hvad _int WINAPI_ dækker over i eksemplet nedenfor ?

<eksempel>
....
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow)
{
MessageBox(NULL, "Goodbye, cruel world!", "Note", MB_OK);
return 0;
}


Jeg har fundet følgende i en tutorial for Windows API'et :

"WINAPI specifies the calling convention and is defined as _stdcall...."

I "windef.h" fandt jeg WINAPI defineret som:

#ifndef _stdcall
#define _stdcall __attribute__((stdcall))
#endif
#ifndef __stdcall
#define __stdcall __attribute__((stdcall))
#endif
.....
#define WINAPI __stdcall

, hvilket må betyde at der egentlig står noget i retning af :

int __attribute__((stdcall)) WinMain(.......)
{
....
}

Hvordan er det nu lige at det skal forståes ?




Med venlig hilsen
Torben W. Hansen

---

> Kan nogen forklare hvad _int WINAPI_ dækker over i eksemplet nedenfor ?

tjae.. "int" delen er den variabeltype, som funktionen returnerer og WINAPI
er en makro som indsætter en såkaldt "calling convention", som jeg har
forstået det, er den måde, computeren kalder funktionen på.

WINAPI makroen gør i hvert fald funktionen statisk og bruges f.eks. til
callback's i windows API funktionerne.

Der er sikkert andre i gruppen der kan fortælle dig lidt mere om calling
conventions...

---

"Klaus Petersen" <ng@spectual.ra.bnaa.dk> skrev i en meddelelse
news:b57ggd$ig6$1@sunsite.dk...

> tjae.. "int" delen er den variabeltype, som funktionen returnerer og
WINAPI
> er en makro som indsætter en såkaldt "calling convention", som jeg har
> forstået det, er den måde, computeren kalder funktionen på.
>
> WINAPI makroen gør i hvert fald funktionen statisk og bruges f.eks. til
> callback's i windows API funktionerne.

Mener du at WINAPI makroen i virkligheden udgør en lagringsklasse angivelse
for WinMain() ?

Med venlig hilsen
Torben W. Hansen

---

> Mener du at WINAPI makroen i virkligheden udgør en lagringsklasse
angivelse
> for WinMain() ?

Ved ikke helt hvad du mener med lagringsklasse.
Det den gør, er som du selv har set, at definere calling convention stdcall
for funktionen.
Det vil sige at parametre pushes på stacken i først til sidst rækkefølge og
at den kaldte funktion selv hiver dem fra stacken igen.
Der er ingen information om antallet og typen af paramterene , som name
mangling ellers kan levere, så funktionen skal bare være korrekt defineret.

---

"Peter F" <a@b.c> skrev i en meddelelse
news:b581e4$sn$1@news.cybercity.dk...
> Ved ikke helt hvad du mener med lagringsklasse.
Jeg troede at WINAPI måske dækkede over f.eks. "static", "register", osv...
eller en kombination af disse - altså noget ANSI C.

> Det den gør, er som du selv har set, at definere calling convention
stdcall
> for funktionen.
Min K&R C-bog er af ældre dato - men er _calling convention_ da en del ANSI
C ?

Iøvrigt - Tak for svarene...

Med venlig hilsen
Torben W. Hansen

---

Den Tue, 18 Mar 2003 22:34:46 +0100 skrev Torben W. Hansen:
>
>"Peter F" <a@b.c> skrev i en meddelelse
>news:b581e4$sn$1@news.cybercity.dk...
>> Ved ikke helt hvad du mener med lagringsklasse.
>Jeg troede at WINAPI måske dækkede over f.eks. "static", "register", osv...
>eller en kombination af disse - altså noget ANSI C.
>
>> Det den gør, er som du selv har set, at definere calling convention
>stdcall
>> for funktionen.
>Min K&R C-bog er af ældre dato - men er _calling convention_ da en del ANSI
>C ?

Det har jeg svært ved at forestille mig.

Calling convention indeholder ting som hvem der gemmer registre så de
ikke bliver overskrevet, hvordan parametre overføres - på stacken, i
registre, og hvilke registre, hvor returadressen ligger osv.

Det er ting der er delvist afhængige af hvilken CPU man bruger, fx. vil
nogle RISC-CPU'er lægge returadressen i et register, de fleste andre
CPU'er vil lægge den på stacken. En calling convention der specifiserer
at de første 15 parametre skal overføres i registre vil være ubrugelig
på en maskine med 8 registre. En calling convention der specifiserer at
alle parametre lægges på stakken vil være ubrugelig på en ikke-stack-
baseret CPU (de er dog vist efterhånden ret sjældne).

Mvh
Kent
--
"Intelligence is the ability to avoid doing work, yet get the work done"
- Linus Torvalds

---

"Kent Friis" <leeloo@phreaker.net> skrev i en meddelelse
news:b5a5mn$2eh$12@sunsite.dk...

> >Min K&R C-bog er af ældre dato - men er _calling convention_ da en del af
ANSI
> >C ?

> Calling convention indeholder ting som hvem der gemmer registre så de
> ikke bliver overskrevet, hvordan parametre overføres - på stacken, i
> registre, og hvilke registre, hvor returadressen ligger osv.
Jeg takker meget for informationen.

Men hvis " int WINAPI WinMain(...) " omskrives til noget psuedo, så står der
faktisk følgende:

"returtype makro funktion(...)"

- så er det at jeg spekulerer over, hvad er det som "makro" indskyder
imellem "returtype" og "funktion(...)" uden at dette medfører syntax fejl
???

- har du et godt bud ?

Med venlig hilsen
Torben W. Hansen

---

"Torben W. Hansen" <mail@ins-intersoft.com> wrote

> - så er det at jeg spekulerer over, hvad er det som "makro" indskyder
> imellem "returtype" og "funktion(...)" uden at dette medfører syntax fejl
> ???
>
> - har du et godt bud ?

En mulighed er (til 32 bit MS-Windows)
__stdcall
og en anden mulighed er (til 16 bit MS-Windows)
_far _pascal
og måske noget andet til 64 bit MS-Windows eller til andre CPU arkitekturen
end Intel.

Hvorfor medfører det ikke syntax fejl ?
Fordi det er sprog udvidelser som compileren understøtter, og som er
nødvendige for at understøtte platformen - platformen kalde konventioner
skal jo overholdes når man kalder direkte ind i platformens funktioner.
I ens egen ikke platform afhængige kode vil man typisk ikke få nogen glæde
af den slag dekorationer.

Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> skrev i en meddelelse
news:b5agge$mo$1@news.cybercity.dk...

>> Hvorfor medfører det ikke syntax fejl ?
> Fordi det er sprog udvidelser som compileren understøtter...

Det var lige det jeg manglede - for at komme videre med Windows API'et.

Tak til jer alle

Med venlig hilsen
Torben W. Hansen