Significant Pure Assembler Application In MASM ?
in [ASM]
|
Prev: aeBIOS Test Request
Next: CMOVcc vs. Jcc
From: hutch-- on 7 Oct 2007 23:02 HAY Betov, > As for Hutch, redistributing illegaly MASM, these two bastards > working hand in hand, at their respective quest of fame, and > reciprocal acknowlegments, it is self-evident that, if Hutch > had any legal rights on MASM, Master Pdf would have got them > as well. Instead of bitching about how generous Microoft have been with their MASM EULA, how about PAYING for ASM32 that you cobbled the original version of SpAsm together with.For a lousy few buck$ you could legitimise that crapheap of yours (if you did not tell them you stole it first) so that your userbase (You and half wit) could legally distribute your software. Shame on you Betov for STEALING Intelligent Firmware's ASM32. You should be forced to eat Wannabee's hat for all the lies you have told.
From: santosh on 8 Oct 2007 03:16 Frank Kotler wrote: <snip> > Herbert's recent experiments encourage me toward the "bottom up" > approach. Libraries would be "easier", no doubt... at least initially. > But we could find ourselves "locked in". How exactly? Something like GTK is available wherever X is available. I think this fear of getting "locked in" is just paranoia. > The "problem" with libraries, > IMO, whether for asm or not, it that it encourages us to solve a > problem in terms of the library routines we have available, instead of > solving the problem by "doing what needs to be done and not doing what > doesn't need to be done". This is not necessarily bad. Even without user libraries, you're still solving problems in terms of other pre-canned code, whether it's the OS or BIOS or whatever. If course I'm not saying you should gratuitously depend on libraries and certainly from an educational perspective "doing it manually" is good, but once you are past this, and the libraries in question are well designed and widely available, I don't see any problem in depending on them. It saves a hell of a lot of work. > I'm not ready to count ReactOS out. It's not ever going to become a serious replacement for Windows unless Microsoft themselves start sponsoring it, and then it'll be a "poor man's" Windows, much like the "Windows Starter Edition" available today. > ReactOS suffers from the same problem as Linux, anyway: not enough asm > in it! Seeing as Windows and clones are never going to be ported to non-x86 architectures, you absolutely right, but for Linux more assembly will mean more things for Linus to keep track of manually. On the other hand it'll likely speed up the kernel. > Yes. And for what user base? I've been asked by newbie Nasm users, > "where's the IDE for Linux?", so there's *some* interest in that sort > of thing. I fear it's a small percentage of a small percentage - not > that many Linux users, not that many of 'em interested is asm, not > that many of *them* interested in an IDE. Personally I use Vim/GVim as the "IDE" for both my C and assembly programming. So far, it's done all that I want out of it, (hell I still don't know more than half of Vim's tricks.)
From: Betov on 8 Oct 2007 04:00 Frank Kotler <fbkotler(a)verizon.net> �crivait news:FKcOi.6093$br2.2298(a)trndny03: > The "problem" *may* be that you think you want/need a "replacement for > the Win Api". That would be one way to do it. Another way would be to > do it "from the bottom, up". Everything the libraries do *can* be done > in terms of the int 80h services. It is a *large* amount of > "everything", however! I've given this a lot of thought, and I *still* > don't know which would be "best" for the vaporous "LuxAsm" or some > like product. This is a layer scale problem. What are the OSes for, if not for providing layers to be re-used by the Applications? Progamming something real with int 80 would be like doing so with the BIOS interrupts, in my opinion. A terrific task that, considering the number of volunteers, would take longer than the life of x86. > Herbert's recent experiments encourage me toward the "bottom up" > approach. Libraries would be "easier", no doubt... at least initially. > But we could find ourselves "locked in". The "problem" with libraries, > IMO, whether for asm or not, it that it encourages us to solve a > problem in terms of the library routines we have available, instead of > solving the problem by "doing what needs to be done and not doing what > doesn't need to be done". OSes are there for providing that layer of Libraries which makes the developing a possible thing. Not calling for them would have no effect but dramaticaly slowing down a process, which is already slow and long enough. I am always estonished when seeing a guy like you under-estimating the quantity of work to be done. Something like RosAsm was 10 years of work for a significative number of contributors. Only my part was a full time job for, at least 7 years, and Ludwig's one was around 4 or 5 years. So, where will the OSes be in 10 years, even when making our lifes easier with the OS libs Functionalities?... This question puzzles me. Another point about Ubuntu: The reason why there exists an actual hope with *Ubuntu* (in no way with the *Linuxes*) is because several majors among the gears sellers choosed it, for being sold "out of the box". This is not us who choose the future. This is the Market. Personaly, i think i will make my choice in one week or so, when the new 7.10 release will be official. I will then be able to estimate the progress(es) they do, in between two releases... Betov. < http://rosasm.org >
From: Betov on 8 Oct 2007 04:13 "rhyde(a)cs.ucr.edu" <rhyde(a)cs.ucr.edu> �crivait news:1191791435.186761.102940(a)v3g2000hsg.googlegroups.com: > Actually, HLA was announced *before* SpAsm was. > HLA was announced in CLAX (and this group, IIRC) in Oct 1999. SpAsm's > announcement came along sometime in 2000. > Just to set the record straight. Clown, everybody knows that you are used to make noise long before having written a single line. The real facts are that, since the first Iczelion Board, up to the Iro- the-snake one (many years afterward), nobody ever heard of famous name, in the Win32 Assembly Rebirth area. Also, as said in B_U_Asm, since the day one of SpAsm: "I began working on the RosAsm project in September 1998. The very first version was written with Asm32. I begin this history in July 2000"* Not noticing that, before releasing any SpAsm/RosAsm, around 1999, i had done the job of porting its 16 bits ancestor to 32-bit (what i used ASM32 for). That is, the dates i provide are not the ones i "thought" about doing something with a keyboard. These are dates, when SpAsm was already a *usable* something, clown. Betov. < http://rosasm.org >
From: Betov on 8 Oct 2007 04:27
"rhyde(a)cs.ucr.edu" <rhyde(a)cs.ucr.edu> �crivait news:1191792086.074736.9910(a)k79g2000hse.googlegroups.com: > HLA also produces MASM code and MASM > is still the most commonly-used back-end for HLA. This may change, Sure, clown. This will change the day you will have obfuscated FASM enough for introducing the whole HLA (modified-FASM included), as *your* whole production. Then, HLA will be sold as written by Master Pdf. Period. > but > that's irrelevant because your second comment -- FASM syntax is > derived from NASM -- is not true at all. As you do not understand a thing at the basics of Syntax, it is no use to try to explain to you, but *YES*, evidently FASM, - which was first based on TASM special Syntax -, was later aligned for conforming, like all of the actual Assemblers, to the NASM Syntax basics, after one of the friends of Thomasz had succeed to convince him that this change was absolutely required, for saving, among other things, from the scaring confusions introduced by MASM in the Addressings. Betov. < http://rosasm.org > |