Re: Release of RosAsm V.2.025a

On Mon, 19 Sep 2005 23:36:03 -0400, Guga <mauroteste@[EMAIL PROTECTED]
> wrote:

> About the single (Unique) source, this is not a problem. In fact, it
> helps to you assemble your source when you don´t have the other(s)
> external file(s).

Well, if I lose some of my source, then I certainly don't expect to be  
able to assemble the code.  I also wouldn't expect to be able to assemble 

RosAsm code if half of the file turned up missing.

> It is usual (common) when you try to assemble your file, sometimes you
> get an error message from your assembler (example: masm) saying that it
> is missing one of the include files (.inc, .asm, or .lib etc).

I've never had that happen.  I never include files that I don't have.

> On masm board or win32 asm board for example, many times when i was
> trying to assemble a project i couldn´t be able to assemble a given
> source, because the file that were uploaded did not contained one (or
> more) of the necessary files to be used.

Well, that's a problem with the person not having given you the entire  
source then.  If I gave you half a RosAsm source, then you wouldn't be  
able to assemble that either.

Granted, it's typical for some people to just assume that your system has 

the same files that theirs does, some programmers do that all of the time 

with DLL files, like VBRUN45.DLL or whatever it was.

I don't see the logic in enforcing restrictions on yourself as a way of  
dealing with other people's mistakes.

> If your project have few multiple files..let´s say 02, 3, 5 ...this
> problem _tend_ to don´t happen that offten (but it surelly happens) ,
> but when you have dozens or hundreds of different sources to be
> "included" it is easy to happen those kind of errors.

Then you need a better tracking system for your files.

Besides, if you want to eliminate that problem by combining all of those  
files into one, that's always an option, but it shouldn't be a
requirement.

> So, multiple files are not the proper answer for everything. This is
> the major disadvantage of having multiple files.

The major disadvantage of allowing multiple files is that you don't  
believe they are the proper answer for everything?  What about the things 

for which you do believe they are the proper answer?  What about the  
things for which other people believe they are a proper answer?

Hell, what about making software that serves the user instead of yourself?

It's fine if you want to make your program not sup****t multiple files,  
it's your program and you can make it do whatever you want.  However, to  
claim that it's a universally beneficial feature is just a lie.  It may  
help you, since you don't want to use multiple files, and you don't want  
other people to be able to use them either, but it certainly does nothing 

to help someone who does want to use multiple files.

> In RosAsm if your source gets big, or if you want to organize the
> functions on your code, all you need to do is "split" your code
> internally.

I really wish I could find a text editor (for a linux console) that  
sup****ted that feature.  It was great to have in QuickBASIC, it made  
dealing with large sources very easy.  However, it's no substitute for  
multiple sources.  Even in QuickBASIC I used multiple sources
occasionally.

> a) When you think in library files that can be linked to your
> application you get the risk of restrict the capabilities of your own
> program.

Even so, shouldn't it still be my choice?

> We all know that a library file is fixed.

Not if it's my library.

> So far, the object code cannot be, in general,  modifiable.

Short of a recompile.

> If you build your library files (.obj or .lib) on C or C++, and wants
> to link it with an common assembler, this is not - generally speaking -
> a good idea. This is not a good way to go, because when you are dealing
> with those object files produced by a C/C++ compiler you don´t have
> access to the internal data, i mean, you can´t modify the code as
> needed (if it is needed). So if, for some reason the library file is
> bloated, you will  disseminate bloated code all over the other apps
> from whom you were linking your object file.

Again, it should be my choice to do that if I so desire.

If a library isn't working out for me, wether it's because I don't like  
the size of it's code or some other reason, I'm always free to simply not 

use the library.  Libraries don't have to be unsup****ted for me to be able
 
to decide that I don't want to use one.

> It get worst when you don´t have the C or C++ source...imagine that
> you got the object file from a friend, or somehow you don´t have the
> source code. All you have is the object file.

In that case I wouldn't using the library unless I didn't have any other  
choice.

> Again, if the obj file have bloated code, you are doomed to use it as
> it is, like it or not.

However, all that a 'you can't link to external code' feature does to help
 
me out with this problem is make it so that I can't write a program that  
uses that object code at all.  At least without the 'you can't link to  
external code' feature I could write a bloated program that used that  
object code.  A bloated program is much better than no program at all.

I also assume that you're overestimating when you talk about bloated.   
Most assembly programmers tend to consider anything larger than a few  
kilobytes to be bloated.  No consideration is ever made for what the code 

does, and in fact features such as comprehensive error messages and error 

