Re: HLA History

From: Herbert Kleebauer (klee_at_unibwm.de)
Date: 02/08/05 

Date: Tue, 08 Feb 2005 17:16:23 +0100

Betov wrote:
> Herbert Kleebauer <klee@unibwm.de> écrivait

> >> What you say here is 100% evident, but this is in no way
> >> any argument about why to choose a dead Operating System
> >> to learn Assembly.
> >
> > Do you really call Windows XP a dead operating system?
 
> You don't call XP API, you call DOS Interruptions that
> are emulated by XP. Anyway, this is not an argument,
> that i expected from you, as there is no reason for
> playing an intellectual game with this.

I'm not playing any game. Maybe you are right, DOS is obsolete
(but I had no problem to install DOS 6.2 on my new PC but wasn't
able to install WIN98 so I have to use XP instead), but the
API used in DOS is not obsolete, it is still a valid API in XP.
So I'm not writing code for an obsolete operating system (DOS)
but for the newest available Windows version (XP) using the int21
API.
 

> Where is a stupid Command Line better than a Mouse Click?
> At what point of view?

I'm not speaking of the program you write. A Windows program
which is used by average Windows users has to use a graphical
user interface or it will mostly be ignored. I'm speaking
of the tool to implement the program (editor, assembler,
compiler). And I think I'm not the only one who prefers
here a command line interface, supported by a script language.
It is more productive to have both hands on the keyboard
instead of using the mouse and click through many menus.

> > The size doesn't matter. But if I learn assembly programming,
> > then I want to understand any byte the generated executable
> > file because there should be nothing than my converted
> > source code. I don't like it when some library or startup
> > code is inserted which I don't know anything about. And
> > that's what makes the com file format so perfect for
> > starting assembly programming: nothing but the bytes of
> > your code.
>
> Then, you cannot make use of the DOS Interrupt, as well.

?????????

> side, ... How does a beginner understand the Org 0100h?

What is hard to understand that the program has to be
loaded into memory (from disk) before it can be executed.
And this program will be loaded at address 100h. Therefore
we see in the listing two numbers on the left side. The first
is the position of the byte in the executable file and the
second is the memory address of the byte when the program
is loaded into memory. I think any beginner will understand
this.

00000000: 00000100: b8 0900 move.w #$0900,r0 ; DOS
00000003: 00000103: ba 0109 move.w #text,r1 ; addr

> Why do you have several forms of headers in a the various
> DOS executable? Do you do the Linker job by hand why
> writing more than a DOS .COM file? and so on...

> There is, there, nothing but a difference of SCALE.
> Under DOS also, you have Headers, in the executables.
> They are just more complex in the PEs Format. Nothing
> new, at a theorical point of view.

If I would teach somebody assembly programming, then there
would be only one executable file format, the com format.
So this questions would never arise. When they are familiar
with assembly programming, other executable file formats
can be introduced.
 

> Well, if so, nothing makes it impossible to also view
> a PE with an Hexa Editor and/or Disassemble a PE with
> a PE Disassembler.

You can look at it, but you will see nothing. Look at
the 21 byte "Hello world" program and you will see
exactly (and only) the 21 bytes you also see in the
listing generated by the assembler. Then look in
your 1.5 kByte PE file and try to match it with the
listing generated by the assembler. This must be
very frustrating for a beginner.
 

> Nothing forces you to make use of complex API, under Win32,
> for learning the basics of Assembly, as i shown you here.

There is no non complex API in Win32.

 
> >> For an output of something, all a beginner needs is:
> >>
> >> > [Data: 'Hello World', 0]
> >> >
> >> > Main:
> >> >
> >> > push 0
> >> > push Data
> >> > push Data
> >> > push 0
> >> > call 'USER32.MessageBoxA'
> >> >
> >> > push 0
> >> > call 'KERNEL32.ExitProcess'
> >
> > And what's the difference to:
> >
> > program helloWorld;
> > #include( "stdlib.hhf" );
> > begin helloWorld;
> > stdout.put( "Hello, World of Assembly Language", nl );
> > end helloWorld;
>
> This is HLL. Period. No relationship with Assembly,
> at all...

