Sorry E^cube I split this out of the headers thread to deal with it more exclusively - Donkey
Great! And I have some questions, that's GoASM related, not your headers related
1) you said you had to specify short and long jumps, what does that mean exactly?
2) I see you use offset a lot in sources, is addr not supported?
3) In a few GoASM sources, if i'm not mistaken I saw individuals use PROC, is that inferior to FRAME?
4)
mov edx,[esi]
and edx,0FFFFh
CInvoke(wsprintf,offset szOrdinal,"Ordinal %u",edx)
how come you used your macro vs regular invoke?
Also I just checked out your WinExplorer project,very nice :)
1. Jmp short is jmp >label, jmp long is jmp >>label. GoAsm does not automatically calculate the type of jump needed though it will throw an error if the target of a short jump is outside of the allowable range.
2. ADDR and OFFSET are interchangeable in GoAsm. both keywords are available but do the exact same thing. LOCALs can be mov'ed using offset, btw GoAsm does not use the famous lea eax to push the offset of a local, it is calculated using the stack pointer.
3. PROC is not available to GoAsm and will throw an error. To build a stack frame you have only FRAME. Though unlike MASM there are other ways as well, see USEDATA in the GoAsm manual. Because scoping is so much better in GoAsm it provides for some pretty interesting stuff, you can even have constants local to a procedure with LOCALEQU, or release LOCAL data inside a procedure and redefine it with LOCALFREE. Finally, since there is no type checking in GoAsm there is no need for PROTOs. BTW, with USEDATA you can write a procedure and use the LOCALs and arguments from a different procedure, it inherits the stack frame of the other procedure, very cool.
4. Invoke in GoAsm is only for STDCALL in Win32 and FASTCALL in Win64, to have the stack automatically balanced after a call to a C calling convention function I wrote that macro. Personally I just use ADD ESP,xxx, it's clearer for me.
Yes, WinExplorer was a lot of fun to write and demonstrates some useful techniques, which was its original goal. Pretty much on the back burner now though, but I do constantly farm it for code.
Wow thanks for all that, i'm suprised wsprintf uses cdecl though which msdn confirms, I assumed all win api used stdcall :\. This kind of makes things tricky now as MASM user32.inc automatically has wsprintf defined as wsprintfA PROTO C and it allows you to call with invoke happily. GoASM only supports stdcall so this poses the problem of having to check each and every windows api for cdecl calling...ugh.
Hi E^cube,
Pretty much only ws___ calls and anything from the C runtime library are cdecl. There are very few, generally if you don't use the CRTL you can assume that the only CDECL call you make in your source is wsprintf. I have a list somewhere but can't seem to find it, it would be easy to generate one from the MASM protos.
alright great, I may just mod 32bitto64 code I wrote to list all of masms proto C defs to be sure. GoASM won't throw a error or anything will it if you try and call a cdecl function?
Quote from: E^cube on March 30, 2009, 06:09:46 AM
alright great, I may just mod 32bitto64 code I wrote to list all of masms proto C defs to be sure. GoASM won't throw a error or anything will it if you try and call a cdecl function?
No, invoke doesn't care what the functions calling convention is, it just pushes (in Win32) the parameters onto the stack and executes a CALL instruction.
Jeremy can you please keep up to date, or add additional links to your latest assembler+linke versions on your site, or atleast on here, so all can benefit not just select few? it took me forever to find your latest link in order to use donkeys headers, the linker was hidden in some random thread on this forum.
Donkey
C:\GoAsm\Examples\Hello64World2>\GoAsm\bin\GoAsm /x64 Hello64World2.asm
GoAsm.Exe Version 0.56.5d - Copyright Jeremy Gordon 2001/9 - JG@JGnet.co.uk
Warnings ......................
Line 227 of the include file \GoAsm\include\windows.h:-
Could not open file:-
#include windef.h
Line 228 of the include file \GoAsm\include\windows.h:-
Could not open file:-
#include winbase.h
Line 244 of the include file \GoAsm\include\windows.h:-
Must declare a section first -
Use DATA SECTION ["name"], CODE SECTION ["name"] or CONST SECTION ["name"]
Or just DATA, CODE or CONST; .DATA, .CODE or .CONST
any suggestions? I don't want to build all my programs in the include directory with the headers...that's not ideal at all.
after I copied the build.bat and the example.asm to the include directory I got this
C:\GoAsm\Include>\GoAsm\bin\GoAsm /x64 Hello64World2.asm
GoAsm.Exe Version 0.56.5d - Copyright Jeremy Gordon 2001/9 - JG@JGnet.co.uk
Error!
Line 119 of assembler source file (Hello64World2.asm):-
Unresolved material after LEA:-
DQ 0
In the struct at Line 3270 of the include file winuser.h
the Hello64world2 line erroring is
INVOKE RegisterClassA,ADDR WNDCLASS
I used the #DEFINE WIN64 switch before including windows.h which is the only file I included.
Hi E^cube,
Did you set the INCLUDE environment variable ? The windows.h file has a note about it as does the GoAsm manual.
WNDCLASS is a structure name, you must supply a data buffer address in order to use it with ADDR/OFFSET
LOCAL wcx:WNDCLASS
INVOKE RegisterClassA,ADDR wcx
Edgar
no I didn't, i'll take a look, sorry about that, thankyou for the help.
Hi E^cube,
Thinking that this might be a problem declaring the structure locally, I tried this:
TestLocal FRAME
LOCAL wcx:WNDCLASS
INVOKE RegisterClassA,ADDR wcx
mov Q[wcx.hInstance],0 // This member uses a redefined data type
RET
ENDFEverything seems to work perfectly:
QuoteC:\Programming\GoAsm\BIN\GoAsm.EXE /x64 "TestStuff.asm"
GoAsm.Exe Version 0.56.5c - Copyright Jeremy Gordon 2001/9 - JG@JGnet.co.uk
Output file: TestStuff.obj
C:\Programming\GoAsm\BIN\GoLink.EXE /entry Start "TestStuff.obj"

