Iczelion's tutorials revisited.
in [ASM]
|
From: randyhyde@earthlink.net on 29 Aug 2005 13:37 Herbert Kleebauer wrote: > JGCASEY wrote: > > > > I am still keen to spend time learning some Windows > > assembler as it can only make it easier to understand > > how the Win32 APIs are used. > > Forget about all the second level documentation. For > the processor use the processor manuals from Intel or > AMD and for the Win32 API use the documentation at msdn.com. Sure. Spend months and months wondering why you would use some particular API rather than figuring it out in a few minutes from some "second level documentation." > If you really want to know what happens within an exe file, > select a small exe file (I used write.exe which comes with > Windows) and the exe file format specification and try > to identify any byte within the exe. Remove anything which > isn't necessary for a minimal executable. Then step by step > add additional API calls and save the documentation for this > API functions so you get your own API handbook for all the > API calls you used. Great for learning the binary format of a file. Then what? How does this help you write Win32 apps in assembly? > But I very fast lost interest in Win32 > assembly programming, No wonder. Doing what you were doing would bore just about anyone to death. Most people aren't really learning the APIs because it sounds like a good idea. They're learning the APIs because they want to write actual applications. Much better to have a tutorial that teaching them how to write applications in a top-down fashion rather than a bottom-up fashion. Regardless of what a few people around here believe, bottom-up education is *not* natural for most people. > because it mostly is a sequence of > API calls and nothing I would call "assembly programming". And therein lies the problem with the bottom-up approach. You spend all your time learning API calls rather than concentrating on using assembly language to actually *solve* problems. > It is much more fun to directly access the hardware in a > DOS program (even if only emulated by Windows in V86 mode). Perhaps to you. This statement isn't universally true. > > Here the source of such a miniumal Win32 console program: And how does this teach someone how to write assembly applications under Win32? Cheers, Randy Hyde
From: Betov on 29 Aug 2005 15:44 Herbert Kleebauer <klee(a)unibwm.de> ýcrivait news:431344C1.8AE6C114(a)unibwm.de: > 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"? Betov. < http://rosasm.org >
From: wolfgang kern on 29 Aug 2005 16:51 JGCASEY wrote: [...] | I am still keen to spend time learning some Windows | assembler as it can only make it easier to understand | how the Win32 APIs are used. All you need is "Win32.hlp" (~24MB) Microsoftý Win32ý Programmer's Reference I can't tell where the official source for it is, looks like it's only available within the whole M$-SDK pack. I once got my copy from a fellow. Most of the function usage is explained in C-style, but translation into pure ASM is easy, ie: BOOL DrawIconEx( HDC hdc, // handle to device context int xLeft, // x-coordinate of upper left corner int yTop, // y-coordinate of upper left corner HICON hIcon, // handle to icon to draw int cxWidth, // width of the icon int cyWidth, // height of the icon UINT istepIfAniCur, // index of frame in animated cursor HBRUSH hbrFlickerFreeDraw, // handle to background brush UINT diFlags // icon-drawing flags ); may become in HL-RosAsm: call 'USER32.DrawIconEx', HDC hdc, ; handle to device context int xLeft, ; x-coord of upper left corner int yTop, ; y-coord of upper left corner HICON hIcon, ; handle to icon int cxWidth, ; icon width int cyWidth, ; icon height UINT istepIfAniCur, ; frame index, animated cursor HBRUSH hbrFlickerFreeDraw, ; handle to background brush UINT diFlags ; icon-drawing flags or with LL-RosAsm (with the more visible order on stack ): push 0 ;&DI_... push eax ;handle to bg-brush push 1 ;frame index cursor push 64 ;H push 64 ;W push D$ICONhdl2 push 1 ;y push 620 ;x push D$WDC |call 'USER32.DrawIconEx' or will become in FASM/NASM LL-style: push 0 ;&DI_... push eax ;handle to bg-brush (from previous..) push 1 ;frame index cursor push 64 ;H push 64 ;W push dword [ICONhdl] push 1 ;y push 620 ;x push dword [WDC] call 'USER32.DrawIconEx' ;or any similar syntax there __ wolfgang
From: randyhyde@earthlink.net on 29 Aug 2005 18:26 wolfgang kern wrote: > > may become in HL-RosAsm: > > call 'USER32.DrawIconEx', > HDC hdc, ; handle to device context > int xLeft, ; x-coord of upper left corner > int yTop, ; y-coord of upper left corner > HICON hIcon, ; handle to icon > int cxWidth, ; icon width > int cyWidth, ; icon height > UINT istepIfAniCur, ; frame index, animated cursor > HBRUSH hbrFlickerFreeDraw, ; handle to background brush > UINT diFlags ; icon-drawing flags Wow! Rene must have added a lot of new features recently! I don't ever remember seeing RosAsm support HDCs, ints, HICONs, UINTs, and HBRUSHes :-). Obviously, the above is syntactically incorrect, suffering from a case of cut&paste. Of course, the cool thing is that assemblers like MASM and HLA actually let you specify similar things to this. And, of course, MASM and HLA also let you work in low-level code, just like RosAsm and FASM. E.g., or will become in MASM LL-style: pushd 0 ;&DI_... push eax ;handle to bg-brush (from previous..) pushd 1 ;frame index cursor pushd 64 ;H pushd 64 ;W push ICONhdl pushd 1 ;y pushd 620 ;x push WDC call DrawIconEx ;or any similar syntax there or will become in HLA LL-style: pushd( 0 ); //&DI_... push( eax ); //handle to bg-brush (from previous..) pushd( 1 ); //frame index cursor pushd( 64 ); //H pushd( 64 ); //W push( ICONhdl ); pushd( 1 ); //y pushd( 620 ); //x push( WDC ); call w.DrawIconEx Amazing how similar these instruction sequences are. Yet a few people around here keep insisting that MASM and HLA are HLLs, not assemblers. Hmmm... Cheers, Randy Hyde
From: JGCASEY on 29 Aug 2005 18:27
randyhyde(a)earthlink.net wrote: > Betov wrote: Betov wrote: >> "JGCASEY" <jgkjca...(a)yahoo.com.au> écrivait news:1125313208.846362.289800 >> @z14g2000cwz.googlegroups.com: > >> > This is a reasonable comment. You've made me realise I >> > have been ranting away without really giving it a fair >> > go. Partly I guess I have been expressing my frustration >> > at getting started and deciding the best way to go about >> > it while feeling there must be an easier way. > > >> _My_ problem is that i fail to imagine what could be made >> easier and how... > > > Actually, there are lots of things that could be done > to make the whole learning process easier. First of all, > and probably most important, the Iczelion tutorials are > a disconnected bunch of examples that demonstrate how to > make certain Win32API calls. The one thing they don't > particularly do is answer *why* you would want to make > these calls. That is, they are focused on demonstrating > particular API calls rather than on demonstrating how > you solve real application problems. This is *exactly* > the same problem one has, for example, when trying to > learn assembly by reading only the Intel Reference > manuals (as Wolfgang suggests) or trying to learn > assembly language by reading an assembler's manual. > > >> > The Iczelion tuts are written for MASM so I figured >> > that I should use MASM. > > >> I warned you that MASM was the worst of the available >> Assemblers, and that Iczelion Tutorials had been ported >> to almost all of the good Assemblers around. > > > I didn't realize John was complaining about the quality > of the MASM code, only that the FASM and MASM versions > were different. Indeed, from what I infered from John's > remarks, it was *exactly* using these other assemblers > that caused the problems, not using MASM. > > [...] > > > How about decent tutorials that teach you how to solve > problems rather than simply teach you what API functions > do? You have read me correctly Randy. While perusing your "Windows Programming in Assembly Language" I read, "Petzold estimates this (mastering the Win32 API set) at six months for an established C programmer" my heart sank and I thought, oh sh*t, I wonder how many hours per day that would be. And how long for an unestablished C programmer. Of course I may not need to *master* the Win32 API set only figure out how to use the ones relevant to my limited needs. I am not out to write large Window assembler programs. I am happy to use Java. --------------------------------- At the Win32ASM Community messageboard in Win32ASM Main a post from Bronty on Multiple Webcams http://www.scrontsoft.com/win32asm/webcamapp.zip How easy would that be to convert to a "readable" HLA source code? --------------------------------- This is the kind of stuff I would like to be able to understand and modify (or even write) for my own projects. I see myself writing some kind of generic shell in which I can develop a library of modules tailored to my personal interests. I am not sure what skill level I must reach to do this. There are many things you can do in Windows that don't interest me. I just want to write small stand alone code, like the example above, that makes use of things like a webcam and the GUI image display. The rest of the code doesn't need any other Window stuff and could just as easily run in DOS. Indeed if you don't want the GUI you don't even need Windows. When a computer is used to run a single application with text i/o DOS is good enough... until you need to hook up to hardware, or other software, that only supports Windows! I noticed that here, in Australia, that many of the retail outlets have what appears to me to be DOS text displays. Of course the supermarkets have the fancy graphic displays which they use to advertise products at the checkout. I call it all dross and gloss :) Cheers, John Casey |