The MASM Forum Archive 2004 to 2012

General Forums => The Campus => Topic started by: StatusQuo on December 07, 2011, 05:45:04 PM

Title: Dont Thread The BOX!
Post by: StatusQuo on December 07, 2011, 05:45:04 PM
Hey guys, I appreciate all the work that goes through here, and so far in my school semester I have been having a complete ballfield with Assembly Language. Now I just ran into an ultimate wall. So as a last minute final my professor decides to give us an assignment where i am supposed to make a BOX within DOS, that must have a title. For the first time in my life, I don't know what to do. When I approached the professor about this, he said to me, "Well a good programmer doesn't know what to do. But a bad programmer knows what to do." which left me at a  :eek ??? So anyways, long stories short, I have been seeking templates and examples of how to create a box inside the DOS box. I saw one thread here that actually made a blue DOS box, but for me it is a horrible example, simply because the coding is 16Bit,  I need to make a 32Bit coding and I seriously have no approach. This is the first time where I am actually clueless and the shrimp of my professor wants me to fail so i can come back to college and pay another 750 bucks, no thank you. If i have to read 400 pages on how to make a box then I will do it, but I guess what I'm asking for here, is not answers, but direction. Would anyone be kind enough to point to me how to even begin phase 1 of this final that i have to do?
Title: Re: Dont Thread The BOX!
Post by: dedndave on December 07, 2011, 06:07:11 PM
it isn't hard at all
in console mode, you are using the old IBM character set (sometimes refered to as OEM char set or "Terminal" font)
it includes "line graphics" characters for drawing single and double outline boxes, as well as filled and dithered boxes
these characters are all chr$(128) and above
there are also several other interesting graphics characters

http://telecom.tbi.net/asc-ibm.html
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 07, 2011, 06:13:03 PM
dendave to my rescue as usual  :U . Okay i get it, so basically its ASCII characters made up of lines and blocks, yet i would ASSUME in order to do that, one would have to write a PROC that finds the cursor, and from there just draw lines and innner boxes, am I right?
Title: Re: Dont Thread The BOX!
Post by: dedndave on December 07, 2011, 06:24:05 PM
well - you can clear the screen, knowing that the position is 0,0 afterward   :P
but - there are also functions for getting and setting the cursor position, as well

to get the cursor position:
GetConsoleScreenBufferInfo
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683171%28v=vs.85%29.aspx

to set the cursor position:
SetConsoleCursorPosition
http://msdn.microsoft.com/en-us/library/windows/desktop/ms686025%28v=vs.85%29.aspx

properly clearing the console screen involves using:
GetConsoleScreenBufferInfo
FillConsoleOutputCharacter
FillConsoleOutputAttribute
ScrollConsoleScreenBuffer
SetConsoleCursorPosition

there are a number of ways to do it, of course
a simple version might just fill the buffer with spaces and set the position
i think the masm32 package has a macro for this - not sure, as i never used it   :P

you can create strings using DB like so

DblHorzLine db 0CDh, 0CDh, 0CDh, 0CDh, 0

or, you can create the entire box in a memory buffer then display it a set of text lines
this is probably the method i would use

a while back, Frank and Alex were writing a program called "TestBed"
you can use the forum search tool to find some info
Frank created the box in a data file
then, when the program was run, he loaded the data file and displayed it
Title: Re: Dont Thread The BOX!
Post by: mineiro on December 07, 2011, 06:25:56 PM
Like Sr dedndave have said:
http://www.masm32.com/board/index.php?topic=14734.0
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 07, 2011, 06:28:18 PM
Dave I kind of lost you when you mentioned this term:

"or, you can create the entire box in a memory buffer then display it a set of text lines
this is probably the method i would use"

Could you possibly explain that in a little bit more detail.
Title: Re: Dont Thread The BOX!
Post by: dedndave on December 07, 2011, 06:35:54 PM
sure
you create an empty buffer in memory
you can do this either by defining bytes in the uninitialized data section,
or by allocating memory using one of the API functions

then, you can write a simple loop to generate a series of characters for the lines at the correct addresses
fill in the corners with the appropriate characters and you have  box

for a beginner, it is probably simpler to just use DB and create the lines
your professor probably doesn't care which method you use, so long as a box appears

give me a little time - i will write a simple example...
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 07, 2011, 06:43:56 PM
Thank you, I am going to take some little time to brain storm this and just write it out rashly, how ever it comes to mind before organization and testing. I shall return. Also,  I was wondering, the minute my professor told the class about this, a word popped in my head that I havent seen since Java. I want to go out with a bang with this professor because he is a bigot, and he makes his bigotry known. Since i am one of the three spics in the class, i figured I would give him two versions of the final, his way, and a little hit different version. I was wondering, if it is possible to make a box with the title and its lovely perks, through Inheritance. I am familiar with the term inhertience being, correct me if I am wrong, to create an object using the data off of another. My mind has been circling that threory and I guess I am jogging at the moment, one thing at a time, but i just have to ask.  :clap:
Title: Re: Dont Thread The BOX!
Post by: dedndave on December 07, 2011, 07:06:17 PM
here - this is pretty easy   :P
Title: Re: Dont Thread The BOX!
Post by: dedndave on December 07, 2011, 07:20:56 PM
not too sure about the "inheritance" thing
if you want to use 2 methods, use one that defines the box with DB and another with loops
you see, if the box is defined with data, the EXE can get pretty large for larger boxes
the loop method is more efficient in terms of size
even more efficient (in terms of memory usage) is to write the loops so they output directly to the screen
although, the later may be a bit sluggish
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 07, 2011, 07:28:02 PM
So then suppose if I wanted to make a cheap programmers box border, where you would have one box over lapping the other, and the difference may come in when the box is slightly smaller than the original, to make it seem like a border,  would that be even sluggier? It would inherit simuliar data, with the negate of size being adjusted, kind of like an instance or interrupt but EHH, you see i toggle this question in my head all day.
Title: Re: Dont Thread The BOX!
Post by: dedndave on December 07, 2011, 07:41:10 PM
a really good approach might be to write a procedure that creates boxes of different sizes
you could pass the upper left corner X, Y, width, and height as parameters
that would make a re-usable function which could be handy