GoLink.Exe Version 0.26.10 beta3- Copyright Jeremy Gordon 2002/9-JG@JGnet.co.uk
Output file: TestStuff.exe
Format: X64 size: 2,048 bytes
Make finished.
Total compile time 235 ms
I been converting some of my 32bit masm code to 64bit in GoASM the last few hours and I must say it's been a real pleasure!
the inline text support for functions
invoke messagebox,0,'neat0',etc..
the direct callin with invoke such as
invoke getprocaddr,rax,'whatever'
invoke rax,etc <---
the prototype less function fram
blah frame param1,param2
ret
endf
is all great! its stuff I wish MASM did by default, the only thing missing is the .IF,.ELSEIF,.ELSE,.ENDIF, I hope Jeremy adds them, so I can start converting my 32bit source full on!
also donkey invoke wsprintfA works fine directly, no need for a special macro.
also whats the switch in windows.h that I can set the global path like all includes in
\GoASM\Includes\
can GoASM produce 64bit static link libraries?
Quotealso donkey invoke wsprintfA works fine directly, no need for a special macro.
I should have mentioned that the macro is for 32 bit only, wsprintf uses FASTCALL in WIN64. I did not restrict it to 32 bit mode because there is a chance that you might want to write a CDECL function for yourself and use it, I have a couple of functions that are CDECL that I may eventually convert to WIN64 without bothering to convert to FASTCALL.
Hi E^cube,
Wait til you see the real power of GoAsm invoke, no more GetProcAddress except for delay loads...
// call the "Whatever" function in SomeDll.dll
invoke SomeDll.dll:Whatever, param1, param2
// include the "Whatever" function from a static lib and call it
invoke SomeLib.lib:Whatever, param1, param2
// Call ordinal 2 in a DLL
invoke SomeDll.dll:2 , param1, param2
GoAsm invoke is much more powerful than you are used to as a MASM user.
Using #dynamiclinkfile you can skip the SomeDll.dll for named functions (without conflicts):
#dynamiclinkfile SomeDll.dll
invoke Whatever, param1, param2
And you can even use RichEdit without LoadLibrary since exported data is also accessible:
#dynamiclinkfile RichEd20.dll
// Touch the DLL to force it to be mapped
mov eax,[IID_ITextHost2] // IID exported by RichEd20.dll
GoAsm can produce OBJ files that can be used by MS lib.exe or PoLib.exe to create a static library however there is no lib compiler in GoTools.
wow thanks donkey, I must admit when I first seen your library a long time ago with the strings, files etc I got raged and thought to myself "why the hell is coding in this Goasm stuff" as I had to convert to Masm. But more I learn about GoAsm, the more i'm convinced that it's very close to being superior.The .if stuff is the only thing holding it back, everything else is golden :D With the recent MASM64 release it's clear Microsoft is saying sh*t on the ASM community, so they've lost my support. Also how do I
#include \GoAsm\include\windows.h
make goasm not complain about being unable to find that? I looked for a global switch/path in various .h's, didn't see it. any hints?
GoAsm is written by an assembly language programmer who uses it, MASM is written by a committee of C++ programmers who don't. As is evidenced here, its nice to have the author listen to your concerns and act on them, bugs don't have a long lifespan in GoAsm, it can be years in MASM.
Quote from: E^cube on March 31, 2009, 01:54:43 AM
Also how do I
#include \GoAsm\include\windows.h
make goasm not complain about being unable to find that? I looked for a global switch/path in various .h's, didn't see it. any hints?
I'm not sure what you mean here, there should be no absolute paths in the header project, generally you would simply use
#include windows.h
the include environment variable takes care of the paths. For stuff like GdiPlus there are relative paths to the sub folder but that is the extent of path dependency. In your case the include variable should be:
INCLUDE= C:\GoAsm\include
From there everything should work.
alright great thankyou, I thought you met a special switch in the include
set INCLUDE=C:\GoAsm\include
\GoAsm\bin\GoAsm /x64 /l Prodll.asm
\GoAsm\bin\GoLink Prodll.obj /dll /entry DllEntry user32.dll kernel32.dll
pause
that seems to build my dll from any dir, fantastic!
set INCLUDE=C:\GoAsm\include
\GoAsm\bin\GoAsm /x64 testlib.asm
\GoAsm\bin\polib /MACHINE:AMD64 /OUT:COOL.lib /VERBOSE testlib.obj
pause
works for makin the static lib :)
Hi E^Cube,
If you're using the header files, use the LINKFILES switch and the dll imports are handled automatically, no need to specify the dll's on the command line. In your source (before windows.h)
#DEFINE LINKFILES
Without this a large application can have a pretty unmanageable command line, if you have 20 or so different import DLLs it can be a nightmare.
very nice! I was going to ask about that but I forgot. Once Jeremy adds .if etc.. supports i'm going to make a SDK like masm has for GoASM, with all the latest tools, your includes, lots of nice looking static lib, exe, dll, com explains with invoke etc.. might even translate all of masm32lib's code. You and Jeremy have done great things with this project but most people have no idea how fantastic it is, and theres no up to date SDK anywhere so it's hard to tell people about it without being confusing, download this from there, and that from here. Can't even find the latest stuff on GoASM's site, which is a shame.
Hi E^cube,
The credit is all Jeremy's, he has created the best assembler I have seen and is constantly upgrading it based on the user base's needs and wish list. When I started using GoAsm there was only modest structure support, no libs, no intrinsic Unicode, macro capability was severely limited, in other words none of the features that make it as powerful as it is now. However, even then you could see its potential and I wrote the first RadAsm implementation for it and never looked back. A year or two ago I decided that the MASM32 formula of one giant include file was not the right approach, Microsoft's splitting of headers by functionality is a much better system and I started the header project with the goal of following the documentation at MSDN/PSDK closely. None of the headers would have a chance of working if Jeremy hadn't diligently worked to adapt GoAsm to the needs of the project, expanding functionality where necessary.
Edgar
Well he's done a fantastic job, it's clear he's a gifted programmer, as are you. I was worried with MASM being weak in the 64bit world, JWASM authors abandoning us, my complete dislike of nasm and minimal interest in fasm that Assembly could be dead for me inregards to 64bit. I was getting so desperate I even dusted off a x86 ASM compiler source I have written in visual basic, that has minimum win api support, know full well writing my own assembler would be a daughtening task that I would struggle greatly with. I'm glad Jeremy decided to create GoASM and continues to work on it, if I use in a major commerical project which I may very well, i'll be sure to compensate via donation or what have you.
Hi E^cube,
FYI, I worked on a test tonight of using the type defs from the header project in a real application. I discovered a bug in GoAsm when declaring multiple structures in a LOCAL but that aside I redid Help2 Viewer using header types and it worked perfectly. This type of usage will make transitioning to 64 bit much smoother, you can use the headers data types and when you define WIN64 the sizes of all declarations, both local and global will be adjusted accordingly. The only thing left for you to fix up is registers and a few other minor patches. I am not uploading the version of Help2 Viewer as there is an incomplete module in it but here's a few samples:
idCurrent DWORD32 ?
DoubleClickTimer DWORD32 ?
SysDblClkTime DWORD32 ?
Namespace CHAR MAX_STRINGLEN DUP (?)
szTitle CHAR MAX_STRINGLEN DUP (?)
nNamespaces DWORD32 ?
// This null BSTR is used for calls that require one
pbszNULL PTR ?
// WebBrowser stuff
hWeb HANDLE ?
SingleInstance FRAME pMutexString
uses ebx,edi,esi
LOCAL pid :%PTR
LOCAL hwnd :%HANDLE
LOCAL pCommandLine :%PTR
LOCAL hProcess :%HANDLE
LOCAL pRemoteMem :%PTR
LOCAL cbWritten :%DWORD32
LOCAL pPath :%PTR
LOCAL pAppPath :%PTR
LOCAL pArg1 :%PTR
LOCAL pArg2 :%PTR
Seems to work great, it will be even better when I can declare multiple local structs.
Edgar