How to work with Nagoa+.inc?

[wyvern666]

Well, im trying the Nagoa macros package (maybe it is a good alternative to nasmx). But i think i dont know how to setup it correctly.... kause i cant assemble nothing with it.
I added the Nagoa+.inc file in the NASM\INC directory. Now i try one of the examples:

Code: [Select]

%define ONLY_NASM
%include "\nasm\inc\nagoa+.inc"

section .data

section .text

__start:

call MessageBox , NULL,"info","title",MB_OK
xor eax,eax
ret



    ; --- [ IMPORTS MUST BE THE LAST PART OF PROGRAM ]


LAST_BEGIN

__LIBS_         user32, "user32.dll"

__IMPORT_    user32,MessageBox, "MessageBoxA",0

LAST_END
The cool thing about "%define ONLY_NASM" is that no linking step is needed. But sadly when assembling this example i get:

app.asm:21: warning: (LIB:5) context-local macro expansion fall-through (automatic searching of oute
r contexts) will be deprecated starting in NASM 2.10, please see the NASM Manual for more informatio
n
app.asm:21: warning: (LIB:5) `_z': context-local macro expansion fall-through
app.asm:21: warning: (LIB:6) `_z': context-local macro expansion fall-through
app.asm:21: warning: (LIB:7) `_z': context-local macro expansion fall-through
app.asm:25: error: segment alignment `200h' is not power of two
app.asm:25: error: segment alignment `200h' is not power of two
app.asm:25: error: segment alignment `1000h' is not power of two

I tryed as "obj" and "win32", but the same. Any help?

[Mathi]

Nagoa+.inc is a 10 year old macro package.
NASM itself has undergone lots of changes since nagoa+.inc was released.

There is one main problem with creating the exe with NASM alone.

If MS windows changes the EXE header attributes , or the way it looks in to it. The ONLY_NASM macros should also be updated.
It will be very difficult to make it work in different windows versions.

Except for some reduction in size we don't gain anything else.

ONLY_NASM doesn't work anymore.
There was a discussion in this forum sometime back related to this.

In FASM, creating exe without linker is an inbuilt feature.
I believe FASM itself will undergo changes if EXE header attributes are changed.
(I should mention that FASM can also work along with a linker)

I used nagoa+.inc when i had win98 (ONLY_NASM and HLL constructs like if , else , for, while  etc were cool ).

Now,Honestly, NASMX is more organized and updated macro package.(cross platform , works both in 32/64 bit)

[Frank Kotler]

Well, im trying the Nagoa macros package (maybe it is a good alternative to nasmx).

Well, it's an alternative to NASMX. Whether it's a "good" one or not may be a matter of taste. I'm somewhat more familiar with it. (Wow, it even has my name in it!)