after a call, you would have to position the cursor and write the title text
so - a good feature of the function might be to position the cursor in the left-most space of the title area
you can use the passed X and Y parameters
position the cursor at X+1,Y+1
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 07, 2011, 07:55:32 PM
That would be a good one, as a reply to your example, it is very good actually, I was on the right track, but suppose if I set the cursor again inside the box for typing, I know that would require me to reposition the cursor, and set a boundry so that it doesnt overflow. Would i be in the right track with that idea, or am I missing some sort of noobish alternative?
Title: Re: Dont Thread The BOX!
Post by: baltoro on December 07, 2011, 08:23:49 PM
STATUS QUO,
Inheritance is, I think, a paradigm existing in higher programming languages, such as C or C++.
You could probably simulate it in assembly language,...but, it would be kind of silly.

...And,...
Quote from: STATUS QUO...dedndave to my rescue as usual ,...
Dave is famous for this. I can't tell you how many times I've suggested some completely inadequate technique to someone's Campus Forum problem,...only to have DAVE post the correct solution within milliseconds. He's almost infallible,...in fact, I think he screws up an answer every so often just to mislead us into thinking he's normal.

In my opinion, your assembly programming professor is teaching you obsolete stuff. If you do a serious search of past posts here at the MASM Forums, you will discover that it is the Mother Lode of cutting-edge assembly programming techniques.
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 07, 2011, 08:38:22 PM
I suppose so, I have done searches upon it, and i have seen simular templates of the like, but for this professor, he has a method where, IF YOU DONT DEGRADE THE PROGRAM TO THE ABSOLUTE BASIC, AND NOT USE IRVINE'S RULES, YOU WILL UNDERSTAND THE METHODS BETTER, AND HOW THINGS WORK, SO EVERTHING MUST BE DOWNGRADED, and for a 4 credit class that I need for Grad, I have to put up with his stupid rules and regulations. I figured just to draw a box would be too simple, that was my theory until I actually had to write it, and dave gave me good direction. Yet with this man he likes to give ME in particullar, last minute changes, so right now I concider this a Box with open options, as I type this, I am making the box multi-colored, another one with a different color border, and later the one that might give me trouble, is a box where I can type into, just to be prepared. I should have dropped the class when i felt that this professor doesnt like me, but I dont want to wait 6 months and pay an extra $500 for this class again. So i have been dealing with him fine until this final came up, where I figured he might try something against me, and he kind of has.
Title: Re: Dont Thread The BOX!
Post by: anunitu on December 07, 2011, 08:46:44 PM
This does sound VERY old school DOS stuff..Working in dos you learn about screen memory where your text or graphic is simply sent to screen memory and using Int to set the coordinates for where it should appear. I am supprised that your "Teacher" would set this type of task in a modern assembler system like windows. As you mentioned he seems prejudiced. It might actully be your race he dosen't have a problem with,but your ability. I have run across this long ago while taking classes. If you seem smarter than the teacher,you threaten their position or something. One teacher hated when I asked questions he couldn't answer.

