CHARGER UNE POLICE DEPUIS UN FICHIER OU UNE RESSOURCE (WIN32)
MuPuF
Messages postés
536
Date d'inscription
mercredi 27 avril 2005
Statut
Membre
Dernière intervention
22 août 2008
-
3 août 2006 à 01:25
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019 - 27 juin 2007 à 17:17
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019 - 27 juin 2007 à 17:17
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/38897-charger-une-police-depuis-un-fichier-ou-une-ressource-win32
https://codes-sources.commentcamarche.net/source/38897-charger-une-police-depuis-un-fichier-ou-une-ressource-win32
27 juin 2007 à 17:17
C'est visible ici:
r = ((DWORD) p) & 3;
27 juin 2007 à 16:26
*((DWORD*) p) = 0;
*((DWORD*) (p + 4)) = 0;
26 juin 2007 à 22:45
J'avais un autre message quand j'avais mis "Ignore All Default Libraries" à yes :
error LNK2001: unresolved external symbol __chkstk
Pour ceux qui l'ont eu c'est à cause d'un buffer trop gros, j'en avait un a 768 WCHAR je l'ai descendu a 256 et plus de message même avec cette option activée.
26 juin 2007 à 19:39
Je viens d'ajouter ceci (entre autre) dans mon taf en cours:
JJ = pcurrArts->dateF - pPLAN[0];
if(JJ < 0) JJ = 0;
for(; JJ < NCOLS; JJ++) TPLANAR.jours[JJ] = 0;
ben il m'a remplacé la boucle par un: call memset
pénible...
26 juin 2007 à 17:21
Versions pour buffers alignés ou non. Utiliser les 'AL' quand tu es certain de l'alignement sur 4 de destination (souvent le cas dans code propre).
void __fastcall bnzeromemAL(void *pmem, DWORD len)
{
BYTE *p = (BYTE*) pmem;
DWORD r = len;
if(!(len >>= 3)) goto prepm1SET;
mem8SET:
*((DWORD*) p) = 0;
*((DWORD*) (p + 4)) = 0;
p += 8;
if(--len) goto mem8SET;
prepm1SET:
if(!(r &= 7)) goto zeromemEXIT;
mem1SET:
*p++ = 0;
if(--r) goto mem1SET;
zeromemEXIT: return;
}
void __fastcall bnzeromemUNAL(void *pmem, DWORD len)
{
BYTE *p = (BYTE*) pmem;
DWORD r;
if(!len) goto zeromemEXIT;
r = ((DWORD) p) & 3;
if(!r) goto okALIGN;
*p++ = 0;
if(--len == 0) goto zeromemEXIT;
if(--r == 0) goto okALIGN;
*p++ = 0;
if(--len == 0) goto zeromemEXIT;
if(--r == 0) goto okALIGN;
*p++ = 0;
if(--len == 0) goto zeromemEXIT;
okALIGN:
r = len;
if(!(len >>= 3)) goto prepm1SET;
mem8SET:
*((DWORD*) p) = 0;
*((DWORD*) (p + 4)) = 0;
p += 8;
if(--len) goto mem8SET;
prepm1SET:
if(!(r &= 7)) goto zeromemEXIT;
mem1SET:
*p++ = 0;
if(--r) goto mem1SET;
zeromemEXIT: return;
}
__declspec(naked) void __fastcall bnfillmemAL(void *pmem, BYTE v, DWORD len)
{ // ECX pmem, EDX v, [esp+4] = len
__asm {
mov eax, ecx ; EAX = pmem
and edx, 0FFh ; octet seul
mov ecx, [esp+4] ; ECX = len
mov [esp-8], esi
mov [esp-4], ebx
mov dh, dl
test ecx, ecx
je short fillEXIT
mov esi, ecx
mov ebx, edx
shr ecx, 3
je short prepf1SET
shl edx, 16
mov dx, bx
f8SET:
mov [eax], edx
mov [eax+4], edx
add eax, 8
sub ecx, 1
jnz short f8SET
prepf1SET:
and esi, 7
je short fillCLEAN
f1SET:
mov [eax], dl
add eax, 1
sub esi, 1
jnz short f1SET
fillCLEAN:
mov ebx, [esp-4]
mov esi, [esp-8]
fillEXIT:
ret 4
}
}
__declspec(naked) void __fastcall bnfillmemUNAL(void *pmem, BYTE v, DWORD len)
{ // ECX pmem, EDX v, [esp+4] = len
__asm {
mov eax, ecx ; EAX = pmem
and edx, 0FFh ; octet seul
mov ecx, [esp+4] ; ECX = len
mov [esp-8], esi
mov [esp-4], ebx
mov dh, dl
test ecx, ecx
je short fillEXIT
mov ebx, eax
and ebx, 3
je short okALIGN
mov [eax], dl
add eax, 1
sub ecx, 1
jz short fillCLEAN
sub ebx, 1
jz short okALIGN
mov [eax], dl
add eax, 1
sub ecx, 1
jz short fillCLEAN
sub ebx, 1
jz short okALIGN
mov [eax], dl
add eax, 1
sub ecx, 1
jz short fillCLEAN
okALIGN:
mov esi, ecx
mov ebx, edx
shr ecx, 3
je short prepf1SET
shl edx, 16
mov dx, bx
f8SET:
mov [eax], edx
mov [eax+4], edx
add eax, 8
sub ecx, 1
jnz short f8SET
prepf1SET:
and esi, 7
je short fillCLEAN
f1SET:
mov [eax], dl
add eax, 1
sub esi, 1
jnz short f1SET
fillCLEAN:
mov ebx, [esp-4]
mov esi, [esp-8]
fillEXIT:
ret 4
}
}
26 juin 2007 à 13:50
Aller BruNews fait péter memset en ASM ! :-)
26 juin 2007 à 12:14
char *asmemset(void *dest, int c, unsigned int count)
{
register char *st = (char *)dest;
while (count-- > 0)
*st++ = c;
return (char *)dest;
}
//------------------------------------------------------------------------------
char *asmemcpy(void *dest, const void *src, unsigned int count)
{
register char *des = (char *)dest;
register const char *sr = (const char *)src;
while (count-- > 0)
*des++ = *sr++;
return (char *)dest;
}
//------------------------------------------------------------------------------
int asmemcmp(const void *buf1, const void *buf2, unsigned int count)
{
register const char *b1 = (const char *)buf1;
register const char *b2 = (const char *)buf2;
while (count-- > 0)
{
if (*b1++ != *b2++)
return b1[-1] < b2[-1] ? -1 : 1;
}
return 0;
}
//------------------------------------------------------------------------------
Est ce que par hasard vous auriez un set de fonction que le compilo ne detecte pas comme étant similaire a celle de la CRT ?
Tu disais BruNews que tes fonction asm n'était pas détectée ? pourrais tu publier tes fonctions ? j'ai juste besoin de ces 3 la , memcpy, memset et memcmp.
25 août 2006 à 20:57
Au début le compilo ne veut pas (il dit fonction intrinsèque, non définissable)
J'ai trouvé qu'il faut juste mettre un pragma avant:
#pragma function(memset)
void* memset(void* buffer, int c, unsigned int num)
{
// notre fonction memset
}
Ca nous permet de pouvoir écrire des {0} ou ZeroMemory par exemple et de ne pas changer nos habitudes
Mais cette solution a un gros onconvénient: elle est incompatible avec l'option /GL de compilo (optimisation globale du programme). On est alors obligé de la désactiver, et du coup /LTCG aussi
Finalement cette solution ne vaut pas le coup, mais je voulais juste vous signaler l'existence de ce pragma
13 août 2006 à 21:36
Faisons que octet est dans AL et on met 'groupe' dans EAX:
mov ah, al
mov dx, ax
shl eax, 16
mov ax, dx
J'avais oublié un shl avec les 3 mov.
Comme d'hab, ne croyons rien et comparons, regarde ton listing asm et on sera certain de ce qui est préférable.
13 août 2006 à 21:18
13 août 2006 à 21:11
Par contre faudra remplacer les multiplications, tu peux obtenir 'groupe' en 3 MOV.
13 août 2006 à 20:49
13 août 2006 à 20:39
void FillMem(void *destination, DWORD longueur,BYTE octet)
{
// Obtenir un pointeur sur DWORD:
DWORD* destination32=(DWORD*)destination;
// Calculer la taille en DWORDs:
DWORD taille32=longueur/4;
// Former un DWORD dont chaque octet contient la valeur de notre octet:
DWORD groupe=(octet*0x1000000 | octet*0x10000 | octet*0x100 | octet);
// Si la longueur est inférieure à 4 on met juste les octets qu'il faut:
switch (longueur-(taille32*2)) // astuce:
{
case 3: ((BYTE*)destination)[longueur-3] = octet;
case 2: ((BYTE*)destination)[longueur-2] = octet;
case 1: ((BYTE*)destination)[longueur-1] = octet;
}
// Remplir par notre DWORD tant que la taille est supérieure à 0:
while( taille32-- > 0 ) *(destination32++) = groupe;
}
Elle ne doit pas être aussi rapide que celle de Brunews, mais elle fonctionne très bien. Je la soumets à vos remarques.
13 août 2006 à 20:33
Moi aussi j'ai remarqué ce petit problème. Le pire c'est que, dans le même code, certains appels à ma fonction se font normalement alors que d'autres sont remplacés par _memeset. J'ai résolu le problème en ajoutant /Ob1 aux options du compilateur. Je comprends pas trop mais ça marche.
13 août 2006 à 20:00
Je vais faire 2 versions de chaque (enfin j'y réfléchis), aligné et non aligné.
13 août 2006 à 19:55
Essaie la compil "profil guided optimization" et vérifie le listing asm à chaque étape, il déplace des bouts de code et réécrit si besoin pour gagner qlqs cycles, un truc de fou.
Me semble que G. Vollant a mis des trucs là dessus sur son site.
13 août 2006 à 19:52
PUBLIC _MemSet
EXTRN _memset:PROC
; Function compile flags: /Ogtpy
; COMDAT _MemSet
_TEXT SEGMENT
_dst$ 8 ; size 4
_byte$ 12 ; size 4
_size$ 16 ; size 4
_MemSet PROC ; COMDAT
; 40 : char* end = (char*)dst + size, *p;
mov ecx, DWORD PTR _dst$[esp-4]
mov eax, DWORD PTR _size$[esp-4]
add eax, ecx
; 41 : for(p = (char*)dst; p != end; *p++ = byte);
cmp ecx, eax
je SHORT $LN3@MemSet
sub eax, ecx
mov DWORD PTR _size$[esp-4], eax
mov DWORD PTR _dst$[esp-4], ecx
jmp _memset
$LN3@MemSet:
; 42 : }
ret 0
_MemSet ENDP
_TEXT ENDS
Je ne pense pas que ce soit un pb de signature (même pb en inversant l'ordre des params)
Sinon t'aurais pas une bonne memset perso sous la main?
13 août 2006 à 19:40
13 août 2006 à 19:03
J'avais résolu en mettant du code asm en remplacement.
13 août 2006 à 18:53
J'ai cette fonction, pour remplacer memset
void MemSet(void* dst, int byte, int size)
{
char* end = (char*)dst + size, *p;
for(p = (char*)dst; p != end; *p++ = byte);
}
Si je mets les deux lignes en commentaire, rien
Si je laisse ces deux lignes: symbole externe non résolu _memset référencé dans la fonction _MemSet
Je n'ai pas de ZeroMemory ou autre choses du genre ailleurs dans mon code
Je trouve que le compilo prend vraiment trop libertés!
13 août 2006 à 14:54
13 août 2006 à 14:48
@bnzeromem@8 PROC ; COMDAT
; _pmem$ = eax
; 20 : BYTE *p = (BYTE*) pmem;
; 21 : DWORD r = len;
; 22 : if(!(len >>= 3)) goto prepm1SET;
mov ecx, 6
xor edx, edx
$mem8SET$77844:
; 23 : mem8SET:
; 24 : *((DWORD*) p) = 0;
mov DWORD PTR [eax], edx
; 25 : *((DWORD*) (p + 4)) = 0;
mov DWORD PTR [eax+4], edx
; 26 : p += 8;
add eax, 8
; 27 : if(--len) goto mem8SET;
sub ecx, 1
jne SHORT $mem8SET$77844
$prepm1SET$77843:
$zeromemEXIT$77849:
; 28 : prepm1SET:
; 29 : if(!(r &= 7)) goto zeromemEXIT;
; 30 : mem1SET:
; 31 : *p++ = 0;
; 32 : if(--r) goto mem1SET;
; 33 : zeromemEXIT: return;
; 34 : }
ret 0
@bnzeromem@8 ENDP
Encore bien optimisé puisqu'il met direct un mov ecx, 6 et enlève toute la deuxième partie de l'algo.
13 août 2006 à 14:44
13 août 2006 à 14:36
Mais ta fonction bnzeromem est fausse, car en l'occurence avec une zone de 48 octets elle va boucler:
len >>= 3 donne 6, ensuite len -= 8 ne vaudra jamais 0
13 août 2006 à 00:40
Je remets le proj ici:
http://bnmvp.free.fr/nocrt.zip
ça permettra de vérifier les options de compilo et linker.
13 août 2006 à 00:32
void __fastcall bnzeromem(void *pmem, DWORD len)
{
BYTE *p = (BYTE*) pmem;
DWORD r = len;
if(!(len >>= 3)) goto prepm1SET;
mem8SET:
*((DWORD*) p) = 0;
*((DWORD*) (p + 4)) = 0;
p += 8;
if(len -= 8) goto mem8SET;
prepm1SET:
if(!(r &= 7)) goto zeromemEXIT;
mem1SET:
*p++ = 0;
if(--r) goto mem1SET;
zeromemEXIT: return;
}
#pragma comment(linker, "/entry:myWinMain")
void WINAPI myWinMain(void)
{
//WNDCLASSEX wc={0};
WNDCLASSEX wc;
//memset(&wc, 0, sizeof(WNDCLASSEX));
//RtlZeroMemory(&wc, sizeof(WNDCLASSEX));
//bnzeromem(&wc, sizeof(WNDCLASSEX));
bnzeromem(&wc, GetTickCount());
RegisterClassEx(&wc);
ExitProcess(0);
}
Ce que je pense être le mieux si on ne veut pas de CRT et surtout ne pas sacrifier la vitesse (tout de même le + important).
WNDCLASSEX wc={0}; comme vu + haut, provoque un appel memset, exclus puisque non inline.
RtlZeroMemory(&wc, sizeof(WNDCLASSEX)); compilo remplace par memset, idem exclus.
bnzeromem(&wc, sizeof(WNDCLASSEX)); incroyable, le compilo a mis 2 affectations de 4 octets et fini, mystère complet. Espérons que ne se produira pas dans un vrai prog complet, à vérifier.
Voila tout ce qu'il en reste, histoire de fou:
@bnzeromem@8 PROC
; _pmem$ = eax
$mem8SET$77844:
mov DWORD PTR [eax], 0
mov DWORD PTR [eax+4], 0
$prepm1SET$77843:
$zeromemEXIT$77849:
ret 0
@bnzeromem@8 ENDP
En forçant une valeur "aléatoire" (GetTickCount), alors là NICKEL !!!
Passage correct en registres, tout se fait dans les 3 registres généraux donc pas de 'push pop', pas 1 cycle de perdu, parfait.
@bnzeromem@8 PROC
; _pmem$ = eax
; _len$ = ecx
; 20 : BYTE *p = (BYTE*) pmem;
; 21 : DWORD r = len;
mov edx, ecx
; 22 : if(!(len >>= 3)) goto prepm1SET;
shr ecx, 3
je SHORT $prepm1SET$77843
npad 9
$mem8SET$77844:
mov DWORD PTR [eax], 0
mov DWORD PTR [eax+4], 0
add eax, 8
sub ecx, 8
jne SHORT $mem8SET$77844
$prepm1SET$77843:
; 29 : if(!(r &= 7)) goto zeromemEXIT;
and edx, 7
je SHORT $zeromemEXIT$77849
npad 6
$mem1SET$77850:
; 30 : mem1SET:
mov BYTE PTR [eax], 0
add eax, 1
; 32 : if(--r) goto mem1SET;
sub edx, 1
jne SHORT $mem1SET$77850
$zeromemEXIT$77849:
ret 0
@bnzeromem@8 ENDP
Qu'il est bien ce compilo quand il ne nout fait pas des trucs à l'insu de notre plein gré...
12 août 2006 à 20:16
Bon appétit
12 août 2006 à 20:10
12 août 2006 à 20:07
12 août 2006 à 19:43
mov ecx, 44
memZERO:
mov dword ptr[eax], 0
add eax, 4
sub ecx, 4
jnz short memZERO
Changerait quoi qu'on mette 40 ou plus dans ECX ???
Même pas de problème d'alignement puisque le compilo aura par force placé correctement une struct, donc aucun besoin de code de controle préalable.
Ce code pourrait se mettre fort bien direct inline en place d'un appel de fonction.
Un compilo reste un compilo, rassurant pour le codeur manuel...
12 août 2006 à 18:43
Certes le fichier police est utile, mais un autre de moindre taille sera aussi utile puisque cette police ne sert qu'à démontrer le fonctionnement d'une fonction. Ce serait préférable de choisir un fichier plus petit. Ainsi on gagnera en taille de l'exécutable et en occupation mémoire. C'est mon point de vue.
12 août 2006 à 18:02
Je veux bien voir ton projet
12 août 2006 à 17:59
J'ai donné le code pour répondre à ta question sur comment je sais que c'est que c'est _memset qui manque. Avec ce code, le linker affiche:
error LNK2001: unresolved external symbol _memset
Si ça t'interesse, je peux t'envoyer le petit projet complet. Avec cette méthode, on est sûr qu'aucune fonction de la CRT n'est ajouté à notre exe.
A propos des 100ko, puisque tu cherches à diminuer la taille de l'exe en mettant ton point d'entrée, pourquoi ne pas choisir une police plus petite et gagner encore des dizaines de ko?
12 août 2006 à 17:36
Pour ton petit code, j'ai pas compris ce que tu voulais montrer avec
12 août 2006 à 17:31
Pourquoi ne pas choisir une police d'une dizaine de Ko?
12 août 2006 à 17:27
12 août 2006 à 17:23
- Pour les tailles inférieures ou égales à 40 octets -> ={0}
- Pour les autres, fournir une fonction perso.
Tu as testé mon petit code? Tu as vu les fonctions manquantes affichées en clair?
12 août 2006 à 17:06
12 août 2006 à 17:01
int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrev, LPSTR cmd,int show)
{
WNDCLASSEX wc={0};
RegisterClassEx(&wc);
return 0;
}
int WINAPI WinMainCRTStartup(void)
{
int retour;
retour = WinMain( GetModuleHandle(0),0,0,1 );
return retour;
}
12 août 2006 à 16:55
12 août 2006 à 16:47
Chez moi le warning apparait avec RegisterClassEx(), seule ou avec memset().
A propos de RegisterClassEx(), je suis tout à fait d'accord. Si elle appelle _memset(), ça doit être en dehors de notre prog.
Personnellement, quand je veux que mon exe soit le plus petit possibe, je mets le code en C, je mets l'option /NODEFAULTLIB pour le linker et /GS- pour le compilateur. Je fouris dans le code la fonction d'entrée WinMainCRTStartup(). Un jour, en étant sûr que mon code ne fait aucun appel à la CRT, je me retrouve devant des erreurs indiquant les fonctions de la CRT manquantes. J'ai alors mis en commentaire tout le code sauf la WinMain(). Et là je découvre qu'avec RegisterClassEx() le linker demande _memset(). En la remplaçant par RegisterClass(), l'erreur diparait et l'exe est généré.
Dans le post suivant, je mettrai un petit exemple de code à tester.
12 août 2006 à 12:12
Je crois qu'il faut donc employer la méthode de BruNews: une fonction perso
12 août 2006 à 12:02
12 août 2006 à 11:57
Parce que WNDCLASSEX est plus grande et doit donc dépasser la limite pour être inlinée
12 août 2006 à 11:41
RegisterClassEx -> pas de warning
memset et RegisterClassEx -> warning
memset et RegisterClass -> pas de warning
Je regarderait les sorties asm pour voir
12 août 2006 à 11:29
De toutes facons je comprends pas: le code de RegisterClassEx est situé dans user32.dll, et donc même si cette api utilise la CRT, ce devrait être indépendant de notre programme, non?
12 août 2006 à 00:51
12 août 2006 à 00:36
vecchio56 >> Je viens de compiler ton projet tel quel sans rien changer. Au linkage j'ai deux warnings du genre:
warning LNK4210: .CRT section exists; there may be unhandled static initializers or terminators
Ca prouve bien qu'il y'a de la dépendance à la CRT. Pourtant, Depends n'affiche aucune dépendance. En remplaçant WNDCLASSEX par WNDCLASS et RegisterClassEx() par RegisterClass() les warnings disparaissent et la taille de l'exe descend à 100ko. Ca veut dire que RegisterClassEx() provoque implicitement l'ajout du code de _memeset à l'exéutable. C'est vrai qu'on se demande pouquoi cette API appellerait _memset().
11 août 2006 à 23:49
brunews >> C'est justement à cause de cette msvcrt80.dll que j'ai découvert tout cela. Cette dll n'est pas présente sur tous les ordinateurs et cela nous oblige à la lier statiquement dans le programme. Même en virant toute référence à la CRT, mes programmes en dépendent toujours à cause de certaines APIs. RegisterClassEx() n'est pas la seule car j'ai remarqué le même comportement avec d'autres. J'ai l'intention de les répertorier et essayer de faire un tutorial à ce sujet.
11 août 2006 à 23:21
S'il y a de l'alea dans le binaire maintenant, tout est perdu...
11 août 2006 à 23:17
11 août 2006 à 23:16
WNDCLASSEX wcex={0}; va sans doute générer un fichier plus gros, il signifie en fait WNDCLASSEX wcex={0, 0, 0, ..., 0}; (cela dit ta solution diminue la taille du fichier source)
RegisterClassEx est une fonction, donc son appel est traduit par un call, rien de plus
Heureusement d'ailleurs, pourquoi ferait-elle un memset? Elle pourrait plus lire les infos dans la structure
11 août 2006 à 23:15
Faut dire que c'était la 1ere fois que je notais cela et l'exe de vecchio non plus n'a pas de dépendance.
Je note pourtant le
call _memset
dans l'asm produit par le compilo.
Mystique tout cela, sera à approfondir.
11 août 2006 à 23:03
- Charger la ressource avec LoadResource().
- Appeler AddFontMemResourceEx()
- Libérer la ressouce avec FreeResource().
- Créer la police.
D'après mes tests, RemoveFontMemResourceEx() ne doit être appelée que si on n'aura plus besoin de notre police. Elle fera donc suite à DeleteObject(hPolice)
Puisque tu cherchais à diminuer la taille de l'exe, pourquoi ne pas virer memset()?
WNDCLASSEX wcex={0}; serait suffisant.
Il est à noter que l'API RegisterClassEx() fait implicitement appel à memset() et fait donc augmenter la taille de l'exe. RegisterClass() quant à elle ne fait pas d'appel à la CRT. J'ai découvert tout ça dernièrement. Tu peux faire des tests pour en avoir le coeur net.
11 août 2006 à 22:34
Pour l'option: si, elle diminue la taille de l'exécutable ici (103Ko au lieu de 134Ko avec WinMain)
11 août 2006 à 22:25
Merci vecchio56 pour ce code. Je viens de me servir de la fonction AddFontMemResourceEx() dans mon dernier code source déposé il y'a un instant. Cette fonction m'a servi à ajouter une police au système à partir d'une ressource en mémoire. Je viens de remarquer qu'une fois la police ajoutée, la ressource peut être libérée sans problème. Donc un appel de FreeResource() juste après AddFontMemResourceEx() serait préférable.
A propos du #pragma comment(linker, "/entry:myWinMain"), je ne crois pas qu'il soit d'une grande utilité dans ton code. Car même si le point d'entrée du programme évite l'utilisation de la CRT, cette dernière sera de toute façon utilisée dans ton programme. memset() par exemple. Et la taille de l'exe ne sera pas réduite.
Y'a-t-il une autre raison de l'utilisation de cette option du linker?
Merci.
4 août 2006 à 17:02
3 août 2006 à 10:35
3 août 2006 à 08:29
ca compile mais en remplacant :
#ifdef _DEBUG
int main()
#else
#pragma comment(linker, "/entry:myWinMain")
int __stdcall myWinMain()
#endif
par :
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow)
et
#ifdef _DEBUG
return (int)msg.wParam;
#else
ExitProcess(msg.wParam);
#endif
par :
return msg.wParam;
sinon, j'ai une erreur :
[Linker error] undefined reference to `WinMain@16'
ld returned 1 exit status
quelqu'un peut m'expliquer ?
merci
3 août 2006 à 03:00
3 août 2006 à 01:30
3 août 2006 à 01:27
3 août 2006 à 01:25
La source compile sans probleme et fonctionne parfaitement.
Encore une fois merci ;-)