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?
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
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?
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
Like Sr dedndave have said:
http://www.masm32.com/board/index.php?topic=14734.0
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.
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...
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:
here - this is pretty easy :P
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
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.
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
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?
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.
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.
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.
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. :(
Well,...I suppose the suffering will eventually make you a great programmer.
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
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
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.
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
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.
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
...Wild Eyed Look,...
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
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
one thing that should not work....
END speedracer
the END directive should reference the entry point for EXE source files
END MAIN
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
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
Never mind i figured it out lol. This is the entire file.
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.
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
you are doing the pushes by hand, so, change lines like:
PUSH ADDR BTitle
to
PUSH offset BTitle
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.
i am doing some clean-up :P
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
You have got both 16 and 32 bit code, so it won't assemble correctly.
:eek
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)
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.
...
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....
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.
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.
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
...
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....
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
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...
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.
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
you have 3 different posts with attachments named TESTDRIVE4 - lol
no wonder we are having issues :P
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...
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.
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.
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.
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.
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.
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.
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.
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
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
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.
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.
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
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
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.
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....
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
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?
By The Way, I made the changes and I still get the same effect, nothing but crash and burn.
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.
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.
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.
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.
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.
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.
I meant to type FORMAT.. I was looking at the CURPOS proc on the other monitor when I was typing the reply
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.
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
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.