citation:
Sinon saurais-tu passer du code 16 bits au 32 bits.
fin de citation

L'expérience && été tenté par plus d'une personne,la conclusion est toujours la même,il vaut mieux réécrire tout.
Pourquoi ?.L'évolution du système entre le 16 bits et le 32 est tel que l'on perd son temps a essayé de raprocher les deux.

L'info manquante existe en masm sous forme d'un fichier systeme modele ,modifiable facilement.
Celui ci se trouve dans mon ide (Modeles standards) et peut etre içi parmi mes sources.
En nasm,il faut chercher.
sinon http://neitsabes.free.fr/ASM/KMD/KMDindex.htm

citation:
Je te remercie de la recherche que tu a fait. Mais je n'utilise pas(et je ne veux pas!)utilisé des fonctions déjà toute faite. Ex:l'api Windows setpixel() ou getpixel().
Findecitation:
Désolé alors , mais le système a bien évolué depuis le 8086 et il faut passer par un fichier système devant lui même répondre aux besoins des api pour obtenir un resultat utilisable avec les systèmes et machines actuels.
Il n'y a pas d'autre choix.

La remarque sur le 32 bits me parait Ô combien judicieuse.
Après 30 s de recherche parmi les Api comportant pixel dans leur nom,j'ai trouvé:
(GetPixel et SetPixel répondent à la question)
BitBlt
CreateBitmap
CreateBitmapIndirect
CreateCompatibleBitmap
CreateDIBitmap
CreateDIBSection
CreateDiscardableBitmap
ExtFloodFill
FloodFill
GetBitmapBits
GetBitmapDimensionEx
GetDIBColorTable
GetDIBits
GetPixel
GetStretchBltMode
LoadBitmap
MaskBlt
PatBlt
PlgBlt
SetBitmapBits
SetBitmapDimensionEx
SetDIBColorTable
SetDIBits
SetDIBitsToDevice
SetPixel
SetPixelV
SetStretchBltMode
StretchBlt
StretchDIBits

Juste un mot pour signaler un problème stupide avec DdeGetData
La fonction ne renvoie ps de données terminées par zero.et il faut:

;---------------- client -----------------------------------------
invoke DdeCreateStringHandle,HddeInst,addr Stock,CP_WINANSI
mov hszItem,eax
invoke lnstr,addr Stock
mov edx,eax ;TIMEOUT_ASYNC
invoke DdeClientTransaction,addr Stock,edx,Hconversation,hszItem,CF_TEXT,XTYP_POKE,\
TIMEOUT_ASYNC,addr idTransaction
;retourne un handle de data a détruire par DdeFreeDataHandle
;----------------------- Serveur ---------------------------------------
invoke DdeGetData,hdata,addr ReceptData,sizeof ReceptData,0 ;transfert données
mov retour,eax ;preserve la réponse
invoke DdeGetLastError,HddeInst
.if eax == DMLERR_NO_ERROR
lea edx,ReceptData
add edx,retour
mov byte ptr [edx],0 ;<<<<<<<<<<<<<<<<<<<<<<<<
jmp @F

;-----------------------------------------------------------
Eternel discours entre le pseudo ASM qui finira toujours moins efficace que du bon C et le vrai ASM dont le seul but devrait être l'optimisation maximale.
;----------- fin de citation -------------------------------
Si quelqu'un me montre qu'en utilisant la close uses on perd ne serais ce qu'une µs par rapport a une inscription manuelle,là CHAPEAU.

citation:
Mouais ... à quoi bon faire de l'asm si on ne fait qu'utiliser les macros !
--------- fin de citation ------------------------------
L'utilistion de la macro uses est beaucoup plus clair qu'un push/ pop.
Elle garantit:l'équilibre de la pile
              est visible instantanément dans l'entête du proc
              ++++++++
Utiliser les macros c'est permettre à l'assemleur de régler la foule de petits détails permettant un bon fonctionnemt du proc et rendant le code plus lisible.
Ce n'est pas parce qu'on fait de l'asembleur qu'il faut se passer des solutions automatiques.

Il faudrait aussi dire quel est le compilateur C utilisé:
avec c++ express
extern  int _stdcall CreerMiniWin(void);
.
.
CreerMiniWin();
.

Le truc tout simple,c'est:
Créer un fichier objet en asm normal:
et .... faire un appel stdcall depuis le c ou c++

L'inverse marche aussi.
PROTO C               ;a déclarer dans l'assembleur
PROTO SYSCALL         ;noms décorés ??@monprog@?

La démo est effectivement impressionnante.