checking in general are frequently left out of assembly programs because  
those things cause bloat.
There's a similar deal with code execution time, anything that takes  
longer than half the time an equivelant C program takes is slow.  So by  
definition, all C programs are slow.  Again, assembly programs frequently 

have to dump features in order to avoid being slow.

When I write programs, I'm interested in making a good program, not a  
small program or a fast program.  So the fact that some piece of object  
code may not be as good as the equivelant written in assembly isn't of  
much im****tance to me.  If the object code is good enough for me, then  
I'll use it.

> It could be an good idea im****ting and linking object files that where
> produced by C or C++ for example, except for the fact that you are
> restricted to use them and not _modify/fix_ them.

Again, I'm free to simply not use the library if I don't like it, and I  
don't need a 'you can't use libraries' feature to allow me to do so.

> So, the reason why linking _for me_ is not a good idea is basically

The im****tant key phrase there is "for me", linking is a good idea for  
pleanty of other people.

> b) However, ex****ting an object file (.lib or .obj from an asm source)
> to be used in your other C/C++ applications could be usefull because
> since you wrote them in assembly, it means that you have more control
> of the code and, by consequence, the quality of the data stored inside
> the object file. - Again...assuming you have the source code in asm.

You might also want to link your object code from one assembler to object 

code from another assembler.  You might even want to link object code from
 
one assembler to object code from that same assembler.  This is done quite
 
frequently, since it speeds up recompiles.  When a source file isn't   
modified, the object code to that source file doesn't need to be  
reassembled, and so the compilation script only has to reassemble just the
 
one file which was modified and then link all of the object code together 

again, as opposed to running all of the source code through the assembler 

again.

> You may argue: well....Sometimes i want a routine or library built in
> asm on my C/C++ projects....Well..if is that it...so, use inline
> assembly, it is way better when you are used to your compiler syntaxes,
> and don´t have to learn how to use another asembler just to produce an
> object code, when you own compiler can do that with the routines you
> built inline.

What if someone likes RosAsm better than the inline assembler?  Inline  
assembly doesn't offer you any extra features if you're writing the entire
 
function as inline assembly, so in that case you're better off if you  
write the function in real assembly and just link it, as that lets you use
 
the assembler of your choice, assuming, of course, that the assembler of  
your choice isn't RosAsm.

> One reason that it can be usefull is ****tability to other assemblers.
> For example i have a object code produced in masm, and want to use this
> on my fasm project (I don´t know if fasm allow linking, but..i guess
> you got the idea).
>
> But..again..this is only usefull..assuming you have the source code
> that produced that object file, so if something is wrong, you can
> modify it with your assembler, and fix the object code to be used in
> another assembler.

No, it's also quite useful if that's just the way that I want to do it.

Just because you don't like to do certain things doesn't mean that those  
things aren't useful for other people.

> So, in both cases (Im****ting and ex****ting) it is better that you have
> the source code or some representation of it.

Certainly, but like I've said, even if you don't have the source, it's  
still better to at least have the option of using object code.

> What we are currently doing with the LibScanner can also be used to
> solve those situations, even when you don[t have the source.
>
> It is primarilly designed for a tool we are working with called DIS
> System to be used with the disassembler as we already told here many
> times...But also, it can be used to you translate the source inside a
> given object file, and fix it !!!.....Not that it will produce any
> object code for now...it will produce the source code to you
> use/modify/fix it.

Automatic disassembly?  That'll never work.

What happens when your disassembler comes across the bytes "89C2" and  
"8BD0"?  It's going to disassemble them both as "mov edx, eax", because  
that's what they are.  However, when RosAsm reassembles the two resulting 

"mov edx, eax" instructions, it's going to encode them both as either  
"89C2" or "8BD0" because "mov edx, eax" contains no information about  
which of the origional two byte codes may have disassembled into the  
instruction.

Now that's not really a problem for instructions, but what if the bytes  
were actually data that the disassembler mistakenly thought was  
instructions?  When it reassembles, it's going to create different data,  
and so the code will no longer function.  (It is possible to have data in 

the code segment.)  So the code that reads that data is now going to read 

something else, and so the disassembly-reassembly process isn't going to  
work.

Like Randy said, being able to disassemble object code into source code is
 
no substitute for being able to use the object code.

> This is what the clip feature is for. You can save your functions to be
> reused later with other apps you want to build.

I shouldn't be tied down to the RosAsm editor though.  I've never met an  
IDE that I liked (unless you count the QuickBASIC editor), and I doubt  
RosAsm's IDE would be any better.  After leaving the QuickBASIC world, I'm
 
far too used to having my choice of source editor to be tied down to a  
editor which someone else has decided is the one that is best for me.