fasm и символьные переменные в инклюдах

Вчера задумался и понял, что надоело в инклюдах видеть:
db dd dq, rb и т.д.
Так или иначе берутся со студии хидеры и перерабатываются. Смотрится размер того же HANDLE или TCHAR и потом проставляются dd db dw и т.д.
Кто-то пробывал от этого уходить, в сторону символьных переменных ? Если да, то коим образом ? Да и вообще хотелось бы слышать Ваше мнение относительно того, целесообразно это или нет

 

Код (Text):

1. macro HANDLE var {var dd ?}

Так что ли?

 

Кто - то поделиться набором структур для fasm\nasm ddk/Win32 Api ?

 

Можно также через директиву EQU.
Создаём файл WinApiTypes.Inc:

Код (Text):

1. if TCHAR_SIZE=1
2.     TCHARS  equ rb
3. endif
4.  
5. if TCHAR_SIZE=2
6.     TCHARS  equ rw
7. endif
8.  
9. OBJREF  equ dd
10. HBITMAP equ dd
11. PTCHAR  equ dd
12.  
13. ; ... and so on ...

И далее пользуем ():

Код (Text):

1. ;
2. ; Comment out one of these
3. ;
4. TCHAR_SIZE=2  ; UNICODE
5. TCHAR_SIZE=1  ; ANSI
6.  
7. include 'WinApiTypes.Inc'
8.  
9. ...
10.  
11. virtual at 0
12. TApplication:
13.     .Path   TCHARS      MAX_PATH
14.     .Bitmap HBITMAP     ?
15.     .Object OBJREF      ?
16.     .size = $
17. end virtual

 

Вообще, по-моему, правильнее в fasm определять свои типы с помощью struc:

Код (Text):

1. struc HANDLE [value] {
2. common
3.         . dd value
4. }
5. ...
6. hWnd HANDLE ?
7. hWndArray HANDLE 10 dup (?)

 

Зачем умножать сущностей? HANDLE, (как и многие другие) и есть двойное слово. FASM тем и хорош, что называет вещи собственными именами. Это делает программа лучше и понятнее.
А если реальность так надоела, всегда можно переходить на C.

 

Сущий TypeCast - мое большое разочарование.

 

Сущий или не сущий, а переработка хидеров - отдельная тематика в асм кодинге, согласись.