Release of RosAsm V.2.025a
in [ASM]
|
From: Betov on 22 Sep 2005 05:35 "wolfgang kern" <nowhere(a)nevernet.at> ?crivait news:dgtsie$52u$3 @newsreader1.utanet.at: > > Charles A. Crayne replied to "randyhyde(a)earthlink.net" > >| :(a >| :problem that has been reduced to the halting problem, which has been >| :proven to be undecidable). >| >| Only on machines with infinite memory. > > Oh No, the Professor still sound out his theories ... > He may not have even read our posts in the past. > > So for new readers I state it one more time: > "the halting problem does not apply to disassembling" > (see discussions on it in the history of ALA-posts). Courage, Wolfgang. :))) Betov. < http://rosasm.org >
From: ?a/b on 23 Sep 2005 01:22 On 19 Sep 2005 20:36:03 -0700, "Guga" <mauroteste(a)hotmail.com> 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 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 >built inline. > >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. > >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 >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
From: randyhyde@earthlink.net on 24 Sep 2005 18:29 wolfgang kern wrote: > > So for new readers I state it one more time: > "the halting problem does not apply to disassembling" > (see discussions on it in the history of ALA-posts). > __ > wolfgang Wolfgang has spoken! The world of computer science stand up and take notice! It doesn't matter that some *incredibly* brilliant minds have mathematically proven that the "halting problem" reduces to the problem of determining whether a byte in memory is code or date (that is, they've proven that the problem of disassembly is an undecidable problem). So do go back and read Wolfgang's posts of old, where he's made this claim in the past! It appears in a usenet newsgroup! It *must*, therefore, be true! To Wolfgang: it has been nearly a year since *you* claimed that your work on a disassembler would yield a perfect disassembler program. Where's the solution? We're all still waiting for you to shake the foundations of theoretical computer science! Cheers, Randy Hyde
From: randyhyde@earthlink.net on 24 Sep 2005 18:31 Charles A. Crayne wrote: > On 21 Sep 2005 08:36:01 -0700 > "randyhyde(a)earthlink.net" <randyhyde(a)earthlink.net> wrote: > > :(a > :problem that has been reduced to the halting problem, which has been > :proven to be undecidable). > > Only on machines with infinite memory. Of course, with only a *finite* amount of memory, even *less* computation is possible. Therefore, it's *less* likely that you'll produce a perfect disassembler when you've got a finite amount of memory to play with than if you had an infinite amount of memory to play with. After all, if you can write the perfect disassembler with a finite amount of memory, you can *certainly* write it with an infinite amount of memory. Chuck, file this one under the "what were you thinking?" file. Cheers, Randy Hyde
From: Charles A. Crayne on 24 Sep 2005 23:00
On 24 Sep 2005 15:31:26 -0700 "randyhyde(a)earthlink.net" <randyhyde(a)earthlink.net> wrote: :"what were you thinking?" I was thinking of the Wikipedia article to which you referred us for information about the "halting problem", from which I quote: "The undecidability of the halting problem relies on the fact that algorithms are assumed to have potentially infinite storage: at any one time they can only store finitely many things, but they can always store more and they never run out of memory. However, computers that actually exist are not equivalent to a Turing machine but instead to a linear bounded automaton, as their memory and external storage of a machine is limited. In this case, the halting problem for programs running on that machine can be solved with a very simple general algorithm" Since the "halting problem" can be solved on real machines, then it obviously does not impair the ability to write a 'perfect' disassembler. -- Chuck |