Re: Segmentation in real mode

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 03/13/05 

Date: Sun, 13 Mar 2005 12:47:40 GMT

Rene wrote:
> Tom wrote:
> >> I agree. You'll find some people feel that you shouldn't
> >> "waste" any time at all learning dos. I'd agree that it
> >> isn't worthwhile learning "dos", per se, in any depth, but I
> >> agree with you that it's "simpler" to interface with dos
> >> than with Windows or Linux. Linux has an "int 80h" interface
> >> - similar to the dos "int 21h" interface, but Windows
> >> requires calling a "Dynamically Linked Library". Easy enough
> >> to *do*, but harder to understand what you're *doing* (IMO).
> >
> > Yes, thank you. I know, I agree.
>
> ... and this is all of the sad problem: You agrea
> with something that is utterly wrong and completely
> absurd. Simply, as DOS is evidently "simpler", at a
> technology point of view, you fall easily into the
> illusion that it should be easier to program and easier
> to understand. This is wrong and the reverse is true.
>
> There is absolutely nothing different between calling
> a DOS interruption, that is a Black Box, doing some
> operation, and calling a Win32 Api, that is also a Black
> Box, doing some operation. Whatever you _call_ for, be it
> an INT or an API, black is black. DOS INTs are, in no
> way lesser black than black.

Essentially, you're correct...

Except that Windows does have its "prohibition" on "direct hardware
access"...and writing Windows "device drivers" _ISN'T_ easier than DOS
programming...so, with Windows, there can be a "hole" in your assembly
education regarding "accessing hardware directly"...oh, granted, with
"device drivers" and modern OSes, you don't particularly need to be a great
expert on this anymore...but, from an "educational" point-of-view, Windows
is, if you like, "prohibiting" a part of a fully rounded assembly language
education...there is much to be learnt in general from "direct access"...if
assembly language is "talking to the CPU", then "direct access" is learning
how to get the CPU to talk to the rest of the system...there's much that
can be learnt about "the machine" in this way because, after all, the CPU
isn't solely the only component that makes up "the machine"...

Nevertheless, what you're saying about 32-bit programming is still
correct...simply use _LINUX_ (which allows "direct access" by asking for
"permissions" to do so, as "root" user :) in order to do it...also, a
UNIX-based education actually has a wider applicability across many OSes
(including Windows...where you think Windows got its "stdin" / "stdout"
streams stuff from? ;)...than a Windows education, which, in many ways, is
often solely applicable to Windows only...though, admittedly, where UNIX
may have the "wider applicability", Windows has the "sheer weight of
numbers" on its side, as the most used x86 OS (actually, most used OS, full
stop)...

Linux is often ignored in this context but it's actually arguably the best
"compromise"...it has a simple interface (very much like DOS's interface,
in fact...you call "INT 80h" rather than "INT 21h", basically :)...it has
the simple "32-bit flat mode" addressing, though...it also has "device
drivers", proper "multi-tasking" and "multi-user" capabilities (so you can
learn about "concurrent programming" and get a taste for the "device driver
model")...but, at the same time, as "root", you can still get "permissions"
to access I/O devices directly too (such as Frank's fun little "PC speaker"
program that plays what I think is supposed to be Mike Oldfield's "Blue
Peter" - that whole "yo-ho-ho and a bottle of rum" sea shanty "stylee" -
but, well, sounded a little out-of-tune that I couldn't be completely
sure...I checked the values for the frequencies, though, Frank, and those
seem right for standard "just tuning", so, is it a "timing" problem? Would
it be "safe" to hook up the other timer to control the timing properly? Or
is Linux using that itself for "task switching" and you'd cause an almighty
crash? Ah, the problem of "direct access" under any "multi-tasking system":
You can't be sure you're the sole program "accessing" the device at the
same time and if two programs ask it to do two completely different things
then, well, a complete "roll of the dice" what'll result...probably a crash
or something ;)...

So, it has all the various "features" to make a very good "learning"
environment...

The problem? No-one's really written too much about it...a lack of
"tutorials" and easily understood "information" about what to do...at
least, in "useful form" for the beginner...

The _environment_ itself is actually potentially very good for learning
because it's very "DOS-like" but _WITHOUT_ the ugly "real-mode
addressing"...but, well, UNIX has a "C connection" and, thus, lots of
"bias" in that most information ("man pages" and such) are all based on how
it's done in C...not a problem for people who already know assembly to
"translate" but not particularly useful for "beginners"...