A really GOOD teacher would not be bothered by a student that exceeded his or the other students,he would encourge the extra effort.
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 07, 2011, 08:53:59 PM
Great alternative but one problem, he is a GOOD F'en teacher, you would be surpised to see how many students come out of his class, and he has been around for years. Still stuck on those Black Screen/Green Text DOS days back in the mid-80's. The way I see it, I will just do his work as I have been doing, and then in the VERY end, have a talk with him and the dean of displines. Yet the thing is I DONT want to to bite more than I can chew. For now my grade is in his hands, and unfortuntely, one day of a lesson about his time and how Aseembly came to be, is truly intellectually entertaintaining. I guess thats why the school kept him there all these years, despite his belief, the man can tell you bit by bit how a simple "Hello World" program works, but refuses to tel you how you can write Hello World in a blink of an eye, and tells you to stick the old age of programming. :(
Title: Re: Dont Thread The BOX!
Post by: baltoro on December 07, 2011, 09:07:01 PM
Well,...I suppose the suffering will eventually make you a great programmer.
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 07, 2011, 09:21:46 PM
That is another way i looked at it actually. I find it humorous when a professor gives me two extra credit assignments that have to be done in Java, when the college doesnt teach Java, they have C++, but i came in knowing java, and just to see his facial expressions seems brightful vengence to me. Then an assignment that is of Assembly level 230, which he thought I would look past it, have done and see that slight grin....brightful Vengence.  :U
Title: Re: Dont Thread The BOX!
Post by: dedndave on December 08, 2011, 12:42:08 AM
well - it is good to know how things work underneath the hood
for example - macros are very handy time savers, but isolate you from the underlying code
it's great to use them, but it's better to understand what they do and how they do it
Title: Re: Dont Thread The BOX!
Post by: anunitu on December 08, 2011, 12:46:00 AM
Dave, being a hardware guy can tell you about doing things right down to the bare metal..I tend to be very informed about hardware as well,and like to tinker with my box. In assembler it does help to know your chip level stuff. In fact a lot of assembler classes are discribed as knowing your hardware it seems.
Title: Re: Dont Thread The BOX!
Post by: dedndave on December 08, 2011, 12:51:13 AM
i know what you mean
i have read so many IC data sheets, i feel like a walking library - lol
i used to have many of the pinouts memorized
probably forgotten most of them, now
Title: Re: Dont Thread The BOX!
Post by: anunitu on December 08, 2011, 12:54:22 AM
Somewhere on my drive I have a really good CHM that lists most all connector and other data with a graffic pic of the pinouts. It is a free file. If I can find it I will upload it. its a great referance.
Title: Re: Dont Thread The BOX!
Post by: dedndave on December 08, 2011, 03:17:02 AM
i used to keep those kinds of things under a piece of glass on my desk - lol
i quit doing that - not sure why, really
i could put instructions, timings, and API functions (etc) there   :P
Title: Re: Dont Thread The BOX!
Post by: baltoro on December 08, 2011, 10:34:46 PM
...Wild Eyed Look,...
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 08, 2011, 11:29:30 PM
Okay guys i actually went into the old IRVINE Book, and worked on this program using the masm32 at my house, I forgot that the computers at my school are still on Irvine32.inc, so I have written this program through scratch using what I have seen in the old "Assembly Language For Intel Based Computers, Fourth Edition" color cream book. The horror, I know. So this what I have so far, and I need to seriously down grade this program, into a more basic routine for "he doesnt agree with Masm32" and  he gives me this last minute change to my program, now I have to give him this one and another one where I have to have the cursor, within the box, being able to type as processor, another pain but I will do it, luckly for Dave's and etc's advice i have now a more broaden idea. I honestly dont know how low i have to go with his program, because my brain cant downgrade this anymore than it is, I got this info STRAIT from his stupid Assembly Book, and I really am starting to hate the old Irvine32.Inc rule he gives me. Please correct me if any of the comments I made are wrong, for the Irvine book has many mistakes. Here is my code, excuse the small comments, for they are to him.


TITLE      TESTDRIVE3

include\masm32\include\masm32rt.inc

FORMAT            PROTO   :DWORD
MAKEWIN            PROTO   :DWORD, :DWORD

Rows            EQU 25
Colums            EQU 80
XLength            EQU Rows*Colums*4 ;**string length charachter** Incase someone asks because you wont remember it.

.DATA
BTitle            DB   "[]This Is A Little Blue Box, Filled With Yellow Lies[]",0
InputB            DWORD 1

;Positioning, directly
UpperRow         DB 218
RightCol         DB 191
LowerRow         DB 192
LeftCol            DB 217
Horizontal         DB 196
Vertical         DB 179

.Data? ; Declare my unitialized Data (Irivine pg568)
ConsoleScreen      CHAR_INFO 2000 DUP (<>) ; Declaring a structured variable, my default field, pg 335
Curs            CONSOLE_CURSOR_INFO <> ;pg 402 the information of the cursor's size and visibility.
Handler1         HANDLE ? ;pg 339, toogles Screen Buffer, could be wrong.
Handler2          HANDLE ?

WinSize            SMALL_RECT<>   ;pg390
BufSize            COORD <>
Starter            COORD <> ; Finding X, Y in the DOS field.   

Manyof            DD ?
Buffer            INPUT_RECORD <> ;pg 346, console input functions.


.CODE
speedracer:
WINSIZE            PROC
               INVOKE   SetConsoleTitle, ADDR BTitle ;pg386. Setting the title bar string.
               CALL   HideTheCursor ;****
               INVOKE   SetConsoleWindowInfo, Handler1, TRUE, ADDR WinSize
               INVOKE   SetConsoleScreenBufferSize, Handler1, DWORD PTR BufSize
               RET
WINSIZE            ENDP

PUTCHAR            PROC
               CALL   SetBufferColor
               INVOKE   MAKEWIN, 1, 3
               INVOKE   MAKEWIN, 4, 25
               RET
PUTCHAR            ENDP

; Fill the buffer with a box of 80 characters
; till the number of line passed as II parameter.
;My 3:45AM Buzz Kill.

MAKEWIN            PROC Row1:DWORD, Row2:DWORD
               MOV      EAX, Row1
               SUB      EAX, 1
               IMUL   EAX, 320 ;pg627 perform a signed integer multiplication.
               MOV      EDX, EAX
               LEA      EAX, ConsoleScreen ;pg631 calculate and load the memory address. 
               ADD      EAX, EDX
               
               MOVZX   EBX, BYTE PTR[UpperRow]
               MOV      BYTE PTR [EAX], BL
               ADD      EAX, 4
               MOV      ECX, 78
               
               MOVZX   EBX, BYTE PTR [Horizontal]
               MOV      BL, Horizontal
Filler1:
               MOV      BYTE PTR[EAX], BL
               ADD      EAX, 4
               DEC      ECX
               JNZ      Filler1
               
               MOVZX   EBX, BYTE PTR [RightCol}
               MOV      BYTE PTR [EAX], BL
               ADD      EAX, 4
               
               MOV      ECX, Row2
               SUB      ECX, ROW1
               DEC    ECX
               MOVZX   EBX, BYTE PTR [Vertical]
BordFill:
               MOV      BYTE PTR [EAX], BL
               ADD      EAX, 4
               MOV      EDX, 4
               IMUL   EDX, 78
               ADD      EAX, EDX
               MOV      BYTE PTR[EAX], BL
               ADD      EAX, 4
               DEC      ECX
               JNZ      BorderFill
               
               MOVZX   EBX, BYTE PTR [LowerRow]
               MOV      BYTE PTR [EAX], BL
               ADD      EAX, 4
               MOV      ECX, 78
               MOVZX   EBX, BYTE PTR [Horizontal]
               
Filler2:
               MOV      BYTE PTR [EAX], BL
               ADD      EAX, 4
               DEC      ECX
               JNZ      Filler2
               
               MOVZX   EBX, BYTE PTR [LeftCol]
               MOV      BYTE PTR [EAX], BL
               RET
MAKEWIN            ENDP

;Coloring Time XD
SetBufferColor      PROC
               PUSH   EDI
               MOV      EDI, OFFSET ConsoleScreen
               MOV      EAX, 201E2020H
               MOV      ECX, 2000
               REP      STOSD ; repeats what is stored in EAX.
               POP      EDI
               RET
SetBufferColor      ENDP

CURPOS            PROC
               INVOKE   GetConsoleCursorInfo, Handler1, ADDR Curs
               MOV      Curs.bVisible, TRUE
               INVOKE   SetConsoleCursorInfo, Handle1, ADDR Curs
               RET
CURPOS            ENDP

;*****
HideTheCursor      PROC
               INVOKE   GetConsoleCursorInfo, Handler1, ADDR curs
               MOV      curs.bVisible, FALSE
               INVOKE   SetConsoleCursorInfo, Handler1, ADDR curs
               RET
HidTheCursor      ENDP

InitProc         PROC
               INVOKE   GetStdHandle, STD_INPUT_HANDLE; pg383 return my handle back into EAX, the safekeeper.
               MOV      Handler2, EAX
               INVOKE   GetStdHandle, STD_OUTPUT_HANDLE
               MOV      Handler1, EAX
               
               MOV      windowSize.Left, 0
               MOV      windowSize.Right, 79
               MOV      windowSize.Top, 0
               MOV      windowSize.Bottom, 24
               
               MOV      BufSize.X, 80
               MOV      BufSize.Y, 25
               
               MOV      Starter.X, 0
               MOV      Starter.Y, 0
               RET
InitProc         ENDP

FORMAT            PROC    szFmtName:DWORD
               INVOKE   WriteConsoleOutput, Handler1, szFmtName, DWORD PTR BufSize,
                     DWORD PTR Starter, OFFSET WINSIZE
               RET
FORMAT            ENDP

;Returning the key code in buffer.KeyEvent.wVirtualKeyCode WORD size
AnyKey            PROC
Looper:
               INVOKE   ReadConsoleInput, Handler2, OFFSET Buffer, 1, OFFSET Manyof
               CMP      Buffer.EventType, KEY_EVENT
               JNZ      Looper
               
               CMP      Buffer.KeyEvent.bKeyDown, 0
               JZ      Looper
               RET
AnyKey            ENDP

MAIN            PROC
               CALL   InitProc
               CALL   WINSIZE
               CALL   WINDESC
               INVOKE   FORMAT, offset ConsoleScreen
               CALL   AnyKey
               CALL   CURPOS
RacerX:
               INVOKE ExitProcess, 0 ;MS terminates program pg159
               RET
MAIN            ENDP               
END               speedracer
Title: Re: Dont Thread The BOX!
Post by: dedndave on December 08, 2011, 11:44:16 PM
first of all, you can keep your posted text formatted by using code tags
highlight all the code text, then click on the # icon above the Reply window
this will add code tags and keep things lined up

we need to see the entire program - i think there are some routines missing

however, you do not have to post it all in the Reply window
you can attach ZIP files to the Reply by clicking on the Advanced Options link under the Reply window
zip the complete project and attach it   :U

EDIT - my mistake - it looks complete   :P
Title: Re: Dont Thread The BOX!
Post by: dedndave on December 08, 2011, 11:48:27 PM
one thing that should not work....
END               speedracer

the END directive should reference the entry point for EXE source files
        END     MAIN
Title: Re: Dont Thread The BOX!
Post by: dedndave on December 08, 2011, 11:55:53 PM
here is what i would suggest as far as "breaking the code down to a more basic level"
the instructor wants to see that you understand the concept of passing function parameters on the stack

so - every place you have an INVOKE, simply replace the line with the appopriate PUSH/CALL sequence

for example, replace....
        INVOKE  WriteConsoleOutput, Handler1, szFmtName, DWORD PTR BufSize,
                DWORD PTR Starter, OFFSET WINSIZE


with this....
;may be written as: INVOKE  WriteConsoleOutput, Handler1, szFmtName, DWORD PTR BufSize,
;                           DWORD PTR Starter, OFFSET WINSIZE

        push    OFFSET WINSIZE
        push    DWORD PTR Starter
        push    DWORD PTR BufSize
        push    szFmtName
        push    Handler1
        CALL    WriteConsoleOutput

by adding the comment, the instructor sees that you understand the concept of PUSH/CALL
and he sees that you know what INVOKE does   :U
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 09, 2011, 12:56:24 AM
Thanks for the info dave, i mean th code at the bottom.

MAIN            ENDP               
END               speedracer

Works well, i have written and tested it out throughly, and i made an EXE and it works the same. I am still trying to figure out how to attack a file into these forums. I ddi press that # key and just pasted my WHOLE code into it, so there is no other subroutines missing. This basically it, and it works on a MASM32 Computer. I am breaking it down like dave suggested, and thanks dave, i feel more stupid for not thinking of just Push/Call.  :U
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 09, 2011, 01:11:30 AM
Never mind i figured it out lol. This is the entire file.
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 09, 2011, 01:25:09 AM
Okay guys I cant downgrade it anymore than this, if you see any futher actions of downgrading that I have missed, please let me know. Also, I wonder if I broke them right for I cant test this program on the computers i am currently using.
Title: Re: Dont Thread The BOX!
Post by: dedndave on December 09, 2011, 02:03:58 AM
parameters are pushed in right-to-left order

also, the terms "handle" and "handler" have distinctly different meanings

the term "handle" is used as the name of a unique identification number for objects like files, buffers, etc
the console input and output handles provide you a way to specify which device or objext is to be used
as an example, you can use multiple screen buffers
each buffer will have a different handle
you may fill one up with data while another one is being displayed
then, switch to the newly updated buffer
this gives the appearance of fast screen updating

the term "handler" is generally used to refer to a section of code that responds to some event, like a hardware event
for example, when you press a key on the keyboard, the BIOS and operating system execute handler code
Title: Re: Dont Thread The BOX!
Post by: mineiro on December 09, 2011, 02:06:28 AM
you are doing the pushes by hand, so, change lines like:
PUSH   ADDR BTitle
to
PUSH   offset BTitle


Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 09, 2011, 02:08:44 AM
Then I shall change the variable, ill probably call it Handit lol. Ive made changes in my fourth test run, and right now I am trying to get it to run in a regular make32, opposed to Masm32. Take a look, let me know the foul ups so I can redeem myself.
Title: Re: Dont Thread The BOX!
Post by: dedndave on December 09, 2011, 02:16:06 AM
i am doing some clean-up   :P
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 09, 2011, 02:17:50 AM
Quote from: dedndave on December 09, 2011, 02:16:06 AM
i am doing some clean-up   :P

Define Clean Up, that sounds kinda dirty :p :lol
Title: Re: Dont Thread The BOX!
Post by: Magnum on December 09, 2011, 02:21:58 AM
You have got both 16 and 32 bit code, so it won't assemble correctly.

Title: Re: Dont Thread The BOX!
Post by: dedndave on December 09, 2011, 02:24:11 AM
 :eek
Title: Re: Dont Thread The BOX!
Post by: dedndave on December 09, 2011, 02:38:02 AM
Rafael,
i am going to put a high-voltage electrode on your tab key   :bdg
every time you hit that sucker, you will jump out of your chair and your hair will get curly(er)
Title: Re: Dont Thread The BOX!
Post by: mineiro on December 09, 2011, 02:48:42 AM
You need preserve the sensitivity of names, so Myvar and myvar are not equal.(this is default in masm32, included inside masm32rt.inc
Do not mix ms-dos interruptions with windows.
Your exit macro need be:
exit macro
push 0
call ExitProcess
endm
You have named a procedure with the same name of one variable, this confuses the assembler and the reader(your teacher)
You need review/check the right to left parameters order.
Have some "[" opened but not closed.
Have some variables inside code, but not defined.
...
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 09, 2011, 02:58:20 AM
Quote from: mineiro on December 09, 2011, 02:48:42 AM
You need preserve the sensitivity of names, so Myvar and myvar are not equal.(this is default in masm32, included inside masm32rt.inc
Do not mix ms-dos interruptions with windows.
Your exit macro need be:
exit macro
push 0
call ExitProcess
endm
You have named a procedure with the same name of one variable, this confuses the assembler and the reader(your teacher)
You need review/check the right to left parameters order.
Have some "[" opened but not closed.
Have some variables inside code, but not defined.
...


Thanks Bro, but actually that EXIT MACRO was to insult the professor at the time, I did it for no apprent reason and it is irrelivant, but that information I did not know, and I will add it to memory.  Yet your last comment left me at a riddle, can you please go into through detail into that, so I make not the same mistakes.

You need review/check the right to left parameters order.
Have some "[" opened but not closed.
Have some variables inside code, but not defined.

What do you mean? Ive never heard of that. BTW Dave, I am just following orders, WHICH COMES TO SHOW YOU about my professor. As you can see he perfers that OLD SCHOOL T, or organizing my program. So its EAX TAB THREE TIMES then variable...Last time he litterarly expressed his dislike in me when he took off 10 points for "bad organization & structure." and that was my mid-term. I really want to get out of this class....
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 09, 2011, 03:10:57 AM
Quote from: Magnum on December 09, 2011, 02:21:58 AM
You have got both 16 and 32 bit code, so it won't assemble correctly.



How so? I mean I know why, and I understand your theory, but when I had it a little bit more advanced using the invoke, not broken down to PUSH & CALLS, it still worked lovely at my laptop which has MASM32, but the schools computer it woudlnt for obvious reasons. I thought it wouldnt matter if the 16 & 32 bit codes are mixed up as long as it can coincide with eachother. If wrong, please let me know why, i love asking dumb questions, makes me that much smarter. Yet to ask what you know is polite  :bg lol.
Title: Re: Dont Thread The BOX!
Post by: Gunner on December 09, 2011, 03:11:18 AM
What Dave is saying, don't use tabs, or convert them to spaces.  A space is a space.  Your tab might be equal to 5 spaces, someone else - 3.  
Title: Re: Dont Thread The BOX!
Post by: mineiro on December 09, 2011, 03:13:02 AM
WINDESC            SMALL_RECT<>   ;you put this in .data section
WINDESC            PROC ;the same name to reference a procedure, but now, this is code
...
Curs   CONSOLE_CURSOR_INFO <> ; first letter Uppercase = Curs
PUSH   OFFSET curs                        ;first letter here is not Uppercase = curs
...
;               INVOKE   SetConsoleWindowInfo, Handit1, TRUE, ADDR WINDESC
push offset WINDESC        ;push last one at right -->Question: What it need push? the WINDESC SMALL_RECT structure or the offset of WINDESC procedure?
push TRUE                       ;push before last one
push Handit1                    ;push before before last one
call SetConsoleWindowInfo
...
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 09, 2011, 03:13:48 AM
Quote from: Gunner on December 09, 2011, 03:11:18 AM
What Dave is saying, don't use tabs, or convert them to spaces.  A space is a space.  Your tab might be equal to 5 spaces, someone else - 3.  

I can understand that Gunner, but like i said earlier, use tabs or hear my bigot teacher say "10 points off" because i dont appropiate to HIS terms...Well the scale out weights itself....
Title: Re: Dont Thread The BOX!
Post by: Magnum on December 09, 2011, 03:17:34 AM
This is used in 16 bit code.

.MODEL            SMALL
.STACK            100h

You probably ought to be sleeping at 3:45 am.  :bg

;My 3:45AM Buzz Kill.

I get these errors when trying to compile it.

C:\masm32\SOURCE\status.asm(38) : error A2005:symbol redefinition : WINDESC
C:\masm32\SOURCE\status.asm(44) : error A2008:syntax error : ,
C:\masm32\SOURCE\status.asm(52) : fatal error A1010:unmatched block nesting : WINDESC

Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 09, 2011, 03:20:42 AM
Quote from: mineiro on December 09, 2011, 03:13:02 AM
WINDESC            SMALL_RECT<>   ;you put this in .data section
WINDESC            PROC ;the same name to reference a procedure, but now, this is code
...
Curs   CONSOLE_CURSOR_INFO <> ; first letter Uppercase = Curs
PUSH   OFFSET curs                        ;first letter here is not Uppercase = curs
...
;               INVOKE   SetConsoleWindowInfo, Handit1, TRUE, ADDR WINDESC
push offset WINDESC        ;push last one at right -->Question: What it need push? the WINDESC SMALL_RECT structure or the offset of WINDESC procedure?
push TRUE                       ;push before last one
push Handit1                    ;push before before last one
call SetConsoleWindowInfo
...


the offset of WINDESC procedure, but if noticed on the commented INVOKE above that, it took care of the WINDESC Procedure, but in the sake of downgrading this to a basic make32, I relayed on PUSH & CALL commands like Dave suggested. The WINDESC SMALL_RECT is kind of a structure I took from the professor exaple, i.e:

WINDESC   STRUCT
                UpperRow     BYTE ?
                LeftCol     BYTE ?
                LowerRow     BYTE ?
                RightCol     BYTE ?
                foreColor     BYTE ?
                backColor     BYTE ?
WINDESC   ENDS

then in HIS example, he would have a different .Data, I.E
.DATA
APPLICATION         WINDESC     <05h, 05h, 15h, 45h, 07h, 10h>

the problem is, his example is COMPLETE 16bit...
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 09, 2011, 03:26:09 AM
Quote from: Magnum on December 09, 2011, 03:17:34 AM
This is used in 16 bit code.

.MODEL            SMALL
.STACK            100h

You probably ought to be sleeping at 3:45 am.  :bg

;My 3:45AM Buzz Kill.

I get these errors when trying to compile it.

C:\masm32\SOURCE\status.asm(38) : error A2005:symbol redefinition : WINDESC
C:\masm32\SOURCE\status.asm(44) : error A2008:syntax error : ,
C:\masm32\SOURCE\status.asm(52) : fatal error A1010:unmatched block nesting : WINDESC



Because I zipped the wrong Testdrive, I KNOWWWWWWWWWW LOL, but i am determined, Ive applied the one i am CURRENTLY working on at the moment. That has an ERROR in the bottom on the MAIN, i called it TWICE, maybe thats why.
Title: Re: Dont Thread The BOX!
Post by: dedndave on December 09, 2011, 03:31:17 AM
well - i got it to assemble by commenting out the CALL WINDESC line
but - nothing happens
if i press a key, the program terminates   :U

maybe we should have a look at the professor's example code

by the way - i cleaned things up a bit
see if you can read it a little better   :bg

i am going to go visit mom for a few
i will be back later tonight and work on it a little more, if you like
Title: Re: Dont Thread The BOX!
Post by: dedndave on December 09, 2011, 03:32:44 AM
you have 3 different posts with attachments named TESTDRIVE4 - lol
no wonder we are having issues   :P
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 09, 2011, 03:37:23 AM
Quote from: dedndave on December 09, 2011, 03:32:44 AM
you have 3 different posts with attachments named TESTDRIVE4 - lol
no wonder we are having issues   :P

So sorry bro, but the lastest I have been typing up is the 4th one i just put up not to long ago and I dont think i am going to change anymore until i make something up even better. The professors example, which i wrote is a COMPLETE 16bit program that i labled as ProfBox, his method...
Title: Re: Dont Thread The BOX!
Post by: mineiro on December 09, 2011, 03:39:51 AM
Quote from: StatusQuo on December 09, 2011, 03:20:42 AM
the offset of WINDESC procedure
So, this will pass a wrong parameter to that call, can you see. The function SetConsoleWindowInfo need that the 3rd parameter be a pointer (offset) to a structure.
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 09, 2011, 03:43:55 AM
Quote from: mineiro on December 09, 2011, 03:39:51 AM
Quote from: StatusQuo on December 09, 2011, 03:20:42 AM
the offset of WINDESC procedure
So, this will pass a wrong parameter to that call, can you see. The function SetConsoleWindowInfo need that the 3rd parameter be a pointer (offset) to a structure.


o_o awww dude dont say that to me now  :'( I might have to re-evaluate this program, suppose if I push WINDESC SMALL_RECT, I have an idea of the outcome but I want to play the safeside and and rather hear other options you might give.
Title: Re: Dont Thread The BOX!
Post by: mineiro on December 09, 2011, 03:54:51 AM
WINDESC procedure need's be called. So search for "call WINDESC" and change to "call descwin".
Search for "WINDESC proc" and change to "descwin proc".
search for "WINDESC endp" and change to "descwin endp"
...
I be honest(diplomatic) with you, I have cleaned your code, but the flow of your code do not do what it is supposed to do.
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 09, 2011, 03:58:32 AM
Quote from: mineiro on December 09, 2011, 03:54:51 AM
WINDESC procedure need's be called. So search for "call WINDESC" and change to "call descwin".
Search for "WINDESC proc" and change to "descwin proc".
search for "WINDESC endp" and change to "descwin endp"
...
I be honest(diplomatic) with you, I have cleaned your code, but the flow of your code do not do what it is supposed to do.


but how so? I had to work earlier, and I dont see how flip flopping the WINDESC would change that. Could you please explain to me that situation. Also did you see the ZIP file from my professors example? I am basing it on his, in a way.
Title: Re: Dont Thread The BOX!
Post by: mineiro on December 09, 2011, 04:30:15 AM
I have download that example, and is very similar to one that I have seen.
What I'm saying to you is; you need review the flow of you code after cleaned it. Inside your code have what you need, but you do not have called it in the right way, following some sequence.
This is your code cleaned, but I have removed your's previous works.
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 09, 2011, 04:43:06 AM
Quote from: mineiro on December 09, 2011, 04:30:15 AM
I have download that example, and is very similar to one that I have seen.
What I'm saying to you is; you need review the flow of you code after cleaned it. Inside your code have what you need, but you do not have called it in the right way, following some sequence.
This is your code cleaned, but I have removed your's previous works.

I am re-drawing my outline now. So instead of having everything being called in the MAIN, ill just call one PROC upon another. I.E:
1. MAIN PROC
2. MAKEWIN
3.WINDESC1
4.CURPOS
5.PUTCHAR

and etc? An old friend once told me that a MAIN PROC does one thing at a time.
Title: Re: Dont Thread The BOX!
Post by: mineiro on December 09, 2011, 04:52:31 AM
No Sr, I will be precise now, in your example, your last line is:
END   speedracer
and need be:
END MAIN

Your program is working, but because that mistake, all changes.
That posted code(your code) is working and clean, but I have only removed your low level.
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 09, 2011, 04:58:08 AM
Quote from: mineiro on December 09, 2011, 04:52:31 AM
No Sr, I will be precise now, in your example, your last line is:
END   speedracer
and need be:
END MAIN

Your program is working, but because that mistake, all changes.
That posted code(your code) is working and clean, but I have only removed your low level.

But kind Sr, low level is what I NEED. I understand the irrelivancy of MANY of the lines in my programs, the trick is in my mind Sr, I have gone to extent of learning new, for the first time, a man tells me to do it an OLD fashionate way. Meer Basic and OLD to an extent, that i was looping the entire program in a MASM32 laptop that speedrace wasnt the issue. The issue at hand is, how far older can I turn this program into without the use of Irvine32, nor MASM32, but in a basic make32 bit. I got it working on that level with MASM32. With that being said, thank you for the small detail i missed out on. I am having quite better results on the program but still a few errors like the one mentioned in earlier post. Thank You Sincerely minderio
Title: Re: Dont Thread The BOX!
Post by: mineiro on December 09, 2011, 05:10:42 AM
Allright, I'm going to my work StatusQuo. You need change the invoke's:
      INVOKE   GetConsoleCursorInfo, Handit1, ADDR Curs
to this:
      push offset Curs
      push Handit1
      call GetConsoleCursorInfo
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 09, 2011, 05:42:14 AM
Quote from: mineiro on December 09, 2011, 05:10:42 AM
Allright, I'm going to my work StatusQuo. You need change the invoke's:
      INVOKE   GetConsoleCursorInfo, Handit1, ADDR Curs
to this:
      push offset Curs
      push Handit1
      call GetConsoleCursorInfo

Thanks for the info, good day.
Title: Re: Dont Thread The BOX!
Post by: anunitu on December 13, 2011, 04:25:57 PM
Here is a link for the help file I mentioned..The Hardware book.

http://margo.student.utwente.nl/stefan/hwb/hwb.html

Very good reference for making your own cables.

Scroll down to where it says download.
Lots of other hardware stuff also.
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 13, 2011, 09:58:56 PM
Quote from: anunitu on December 13, 2011, 04:25:57 PM
Here is a link for the help file I mentioned..The Hardware book.

http://margo.student.utwente.nl/stefan/hwb/hwb.html

Very good reference for making your own cables.

Scroll down to where it says download.
Lots of other hardware stuff also.

I am actually at the same problem you mentioned much earlier. I got it to Assemble, but for some odd reason, it is complaining about the compatibility within my machine, so it is not running. I will check this site out now. Thank you for thinking of me.   :bg
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 14, 2011, 01:26:24 AM
Okay guys I got the code working and I played around with the PROC calling, and now my program works but it doesnt run, does anyone have a second opinion that you guys might give? Please check the attachment
Title: Re: Dont Thread The BOX!
Post by: Gunner on December 14, 2011, 01:42:49 AM
in your FORMAT proc, you have a ret THEN call WriteScreenTitle, guess what... you won't reach WriteScreenTitle since the proc returns before that.

same thing in CURPOS you have a call AFTER the ret...  same thing in WINDESC and WriteScreenTitle and InitProc

fix those and you should be good to go

EDIT:
I missed...  You invoke MAKEWIN with parameters when it takes 2 parameters which is correct..  but on line 63, you call MAKEWIN without pushing 2 args onto the stack... that might/will give you problems.
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 14, 2011, 01:54:26 AM
Quote from: Gunner on December 14, 2011, 01:42:49 AM
in your FORMAT proc, you have a ret THEN call WriteScreenTitle, guess what... you won't reach WriteScreenTitle since the proc returns before that.

same thing in CURPOS you have a call AFTER the ret...  same thing in WINDESC and WriteScreenTitle and InitProc

fix those and you should be good to go

EDIT:
I missed...  You invoke MAKEWIN with parameters when it takes 2 parameters which is correct..  but on line 63, you call MAKEWIN without pushing 2 args onto the stack... that might/will give you problems.

I fixed it, yet the program still crashes. Perhaps it is the form I have them calling each other, that is getting the program to crash. I dont know yet, I still need reference. Behold the corrections....
Title: Re: Dont Thread The BOX!
Post by: Gunner on December 14, 2011, 02:00:09 AM
Have you tried stepping through your program in a debugger?

Still on line 63, you are not pushing 2 parameters on the stack when MAKEWIN expects 2 parameters so the stack pointer will be messed up.

On line 67 you do:
INVOKE MAKEWIN, 1, 3 which is correct

So line 63 should be like:
push    2 ; or whatever number you need
push    3 ; another number you need
CALL MAKEWIN
            
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 14, 2011, 02:05:31 AM
Quote from: Gunner on December 14, 2011, 02:00:09 AM
Have you tried stepping through your program in a debugger?

Still on line 63, you are not pushing 2 parameters on the stack when MAKEWIN expects 2 parameters so the stack pointer will be messed up.

On line 67 you do:
INVOKE MAKEWIN, 1, 3 which is correct

So line 63 should be like:
push    2 ; or whatever number you need
push    3 ; another number you need
CALL MAKEWIN
            


Could you explain that just a little bit? Because invoking it would mean the same way as pushing it. Or rather, they both mean the samething doesnt it?
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 14, 2011, 02:06:33 AM
By The Way, I made the changes and I still get the same effect, nothing but crash and burn.
Title: Re: Dont Thread The BOX!
Post by: Gunner on December 14, 2011, 02:08:52 AM
In one place you are invoking correctly with 2 parameters, MASM will assemble it to 2 pushes an a call

so when you do inovke MAKEWIN, 1, 3

MASM will assemble it to
push 3
push 1
call MAKEWIN

BUT on line 63 you only do call MAKEWIN WITHOUT pushing any paramters onto the stack so the stack pointer will be screwed up and probably the cause of your crash.
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 14, 2011, 02:11:35 AM
Quote from: Gunner on December 14, 2011, 02:08:52 AM
In one place you are invoking correctly with 2 parameters, MASM will assemble it to 2 pushes an a call

so when you do inovke MAKEWIN, 1, 3

MASM will assemble it to
push 3
push 1
call MAKEWIN

BUT on line 63 you only do call MAKEWIN WITHOUT pushing any paramters onto the stack so the stack pointer will be screwed up and probably the cause of your crash.


I understand now, but weither it is pushed into the stack, it will still crash.
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 14, 2011, 02:21:00 AM
Quote from: Gunner on December 14, 2011, 02:08:52 AM
In one place you are invoking correctly with 2 parameters, MASM will assemble it to 2 pushes an a call

so when you do inovke MAKEWIN, 1, 3

MASM will assemble it to
push 3
push 1
call MAKEWIN

BUT on line 63 you only do call MAKEWIN WITHOUT pushing any paramters onto the stack so the stack pointer will be screwed up and probably the cause of your crash.

I fixed it actually, now I get a box, the trick was to take OUT the CALL MAKEWIN because your right, i wasnt passing anything, so from there, I can play along a little bit further.
Title: Re: Dont Thread The BOX!
Post by: Gunner on December 14, 2011, 02:21:44 AM
Step through a debugger.  It is your best friend.

in CURPOS you are calling format WITHOUT pushing anything onto the stack when the FORMAT proc expects 1 argument.
Title: Re: Dont Thread The BOX!
Post by: Gunner on December 14, 2011, 02:22:44 AM
Yes, I found that out too by running the code through a debugger so I make a number bigger... but you should handle that in code to catch a small number.
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 14, 2011, 02:28:40 AM
Quote from: Gunner on December 14, 2011, 02:22:44 AM
Yes, I found that out too by running the code through a debugger so I make a number bigger... but you should handle that in code to catch a small number.

Yet CURPOS isnt supposed to push anything. The only purpose I have done in CURPOS is to just locate the cursor within the box.
Title: Re: Dont Thread The BOX!
Post by: Gunner on December 14, 2011, 02:32:52 AM
I meant to type FORMAT..  I was looking at the CURPOS proc on the other monitor when I was typing the reply
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 14, 2011, 02:37:59 AM
Quote from: Gunner on December 14, 2011, 02:32:52 AM
I meant to type FORMAT..  I was looking at the CURPOS proc on the other monitor when I was typing the reply

Still though, FORMAT's purpose is to put the window title there. Apperently I am still doing it wrong compared to my previous endavour. I got the box to work in an earlier example. with the color, and border. Yet now I feel as if i am forced to go back to the drawing board.
Title: Re: Dont Thread The BOX!
Post by: Gunner on December 14, 2011, 02:40:43 AM
FORMAT PROC szFmtName:DWORD
INVOKE WriteConsoleOutput, Handler1, szFmtName, DWORD PTR BufSize,
DWORD PTR Starter, OFFSET WINDESC
CALL WriteScreenTitle
RET
FORMAT ENDP

This expects 1 parameter on the stack, a pointer to a string.
CURPOS PROC
INVOKE GetConsoleCursorInfo, Handler1, ADDR Curs
MOV Curs.bVisible, TRUE
INVOKE SetConsoleCursorInfo, Handler1, ADDR Curs
CALL FORMAT ;<<<<<<<<<<<<<<<<<<<<<<<<<  LOOK your not pushing a pointer to a string, the stack pointer is messed up!
RET
CURPOS ENDP
Title: Re: Dont Thread The BOX!
Post by: StatusQuo on December 14, 2011, 07:44:18 PM
Quote from: Gunner on December 14, 2011, 02:40:43 AM
FORMAT PROC szFmtName:DWORD
INVOKE WriteConsoleOutput, Handler1, szFmtName, DWORD PTR BufSize,
DWORD PTR Starter, OFFSET WINDESC
CALL WriteScreenTitle
RET
FORMAT ENDP

This expects 1 parameter on the stack, a pointer to a string.
CURPOS PROC
INVOKE GetConsoleCursorInfo, Handler1, ADDR Curs
MOV Curs.bVisible, TRUE
INVOKE SetConsoleCursorInfo, Handler1, ADDR Curs
CALL FORMAT ;<<<<<<<<<<<<<<<<<<<<<<<<<  LOOK your not pushing a pointer to a string, the stack pointer is messed up!
RET
CURPOS ENDP


Okay I fixed it far enough that a box does appear for it. If it doesnt work for any of you, please let me know so that perhaps I can convince myself that my eyes arent playing tricks on me.