So I was in assembly class today writing some code. Let me start by describing the process I go through at the beginning of each class.
1) Turn on computer, plug in USB stick.
2) Wait.
3) Wait.
4) Wait.
5) Log in.
6) Wait.
7) Wait.
8) Wait.
9) Merge registry file to restore the settings for Textpad so it will actually work and not pop up nag boxes.
10) Turn on line numbers again, hoping it'll work this time. It doesn't.
11) Begin coding for an assembler that has to be at least 10 years old.

In class we talk about how things work in "real mode" back in the days of DOS, how you'd write to specific memory ranges to display things and read from some register to access the keyboard... you'd expect, then, we'd use a DOS emulator, but no. The programs run directly on Windows 7, using some third-party library to do most of the work.

The assembler is just the most retarded thing you've ever seen. Some fun details:
You define a string like:
mystring BYTE "this is a string lala",
" more text...", 0
you cannot, however, do this:
mystring BYTE
"this is the first of",
"several lines",0
nor this:
mystring BYTE "",
"here's another long string", 0
the string has to begin on the same line as the name and cannot contain any empty strings, thus throwing any alignment of multi-line strings out the window. There's also an unspecified maximum string length, even though you just leave the null off the end and do
mystring BYTE "some long string... "
mystring2 BYTE "that continues here...", 0

If you want to declare an array?
myarray BYTE 10 DUP(5)
hell, I don't even remember whether this does 10 bytes with value 5 or 5 with value 10.

Hex values end with 'h' and can't start with a letter. So 99h is fine, 0A1h is fine, A1h is not.

Procedure declarations blatantly violate the DRY principle and are also just syntactically backward and inconsistent:
myproc PROC
...some code...
myproc ENDP
END myproc

The entire system runs with a series of batch files that call more batch files that generate temporary batch files in your working directory and don't delete them when finished.


Now, my two favourite issues I've found so far were both found today. The assignment was to take a simple program like:
main PROC
...some code...
main ENDP
END main
and add some more procedures to it. So I add a couple and suddenly, my program isn't doing anything. It assembles without error, but just exits without doing anything. I strip it down to just:
myproc PROC
ret
myproc ENDP
END myproc

main PROC
...some code that just prints a string and exits...
main ENDP
END main
and still, it does nothing.

About this time, the professor just so happens to explain:

---

Oh by the way, don't copy the "END main" line to your other procedures. That tells it to ignore the remainder of the file.

---

So... we not only have to tell it where the end of the file is and which function is the entry point... but it doesn't even give a warning if this is done more than once.

I literally stood up, walked to the front of the room, bashed my head into the wall, and sat back down.

So after more coding, I found that once again, my program stopped doing anything. In fact, some variables were getting corrupted. I had a routine that was simply:

get_screen_size PROC
push dx
call GetMaxXY
mov ysize, dh
mov xsize, dl
pop dx
ret
get_screen_size ENDP

GetMaxXY worked fine, but the variables somehow ended up being zero. I found that this problem disappeared if I removed the push and pop surrounding the routine. So I added another call immediately after to dump the register state to see what the heck it was doing.

The program aborted without doing anything.

I got the prof to check it out and he too couldn't see what could possibly be wrong, and we fiddled around for a while until we finally discovered the problem.

The assembler doesn't assemble "pop dx" correctly. It corrupts the stack any time you try to pop a 16-bit value. Somehow, this bug hadn't been noticed before.



You'll never guess who wrote this assembler...


Microsoft.

____________________