how mature is goasm?

[ecube]

I see Donkey fully backing goasm, writting many examples in it, but how mature is the language, honestly? anything masm can do that it can or vis versa? how are the system definitions, like masm wealthy of kernel32, user32, etc etc definitions? I've tried many languages like D that were great but lacked the necessary windows definitions and such so it rendered it useless for myself.

[Mark Jones]

Donkey's headers are an absolute must IMO:

http://www.jorgon.freeserve.co.uk/#headers
http://www.quickersoft.com/donkey/index.html

There are/were two incarnations of Donkey's headers -- an older .inc version, and the newer .h version.

I've used GoASM quite a bit and it does everything I need it to. It has some nice features which simply do not exist in MASM/32 such as native unicode support, inline text capability, 64-bit, etc. However, its macro language is minimal, and no HLL-lilke features are provided (if/then, etc.) This means that WndProcs must be written "long-hand." I guess this is generally preferred; I tried to improvise a switch/case macro for the purpose of simplifying and streamlining the WndProc boiler-plate but the idea was adamantly shot-down by the community.

But in terms of maturity, I think GoASM is very mature. It is rock-solid and robust. If you don't mind learning some new syntax, it is a great tool and very powerful.

[donkey]

I see Donkey fully backing goasm, writting many examples in it, but how mature is the language, honestly? anything masm can do that it can or vis versa? how are the system definitions, like masm wealthy of kernel32, user32, etc etc definitions? I've tried many languages like D that were great but lacked the necessary windows definitions and such so it rendered it useless for myself.

Hi E^cube,

The Windows definitions for GoAsm are much more extensive than Windows.inc for MASM, including the defs for hundreds of COM interfaces, more syntactical parity with the Microsoft definitions (ie try TBBUTTONINFO.cx in MASM) and will soon include most definitions up to and including Vista. The header files are "switchable" in otherwords to change all strings and APIs over to Unicode you have only to use the UNICODE switch, or to use Ordinal values for many common control or shell functions to extend OS compatibility just use CCUSEORDINALS, SHUSEORDINALS, for undocumented APIs use SHVISTAORDINALS or SHUSEUNDOC. Specifying a target OS will filter structure sizes and undocumented API availability (for example WIN9X, WINNT4, WIN2K, WINXP or VISTA). But for most projects the standard set does fine...

Code Select Expand

#DEFINE IDISPATCH_DEFINED
#DEFINE IUNKNOWN_DEFINED

#DEFINE LINKFILES
#DEFINE LINKVCRT
#DEFINE ODBC_STD
#DEFINE NOMCX
#DEFINE NOIME
#DEFINE NOTV
#DEFINE NONETWORK
#DEFINE NOSERVICE
#DEFINE NOCON
#DEFINE NOCARD
#DEFINE NORADASM
#DEFINE NOZLIB
#DEFINE NODONKEY

#include "WINDOWS.H"

// Minimum header version
#IF GOASMHDRVER < 0x013002
GOASM_ECHO This program requires headers version 1.30.02 or greater
GOASM_EXIT
#ENDIF

#include "Commctrl.h"

The current state of the headers is that it is undergoing a complete rewrite to make it switch compatible with 64 bit Windows, automatically adjusting pointer width as well as any structures. The most important feature as far as I am concerned is that there is a direct correlation between the GoAsm headers and the declarations at MSDN, if MSDN says include atlbase.h then in GoAsm you would do exactly that.

I no longer update or support the "older" windows.inc for GoAsm as it was too restrictive and did not allow for expansion as new OS versions are released. So I would suggest that you start out with the header project, it is rare that it is missing a definition that I need and when I find one the header is translated and a new version released.

As for GoAsm itself, some time ago I made the switch, full 64 bit support for GoAsm has been around longer than for MASM, scoping is much more powerful, the syntax is close enough to MASM to make a light learning curve but mostly if you have an issue or would like a feature you don't scratch your head over a work-around, you post it and it gets fixed. It's nice to have direct contact with the author, many features in GoAsm are a result of requests by users, for example structures have been radically expanded since I began using GoAsm and library support didn't even exist when I started using it. Without the limitation of lib files, any function or label in a DLL is directly accessible without supporting files, for example to call a function by ordinal you would do this...

invoke dllname.dll:1, param1, param2

Once you get used to walking without the .IF/.ELSE/.ENDIF crutches you'll find running with GoAsm a pleasure.

Edgar

[ecube]

the .if etc stuff is important for me as it makes pages of code a lot easier to read, and looks better overall. Is it not possible to replicate .if etc in GoASM someway? the 64bit stuff is what I heard about and is my primary interest in GoASM. It's good to know its matured with definitions, will save conversion/manually writing time.Thanks for the rest of the information.

[donkey]

Hi E^cube,

Jeremy has said that if there is enough demand that he would add run time conditionals to GoAsm, to date it has been voted down consistently in favor of concentrating development in other directions. However the package is nearing a point where there are few features left that are outstanding and perhaps he would consider tackling the addition. For myself I find doing it with test/cmp/jxx just as clear as .IF/.ENDIF and it makes for more efficient code, no unnecessary jumps to the end of a condition block etc... For the other high level stuff (.REPEAT etc..) they should always be done without the constructs anyway even in MASM so I can't see a scenario where they would be necessary.

Edgar