Re: RosAsm is a broken pile of crap


f0dder wrote:
> "Betov" <betov@xxxxxxx> wrote:

>
> > Libraries are _NOT_ a Code Reuse Method. Libs are
> > a Compilation-Speed-Up trick coming from the old
> > days when the Compile-Times were a serious problem,
> > and absolutely nothing else.
> >
> Well, that's a subjective opinion. What code-reuse strategy
> is best depends on the individual - the flexibility to choose
> is always a good thing.

And the thing that Rene continues to ignore is that everything that
RosAsm can do with "cut & paste" can be done by every other assembler,
too. All he is doing by not supporting statically linked libraries is
cheating his users out of a choice.


> I like to keep common code in a
> centralized location, so I can easily refer to it from several
> independant projects - that's easy code reuse for me. Of course
> an "include" statement could do the trick as well, but having
> to resort to copy/paste is a big no-no - it's too much of a
> hassle to update multiple projects when the re-usable code
> is updated.

But you're talking about software engineering here. Rene doesn't have a
clue about software engineering. He *has* in the past, gone on tirades
about how software engineers don't have a clue what they're talking
about (which, in general, may be true -- but he was blasting
well-established principles, such as library usage, readability
metrics, etc.).


>
> Even turbo pascal supported libraries (in the form of .tpu
> units - a much nicer format btw), and there certainly wasn't
> speed problems with TP, even on old 80286 hardware. It had
> this pretty cute trick of compiling to memory rather than
> disk, which worked very well.

Actually, that's one of the big reasons RosAsm is fast - it compiles
from memory. There *is* a speed advantage to not having to open up all
the files for linking and what-not. But on a modern machine, we're
talking, like, half a second for a decent sized project.



>
> > Either the Lib is open source and free reuse. In
> > that case, there is no reason for a RosAsm to link
> > to a Lib, as he holds the Source. Period.

Rene, you're not considering the fact that that source isn't in a
RosAsm format. Suppose it's in C? Then what? Other assemblers can link
against the object code. Your poor RosAsm users are going to have to
convert it to RosAsm (which would actually be less work that trying to
clean up after your disassembler).


> >
> Consider a not-so-small library written in another language.
> To use it in RosAsm, you'd have to convert it all to assembly.
> It would take a while to convert something like zlib or libjpeg
> to assembly :)

Yeah. See the above. :-)

>
> > Or the Lib is Closed Source. In that case he just
> > has to put it in the Trash Bin.

And wind up reinventing a lot of code that could have been used as-is.
Rene, this comment makes you the "poster child" for 'what's wrong with
assembly.' One of the top five complaints the HLL crowd has against
assembly is the fact that assembly programmers are constantly
reinventing the wheel. You're not going to attract too many HLL
programmers into your "assembly rebirth" by insisting that they rewrite
all that library code that already exists.


> >
> Unfortunately, you don't always have that option, if you have
> to code for a living.

Money? Why that would be inethical according to Rene! It all has to be
free, free, free!

> Besides that, there are useful closed
> source libraries around.

Hear, hear!

> And finally, keep in mind that there
> might be RosAsm users that don't care that much about GPL or
> whatever (at least do consider it if you want more users :-)).

I doubt it. Rene would scare them off with his political nonsense. He's
already scared off several people interested in RosAsm by being
critical of their views concerning issues like the GPL.

Here's the paradox: Rene would love to have more users (his jealousy
concerning certain other products is *way* too obvious), but he simply
doesn't have the social skills to apply to the task. I really feel
sorry for the other RosAsmites (especially the contributors) who really
would like to see the RosAsm user base grow, but have watched Rene
destroy their hopes. They must cringe every time he posts something
around here.


>
> > we are implementing a "Lib Scanner", that is, simply a Libs
> > Disassembler, that will recover the Libs contents, so that
> > the Programmer could re-use the lost Code directly in his
> > Application.
> >
> Hm. Even if we disregard things like "the halting problem",
> writing a 'perfect' disassembler is going to be very hard.

We've been through this before with him. At least he no longer claims
that a perfect disassembler can be written. That's some major progress
(though I think that Wolfgang still thinks that a perfect disassembler
can be written).


> I've played a (tiny) bit with it myself, and getting xrefs,
> code/data and relocation detection right is... argh. At least
> if you plan on supporting anything but the really trivial.
> (Of course .lib will be a bit easier, since you have both
> relocs and symbol names).

Even if the disassembler *were* perfect. The whole point of source code
is to have something that can easily be studied and modified. If you
never plan on modifying it or looking at it, object code (closed,
whatever) is perfectly fine. If you do plan on looking at it, figuring
out how it works, and modifying it, disassembled code is the *last*
thing you want to deal with. Reverse engineering code to the point it
is maintainable is a real pain in the behind.

About the *only* way Rene's disassembler would be useful is if you
*had* the source code to the library so you could add the comments,
labels, symbolic names, etc., back to the source code after conversion.
But I suspect it would just be easier to hand translate the source code
in the first place. And all that's assuming that the disassembler is
perfect. Of course, it never will be and it's *far* from ready for
prime time now (indeed, it appears as though work on it is at a
standstill right now; maybe support for it is dying off, who knows?).


>
> > There is no other Assembly way, for this "problem", as an
> > Assembly Programmer CANNOT call for a Lib. If he could do
> > so, he would have better using... PowerBasic.
> >
> But you can still call OS services - how much different is
> this from calling a library, really?

And that's the real paradox. It's okay for RosAsm to call *dynamically*
linked libraries, but it is not okay to call statically linked
libraries. Rene has *never* explained that one satisfactorily.

Of course, the real reason RosAsm doesn't support statically linked
libraries is because his "bury the source code in the EXE file" design
makes this *very* difficult to do. As is the case for many of the
RosAsm design decisions, this one really seems to be based more on
Rene's programming capabilities (or lack thereof) rather than on any
real technical point. As usual, he defends his lack of competence in
these areas by falling back on the good old line "that's incompatible
with assembly language." Strange, none of the other assembler authors
seem to feel that way.

Cheers,
Randy Hyde

.

Relevant Pages

  • Static Linking in RosAsm
    ... > by libraries which have private variable lables, ... assembler produces creates some problems here. ... Understood that the goal is not to add a linker to RosAsm. ... programmers know C/C++. ...
    (alt.lang.asm)
  • 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: The Lib debate
    ... >> Since Master Pdf discovered that RosAsm does not assume Static ... >> Libraries, it has become a no end thread argument for discrediting ... disassemblers, wizards, and all these other tools while your assembler ...
    (alt.lang.asm)
  • Re: Stack frames
    ... in order to save from no end Compilation ... Fast assemblers (RosAsm included) work great ... libraries, as it is practically impossible to do a large ... the only assembler anyone is trying to push as a serious ...
    (alt.lang.asm)
  • Re: Win32 help
    ... > is no CPU instruction. ... > an executable program from this source code. ... just about any assembler that supports linking. ... libraries. ...
    (alt.lang.asm)