From: Betov on 19 Sep 2005 08:09
"wolfgang kern" <nowhere(a)nevernet.at> ?crivait
>| Idem. Mind you, any "Home made Assembler" Author can
>| easily output obj files and rely on an external Linker,
>| in 1% of the time that we are investing at developing
>| way more serious ways.
> Linking to or include a library would make sense if the libraries
> would contain really useful things only.
> I haven't found any real good code in any yet.
In the team, everybody is in this opinion too. The (demential)
work, we are actually doing on the LibScanner - that will take
all of this in charge, anyway... - is, first, designed to create
a complete D.I.S. system, for the Disassembler. Another story...
< http://rosasm.org >
From: Richard Cooper on 19 Sep 2005 09:47
On Mon, 19 Sep 2005 05:56:48 -0400, Betov <betov(a)free.fr> wrote:
> No, he is not _wrong_. He is just introducing a _HUGE_
> ADVANTAGE as an implicit inconvenient.
I don't see now not being able to do something can be an advantage.
When I write a really nice function, I like to be able to use it in every
program that I write, simply by making the file it's in part of the set of
source files that make up the program, or by using an include directive.
With RosAsm, I'd have to go and copy and paste it into RosAsm, because
apparently being able to keep it as a seperate file would be a huge
I also don't link to external object code often. Currently the only time
I do it is with my "quick little assembly programs" folder that I write
simple little programs in. In there I've got my register dump code
compiled into an object file, and my script to assemble files links them
with that object file. That way I've got all of the debugging support
I've developed in every program without having to copy all of that code
into every program. However, like you've said, doing it that way is a
huge disadvantage. I'd be much better off to just copy and paste that 546
lines of code into every program that I write, that way if I later come up
with a better idea for some of the debugging stuff that's in there, I have
to go through every program I've made that uses it and update the
debugging code seperately. Being able to update them simply by updating a
single object file and a single include file would be a huge disadvantage.
From: Betov on 19 Sep 2005 10:06
"Richard Cooper" <spamandviruses(a)xersedefixion.com> ?crivait
> On Mon, 19 Sep 2005 05:56:48 -0400, Betov <betov(a)free.fr> wrote:
>> No, he is not _wrong_. He is just introducing a _HUGE_
>> ADVANTAGE as an implicit inconvenient.
> I don't see now not being able to do something can be an advantage.
Having a Tool that does not push the user to bad programming
practice _is_ in _HUGE_ advantage.
> When I write a really nice function, I like to be able to use it in
> every program that I write, simply by making the file it's in part of
> the set of source files that make up the program, or by using an
> include directive. With RosAsm, I'd have to go and copy and paste it
> into RosAsm, because apparently being able to keep it as a seperate
> file would be a huge disadvantage.
Utterly wrong. With RosAsm, we store the "nice function" into
the Clip File, what is _WAY_ better and _WAY_ more intelligent
than going the "Blind-Box" programming way.
> I also don't link to external object code often. Currently the only
> time I do it is with my "quick little assembly programs" folder that
> I write simple little programs in. In there I've got my register
> dump code compiled into an object file, and my script to assemble
> files links them with that object file.
With the RosAsm methods, you don't _have to_ do it
this stupid way.
< http://rosasm.org >
From: Guga on 19 Sep 2005 23:36
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)
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).
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.
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.
So, multiple files are not the proper answer for everything. This is
the major disadvantage of having multiple files.
On the other hand, with a single file, this problem would never exists.
All it needs is someone pass to you his single asm file to you
assemble. You don´t need anything more then it.
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 mean, all you need is use the command TITLE to you be
able to internally separate your source inside the source editor. So
you can actually read in one Tab (Title) a certain function, and in
another Tab you can see another function.(Or any other part of the code
you want to be separated)
Library files and linkage have some problems that we must consider.
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. Let me try to explain :)
We all know that a library file is fixed. So far, the object code
cannot be, in general, modifiable. (Except for one or two tools called
obj2asm that you are supposed to be able to retrieve back the contents
of a given .obj to asm code.)
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.
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.
Again, if the obj file have bloated code, you are doomed to use it as
it is, like it or not.
It could be an good idea importing 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.
Also, if you want let´s say to use on your C/C++ app a library made
with Delphi, for example, or with any other object file that is OMF
(and not Coff), you can´t use it, unless you convert the OMF to Coff
with another tool. (And yet..you don´t have access to the internal
data as well)
So, the reason why linking _for me_ is not a good idea is basically
because you can´t fix the object code, and you can´t use the source
code (specially, if it came from C or C+ sources..i mean...when you
don´t have the asm source).
b) However, exporting 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.
The only question here is..Why ? If you are building your app in
assembly, why would you want that the object code produced by it,
should be used or linked on a C or C++ compiler ?
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
One reason that it can be usefull is portability 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
So, in both cases (Importing and exporting) it is better that you have
the source code or some representation of it.
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
So, if you have a C or C++ object code (Coff for now, but
later...Delphi, or Borland OMF, DCU, CVL libraries), you don´t need a
linker. All you need is the source code. When you suceeded to
retrieve/translate the source code, all you need to do is store it on
the clip features, for example.
This is what the clip feature is for. You can save your functions to be
reused later with other apps you want to build.
From: Guga on 19 Sep 2005 23:49
CVL Libraries ? Sorry.. I mistyped
(Coff for now, but later...Delphi, or Borland OMF, DCU, VCL