Iczelion's tutorials revisited.
in [ASM]
|
From: Alex McDonald on 5 Sep 2005 06:31 anonymous wrote: > "Alex McDonald" <alex_mcd(a)btopenworld.com> skrev i en meddelelse > news:1125608344.889032.313180(a)g49g2000cwa.googlegroups.com... > >>anonymous wrote: > > >>>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. > > Coding in assembly in Linux or Windows (or any other OS) on a x86 machine > will be exactly the same "call" is still "call", "push" is still "push", > "mov" is still "move", etc. What changes when you change OS is the > environment, meaning how you interface the operating system (which call's or > int's will have surtain functions) and how you interface the operating > system to again interface the hardware. > Therefore Assembly instructions don't change. The only time when assembly > changes is when you the hardware, when foreinstance you replace your pentium > IV chip with a z80 or motorola chip. In most applications written for large, complex OSes the amount of code that doesn't inetract with the OS is relatively small. I agree that a call is a call, but drawing a window under X or Windows is more than just a different set of calling parameters; the techniques are fundamentally quite different. > > >>>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. > > This was supposed to be read as an explanation to the fourth statement: > "Fourth, there are no _standard_ StdIn/StdOut/StdErr calls between OSes!" But here the techniques are the same (as opposed to the example above). Windows and Unices all have a handle that writes to a standard output, for example -- the difference is getting the handle under Windows requires some extra work. > STD_INPUT_HANDLE, etc. are indeed constants, I was not referring to the > handle > you receive from GetStdHandle, but the constant you supply it. > > But actually the constants StdIn/etc. are not always from 0 through 2, as > you state. > I didn't bother to check their actual values, merely assumed they were the > same as in linux, but apparently not. > they have values from 0F4h through 0F6h. They have values 0xFFFFFFF6 through 0xFFFFFFF4; signed -10 through -12. >> >>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. > > > They were merely statements, though I believe them all to be true, they > could be true or false. :) But the factual ones are easily checked; are you too lazy look it up and get it right? -- Regards Alex McDonald
From: anonymous on 5 Sep 2005 11:15 For reference I'll just repost the original statements: [1.] first of all to my understanding portability is merely illusion! [2.] second, show me the Win32 C program that isn't Win32Asm! [3.] third, Assembly [instructions] is universal, it doesn't change from OS to OS (only from hardware to hardware)! [4.] Fourth, there are no _standard_ StdIn/StdOut/StdErr calls between OSes! [5.] Fifth, programming resides in taking advantage of the functions one has in order to do useful things! (For a more in depth explanation of the different statements refer to my original statement.) Number 2 should probably have been: "A win32 C program is a win32asm program" or something to qualify as a statement, but the meaning of the old one should be clear enough anyhow. Alex McDonald wrote: > In most applications written for large, complex OSes the amount of code > that doesn't inetract with the OS is relatively small. I agree that a call > is a call, but drawing a window under X or Windows is more than just a > different set of calling parameters; the techniques are fundamentally > quite different. Which is one of the reasons why portability is an illution. [1.] >>>>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. >> >> This was supposed to be read as an explanation to the fourth statement: >> "Fourth, there are no _standard_ StdIn/StdOut/StdErr calls between OSes!" > > But here the techniques are the same (as opposed to the example above). > Windows and Unices all have a handle that writes to a standard output, for > example -- the difference is getting the handle under Windows requires > some extra work. wouldn't the fact that you 'push & call' the windows function and the fact that you 'mov reg, val & int 80' apply for difference in both technique/method and the call itself? >> STD_INPUT_HANDLE, etc. are indeed constants, I was not referring to the >> handle >> you receive from GetStdHandle, but the constant you supply it. >> >> But actually the constants StdIn/etc. are not always from 0 through 2, as >> you state. >> I didn't bother to check their actual values, merely assumed they were >> the same as in linux, but apparently not. >> they have values from 0F4h through 0F6h. > > They have values 0xFFFFFFF6 through 0xFFFFFFF4; signed -10 >through -12. Sorry, my bad, I expected those to read the same, afterall, 0F4h = signed -12, and 0F5h = signed -10, just not dwords. >>> >>>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. >> >> >> They were merely statements, though I believe them all to be true, they >> could be true or false. :) > > But the factual ones are easily checked; are you too lazy look it up and > get it right? I thought I had already done that, which factual statements were wrong? greetz, :?) Jakob Wrigley
From: Alex McDonald on 5 Sep 2005 12:12 anonymous wrote: > For reference I'll just repost the original statements: > [1.] first of all to my understanding portability is merely illusion! I still agree; it's an illusion that works. > [2.] second, show me the Win32 C program that isn't Win32Asm! > [3.] third, Assembly [instructions] is universal, it doesn't change from OS > to OS (only from > hardware to hardware)! > [4.] Fourth, there are no _standard_ StdIn/StdOut/StdErr calls between OSes! > [5.] Fifth, programming resides in taking advantage of the functions one has > in order to do useful things! > (For a more in depth explanation of the different statements refer to my > original statement.) > Number 2 should probably have been: "A win32 C program is a win32asm > program" or something to qualify as a statement, but the meaning of the old > one should be clear enough anyhow. > > Alex McDonald wrote: > >>In most applications written for large, complex OSes the amount of code >>that doesn't inetract with the OS is relatively small. I agree that a call >>is a call, but drawing a window under X or Windows is more than just a >>different set of calling parameters; the techniques are fundamentally >>quite different. > > Which is one of the reasons why portability is an illution. [1.] My original answer was in response to (3). Portability is more than just at the level discussed here. Take, for instance, a Web server like Apache running MySQL and PHP. The portability between Windows and Unix is just about complete. I can transplant my entire website from one to the other without a single change. Another example; there are portable graphics windowing libraries, such as wxWidgets. The issue is at what level the portability is provided. It can be quite low level, or quite high level. Portability is about an illusion; the illusion works, if you're willing to work at it. The lower you go (for instance, down to the OS level) the harder it is to provide portability; but it's not impossible, just a lot of hard work. Look at wine for instance; Windows emulation under Linux. Slightly higher up the tree are Mono, which will (when complete) allow .Net applications to run seamlessly on Linux or Windows, and Java which already provides x-platform portability across a wide range of platforms. Back to point (3); with most apps, the amount of code that doesn't interact with the OS is small. There are major differences between assembly programming between different OSes (and major differences between assemblers too, although some are x-platform). Even so, they can be portable. > > >>>>>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. >>> >>>This was supposed to be read as an explanation to the fourth statement: >>>"Fourth, there are no _standard_ StdIn/StdOut/StdErr calls between OSes!" >> >>But here the techniques are the same (as opposed to the example above). >>Windows and Unices all have a handle that writes to a standard output, for >>example -- the difference is getting the handle under Windows requires >>some extra work. > > wouldn't the fact that you 'push & call' the windows function and the fact > that you 'mov reg, val & int 80' apply for difference in both > technique/method and the call itself? At that low level, straight portability of code isn't possible. I may not be able to assembler and run Windows code on Linux directly, but portability by emulation or harness is possible; code written for Windows using standard handles will run fine on Linux under wine. > > >>>STD_INPUT_HANDLE, etc. are indeed constants, I was not referring to the >>>handle >>>you receive from GetStdHandle, but the constant you supply it. >>> >>>But actually the constants StdIn/etc. are not always from 0 through 2, as >>>you state. >>>I didn't bother to check their actual values, merely assumed they were >>>the same as in linux, but apparently not. >>>they have values from 0F4h through 0F6h. >> >>They have values 0xFFFFFFF6 through 0xFFFFFFF4; signed -10 >>through -12. > > Sorry, my bad, I expected those to read the same, afterall, 0F4h = > signed -12, and 0F5h = signed -10, just not dwords. > > >>>>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. >>> >>> >>>They were merely statements, though I believe them all to be true, they >>>could be true or false. :) >> >>But the factual ones are easily checked; are you too lazy look it up and >>get it right? > > I thought I had already done that, which factual statements were wrong? The one's you corrected above about handles and their values. -- Regards Alex McDonald
From: anonymous on 5 Sep 2005 17:32
Alex McDonald wrote: > anonymous wrote: >> For reference I'll just repost the original statements: >> [1.] first of all to my understanding portability is merely illusion! > > I still agree; it's an illusion that works. > >> [2.] second, show me the Win32 C program that isn't Win32Asm! >> [3.] third, Assembly [instructions] is universal, it doesn't change from >> OS to OS (only from >> hardware to hardware)! >> [4.] Fourth, there are no _standard_ StdIn/StdOut/StdErr calls between >> OSes! >> [5.] Fifth, programming resides in taking advantage of the functions one >> has in order to do useful things! >> (For a more in depth explanation of the different statements refer to my >> original statement.) >> Number 2 should probably have been: "A win32 C program is a win32asm >> program" or something to qualify as a statement, but the meaning of the >> old one should be clear enough anyhow. >> >> Alex McDonald wrote: >> >>>In most applications written for large, complex OSes the amount of code >>>that doesn't inetract with the OS is relatively small. I agree that a >>>call is a call, but drawing a window under X or Windows is more than just >>>a different set of calling parameters; the techniques are fundamentally >>>quite different. >> >> Which is one of the reasons why portability is an illution. [1.] > > My original answer was in response to (3). > > Portability is more than just at the level discussed here. Take, for > instance, a Web server like Apache running MySQL and PHP. The portability > between Windows and Unix is just about complete. I can transplant my > entire website from one to the other without a single change. Another > example; there are portable graphics windowing libraries, such as > wxWidgets. > > The issue is at what level the portability is provided. It can be quite > low level, or quite high level. Portability is about an illusion; the > illusion works, if you're willing to work at it. > > The lower you go (for instance, down to the OS level) the harder it is to > provide portability; but it's not impossible, just a lot of hard work. > Look at wine for instance; Windows emulation under Linux. Slightly higher > up the tree are Mono, which will (when complete) allow .Net applications > to run seamlessly on Linux or Windows, and Java which already provides > x-platform portability across a wide range of platforms. > > Back to point (3); with most apps, the amount of code that doesn't > interact with the OS is small. There are major differences between > assembly programming between different OSes (and major differences between > assemblers too, although some are x-platform). Even so, they can be > portable. > >> >> >>>>>>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. >>>> >>>>This was supposed to be read as an explanation to the fourth statement: >>>>"Fourth, there are no _standard_ StdIn/StdOut/StdErr calls between >>>>OSes!" >>> >>>But here the techniques are the same (as opposed to the example above). >>>Windows and Unices all have a handle that writes to a standard output, >>>for example -- the difference is getting the handle under Windows >>>requires some extra work. >> >> wouldn't the fact that you 'push & call' the windows function and the >> fact that you 'mov reg, val & int 80' apply for difference in both >> technique/method and the call itself? > > At that low level, straight portability of code isn't possible. I may not > be able to assembler and run Windows code on Linux directly, but > portability by emulation or harness is possible; code written for Windows > using standard handles will run fine on Linux under wine. > >> >> >>>>STD_INPUT_HANDLE, etc. are indeed constants, I was not referring to the >>>>handle >>>>you receive from GetStdHandle, but the constant you supply it. >>>> >>>>But actually the constants StdIn/etc. are not always from 0 through 2, >>>>as you state. >>>>I didn't bother to check their actual values, merely assumed they were >>>>the same as in linux, but apparently not. >>>>they have values from 0F4h through 0F6h. >>> >>>They have values 0xFFFFFFF6 through 0xFFFFFFF4; signed -10 >>>through -12. >> >> Sorry, my bad, I expected those to read the same, afterall, 0F4h = >> signed -12, and 0F5h = signed -10, just not dwords. >> >> >>>>>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. >>>> >>>> >>>>They were merely statements, though I believe them all to be true, they >>>>could be true or false. :) >>> >>>But the factual ones are easily checked; are you too lazy look it up and >>>get it right? >> >> I thought I had already done that, which factual statements were wrong? > > The one's you corrected above about handles and their values. Seamingly we agree, I agree with all you've written, I don't see the contradicting parts, but if we agree I guess that would remove contradictions ;-) Greetz, :p) Jakob Wrigley |