I consider it somewhat obsolete... as you've discovered. There's a bug in the dos stub (I thought I gave 'em a fix for that). I don't think anyone cares if the dos stub works or not, but might as well fix it. The warning about outer-context lookup of macro-local variables is "just a warning" at this point, but it's really going to stop working soon. (geez, that really got triggered!) If it's just "sloppy programming" it may be easy to fix, if it's really needed, maybe trickier. The error on alignment is a real error and will stop it from assembling (as you know) - but probably shouldn't be...

Lemme look at it. No promises, but I may be able to come up with a nagoa+.inc that works...

Later,
Frank

P.S. I see Mathi has posted. ONLY_NASM doesn't work anymore? Okay, but I'm still going to take a quick look at it...

[Frank Kotler]

Mmmm, not so easy! We try not to break existing code with updates to Nasm, but we broke nagoa+.inc good!

As recently as 2.08.01, it assembles okay. Minor complaint about a label with out a colon. Nearby to the bug in the dos stub...

With 2.09.10, errors are as you show. The out-of-context lookup is easily fixed. The alignment error is still there. I think that's a bug in Nasm, or a misfeature. True, those numbers are not a power of two. Just shut up and align it the way I tell ya! Whatever...

No sense in working with intermediate versions of Nasm... what's 2.10rc8 (which is where the 2.10 series with the new preprocessor is at) have to say? As expected, the out of context lookup fails:

Code: [Select]

t1.asm:21: error: (LIB:8) expression syntax error
t1.asm:21: error: (ENDM:5) expression syntax error
t1.asm:21: error: comma expected after operand 1
t1.asm:21: error: comma expected after operand 1
t1.asm:21: error: (ENDM:8) `%endrep': no matching `%rep'
t1.asm:21: error: (ENDM:12) expression syntax error
t1.asm:21: error: parser: instruction expected
t1.asm:21: error: (ENDM:15) `%endrep': no matching `%rep'

Okay, fix the out-of context lookup...

Code: [Select]

nasm: fatal: cannot mix real and virtual attributes in nobits section (.bss)

Interestingly, it doesn't say where this alleged mixing occurs. I haven't found it. I may look more...

I would say, if you wanna use nagoa+.inc, revert to Nasm-2.08.01 (or so) for now. If there's interest in reviving it, we can look at it more - I think it can be fixed, but I'm not sure what's happening right now... As Mathi says, it may not work on modern/future versions of Windows anyway.

Best,
Frank

[wyvern666]

Ok ok, i admit i was naive about the "ONLY_NASM" feature, i didnt take in count compatibility issues in the PE format across different Windows versions. Mi nagoa+.inc file is from ??/03/2005, and i understand this project is not in active development or whatever, so yeah you are rigth that is a bit obsolete xD.

Ovbiusly (or is just mi guess...) there is a bunch of people out there using nagoa set of macros customized or fixed for personal use, i can fix the PE format template as i need, but i cant fix macro coding because i sucks at macros (and the truth is that i really hate the ugly macro syntax, but still think i need to learn it).

However, following Franks advice, nagoa macros works fine with Nasm-2.08.01 (at least by now...) even in Windows 7 x64, just some warning. Something funny is that, the first time, i forgot to assemble with the "-fbin" parameter when trying the ONYL_NASM, instead y used -fwin32 and -fobj... xD.

As Mathi said the generated EXEs are really small (code, data and imports are merged together). Anyway maybe there is no really good reason to use this outdated macros if something like nasmx exists, wich looks a little more "seriuos" (just mi impression).

[Frank Kotler]

I tried to post something last night. About how the purposes of NASMX and nagoa+.inc were slightly different, and how while ONLY_NASM might be an "advantage" or a "limitation", we still ought to be able to do it if we want to...

In short, I've got a version of nagoa+.inc that I think works with Nasm-2.08.01 and Nasm-2.10rc8. 2.09.10 complains about the alignment still - I think it's a bug in Nasm! Since we've gone beyond that, I don't see any point in fixing it. I haven't actually tried to run the executables in Windows, but they appear to be the same. This is a "work in progress" (probably not much progress) if anyone feels like fooling with it...

Best,
Frank

P.S. Oh, oh! Tried again to post, and "413: request too large", and again it wouldn't let me post this message even after I'd killed the attachment! But this time I was smart(?) and saved the text. If anyone's interested, I'll make the file available elsewhere. Try again...

[Mathi]

If anyone's interested, I'll make the file available elsewhere. Try again...

Yes Plz. I can certify for windows 7 - 32 bit. 

Also,

Nasm-2.08.01 and Nasm-2.10rc8. 2.09.10 complains about the alignment still

I am assuming those are warnings.

[Frank Kotler]

Okay:

http://home.myfairpoint.net/fbkotler/nagoa20120202.zip

... and, no, those are real "showstopper" errors with 2.09.10.

Best,
Frank

[Mathi]

Hi Frank,
            ONLY_NASM macros work perfectly with windows 7 32 bit with this include file.
NASM version: 2.10rc8

Hopefully should work in other versions.

Thanks for fixing. 

Regards,
Mathi.

[wyvern666]

Yes Frank, the executables are the same, i checked that with PE editor. Nice job. 

By the way, i was doing some console application, and i always wonder with macros if i can add some special characters to literal strings, this is something i dont know how to do it in NASMX or Nagoa or any other macros.
For example if i have a little print function and y call it with the string as literal parameter (invoke printFunction, "some string")... can i add there in the string the 0Ah (CR) and 0Dh (LF)?? .

[Frank Kotler]

In general, no - you couldn't do "some string 0Ah". Depending on how your PrintFunction is defined, you may be able to do:

Code: [Select]

invoke PrintFunction "some string", 0Ah

However, in a fairly recent feature, if you enclose your string in "back quotes", Nasm will recognise the usual C "escape" characters - "\n", etc.

Code: [Select]

invoke printFunction `some string \r\n`
I haven't experimented with this too much, so I'm not sure exactly where it will work and where it won't, but it may help you...

Best,
Frank

[wyvern666]

Well, thank you frank, but it didnt work. 

[Rob Neff]

Using newlines in conjuction with NASMX is rather simple:

Code: [Select]

[section .data]
    szMyString:      declare(NASMX_TCHAR) NASMX_TEXT('Hello, World!'), 0xA, 0x0

A little explanation of the above may help:

NASMX is designed to support internationalization (I18N) across both Windows and Linux.  That is the reason for the the use of the NASMX macros.  Depending on whether you've defined UNICODE prior to assembly determines whether or not you'll be using bytes, words, or dwords for storage ( highly platform dependent ).  By always setting up your strings using these macros you will ensure that your code can be easily portable for users with locales quite different than your own.

The newline char (0xA) is simply another character in the array allocated at the correct storage requirement when using declare(NASMX_TCHAR).  You will see that, once you become more familiar with NASMX, it is doing quite a lot for you.  You'll notice that the macro architecture is somewhat similar to Microsoft's C and Masm in order to make the transition easier for Windows developers moving to Linux.

[wyvern666]

Yes i know how to declare it, but can you use it with invoke?

[Frank Kotler]

Good question. Will...

Code: [Select]

invoke anyfunction, "any string"
work? Depends on how "invoke" is written. If it uses "%ifstr" to detect a literal string (jumps over it or moves it to another section), then it should. But "invoke" will see:

Code: [Select]

invoke anyfunction, "any string", 13, 10
as three separate parameters, not one! Enclosing it in curley brackets should fix this(?).

Code: [Select]

invoke anyfunction, {"any string", 13, 10}

I'm not sure if "%ifstr" will see the "back quotes" as a string or not - it just checks for quotes, I think. I'll have to experiment. You can, too! Let us know...

Best,
Frank