Re: Iczelion's tutorials revisited.


JGCASEY wrote:

> > Many of them, yes... but you said that you _had_
> > that knowledge...
>
> Only the old syntax without the .Else_If stuff I
> see in your source code.

This is the really funny part about RosAsm. Rene constantly gripes
about the HLL-like statements in MASM, TASM, and HLA, and then sticks
all these macros into his source code to simulate them all. He somehow
believes that because he's used macros rather than building them into
the assembler that this somehow means something different to the end
user. I keep telling him that if someone is opposed to "IFs" and
"WHILEs" in assembly language, they'll be opposed to them regardless of
their implementation.

Thank you for demonstrating this point.


> Then there is the strange
> looking macros.

And the syntax in general. For some reason Rene likes to claim that
RosAsm's syntax is "Intel Syntax". It has been pointed out to him over
and over again that his syntax isn't even close. And the way typical
Rosasm source files are written, the code often looks like an explosion
in an alphabet soup factory. Here is some of Wolfgang's code from his
Kesys program, for example (and don't think this is just Wolfgang's
problem, most RosAsm source code is formatted this way):

MainWindowProc: ;esp+00=ret +04=hdl +08=msg +0c=wP +10=lP
pushad
; mov edx D$esp+024 ;hdl
mov eax D$esp+028 ;msg
mov ebx D$esp+02c ;wP
; mov ecx D$esp+030c ;lP
cmp eax &WM_CHAR |jnz L7>>
mov al bl
cmp al 30h |jc L5> |cmp al 3Ah |jc L0>
and al 5fh |cmp al 'X' |jz L4>
cmp al 41h |jc L5> |cmp al 47h |jnc L5>
L0: sub al 30h |cmp al 0ah |db 072 02 |sub al,07 |shl D$INPval 4 |or
B$INPval al |mov b$keyflag+1 al
mov ebx Kname00 |mov eax D$Kindex |mov cl B$KsizeE2 |shl eax cl
|add ebx eax
mov eax D$INPval |mov D$ebx+010 eax
L3: call repaint |cmp D$INPptr 9 |jc L9>>
xor eax eax |mov D$INPptr eax |mov D$INPval eax| jmp L9>>
L4: xor b$keyflag 080h |jmp L9>


Quite honestly, it looks like code written by a BASIC programmer back
in the days when people discovered that BASIC programs ran a little
faster when you crammed as many statements on one line as you could.
There is *one* thing you can say about Wolfgang's (versus Rene's) code,
however. He doesn't use macros (including all the HLL-like statements).

> Very little looks like the DOS
> code I used.

This is why it's good to learn and use a standard set of library
routines. When you move from OS to OS (as you've done from DOS to
Windows), you can port your library routines to the new OS and the code
will look just as it did before. If you're really good about how you
maintain your library, you can even port your code from OS to OS. The
HLA Standard Library, for example, is portable between Linux and
Windows, requiring only a recompile to get an application running under
either OS.

> But anyway the tutorials need to deal
> with an absolute beginner so a working knowledge
> of the assembler syntax is needed. This is best
> done, in my opinion, by introducing them in stages
> as needed to understand a particular program.

Writing a decent set of tutorials that take beginners from point zero
to experienced assembly programmer takes a lot of work and experience.
Some people (like Rene) seem to think that there is no work involved in
this process. Nothing could be farther from the truth. Generally, the
first thing that comes to mind when someone sets off to write a
tutorial really doesn't work for most people who read the tutorial.
Believe me, I've tried a lot of different teaching methods over the
years (and incorporated what I've learned into books like AoA and the
materials I've written for Webster). It takes a lot of "trial and
error" to fine tune pedagogical material so that it works for a lot of
people. And no single tutorial or book is going to work for everyone.
For example, you've alluded to the fact that you like things as concise
as possible. The majority of people, however, don't like curt
tutorials. They want friendly and approachable explainations. You can't
write a tutorial that is going to satisfy both types of people.

>
> That appears to cover it. For an absolute beginner
> you would have to cover binary numbers perhaps?
>

Actually, there is the whole subject of machine organization that needs
to be covered. Indeed, "machine organization" is what people are
*really* expected to learn when they take an assembly language course
at the local college or university. Binary numbers (actually, data
representation) is certain a part of this, but there is quite a bit
more (such as logic, basic computer architecture/organization, basic
I/O, and stuff like that).

>
> Do you mean those funny little pop up window thingies
> IVTOOOBeginner_1? It would be nice to be able to
> print them out. I do like hardcopy. From your IDE
> Help menu I chose IVTOOOBeginner_1.exe to be greeted
> with a source file I couldn't read. Nothing like the
> DOS code? Except for the occasional move eax &FALSE.
> I assume & means address?

As I've said earlier, most RosAsm code looks like an explosion in an
alphabet soup factory to me. And people like Wolfgang constantly
complain that I tend to suggest that beginners concentrate on writing
readable/understandable code rather than the tightest or most efficient
code. Most of the RosAsm sample code I've seen (including Wolfgang's
own Kesys program) amply demonstrate why it's important to write
readable, understandable code. Especially when you're including that
code as part of a "tutorial".

Herein lies a major problem with the RosAsm tutorials I've looked at.
They were written by people who've mastered (?) some subject, for their
peers. The RosAsm team stands around and pats themselves on the backs
because they've written all these "megas of tutorials" but they've
never really tried them out on a large number of people to determine if
they are practical or if they achieve what they are intended to
achieve. To my knowledge, no one on the RosAsm team has any experience
teaching a formal assembly language class. So they really have no idea
what beginning assembly language programmers want or need. They just
crank out this code and assume that it satisfies some need. Oh well,
more power to them I suppose. Somebody *may* benefit from the work, and
that's what really counts. But I suspect that most people are like you.
They view these things and think "Okay, this is a nice demo, but it
doesn't really teach me much."