Also, most "distros" come with a whole array of useful programming tools
"out of the box" too...GCC's always there...which is "handy" for
"borrowing" its "LD" linker to "link" up your assembly program, even if
you're not using C / C++...and all the great "UNIX tools" like "GREP"
(searches for strings in a bunch of files...so, you know, if you're
wondering where some "symbol" is defined in a "header file" somewhere, set
GREP on the files and let it do all the "looking" for you :)...and "MAKE"
(helps maintain multi-file projects by only compiling what needs to be
compiled when you make changes, based on the "time stamp" of the files
:)...and so forth...

Linux's problem is actually "lack of support" (LuxAsm will Hopefully change
that, of course :)...but, you know, there's GAS but that's the GCC
compiler's "back end" and not particularly "friendly" or well-documented
(with odd "AT&T syntax")...then there's NASM but, as great as NASM is, it's
a "portable assembler", so, you know, it's not really got anything
"specific to Linux" in that sense (but with a good NASM-based Linux
tutorial, this would be the "best so far" :)...HLA works on Linux too, of
course...but, again, it's not "specific" to Linux...kind of the point with
the HLA / AoA is that it concentrates on the _assembly language_ and leaves
the "OS specific" parts out of it...and, though Randy has written a
"Windows programming with HLA" tutorial book, there is no comparable one
for Linux, as far as I know, at the moment (for Linux, there's a "how to
write device drivers" tutorial...which is great...but this is not the
"beginner" level...in time, Randy will probably close this "gap" in his
tutorials but, at the moment, there's nothing "beginner level" which
focuses on "Linux programming in HLA" or anything...well, there wasn't last
time I looked on Webster for that kind of thing, anyway :)...

Windows is more popular so, naturally enough, all the stuff tends to be on
Windows...for instance, MASM32 has "Windows headers", RosAsm has "Windows
equates" (RosAsm's version of "header files"...serves the same purpose but
is "built-in" :) and so forth...and these kinds of files are very handy for
beginners, as they define all the various types, constants, API and such
that you can access in an "assembly form"...you know, when something is
"more popular" then all the "tutorials" and things "gravitate" towards
it...

Another nice facet of Linux is that the GUI is _separated_ (and, in my
opinion, of a superior design)...so, with Windows, you've usually got to
"jump in" with "event-driven" programming and windows and things...and
that's a whole new subject in itself...but you can comfortably "graduate"
in Linux because the distinction between "kernel" and "GUI" is
_clear_...but it's all mixed up together in Windows...

Linux would be _very good_ as a learning environment, _IF_ only there was
comparable "support" for assembly coding on the OS...but, unfortunately,
though it's not completely absent, it isn't of the quantity of what you
find for DOS or Windows...it's still not really an appropriate "beginner"
environment in terms of "header files", "documentation", etc., etc....if
you like, there's lots of "unused potential" there, which isn't really bein
g "exploited" for learning assembly language as it could be...Hopefully, in
time, the situation will become different - as playing around with Linux is
becoming more popular - that we can stop talking about "potential" and
start pointing out how useful it _actually_ is for "learning
assembly"...me, NoDot, Frank and C are currently "working on it" in that
regard :)...

But, as a little "demonstration":

-------------------------------------

; Example.asm
;
; assemble:
; nasm -f elf -o example.o example.asm
; link:
; ld -s -o example example.o
; run:
; ./example
;
            ; make entry-point "global" so linker can see it
            ;
            global _start

            ; data section
            ;
            section .data

     String db "Hello, world!", 0Ah

            ; code section
            ;
            section .text

    _start:
            ; write string to stdout
            ;
            mov eax, 4 ; function (sys_write)
            mov ebx, 1 ; stdout
            mov ecx, String ; address of string
            mov edx, 14 ; number of characters
            int 80h ; make Linux system call

            ; exit program
            ;
            mov eax, 1 ; function (sys_exit)
            xor ebx, ebx ; exit code
            int 80h ; make Linux system call

-------------------------------------

All very simple stuff, in fact...

Very similar to the DOS "Hello, world!" but that this is true 32-bit
programming (no messing around with "segments" or 640KB "limits" ;)...that
Linux uses "int 80h" rather than "int 21h" (different functions provided
than DOS, obviously, too :)...none of that silly "$" sign stuff to end the
strings (you pass it the number of characters as part of the function call,
so it doesn't actually need a "terminator" at all...very good practice to
not create accidental "buffer overflow" bugs too...Microsoft should pay
attention! ;)...

Beth :)