Iczelion's tutorials revisited.
in [ASM]
|
From: randyhyde@earthlink.net on 30 Aug 2005 18:22 JGCASEY wrote: > > Many of them, yes... but you said that you _had_ > > that knowledge... > > Only the old syntax without the .Else_If stuff I > see in your source code. This is the really funny part about RosAsm. Rene constantly gripes about the HLL-like statements in MASM, TASM, and HLA, and then sticks all these macros into his source code to simulate them all. He somehow believes that because he's used macros rather than building them into the assembler that this somehow means something different to the end user. I keep telling him that if someone is opposed to "IFs" and "WHILEs" in assembly language, they'll be opposed to them regardless of their implementation. Thank you for demonstrating this point. > Then there is the strange > looking macros. And the syntax in general. For some reason Rene likes to claim that RosAsm's syntax is "Intel Syntax". It has been pointed out to him over and over again that his syntax isn't even close. And the way typical Rosasm source files are written, the code often looks like an explosion in an alphabet soup factory. Here is some of Wolfgang's code from his Kesys program, for example (and don't think this is just Wolfgang's problem, most RosAsm source code is formatted this way): MainWindowProc: ;esp+00=ret +04=hdl +08=msg +0c=wP +10=lP pushad ; mov edx D$esp+024 ;hdl mov eax D$esp+028 ;msg mov ebx D$esp+02c ;wP ; mov ecx D$esp+030c ;lP cmp eax &WM_CHAR |jnz L7>> mov al bl cmp al 30h |jc L5> |cmp al 3Ah |jc L0> and al 5fh |cmp al 'X' |jz L4> cmp al 41h |jc L5> |cmp al 47h |jnc L5> L0: sub al 30h |cmp al 0ah |db 072 02 |sub al,07 |shl D$INPval 4 |or B$INPval al |mov b$keyflag+1 al mov ebx Kname00 |mov eax D$Kindex |mov cl B$KsizeE2 |shl eax cl |add ebx eax mov eax D$INPval |mov D$ebx+010 eax L3: call repaint |cmp D$INPptr 9 |jc L9>> xor eax eax |mov D$INPptr eax |mov D$INPval eax| jmp L9>> L4: xor b$keyflag 080h |jmp L9> Quite honestly, it looks like code written by a BASIC programmer back in the days when people discovered that BASIC programs ran a little faster when you crammed as many statements on one line as you could. There is *one* thing you can say about Wolfgang's (versus Rene's) code, however. He doesn't use macros (including all the HLL-like statements). > Very little looks like the DOS > code I used. This is why it's good to learn and use a standard set of library routines. When you move from OS to OS (as you've done from DOS to Windows), you can port your library routines to the new OS and the code will look just as it did before. If you're really good about how you maintain your library, you can even port your code from OS to OS. The HLA Standard Library, for example, is portable between Linux and Windows, requiring only a recompile to get an application running under either OS. > But anyway the tutorials need to deal > with an absolute beginner so a working knowledge > of the assembler syntax is needed. This is best > done, in my opinion, by introducing them in stages > as needed to understand a particular program. Writing a decent set of tutorials that take beginners from point zero to experienced assembly programmer takes a lot of work and experience. Some people (like Rene) seem to think that there is no work involved in this process. Nothing could be farther from the truth. Generally, the first thing that comes to mind when someone sets off to write a tutorial really doesn't work for most people who read the tutorial. Believe me, I've tried a lot of different teaching methods over the years (and incorporated what I've learned into books like AoA and the materials I've written for Webster). It takes a lot of "trial and error" to fine tune pedagogical material so that it works for a lot of people. And no single tutorial or book is going to work for everyone. For example, you've alluded to the fact that you like things as concise as possible. The majority of people, however, don't like curt tutorials. They want friendly and approachable explainations. You can't write a tutorial that is going to satisfy both types of people. > > That appears to cover it. For an absolute beginner > you would have to cover binary numbers perhaps? > Actually, there is the whole subject of machine organization that needs to be covered. Indeed, "machine organization" is what people are *really* expected to learn when they take an assembly language course at the local college or university. Binary numbers (actually, data representation) is certain a part of this, but there is quite a bit more (such as logic, basic computer architecture/organization, basic I/O, and stuff like that). > > Do you mean those funny little pop up window thingies > IVTOOOBeginner_1? It would be nice to be able to > print them out. I do like hardcopy. From your IDE > Help menu I chose IVTOOOBeginner_1.exe to be greeted > with a source file I couldn't read. Nothing like the > DOS code? Except for the occasional move eax &FALSE. > I assume & means address? As I've said earlier, most RosAsm code looks like an explosion in an alphabet soup factory to me. And people like Wolfgang constantly complain that I tend to suggest that beginners concentrate on writing readable/understandable code rather than the tightest or most efficient code. Most of the RosAsm sample code I've seen (including Wolfgang's own Kesys program) amply demonstrate why it's important to write readable, understandable code. Especially when you're including that code as part of a "tutorial". Herein lies a major problem with the RosAsm tutorials I've looked at. They were written by people who've mastered (?) some subject, for their peers. The RosAsm team stands around and pats themselves on the backs because they've written all these "megas of tutorials" but they've never really tried them out on a large number of people to determine if they are practical or if they achieve what they are intended to achieve. To my knowledge, no one on the RosAsm team has any experience teaching a formal assembly language class. So they really have no idea what beginning assembly language programmers want or need. They just crank out this code and assume that it satisfies some need. Oh well, more power to them I suppose. Somebody *may* benefit from the work, and that's what really counts. But I suspect that most people are like you. They view these things and think "Okay, this is a nice demo, but it doesn't really teach me much." > > > > It seems that, dispiting the impressive time i and > > James spent at writing these Tutorials, we have missed > > our goal, at least for you, but i still don't know, > > exactly, why and how... > > > Maybe it's the IQ thing :) If you read through Rene's posts here on ALA, you will see him constantly criticizing my work as being "no work at all" or "simple rephrasing of others' work", etc., etc., etc. The RosAsm team has yet to figure out that writing good books, example code, tutorials, and tools that operate in a synergistic fashion to help beginners learn the material as rapidly and efficiently as possible isn't simply cranking out some demo code and some poorly written and organized documentation. It is a lot of work. Any tutorial that makes someone feel stupid, as Rene puts it, "misses the goal." > > Perhaps DOS is for dummies so I found it easy to > learn from a couple of assembler books? A low > level OS for a low level brain :) There is no reason the same books couldn't be written for Win32. It's not really "DOS vs. Windows" but rather "console apps vs. GUI apps." And you can write console apps in true WIN32 all the time. It's really easy. Particularly if you have a set of library routines like the HLA Standard Library. You don't have to get lost opening windows and doing all that GUI stuff when you're first learning Win32 APIs. You can write good old console apps, that are easy to comprehend. And then when you get up to speed on assembly, you can look at the Iczelion tutorials and other Win32 GUI sample code that teaches you how to write GUI apps. The problem you seem to be having is trying to learn too much at once. Concentrate on one thing at a time. Start with the x86 instruction set writing some console apps. *THEN* move on to the more complex Win32 APIs. I think you'll find this a more comfortable approach. BTW, both HLA and MASM32 provide good support for console applications in their libraries. > > I have just been looking at your RosAsm. I didn't > realise you had a Wizard there to create a form > template. I assume you than just add in code like > you do for VB? Indeed you seem to have a lot of > useful programming aids but I am not sure how i > would use them. The wizard is like the disassembler. More promise than reality at this point. Rene is promising us that someday RosAsm will be like VB or Delphi allowing you to create complex apps with just a few mouse clicks. But we've been hearing this for years now (since about 2000), so I wouldn't hold my breath if I were you. RadAsm, btw, has similar capabilities. > > There are issues like, you have the means to load > resources but I am not sure how you integrate this > into a program. Things like an image, for example, > in DOS the program would load it as a file into > some allocated memory location. I would have my > own display routines. Well, you can still do it like you've done it in DOS (reading files). Windows has APIs for embedded resources into the EXE file as well. But that's some of the more advanced APIs that I'd recommend you put off learning about until you get a little more comfortable with the basic x86 assembly stuff. Again, writing console apps will allow you to do things the way you did it under DOS, without the information overload of having to learn all these different APIs all at once. Later on, you can learn about resource compilers and how to link in those resources with your application files. And, btw, don't forget that RosAsm doesn't support static linking, a problem when using resources from different sources, IIRC. > > To test a tutorial I guess you need to sit a > complete beginner down and see where/if they > are not sure what to do next or cannot follow > the explanation. Yes, that's a large part of it. And I'm sure this process never occurred to the RosAsm team with respect to their tutorials. They have a long and storied history of ignoring what the marketplace really wants and taking it upon themselves to dictate what the market *ought* to want. They seem to be more interested in filling in bullets on a feature matrix and having as many bullets as possible rather than ensuring that the quality of those features is as high as possible. "You wrote a tutorial? Great, mark an "X" in that part of the feature matrix and let's move on to something else..." > > Thank you for your efforts in trying to work out > my issues. I am not sure what to do about them. Well, I'd stick with MASM and MASM32 if I were you. That seems to be the approach best suited for you. On the MASMForum, ask the people about standard in/out and console routines. I think you'll find that once you learn a few things, writing console apps will be as easy as writing DOS programs. Of course, HLA also makes writing console apps trivial, and best of all, they are portable to Linux should you decide to mess around with that OS. Cheers, Randy Hyde
From: Herbert Kleebauer on 30 Aug 2005 19:15 Betov wrote: > Herbert Kleebauer <klee(a)unibwm.de> ýcrivait > >> > But I very fast lost interest in Win32 > >> > assembly programming, because it mostly is a sequence of > >> > API calls and nothing I would call "assembly programming". > >> > >> Very funny Herbert but if what you say here about Assembly > >> is true, could you please explain to me why, C Programming, > >> under Win32, would still be "C Programming"? > > > > Only very small applications are written in assembler. > > ???!!!... And, in what term does this answer to my question? Ok, I will repeat it in short and simple sentences: If you write a program (doesn't matter whether you write in assembler or a HLL), then there is a part which is OS independent (like a numerical calculation or the conversion of an assembler source line into the binary opcode) and a part which is OS dependent (display graphics, get keyboard and mouse input etc.). Now, the first part I would call (assembly or C) "programming" whereas the second part doesn't deserve the name "programming", it is nothing but a sequence of calls to the OS. The complete thing can be called programming if the first part is at least of the same magnitude as the second part. If you implement the below program in DOS, than this can be called programming because only a few lines of code are necessary to do the OS calls. But if you implement it as a Windows program (and believe me, there is a stdin and stdout in Windows) then part 2 gets much bigger than part 1, so the whole thing doesn't deserve the name "programming". > > If > > you only need a few dozen lines of assembler code for the > > core program, then most of the source file is win32 overhead. > > But if a real application, written in a HLL, has many thousands > > of lines, then the win32 stuff maybe is acceptable. > > ???!!!... RosAsm Source, that is 3 Megas long calls > for about one hundread of Api Functions. RosAsm is written in assembler because it's author isn't able to recognize the advantage of HLLs for implementing larger applications. > ... And then???!!!... And then ... the author of RosAsm should do some programming in a HLL to see the advantage himself. You can't compare two things if you only have used one of them and always refused to also try the other. > > For example, you want to write a simple text filter program which > > reads from stdin and copies any printable ASCII character (0x20-0x7e) > > to stdout. > > The program shall terminate when any key is pressed. > > As a 16 bit DOS program, this is done in a few lines of assembler > > code. Now show us an equivalent Win32 program. > > DOS is dead since ages. You don't need DOS6.2 or older, Windows XP will execute this program without any problem (or is XP also dead since ages?). > > When ever possible, I also use only standard IO in C programs, so > > the program is OS independent and can be compiled with any C compiler > > on any system (why do you think does an assembler need a GUI?). > > Feel free to believe in things that do not exist, if you > like, but, to me, believing in something that does not exist > is a mental disease. About which "things that do not exist" are you speaking here? > I have compassions for your difficulties, but i fail to > understand in what term this could answer to my question. Your question was fully answered in the first few sentences of my posting. > I have payed to know that PEs are more complicated than > .com, but i fail to see why this would make them "awful". > "More complex" is not "awfull". I'm not speaking about the structure of a PE file compared to a com file, but about the Win32 API compared to the int21 interface. > > So an advice to all who want to learn > > assembly programming: do it in DOS (or in V86 mode of Windows) > > but not in Windows. > > This does not answer to my question, and is utterly faulse: > > Assembly Programing is _way_ easier than DOS programming ????? This sentence is like: "Driving a car is _way_ easier than driving on the highway". You can do assembly programing in DOS or Windows or you can do DOS programing in assembler or C, but how can you compare "assembly programming" with "DOS programing"? > > Assembly programming is programming the > > CPU (which is completely independent of the used OS) and not > > learning an awful OS API. > > Try to teach DOS without calling for any Int. One page is sufficient to explain anything necessary to start assembly programming in DOS (fopen, fclose, getc, putc, test and read keyboard, get mouse position, switch to graphics mode). Try the same with the Win32 API. > I just asked you a simple and clear question: > > "could you please explain to me why, C Programming, under > Win32, would still be "C Programming"?". And I gave you a simple and clear answer. > ... by simply _reversing_ a statement of yours, and to show > you at what extend your statement was absurd. Here, you just > make use a Method we are now very used to, thanks to Master > Randall Hyde swindling, that is, that, when locked in your > own contradiction, you just have to write two or three pages > of bullshits about something else. Please reread my previous posting.
From: JGCASEY on 30 Aug 2005 19:20 Betov wrote: [...] > I would suggest that you ask a bit less questions > at ALA, and that you read a bit more of Tutorials, > Demos and Documentations, and then, that you try to > do something not too complex, for a first hand. > > > Just clicking on "IVTOOOBeginner_1", and not even > reading the first lines cannot help a lot, and i > cannot read them for you (i and James had enough > work at writing them...). Ok. Enough of the questions. Just one last thing about the pop up window tuts. I like a 'module' of information per page without scrolling. I find it easier to read if the whole screen of data is there for the viewing without having to scroll. John.
From: Frank Kotler on 31 Aug 2005 01:11 JGCASEY wrote: .... > Its been six years since I last used assembler so I > am most likely a little bit rusty. By "local" variables > on the stack I assume something like this? Pretty much, yeah... > push bp > mov bp,sp This is enough to cover parameters passed on the stack. For "local"/"automatic" variables, we also need to subtract something from (e)sp - so we can push/pop without overwriting our variables. sub (e)sp, number of local variables * size of variable Normally, "size" would be two (bytes) for 16-bit code, and 4 for 32-bit code. IOW, the amount to subtract is the number of *bytes* taken up by local variables, even though they're probably mostly dwords. It's okay to have byte or word variables on the stack. If you come out with an "odd" number, you want to realign the stack,,, and (e)sp, -4 You might want a larger alignment than this - if you're using 64- or 128-bit variables, for example. > .. then you use [bp + displacement] > to access the variables, Yeah. [(e)bp + displacement] for the parameters, [(e)bp - displacement] for local variables, actually. > then exit with, First, we want to restore (e)sp to its original value: mov (e)sp, (e)bp This has the effect of "freeing" the local variables (this is why C calls this "automatic" storage). Needless to say, we don't want to alter (e)bp in the interim!!! In 16-bit code, [sp] isn't a valid addressing mode, but in 32-bit code, we *can* do [esp + displacement], so we *can* access parameters and locals that way. The "displacement" of a particular variable will change as we push/pop, so it's a PITA to keep track of, but it frees up ebp to use as a "general purpose" register, which is sometimes worthwhile. > pop bp > ret 4 ;remove 4 or whatever number from stack. Whether it's "ret number_of_bytes" or just "ret" depends on the calling convention. The Windows API uses "stdcall" in which "callee cleans up stack" - the Windows functions end with "ret N". The C calling convention expects "caller cleans up stack" - the C functions end with just "ret". We need to know which we're dealing with! Another issue is the "Intel ABI" (Application Binary Interface). Personally, I think it's a misleading name, since the hardware doesn't give a damn, but that's what it's called. Functions are allowed to trash certain registers, but are expected to return others the same way we found 'em. Registers that must be saved/restored if they're altered are ebx, esi, edi, ebp, and of course esp. The return value is normally in eax, maybe edx:eax - ecx is "scratch". Being an old dos-head, I'm used to using (e)cx as a "counter", and it annoys me that calling libc or the Windows API is allowed to trash it, but that's life... In your *own* routines, you can do it any way you like (more "maintainable" if you're consistant), but if you're calling Windows you can expect that behavior, and if Windows is calling you (your WndProc, for example), then your routine has to obey these rules. .... > However I couldn't find > the "teach yourself Window Assembler programming > in 21 days" book :) "Windows Assembly for Dummies" is right there on the bookshelf next to "Military Intelligence" and "Jumbo Shrimp" :) Betov makes a good point that you don't really "learn" the entire Windows API. You need to learn how to navigate the documentation and *find* the API(s) you need. I suppose this gets easier with practice. I've spent *no* time with Windows documentation, so the clock hasn't even started ticking for me :) .... > So what kind of programs do you write these days? "Hello World" for Linux, mostly - not literally "Hello World", but nothing too advanced. I suppose I'm "learning" the Linux API, a little bit at a time. .... > I have already got as far as "processing" an image > using the QuickCam in dos and in a VC++ shell with > a LogiTech webcam. That should be a good start - at least you'll know what to do with the camera. > It is the fairly simple API > stuff I have to get my head around. There must be some kind of "Quick Start" document - "The Dozen Most Frequently Used APIs", or "21 APIs in 21 Days", or something. If there isn't, perhaps there should be. I *thought* that's more or less what Iczelion's tuts did... > The VC++ shell > was written using the MFC Wizard by someone else > not willing to show me how it was done. That'd be "OOP", I guess - where "information hiding" is condidered a *good* thing (!). Perhaps *not* a good place to start if you want to learn to do it yourself... > When I saw the FASM example I thought cool, I > wonder how hard that would be? Well, it doesn't look too bad. Can you get it to "work", as far as it goes? I think I mentioned that I sponged a USB camera, so that I could "follow along", maybe learn how to do it in Linux... When I went to plug it in, I find I haven't *got* a USB port on this machine! (thought I did...) So that's not going to be happening... unless I can figure out what happened to the parallel-port camera I *used* to have... I still find the project "interesting". Best, Frank
From: Evenbit on 31 Aug 2005 04:27
Herbert Kleebauer wrote: > > DOS is dead since ages. > > You don't need DOS6.2 or older, Windows XP will execute this > program without any problem (or is XP also dead since ages?). Actually, it depends on which build of XP. I believe I read where they removed most of the DOS (backwards-compatibility) functionality from the 64-bit version of XP. So your BAT files and COM proggies prolly won't work on it. Nathan. |