Macro Question

[NoCforMe]

The way the macro is written, @Row must be a DWORD and @Col must be a WORD, otherwise you'll get assembler errors

If you had downloaded the source of reply #10 and had a look at it, you would know that this is not true.

1. Contrary to what you may believe, your attachments are not necessarily endlessly fascinating to us, so no, I didn't download that attachment. Does that make you terribly sad?

2. The way the macro is written--at least as you posted it above:

Code Select Expand

@PutText MACRO @Col, @Row, @Attr, @Msg, @Len    ; Msg's and Len's could be
  mov eax, @Row
  shl eax, 16
  mov ax, @Col
@Row MUST be a DWORD and @Col MUST be a word, otherwise you will get assembler errors. How can you refute that?

[jj2007]

so no, I didn't download that attachment. Does that make you terribly sad?

I couldn't care less, but your posts are somewhat ridiculous if you refuse to read what others have written.

[sinsi]

The way the macro is written, @Row must be a DWORD and @Col must be a WORD, otherwise you'll get assembler errors

If you had downloaded the source of reply #10 and had a look at it, you would know that this is not true.

1. Contrary to what you may believe, your attachments are not necessarily endlessly fascinating to us, so no, I didn't download that attachment. Does that make you terribly sad?

2. The way the macro is written--at least as you posted it above:

Code Select Expand

@PutText MACRO @Col, @Row, @Attr, @Msg, @Len    ; Msg's and Len's could be
  mov eax, @Row
  shl eax, 16
  mov ax, @Col
@Row MUST be a DWORD and @Col MUST be a word, otherwise you will get assembler errors. How can you refute that?

Code Select Expand

    mov rax,@Row
    shl rax,16
    mov ax,@Col
According to your logic @row MUST be a QWORD.
As an argument to a macro, it can be whatever you want it to be.
The only error you might get is if @Row is bigger than the register you try to use.

Code Select Expand

MyMacro MACRO var1
    mov ax,var1    <- error if var1 > 0ffffh


[NoCforMe]

OK, my bad, I guess: I was assuming the case where the argument to the macro is a register. If it's just a number, then OK, it'll work as long is it's <= 65,535.

Still a bad example, I think.

[sinsi]

The original macro was fine.

Sorry for hijacking your thread Steve 

[FORTRANS]

Hi,

The original macro was fine.

Sorry for hijacking your thread Steve 

   Actually, as a "cut and paste" Windows programmer,
having someone ask how things really work and have
someone try to explain things is still useful.  After
all this is "The Campus" sub-forum.

   If things start to work out with my program I
will have to try some weird things out to see
what works and what doesn't.  Maybe I can finally
learn something useful about Windows programming?

Regards,

Steve N.

[FORTRANS]

Hi,

   Oh bother; after getting my program to assemble without
errors, it doesn't even get the first obvious thing done
correctly.  And locks up as well.  I had poor luck using the
forum search feature.  Any suggestions as to a preferred
debugger?  And possibly a tutorial as well.

TIA,

Steve N.

[jj2007]

Any suggestions as to a preferred debugger?

Use OllyDbg. No manual needed:
F7 one step forward
F8 one step forward, don't dive into procs
F9 run forward until you hit a problem or an int 3 instruction

[FORTRANS]

Hi,

   Thank you.  I did a search on "ollydbg" and got no posts
newer than 2017.  Same thing today.

   The link you provided worked nicely.  It installed and
seems to run as expected.  Now all I need is a lot of
patience or a bigger screen (and still patience).  A
lot of information in a small area.

Regards,

Steve N.

[jj2007]

Oleh Yuschuk has not done much on Olly recently (see this thread), that's true. But Olly is very stable, and recognises most advanced SIMD instructions. Rumours say he designed the look and feel of x64Dbg.

There is even a 64-bit version.

[FORTRANS]

Hi,

Oleh Yuschuk has not done much on Olly recently (see this thread), that's true. But Olly is very stable, and recognises most advanced SIMD instructions.

   What I was trying to say was I was surprised that your post
of 30 March 2024, 07:30:12 did not show up.  Did the search this
morning with the text copied and pasted from that post and still
the newest shown was from 201.  Seemed defective to me.  Maybe I
missed something.

Cheers,

Steve N.

[jj2007]

Well, thats' the one: 12:30:12 PM vs 07:30:12 PM is just a matter of time zones. SMF is a bit clumsy on that side

[TimoVJL]

Just site time zone and logged user profile timezone differences.
Some users try to fool, where they actually live.

[FORTRANS]

Hi,

   Typo alert.  The newest post shown by the search was from 2015.
Sorry about that.

Steve

[FORTRANS]

Hi,

  An update, give or take.  I was converting a program from a DOS version
to be a Windows program.  Thanks to Jochen, I used OllyDbg to find some of
the errors in my code, and, of course, fix them.  Then, the purpose of the
conversion was to upgrade the floating point input and output routines for
improved appearance and functionality.  So I tried to incorporate the code
from by Raymond Filiatreault in his FPU library of routines.  FpuFLtoA and
FpuAtoFL were the ones selected.  So today I think it is working.  A thank
you to Raymond for his work there.  I have been looking at this code since
I joined this forum (IIRC).  Just never figured how to use it till now.

  Why doesn't MASM generate code for the INVOKEs in its listing?

Code Select Expand

                ; - - - Position cursor past displayed data. - - -
 0000004C  66| B8 000B                MOV     AX,11   ; Row
 00000050  C1 E0 10                SHL     EAX,16
 00000053  66| B8 0000                MOV     AX,0    ; Column
                        INVOKE  SetConsoleCursorPosition, [MyOutH], EAX
That would have saved quite some time and effort.  Isn't there some way to
to fix that?

  If anyone here is using Raymond's FpuFLtoA routine, do they have a nice
set of parameters to generate a flexible or more useful output format?  It
seems the number of decimal digits and the number of characters before the
decimal point needs to be refined in my use of the routine.  And since the
main point was to improve the appearance of the output, now it looks a bit
simplistic.  (Minor point, it is working.)

  An interesting exercise in learning to use OllyDbg, if nothing else.  I
do have a (probably) working program to check out.  So, thanks to all that
helped out.

Regards,

Steve N.