News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

Sifting through emails

Started by donkey, July 25, 2009, 07:57:11 AM

Previous topic - Next topic

donkey

I have been going through my programming related emails tonight and answering a few or just redirecting the author to this forum. One misconception that seems prevalent is that the header project is "part of" GoAsm. Although it is designed for exclusive use with GoAsm, as it states in windows.h it is *not* a member of GoTools and so any errors or omissions in the headers should not be considered a failing in GoAsm. The most common misconceptions:


  • The %local data types are specific to my headers, they were implemented to deal with a problem with using header defined data types as local data
  • GoAsm does not natively support Windows data types (ie HANDLE, WPARAM etc...)
  • Neither the header project nor GoAsm encourage the use of undocumented API functions. they were included in the header files for convenience, use them at your own risk.
  • GoAsm is a 32/64 bit assembler however the structure and data type switching is handled by conditional compilation in the header files.
  • Unicode strings are natively supported by GoAsm and the header project does not (and cannot) do the conversions
  • The example files linked on this board rarely use the header project, for a good set of examples using them check out E^cubes SDK
  • I am not paid to translate the headers nor do I charge any fees for them so being abusive or deriding about some obscure missing header isn't going to motivate me. If you're not satisfied ask for your money back  ::)
Edgar
"Ahhh, what an awful dream. Ones and zeroes everywhere...[shudder] and I thought I saw a two." -- Bender
"It was just a dream, Bender. There's no such thing as two". -- Fry
-- Futurama

Donkey's Stable

ecube

Interesting, on a side note what happened to  this idea http://www.masm32.com/board/index.php?topic=11130.msg82258#msg82258 while I was translating my old masm32 code to GoASM 32bit/64bit I was thinking how nice it would be not to have to copy the same code twice for 64bit just to accommodate a few minor changes. It'd be neat if using your headers we could do what you suggested and have variables that auto changed depending on if is was 32bit or 64bit. Aswell as have something that can handle eax,rax interchangeably, macro or what have you.


donkey

Hi E^cube,

For some time the headers have supported % as the prefix for local types. For example:

LOCAL data :%DWORD32
LOCAL data2:%HANDLE

I have been using them in my programming and they work well (see the Help2 viewer source on my website). For RAX/EAX when using the X86 command line switch RAX is translated to EAX by GoAsm so if you are using something like:

LOCAL hMouse:%HANDLE

mov [hMouse], RAX

It will work in both 32 and 64 bit software correctly, replacing RAX with EAX in X86 and using either a QWORD or DWORD for hMouse depending on the WIN64 switch.

Edgar
"Ahhh, what an awful dream. Ones and zeroes everywhere...[shudder] and I thought I saw a two." -- Bender
"It was just a dream, Bender. There's no such thing as two". -- Fry
-- Futurama

Donkey's Stable

donkey

New one:

  • No, I don't plan on translating the headers to be MASM compatible
"Ahhh, what an awful dream. Ones and zeroes everywhere...[shudder] and I thought I saw a two." -- Bender
"It was just a dream, Bender. There's no such thing as two". -- Fry
-- Futurama

Donkey's Stable

dedndave

lol - you tell em, Edgar
as if you haven't done enough already

wjr

I see that the % prefix usage for LOCALs is based on header defined types and the WIN64 switch.

Without those requirements, I just thought that I would point out another way for GoAsm 32/64-bit switchable LOCAL D/Q data - don't specify the type:


Try FRAME
LOCAL hMouse
;
;
mov [hMouse],rax
ret
ENDF


With the command line switch /x64, hMouse defaults to a QWORD, and with /x86, hMouse defaults to a DWORD.