>
>
> > It seems that, dispiting the impressive time i and
> > James spent at writing these Tutorials, we have missed
> > our goal, at least for you, but i still don't know,
> > exactly, why and how...
>
>
> Maybe it's the IQ thing :)

If you read through Rene's posts here on ALA, you will see him
constantly criticizing my work as being "no work at all" or "simple
rephrasing of others' work", etc., etc., etc. The RosAsm team has yet
to figure out that writing good books, example code, tutorials, and
tools that operate in a synergistic fashion to help beginners learn the
material as rapidly and efficiently as possible isn't simply cranking
out some demo code and some poorly written and organized documentation.
It is a lot of work. Any tutorial that makes someone feel stupid, as
Rene puts it, "misses the goal."

>
> Perhaps DOS is for dummies so I found it easy to
> learn from a couple of assembler books? A low
> level OS for a low level brain :)

There is no reason the same books couldn't be written for Win32. It's
not really "DOS vs. Windows" but rather "console apps vs. GUI apps."
And you can write console apps in true WIN32 all the time. It's really
easy. Particularly if you have a set of library routines like the HLA
Standard Library. You don't have to get lost opening windows and doing
all that GUI stuff when you're first learning Win32 APIs. You can write
good old console apps, that are easy to comprehend. And then when you
get up to speed on assembly, you can look at the Iczelion tutorials and
other Win32 GUI sample code that teaches you how to write GUI apps.
The problem you seem to be having is trying to learn too much at once.
Concentrate on one thing at a time. Start with the x86 instruction set
writing some console apps. *THEN* move on to the more complex Win32
APIs. I think you'll find this a more comfortable approach.

BTW, both HLA and MASM32 provide good support for console applications
in their libraries.


>
> I have just been looking at your RosAsm. I didn't
> realise you had a Wizard there to create a form
> template. I assume you than just add in code like
> you do for VB? Indeed you seem to have a lot of
> useful programming aids but I am not sure how i
> would use them.

The wizard is like the disassembler. More promise than reality at this
point. Rene is promising us that someday RosAsm will be like VB or
Delphi allowing you to create complex apps with just a few mouse
clicks. But we've been hearing this for years now (since about 2000),
so I wouldn't hold my breath if I were you. RadAsm, btw, has similar
capabilities.


>
> There are issues like, you have the means to load
> resources but I am not sure how you integrate this
> into a program. Things like an image, for example,
> in DOS the program would load it as a file into
> some allocated memory location. I would have my
> own display routines.

Well, you can still do it like you've done it in DOS (reading files).
Windows has APIs for embedded resources into the EXE file as well. But
that's some of the more advanced APIs that I'd recommend you put off
learning about until you get a little more comfortable with the basic
x86 assembly stuff. Again, writing console apps will allow you to do
things the way you did it under DOS, without the information overload
of having to learn all these different APIs all at once. Later on, you
can learn about resource compilers and how to link in those resources
with your application files. And, btw, don't forget that RosAsm doesn't
support static linking, a problem when using resources from different
sources, IIRC.

>
> To test a tutorial I guess you need to sit a
> complete beginner down and see where/if they
> are not sure what to do next or cannot follow
> the explanation.

Yes, that's a large part of it. And I'm sure this process never
occurred to the RosAsm team with respect to their tutorials. They have
a long and storied history of ignoring what the marketplace really
wants and taking it upon themselves to dictate what the market *ought*
to want. They seem to be more interested in filling in bullets on a
feature matrix and having as many bullets as possible rather than
ensuring that the quality of those features is as high as possible.
"You wrote a tutorial? Great, mark an "X" in that part of the feature
matrix and let's move on to something else..."


>
> Thank you for your efforts in trying to work out
> my issues. I am not sure what to do about them.

Well, I'd stick with MASM and MASM32 if I were you. That seems to be
the approach best suited for you. On the MASMForum, ask the people
about standard in/out and console routines. I think you'll find that
once you learn a few things, writing console apps will be as easy as
writing DOS programs. Of course, HLA also makes writing console apps
trivial, and best of all, they are portable to Linux should you decide
to mess around with that OS.
Cheers,
Randy Hyde

.

Relevant Pages

  • Re: When to use Rosasm, when to use Masm?
    ... > One person's bloat is another man's essential features... ... coded they are...for example, with better macros and assembler features, ... source code" as anything but the roughest of rough measures because it's ... >> to pretend there's more code in RosAsm than there really is, ...
    (alt.lang.asm)
  • Re: RosAsm is a broken pile of crap
    ... RosAsm can do with "cut & paste" can be done by every other assembler, ... All he is doing by not supporting statically linked libraries is ... *had* the source code to the library so you could add the comments, ...
    (alt.lang.asm)
  • Re: Why I stop attacking HLA
    ... ||Betov did in fact provide a decent alternative to Webster and HLA. ... RosAsm _supports_ windows interface guidelines, ... || About tutorials, Betov's own are not the ... as they would have done for any other assembler - no ...
    (alt.lang.asm)
  • A brief timeline
    ... Source code is source code and if the assembler is technically sound, it will build test pieces and benchmarks correctly and sad to say RosAsm does not. ... show in the MASM forum over a year ago. ...
    (alt.lang.asm)
  • Re: Will HLA2.0 Support rosasm?
    ... little macro facilities you do provide. ... >> And RosAsm doesn't support structures. ... > is that i recommand to any Assembler Author to take a serious ... source code and make decisions about the quality of your ...
    (alt.lang.asm)