Yes, and therefore you don't know what's going on behind the
"stdout.put". But your code is assembly code and the user
still doesn't know what happens when "call 'USER32.MessageBoxA'"
is executed (I don't mean the function of MessageBoxA but where
this code comes from).
 
 
 
> ???!!!... and how do you explain to a beginner what your
> call to INT 21 does? Why calling to 'USER32.MessageBoxA'
> should be bad, whereas call to INT 21 should be good???

You can explain this in a simplified way so even a beginner
understands this: An interrupt instruction interrupts the code
execution in the current user program and activates the
execution of code belonging to the operating system (in this
case the OS outputs text to the screen). After this is done,
the OS gives control back to the user program, executing
the instruction after the int instruction. If you want more
details, read the documentation about the int instruction in
the processor manual.

Now you have to explain the beginner what happens after a
call 'USER32.MessageBoxA'.

 
> This is an indirect call. What's the problem with this?

The problem is the address. Where is it stored and who
has it stored there. Was this done at compile time or
at run time? You have to explain all this to the assembly
beginner (not to me, I know it).

 
> > Who has written the code which
> > is stored at this address.
>
> The same Company who wrote your INT 21 thingie, i suppose.

But in my assembler source I never said, that I want to include
any code from this company. Was this code included by the
assembler and is it now stored together with my code in
the executable file. Or how else is it available at runtime
so I can call it and how do I know the address where it
is stored, so I can call it.

> > And why is there at all code in the address
> > space of my program which I have never written?
>
> ???!!!... Well, now, calling to a DLL is incompatible
> with Assembly... more and more novelties... :(

What the hell is a DLL? This is my first lesson in
assembly programming? Please explain!
 

> "Why is there at all code doing Interruptions? Who
> is the fucky ones who felt allowed to "Interrupt"
> my Application???!!!"... :)) :)) :))

What happens when an int instruction is executed is
explained in the processor manual, but you will find
nothing there about DLL's and switching to kernel mode
using an indirect call.
 

> > Is it generated by the
> > assembler (a hidden #include( "stdlib.hhf" ) as in the HLA code)? And
> > how can this code at the address 'USER32.MessageBoxA' output text to
> > the screen? If this are also just processor instructions, why can't I
> > write this instructions myself in the program? Is it this code which
> > makes the exe file so big (1.5 kbyte for 5 push and 2 call
> > instructions)?
>
> I think i can say, that, at least, with RosAsm, the difference
> is made quite evident, by the different notation, saying that
> a DLL Function call is in the 'Text.Form'.

You have to explain to a beginner HOW it works and not only
what he has to do that it works.
 

> > Many questions, and I would ask any of them if I would be in an
> > assembly course and would have been given the above code. Now please
> > answer me all this questions and don't forget, I'm student in an
> > assembly course and the above program was the first assembler program
> > I have ever seen.
>
> Well i would answer exactely the same as you would do to
> a beginner asking you what is "INT" XX: This is an OS
> Function, that you simply call and that does what it is
> supposed to do, if you did not do any error. Use it and
> don't ask. Period. As simple as this, as well for API
> calls. Where could be any significative difference?

That's not the answer to the question. You have to explain
why I can make an indirect call to an address (which I don't
even know) and why this code can set pixels on the screen
and why CPU instruction I write in my code can not set
pixels on the screen (why can't I use the same code in
my own program?).

 

> any Tool, will always have ___3___ things to learn:

> * The Functions of the OS he is runing under.

And you have to explain how the function in the OS
is activated. In the case of the int instruction
this is trivial, because this is part or the instruction
itself, but an indirect call is just a call and can't
activate the OS.