Iczelion's tutorials revisited.
in [ASM]
|
From: Alex McDonald on 1 Sep 2005 16:59 anonymous wrote: > Hi all, been watching the last couple of days, decided to join in with the > fire fighters (?) in the bushfight ;) > > I shall come with these statements: > first of all to my understanding portability is merely illusion! > second, show me the Win32 C program that isn't Win32Asm! > third, Assembly is universal, it doesn't change from OS to OS (only from > hardware to hardware)! > Fourth, there are no _standard_ StdIn/StdOut/StdErr calls between OSes! > Fifth, programming resides in taking advantage of the functions one has in > order to do useful things! > > > 1. Portability is illution, because portability is based on library calls, > with different libraries for different OSes. The best illusions are those that make you believe that they're not illusions. Like portability; it's an illusion that works. > 2. If the programmer creates a program in Win32 C (which is also in > Win32Asm) and that can be referred to as "programming" then why can win32Asm > programmer not write the same program and that be called "programming" as > well? I think you're confused here. Who said otherwise? > 3. The true assembly are the same regardless of os, only address and method > varies when addressing OS calls. Again, I think you'll find it very different from OS to OS. Solaris on x86 is different from Linux is different from MINIX is different from Windows. > 4. StdIn/etc. are just numbers/ constants from 0 through 2. The calls to use > them are different in every OS. In C however this is hidden under standard > library calls. Funny, on my copy of WinXP, GetStdHandle calls for STD_ERROR_HANDLE STD_INPUT_HANDLE and STD_OUTPUT_HANDLE return 11, 7 and 3. > 5. This means using or not using OS calls or library calls is equivalently > programming, the assembly mnemonics are merely the programming library of > the processor. Unclear what you mean here. > > Now for a bit about myself, I'm a beginner, You're best doing a bit more study and research; stating as fact something that's demonstrably untrue, as with handles, isn't very productive. -- Regards Alex McDonald
From: Betov on 1 Sep 2005 17:21 "anonymous" <wrigley(a)tuknet.dk> ýcrivait news:ec827$431763de$3e3d8699 $24317(a)news.arrownet.dk: > In my oppinion tutorials should never use predefined constants If you are talking about Win32Asm, making use of the Win32 is a real advantage. Depends, of course on what Assembler you use, but FASM comes with its Files to include, and RosAsm comes with more than 62,000 integrated Equates, that you do not even have to care of. Using the Numbers would be a real pain... Betov. < http://rosasm.org >
From: randyhyde@earthlink.net on 1 Sep 2005 17:40 anonymous wrote: > > In my oppinion tutorials should never use predefined constants or predefined > macros in the first couple of tutorials and then if they wish to use them, > the tutorial should describe and explain them, so the reader is included in > the making of these predefined things. How would a beginner ever understand > something predefined, when "pre" is "pre" as in before the first > tutorial/lesson? It depends on the "pre" as in "prerequisites". Every tutorial has to assume a certain amount of prerequisite knowledge on the part of the reader. For example, the Izcelion tutorials, for beginning Win32 API programmers working in assembly language assumes that you're already familiar with MASM, etc. Some "beginning assembly language tutorials" (e.g., Art of Assembly) assume that you're proficient in a high-level language before starting the lesson plan. Those books and schemes that *do* start at ground zero, often fail to progress very far. But if you want a good example of a book that does a reasonable job, take a look at Jeff Duntemann's "Assembly Step-By-Step". It's intended for people with *no* programming experience whatsoever; although most people who read the book have some programming experience, they like the fact that it makes no assumptions about prerequisite material, so even though they wind up reviewing a lot of material, they don't miss anything either. Sounds like just the ticket for you. Cheers, Randy Hyde
From: wolfgang kern on 1 Sep 2005 15:55 Rene against Herbert ??? I can't believe in. This two worlds of ASM may have got more in common than being apart. The difference is the used/preferred syntax, but the common things I'd see are how to avoid all the useless detours from 'great books'. __ wolfgang
From: wolfgang kern on 1 Sep 2005 15:41
f0dder answered Evenbit: | > What exactly does "16bit legacy app" mean? Does this mean that any | > piece of code that contains a "MOV AX, 123" will cause the machine to | > emit a puff of smoke? If so, then it really isn't an x86 CPU then, is | > it? | | 16bit legacy app would be an application running in realmode (and 16bit | protected mode as well, I suppose). At least v86 isn't supported while | the processor is in "long mode". | | 32bit applications will continue to run, and "MOV AX, 123" is a valid | 32bit instruction, with a 66h prefix. | | Somebody with a better knowledge of "long mode" should kick in, though, | my knowledge is currently pretty brief :) As far I understood (I wont buy one of these new 64' gadgets, even I support it with my disassembler to be aware of what's available), long modes: either the true 64-bit-bit mode (that's the one which let you access extended registers and RIP addressingh), or the other long mode (which got extented paging and allow almost all well known 32-bit stuff). But we all should read the AMD64/EMT64 manuals one more time, there are restrictions in both, adressing modes and operand sizes while running in 64-bit mode. 16/32-bit operands ???, 16/32-bit adressing ??? Please check my Hextutor (google), and tell me where it may be wrong. __ wolfgang |