Advanced Linux Programming
in [ASM]
|
From: //o//annabee on 22 Feb 2007 23:18 P� Fri, 23 Feb 2007 02:33:05 +0100, skrev Frank Kotler <fbkotler(a)verizon.net>: > SpooK wrote: >> On Feb 20, 3:51 pm, //\\\\o//\\\\annabee <Wannabee.Wannabee.org> >> wrote: >> >>> P� Tue, 20 Feb 2007 18:37:13 +0100, skrev SpooK <k...(a)dynatos.net>: >>> >>> >>>> Beyond that, NASM32 (http://www.asmcommunity.net/projects/nasm32/) >>>> seems to do just fine with developing Win32 apps. >>> >>> Just realize that it took longer time to COPY the code I wrote with >>> RosAsm >>> into NASM, than it took to create it. >> That is common when translating a convoluted syntax back to a more >> accepted and pure form, no worries :) > > From Wannabee's viewpoint, he was translating from an "improved" syntax > back to the "unimproved" one. That's harder, psycologically, I think. > >>> And also realize that the >>> timediffrence was more like 1-50 in favor of RosAsm. >> Yes, and DOS can start up in 1/50th the time that it takes Windows to >> do so... but I doubt you are posting your replies in DOS ;) > > Well you *could*, y'know. I'm not sure which "time" we're discussing. > Nasm is slow, we know that. I don't recall that it was particularly bad > on "nbliss". Curiously, I think Nasm's faster on a "monofile" project > than on one that "%include win32.inc"s. But I think Wannabee' talking > about coding time. I am talking about the total time, but espesially about the debugging time. Also, the reading time, and navigation of the sourcecode is a significant time stealer when coding the way I do. When looking for errors, and when recapping for new modifications. Because I do not plan everything upfront. I plan on changes. I expect to discover things as I go along. I allways starts with a skeleton, and progressivly expand this. Maybe I am not motivated enough. So in order for me to not give up, I must have running code by each modification. So even if I know I will need a memory FillRect routine, I first like to have an app which uses the API fillrect todo the same thing, and when it works ok, I can take care of replacing it with the one I want, when I want to. This particular exersize was for me needed in order to complete my most in use memory painting routines. Since working on a side project, I got to feel the spirit of starting fresh, but later it turned out it would be as easy to redeploy the new routines in the old sourcecode. I couldnt see this earlier. Because I had not done it, I couldnt see how I could have done it with such ease. I guess I do this in order to trick my self to do it. Its some psychological thing as well. I also think that if I wrote the thing fresh in NASM I would have learned NASM better, and would have done the partial expanding of the source in it, and then it might have felt much easier. So, I maybe should not be so definitive in my judgement. What i want to have finally, is a basis for which to develop applications. Much like what Delphi represented to me, only under my supervision and control. I want to develop a GUI that when done, I will have the tools easy at hand to give the output I need for when later I will develop _real_ applications. By then, when I need dialog for coding scripts to govern my 3D objects, I dont want to at that time, do the Dialog code, and the table, edibox and helpbuttons, and help editor from scratch. I want to focus on the script engine, and the behaviour and looks of my 3D objects. I dont want to be set back by things like "oh, cant run this dialog in DirectX fullscreen", or "this object cant implement this behaviour", or the more common "You have to look like this". I want a unifying thing that I can change at every point in the code, or have as much control of as possible. This is why I build a GUI. _No_ other reason. Plus a GUI is a relativly easy project, and so it is an excellent way to learn how to code at all. It is big enough that it have some use, and it is small enough that it can be completed. And knowing the code, modifications are more times very easy. Plus, the GUI will never be rewrapped inside a black box. Code will never break or change beyound my own doing.. I think its worth it. While using the Window GUI gives many advantages, it also gives many drawbacks and unpleasantries. It is not unified at all, but seem completly haphazard when you want to code it at the lowest possible levels. >>> And realize that I >>> simply gave up on finding some of the bugs that made the NASM version >>> fail >>> for some cases. >> Which version of NASM??? You must be doing something quite awkward to >> invoke any amount of trouble that you suggest. > > I don't think it was strictly a "Nasm problem" - more a "translation > problem", I think. The RosAsm version I looked at had problems in win98. This was a Window95 problem. An API that worked diffrently between two versions of the OS. I solved this inside the OOA.Zip < http://szmyggenpv.com/downloads/OOA.Zip > > The Nasm version was worse. Since I couldn't see what it was "supposed" > to do, I wasn't any help finding the problem(s) in the Nasm version. Yes, everything was upside down in win9x >> Maybe you should post the RosASM source code in question so others see >> if they can find the problem? I am willing to take a stab at it ;) > > At one time, both "bliss" and "nbliss" were available somewhere around > "wannabee.org", aka http://www.szmyggenpv.com/RosAsm.htm - I can't find > an exact filename right now. I've got 'em, but on a drive that's not > plugged into this machine right now (and perhaps not latest version). We > can come up with 'em. Its easy to turn the NASM version to work on win9x if you look at the two labels: * Window.OutputFromRect and * FlipRect (in the OOA.Zip) All you should need todo is to replace those from the OOA version, and add the call to FlipRect to all graphics drawing function. (Done in the two latest OOA versions). Proc Graphics.ClipBlitDIB: Argument @ARect @hBitmap push edi esi ____________________________________________________________________________________________ mov edx D(a)ARect CopyRect ClipBlitDIB.Rect edx mov edx ClipBlitDIB.Rect >>>>>> Insert this line call FlipRect RectSize edx In addition, you should need to instead of allocating a a backbuffer memory, allocate the backbuffer as a BitMapSection instead (Code in OOA.Zip at label "Graphics.Start") > I hope you do take a look at it. I'm mostly not in the mood to run > Windows (and haven't got wine installed), don't know the Windows API, > and am not much interested in learning it. The reason 'bee went through > the pain of translating it to Nasm was so that we could see about > porting it to Xwindows. I understood, before I looked at it, that we > were talking about a "minimalist" homemade GUI that called the Windows > API as little as possible. I think Wannabee got a little too "advanced" > for me - I never got fully "oriented" in the thing. It's too good an > idea to let drop, so I hope you, or someone, gets into it! Thanks. I think so too. Lets credit Michael Abrash for the idea, because it was him that made me want todo it. >>> Progging NASM was a certifiable nightmare compared to the >>> RosAsm one. Maybe I could have done better, if using a IDE for NASM >>> though, as I used Notepad todo it, but given I taken a look at RadAsm, >>> I >>> doubt it would made much of a diffrence. >> I use GVIM, syntax highlighting is always a plus. Sorry to say, an IDE >> doesn't make a better programmer. Also, interfacing with a syntax that >> makes more sense to you doesn't mean you are any better at programming >> said architecture. When you break a programming language down, it is >> simply math and logic with a few twists. > > I don't know GVIM (or RosAsm)... I consider syntax highlighting a > "distraction", Yes. Mostly. It depends. In the back of my mind, there is an idea of a fully interactive assembler that produces application by drag drop mostly. But likly it would be a dumb thing if actually made into code. Few things are simpler than typing, and the process of actually creating and typing the code is not the main job. (Which is why an interactive allways running completly managed assembler, might be possible, even my current ideas are probably not). But if you took at look at the Ketman stuff, it is truely awsome. This is actually an interactive fully runtime/code/documentation tool, that doesnt even need a compiling stage for the average case. It only needs it for the final producing of the exe or com file. You can develop all the code in the editor, and run it, or step it, without ever "compiling it". > but I guess you could get used to it. Question is, once you've got it > highlighted, can you "navigate" on it? Looking at Wannabee's Nasm > version of "bliss", it's fairly obvious that he's used to having some > features unique (AFAIK) to RosAsm's "sources editor". RosAsm may seem like the average editor, but it is not. RosAsm is as diffrent from an ordinary editor, as the KetMan editor is. RosAsm has a _code_ editor.Coding is RosAsm is so completly diffrent experience from anything else, that it needs its own vocalbulary in order to express it propperly. Do you know that several times a day, I get impulses about stuff in my code, and sometimes I stopp the movie I am looking at, launch RosAsm, fix a bug, and continue watching the movie, and the whole thing took like maybe a minute at most? I can do this even though I am sick as a dog at the moment. I cannot take on the serious tasks, or doesnt want to, but I can solve simple bugs. Coding for windows, and not using RosAsm = you're so damn insane. :D :D >>> Added to this, many of the bugs >>> for the NASM version, that I bothered to fix, I found by using the >>> RosAsm >>> Disassembler to step the code :) > > Ndisasm will disassemble the code, but won't "step" it, of course. I > suppose you mean debugger. The integrated disassembler and debugger are > another of RosAsm's good tricks! Definitly. I can fix and discover bugs now in half of the Free Software written in C out there. Jay oh may is it cool to take a look at some of the code written in C .... I espesially liked one I saw: push eax | call "user32.GetNextCharA" (or something like that) when "inc eax" would have done the same thing. How is that for "optimizing compiler" ???? This was inside a LOOP. >> I imagine much of your stress is due to extensive use of macros, >> perhaps poorly written ones as well... so... Garbage In, Garbage >> Out??? > > I don't think it was a macro problem. I showed Wannabee a macro, based > on Nasm's undocumented "&" syntax, so he could use "B$", "W$", "D$". > Thought it would be easier for him. Probably a mistake. Made it harder > for me to read, and I'm not sure it was any easier for him - not enough, > anyway. I forgot why I did not try it. > Part of Wannabee's "difficulty" with translating to Nasm is that he > didn't want to "%include 'nagoa+.inc'", or whatever - rightly so: he > doesn't know what's in it. So he was stuck with implementing all the > equates (that RosAsm "preincludes") and macros that he wanted - in an > unfamiliar syntax - without snippits to cut-and-paste from - right in > the one file. Yes, I probably could have learned better NASM first. But this is hard to convince oneself todo, when one allready found a better solution. Its strange, but if one does not have alternatives, one can prepare to write 100K with something, but once one discovers just on single fact in considerable disfavor, even writing a few kb becomes a painful exersize. Very strange fenominon. It was the same with the translation. I allready had the code, so any work, even a single comma, was a surplus of redundant work. And then doing it for 159kb, it feels like a nightmare, even though, if one did not have any other alternative, one would happily do the thing from scratch, and never even know. >>> If one does not want the ease of an IDE like RosAsm, its because the >>> proggy that one is working on is to small to make much of a diffrence, >>> or >>> simply that one have never realized the extreme benefit of doing so. >>> For >>> an app larger then about 10ko, if ment to run under window, it would be >>> simply insane to not use RosAsm. >> I think the dark days of BIG_FILE.ASM are over. I don't see how this >> statement holds any bearing, even as compared to using a single file >> in RadASM. > > RosAsm goes a long, long way towards lightening the darkness of > BIG_FILE.ASM. It's designed "from the bottom up" to work with > BIG_FILE.ASM. I'm not sure I agree that it makes monofile programming > "The Answer". It will never be the answer to beeing a side tool for another language. Not unless you want to code a DLL. But yes, it is a considerable answer to the "build full PE in assembly" question. I created a downloader for all my apps, with icons on buttons, and with explainations in a few scarce _minutes_. No more than one or two hours. Possible only because of the GUI allready built and because all of the needed components allready built. I could _NOT_ have done this faster in Delphi. > There are advantages to modular programming - "manyfile.asm and all its > children, aunts, incles, and cousins". If one chooses to work with a > single file, RosAsm aims to ease the pain. "Modular" doesnt have to equal "many files". All applications are modular to some extent. Because "modular" is simply the way we _view_ it. RosAsm memorymanger is modular for instance, allthough Ren� may not agree, and may not have planned it this way... it is modular nevertheless. I proved this by ripping it out of RosAsm into a base in like 5-10 minutes. I ported 3 titles over, and filled a few wholes and references. Thus it is modular. > >> I know most of this post seems aggressive, wannabe... > > You didn't call him a fucky one. :) :D I am the happy willage idiot, "fucky one" is allready taken. >> but I really am >> interested in seeing your RosASM example and converting it myself. Who >> knows, maybe you will teach me something :) > > I hope you'll look at it and discuss it a little here ("civilly" would > be nice, but whatever). Perhaps we'll all learn something. I considered his post very sivil, and would not care if it wasnt. I love people beeing direct. > > Best, > Frank
From: Betov on 23 Feb 2007 03:24 "rhyde(a)cs.ucr.edu" <rhyde(a)cs.ucr.edu> �crivait news:1172174143.011540.164030(a)l53g2000cwa.googlegroups.com: > On Feb 19, 11:00 pm, Betov <b...(a)free.fr> wrote: >> >> Not only he _can_, but he can have several personal equates files. >> > > Of course, if the density of equates to source code gets too high, > RosAsm crashes. But then, that's not a bug, is it? Right, clown: RosAsm is not a Tool for compiling news papers. :) Betov. < http://rosasm.org >
From: SpooK on 23 Feb 2007 11:25 I'm not going to re-re-re-re-re-quote things, so I hope people reading this response are following the thread. Don't get me wrong, wannabe, I never coded more than a function's worth at a time before testing, but I've never had consistent need for a disassembler/debugger... probably due to my thorough testing procedures. I can only recall using a disassembler twice, once to see how it worked and once to correct a severe programming error with the difference between Standard calls and C calls... quite some time ago... and before I developed my standard testing habits... but it still counts ;) I'm also not here to convince anyone to change their flavor of assembly language, that just isn't who I am. I just would like to know what would cause such errors in NASM... all the specifics... as NASM is *my* flavor and I don't want it to turn bitter :) The GVIM syntax highlighting seems to help me, especially with the way I section-off functions with obvious comment lines that are deep blue. I tend to keep all of the colors very dull (nothing too bright/ annoying). GVIM is very responsive and I've never had an issue with it. Don't get me wrong, I've spent my fair share of time with VI under Linux/BASH, but GVIM is not so archaic and acts like any other Win32 application under Windows. I've also used it under X11/Gnome/KDE/ Fluxbox and liked it just the same. I am familiar with both Linux Kernel and the Win32 API. I am definitely not an expert in those APIs, but I do remember the basics and the rest of the API calls I tend to look up anyhow. I am also familiar with X11, as I do have a working include file and example for making an X11 window in NASM32. It will be included in the next release. I think the goal is to design some GUI examples for Win32 and Linux to show how one would transition between the operating systems and APIs. As for the "BIG_FILE.ASM" discussion, my first OS kernel was one big continuous file. After it grew big enough, it seemed logical to split the file into multiple files based on major function. Since I do not use an IDE, I've kept this habit, only to find out it is generally a standard anyhow and the "BIG_FILE.ASM" method is more or less obsolete. Whatever works for you, though, is what I encourage ;) Well, I have things that exceed priority of ALA discussion... so until next time... take it easy ;)
From: Evenbit on 23 Feb 2007 16:53 Hey Wannabee - send me the Nasm source for "bliss" to this address: evenbitnb at yahoo dot com Nathan.
From: Evenbit on 23 Feb 2007 17:03
On Feb 22, 2:55 pm, "r...(a)cs.ucr.edu" <r...(a)cs.ucr.edu> wrote: > On Feb 19, 11:00 pm, Betov <b...(a)free.fr> wrote: > > > "Evenbit" <nbaker2...(a)charter.net> écrivait news:1171942188.150538.173100 > > @t69g2000cwt.googlegroups.com: > > > > NASM works just fine without an Equates file, so I conclude that an > > > Equates file is *not required* and is *not germain* to assembly > > > programming. > > > NASM is not a Assembly specificaly written for Win32. > > > > Why not leave it up to the programmer to define his own equates (or > > > 'include' the file) if he wants them? > > > Not only he _can_, but he can have several personal equates files. > > Of course, if the density of equates to source code gets too high, > RosAsm crashes. But then, that's not a bug, is it? It could easily be argued that if an "assembly language programmer(tm)" uses *more* lines of equates than LOC then there is something _wrong_ with his development environment. Nathan. |