Significant Pure Assembler Application In MASM ?
in [ASM]
|
Prev: aeBIOS Test Request
Next: CMOVcc vs. Jcc
From: Betov on 7 Oct 2007 03:54 //\\\\o//\\\\annabee <w(a)w.w.w> �crivait news:op.tztczr0yin6out(a)darth-fpsr: >> The Lisa assembler, another product that tried to insert an editor, >> assembler, debugger, etc. into a single application. > > Not ever heard of it. :)) You are not the only one. The only tracks i found of, it around the Net were comments saying how fast it was abandonned because of multiple bugs. :)) Betov. < http://rosasm.org >
From: japheth on 7 Oct 2007 03:56 > Thanks! Have you implemented a full drag drop server in there? > I think I am going to like this ! If you're interested in implementing OLE Drag&Drop you might be interested to look at http://www.japheth.de/Download/DragDrop.zip This is a sample (MASM), both ends (server and client) are implemented. It might be easier to use as a reference than COMView. If no, just ignore it :). I updated it only recently because the previous version still used MASM32. The current one uses Win32Inc, which is Public Domain (http:// www.japheth.de/Win32Inc.html)
From: Rod Pemberton on 7 Oct 2007 04:25 "Betov" <betov(a)free.fr> wrote in message news:XnF99C1ACCF1CEB1betovfreefr(a)212.27.60.39... > "Rod Pemberton" <do_not_have(a)nohavenot.cmm> �crivait news:fe866a$1ii$1 > @aioe.org: > > > That's quite a bit of proof, but I suspect that no matter how much I > > provide, that it's somehow insufficient for you to adjust your current > > paradigms... > > Of course. Why do you think this individual choosed to support > MASM over NASM, in his earlier versions? The only reason why he > did not finaly choose MASM (even though he goes on supporting it > actively), was that he was afraid of its illegal redistribution. > But, hutch-- wasn't concerned?... And, hutch-- claims he was somehow able to receive permission to do what the well renowned RH couldn't receive permission to do? Most interesting. ;) > Would have MicroSoft given its permission, keep sure that MASM > would be inside his package, dispiting all of the defects and > limitations of this toy. > > When asked about "Why not NASM?", he was used to provide the so > funny answer: > > "NASM Macros Engine is not powerful enough for supporting HLA". > > [Notice the *two* great jokes in one]. > NASM is clearly powerful enough to support C as a backend for a number of LCC ports. IMO, there are very few useful programming concepts that can't be programmed in C. Every time someone says something can't be done in C, it's usually because they never learned basic structured programming techniques such as fall-through. Or, they forget C supports unstructured programming techniques like goto, multiple procedure exit points, and an unstructured form of switch(). Therefore, I'm a bit leary when someone says something can't be done in NASM, when it can be done in C and NASM is being used as a backend for C. Some C++ concepts are difficult to implement in C but not impossible. Multiple procedure entry points (i.e., used for coroutines) would be one such technique. Coroutines aren't native to C but can be implemented in C. NASM already supports function overloading depending on the argument count (useful for C++ or for various code sizes 16/32/64-bit). Also, unless I missed something (not much in the online doc's), FASM has an almost non-existant preprocessor. I've already shown that NASM's preprocessor is quite powerful albeit weak in certain areas such as string processing: http://sourceforge.net/forum/forum.php?thread_id=1741796&forum_id=167169 > "NASM Macros Engine is not powerful enough for supporting HLA". I haven't written any large NASM files, but almost all the expected programming functionality appears to be there (as compared to C). I'd be interested in seeing what complaints he has about the NASM macro engine. I.e., can't implement something like coroutines, recursion, register allocator, parsing, or what? Rod Pemberton
From: Herbert Kleebauer on 7 Oct 2007 04:32 santosh wrote: > It more than a "beginning." Tell me one reasonable thing that you can do > with your Windows that I cannot do with my Ubuntu here. Try to execute a binary you generated with Linux ten years ago. In Windows I can execute DOS programs written twenty years ago (and I hope MS will be forced by the user base to also include 16 bit support in 64 bit Windows). For me Linux becomes an alternative to Windows (as a desktop system) only if: 1. There is a version where they can guarantee that any BINARY written for this version can be executed on any newer release (for at least ten years). 2. This also must be true for the graphics (multimedia) system. This means, the OS and THE (we don't need more than one) graphics system has to be unified like in Windows.
From: santosh on 7 Oct 2007 04:28
Rod Pemberton wrote: [debate about whether NASM is/was suitable as a back-end for HLA] I think Randall has mentioned on several occasions that NASM was not powerful enough for his HLA _when_ he was developing the latter, IIRC sometime during the mid-90s, when NASM was in it's infancy. IIRC he did agree that NASM, as it stands now, *is* good enough as a back-end to HLA. Why then he chose to bolt-in FASM is rather confusing. |