Release of RosAsm V.2.025a
in [ASM]
|
From: Richard Cooper on 20 Sep 2005 06:32 On Mon, 19 Sep 2005 23:36:03 -0400, Guga <mauroteste(a)hotmail.com> 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 support 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 supported 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 unsupported 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 importance to me. If the object code is good enough for me, then I'll use it. > 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. 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 important key phrase there is "for me", linking is a good idea for pleanty of other people. > 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. 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 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 > 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 (Importing and exporting) 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.
From: Betov on 20 Sep 2005 07:09 "Richard Cooper" <spamandviruses(a)xersedefixion.com> ?crivait news:op.sxecvk1z29jixb(a)sucks.airplane.fire: > [...] > > 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. This is simply impossible Troll: The ony way we know of, for having "half of the file turned up missing", in a RosAsm Produced PE, is to take a big hammer and to knock hard and repetitively upon the Hard Disk. > [...] > > 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. This is simply impossible, Troll: You cannot remove half of a Source from a RosAsm produced PE. >> We all know that a library file is fixed. > > Not if it's my library. This would be impossible with RosAsm, Troll: RosAsm does not do Libraries. > Automatic disassembly? That'll never work. The reverse is proven true by RosAsm Disassembler, Troll. > Like Randy said, ... Ah! That explains a lot, Troll... :)) > 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. If you never took any look, what tree are you barking at, Troll? :) Betov. < http://rosasm.org >
From: Richard Cooper on 20 Sep 2005 08:45 On Tue, 20 Sep 2005 07:09:39 -0400, Betov <betov(a)free.fr> wrote: > The ony way we know of, for having "half of the file turned > up missing", in a RosAsm Produced PE, is to take a big hammer > and to knock hard and repetitively upon the Hard Disk. Actually, that's definately not the only way we know of. For example: Take a small hammer and to knock hard and repetitively upon the hard disk. Take a big hammer and to knock lightly and repetitively upon the hard disk. Take a big hammer and to knock hard just once upon the hard disk. You see, there's really quite a few ways it could happen. > You cannot remove half of a Source from a RosAsm produced PE. What about just removing half of the source code from a RosAsm source? Or does RosAsm not support source files too, as you might want to compile someone's program but they forgot to give you the source file? >>> We all know that a library file is fixed. >> >> Not if it's my library. > > RosAsm does not do Libraries. So RosAsm does not do libraries because RosAsm does not do libraries? That seems to be where we're at. RosAsm does not do libraries, so the library is not my library, and so the library is unmodifiable, and so I don't want to use the library, and so RosAsm does not do libraries. Not only is that circular logic, but not a single step in that chain of logic makes any sense. >> Automatic disassembly? That'll never work. > > The reverse is proven true by RosAsm Disassembler, Troll. So how do the RosAsm Disassembler and the RosAsm Assembler work together to handle things such as "89C2" and "8BD0"? Does it always properly guess wether bytes are code or data, and therefore never make such a mistake? I find that hard to believe. Randy says that the disassembler creates normal disassembly output, that is, that the disassembly it creates cannot be magically reassembled into a working program for anything other than the easiest to disassemble programs. I find that much easier to believe. >> Like Randy said, ... > > Ah! That explains a lot, Troll... :)) Is he wrong? By the way, what exactly is the intended meaning when someone calls you a troll and then follows it up with a smiley? I don't get it. > If you never took any look, what tree are you barking at, Troll? Ok, first of all, dogs bark, not trolls. Second, dogs don't typically bark at trees, or anything else that doesn't move for that matter. Now dogs do occasionally bark up trees, but that's only because they're barking at something that is up in the tree that does move. > :) So ambiguous...
From: Paul Dunn on 20 Sep 2005 09:23 Guga wrote: > This is what the clip feature is for. You can save your functions to > be > reused later with other apps you want to build. So if I were to build an app with some clip library functions, are they copied directly into your source, or simply referenced? If I were then to later update the clip library with superior functions, will rosasm automatically make those changes to my source, or would I have to manually locate the function, remove it, and re-paste the new clip library code?
From: Betov on 20 Sep 2005 09:48
"Paul Dunn" <paul.dunn4(a)ntlworld.com> ?crivait news:e3UXe.10283$ws4.4346(a)newsfe5-win.ntli.net: > Guga wrote: > >> This is what the clip feature is for. You can save your functions to >> be >> reused later with other apps you want to build. > > So if I were to build an app with some clip library functions, are > they copied directly into your source, or simply referenced? If I were > then to later update the clip library with superior functions, will > rosasm automatically make those changes to my source, or would I have > to manually locate the function, remove it, and re-paste the new clip > library code? Feel free to use an inferior technology, that will foolish you, if this is what you prefer to the Asm ways of programming, Paul: Assembly is not for guys who believe in baseless Mythologies. Betov. < http://rosasm.org > |