Hi,
I decided to convert a 16-bit DOS program into a Windows
version. I am not very familiar with INVOKE and have essen-
tially used copy and paste from the MSAM32 examples, and some
other programs from members of the forum, to write my earlier
programs. So I tried to convert a MACRO to avoid rewriting
around 400 macro calls. I am proceeding slowly, so any help
is welcome.
Here is the first attempt. As yet untested. Do you see
any problems to be fixed or improvements that can be made?
PAGE 53,132
; Does this look okay?
IF 1
; Windows version to write to a console.
@PutText MACRO @Col, @Row, @Attr, @Msg, @Len ; Msg's and Len's could be
MOV [Row],1
MOV [Col],23
MOV AX,[Row]
SHL EAX,16
MOV AX,[Col]
INVOKE SetConsoleCursorPosition, [MyOutH], EAX
; INVOKE SetConsoleTextAttribute, [MyOutH], FOREGROUND_BLUE OR FOREGROUND_INTENSITY
INVOKE SetConsoleTextAttribute, [MyOutH], @Attr
; INVOKE WriteConsole, [MyOutH], OFFSET MsgText1, [LenText1], ADDR NumWrt, 0
INVOKE WriteConsole, [MyOutH], @Msg, @Len, ADDR NumWrt, 0
ENDM
ELSE
; DOS version to write to mode 3 screen.
@PutText MACRO @Col, @Row, @Attr, @Msg, @Len ; Msg's and Len's could be
MOV [Col],@Col ; combined due to consistant
MOV [Row],@Row ; definitions.
MOV AH,@Attr ; Attribute
MOV SI, OFFSET @Msg
MOV CX,@Len
CALL PutText ; And print the text.
ENDM
ENDIF
END
TIA,
Steve N.
Try this:
@PutText MACRO @Col, @Row, @Attr, @Msg, @Len ; Msg's and Len's could be
mov eax, @Row
shl eax, 16
mov ax, @Col
INVOKE SetConsoleCursorPosition, MyOutH, EAX
INVOKE SetConsoleTextAttribute, MyOutH, @Attr
INVOKE WriteConsole, MyOutH, reparg(@Msg), @Len, ADDR NumWrt, 0
ENDM
...
.DATA?
MyOutH dd ?
NumWrt dd ?
.CODE
start:
... set MyOutH etc ...
@PutText 3, 6, FOREGROUND_BLUE or BACKGROUND_RED, "Hello", 5
One thing I don't understand about your macro:
mov eax, @Row
shl eax, 16
mov ax, @Col
How can you move two of the macro parameters to different-size registers (32-bit / 16-bit)? Aren't all the parameters 32-bit?
Quote from: NoCforMe on March 24, 2024, 04:04:11 PMOne thing I don't understand about your macro:
mov eax, @Row
shl eax, 16
mov ax, @Col
How can you move two of the macro parameters to different-size registers (32-bit / 16-bit)? Aren't all the parameters 32-bit?
Macro parameter size for ml.exe would be 32-bits by default/design, but it's what you do with them that counts.
@Row fits into (in this case) a 32-bit register, just like
@Col fits into a 16-bit register.
This fills a COORD structure, which is 4 bytes in length which can be pushed. It's unusual for Windows to have a structure as an arg, it would usually be a pointer to the structure.
jj sometimes forgets that simple is also ok.
(@Row shl 16) + @Col ;give EAX a rest
Quote from: NoCforMe on March 24, 2024, 04:04:11 PMOne thing I don't understand about your macro:
mov eax, @Row
shl eax, 16
mov ax, @Col
How can you move two of the macro parameters to different-size registers (32-bit / 16-bit)? Aren't all the parameters 32-bit?
Best to convert to use all to 32 bit variables,in 32 bit you get an extra 66h prefix byte before all 16 bit register size and prevent bug when 65535 isnt enough
Quote from: sinsi on March 24, 2024, 04:51:30 PMQuote from: NoCforMe on March 24, 2024, 04:04:11 PMOne thing I don't understand about your macro:
mov eax, @Row
shl eax, 16
mov ax, @Col
How can you move two of the macro parameters to different-size registers (32-bit / 16-bit)? Aren't all the parameters 32-bit?
Macro parameter size for ml.exe would be 32-bits by default/design, but it's what you do with them that counts.
@Row fits into (in this case) a 32-bit register, just like @Col fits into a 16-bit register.
This fills a COORD structure, which is 4 bytes in length which can be pushed. It's unusual for Windows to have a structure as an arg, it would usually be a pointer to the structure.
Still confused here: so those macro parameters (
@Col,
@Row) have no defined size? they're just placeholders for whatever the macro is invoked with? That wasn't clear at all here (remember that I'm
not a macro user, so what's obvious to JJ might be clear as mud to others here).
So if I invoke the macro like so:
@PutText CX, EDX, [attr], [msg], [len]
then it'll work because the macro will assemble
mov eax, EDX
shl eax, 16
mov ax, CX
Izzat right?
Seems weird to have row & col. be 2 different size vars.
QuoteSeems weird to have row & col. be 2 different size vars.
You missed the bit about a COORD structure. This has two members, X and Y, both 16-bit words.
When you lay it out in memory, the low word is X and the high word is Y.
It just so happens that EAX is the size of a COORD, and since you can't load the upper 16-bits of a 32-bit register there's the 'trick' of shifting it.
Assuming @Row is 0..79, you could
mov it into AL, AH, EAX or RAX. It all depends on what you are going to do with it.
Yeah, I get that. But what seems weird is that in the macro, @Row is a DWORD and @Col is a WORD.
No, they are both integers, no size is specified.
Put it this way, if a COORD was 2 bytes you would use this (not realistically, just to explain)
mov al,@Row
shl ax,8
mov al,@Col
AFAIK you can't specify a size or type in a macro definition.
Quote from: sinsi on March 24, 2024, 04:51:30 PMjj sometimes forgets that simple is also ok.
Code Select Expand
(@Row shl 16) + @Col ;give EAX a rest
As Einstein said, "everything should be made as simple as possible, but
not simpler" :azn:
m2m ebx, 3
.Repeat
lea esi, [4+4*ebx]
@PutText esi, ebx, FOREGROUND_RED or FOREGROUND_GREEN or FOREGROUND_BLUE, str$(ebx)
inc ebx
.Until ebx>20
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20Source attached, purest Masm32 SDK code ;-)
Quote from: sinsi on March 24, 2024, 08:01:32 PMNo, they are both integers, no size is specified.
Well, yes and no. The way the macro is written,
@Row must be a DWORD and
@Col must be a WORD, otherwise you'll get assembler errors. Therefore the
code in the macro dictates the size of those vars, even though as you say there is no type declaration for them.
Hi,
Thanks to all. The discussion between NoCforMe and sinsi
was interesting. It probably helps. But it will require some
usage to make sure.
@Jochen: Can reparg be used as below? And does "OFFSET"
add anything? And are all the macro invocations below valid?
What are your style preferences (if any)?
.DATA
LenText1 DD 36
MsgText1 DB ' Fixed Point to Decimal Calculator. '
LenText2 DD 79
MsgText2 DB ' X/x = Exit, 1 = Set, 0 = Reset, Space = Toggle, Left = comma, Right = period. '
Msg_Row DB ' RowWork '
.CODE
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; And print it, Col Row Attr Text TextLength
@PutText 19, 0, 1BH, OFFSET MsgText1, OFFSET LenText1 ; Title
@PutText 2, 1, 10, MsgText2, LenText2 ; Instructions
@PutText 19, 3, 10, reparg(" Say what?"), 10
; And print title, Col Row Attr Text TextLength
@PutText 27, 0, 39H, Msg_Row, 10
Regards,
Steve N.
Sorry, nitpick here:
LenText1 DD 36
MsgText1 DB ' Fixed Point to Decimal Calculator. '
Ugh. Very ugly. Pain in the butt. Count characters? Yuck.
Couple better ways to do this:
1. Use standard NULL-terminated strings and use strlen() to get their length at runtime.
2. If you want prefer to get the string length at assemble time, the assembler is your friend:
MsgText1 DB ' Fixed Point to Decimal Calculator. '
$MsgTextLength EQU $ - MsgText1
and use the constant $MsgTextLength when you need it.
Quote from: NoCforMe on March 25, 2024, 06:08:18 AMThe 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.
Quote from: FORTRANS on March 25, 2024, 08:20:55 AMCan reparg be used as below?
Maybe. I've never used it as an argument, but it might work. Why don't you test it?
Quote from: jj2007 on March 25, 2024, 09:34:27 AMQuote from: NoCforMe on March 25, 2024, 06:08:18 AMThe 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:
@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?
Quote from: NoCforMe on March 25, 2024, 09:58:30 AMso 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.
Quote from: NoCforMe on March 25, 2024, 09:58:30 AMQuote from: jj2007 on March 25, 2024, 09:34:27 AMQuote from: NoCforMe on March 25, 2024, 06:08:18 AMThe 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:
@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?
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.
MyMacro MACRO var1
mov ax,var1 <- error if var1 > 0ffffh
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.
The original macro was fine.
Sorry for hijacking your thread Steve :sad:
Hi,
Quote from: sinsi on March 25, 2024, 11:37:29 AMThe original macro was fine.
Sorry for hijacking your thread Steve :sad:
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.
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.
Quote from: FORTRANS on March 29, 2024, 07:08:36 AMAny suggestions as to a preferred debugger?
Use OllyDbg (http://www.ollydbg.de/version2.html). 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
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.
Oleh Yuschuk has not done much on Olly recently (see this thread (https://masm32.com/board/index.php?topic=575.0)), 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 (https://www.ollydbg.de/odbg64.html).
Hi,
Quote from: jj2007 on March 30, 2024, 11:30:12 PMOleh Yuschuk has not done much on Olly recently (see this thread (https://masm32.com/board/index.php?topic=575.0)), 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.
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 :cool:
Just site time zone and logged user profile timezone differences.
Some users try to fool, where they actually live.
Hi,
Typo alert. The newest post shown by the search was from 2015.
Sorry about that.
Steve
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?
; - - - 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.
Quote from: FORTRANS on April 23, 2024, 08:37:28 AMWhy doesn't MASM generate code for the INVOKEs in its listing?
It does:
INVOKE LoadCursor, NULL, IDC_ARROW
00000079 68 00007F00 * push +000007F00h
0000007E 6A 00 * push +000000000h
00000080 E8 00000000 E * call LoadCursorA
You might not have the right options set on the ml command line. Mine are
ml /c /coff /Fl /Sg /Sn <.asm file>
Hi,
Thank you. I thought I had tried all of the switches,
but obviously not.
Regards,
Steve N.