Re: Release of RosAsm V.2.025a

On 19 Sep 2005 20:36:03 -0700, "Guga" <mauroteste@[EMAIL PROTECTED]
> wrote:
>http://groups.google.com.br/group/alt.lang.asm/browse_frm/thread/2fbb5a4bf7f12ffe/51a1ae1966c44da4?q=annie&rnum=1&hl=en#51a1ae1966c44da4

[]

>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.)

Except for have the original not compiled 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.

Except I have the original not compiled code for that library

>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 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.
>
>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, 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.

>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
>built inline.
>
>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.
>
>So, in both cases (Im****ting and ex****ting) 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
>use/modify/fix it.

>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.
>
>Best Regards,
>
>Guga