Iczelion's tutorials revisited.
in [ASM]
|
From: Evenbit on 31 Aug 2005 17:34 f0dder wrote: > Evenbit wrote: > > 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. > > It's not that they removed DOS functionality - the 64bit processors > simply don't support 16bit legacy apps when working in "long mode", > so Microsoft would have to include a full CPU emulator in XP64 to > enable you to run 16bit apps... 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? Nathan.
From: JGCASEY on 31 Aug 2005 17:42 Betov wrote: >> Try to do: > >> call 'USER32.MessageBoxA' &NULL, >> {'How are you?', 0}, >> {'Message', 0}, >> &MB_OK > > >> ... in Dos. And be prepared for around 40 Pages of very >> complex Source. > > Herbert Kleebauer wrote: > Now you are really joking ?!? The DOS version is: > > move eax,pointer_to_text > call MessageBox There is a little bit more functionality in the Window's MessageBox. You would need a structure to hold its properties. Maybe push the details onto the stack, or copy vales into the structure and than call MessageBox. create structure then, mov eax,pointer_to_MessageBoxStruct call MessageBox > There is absolutely no difference for Win32 or DOS. There is of course a major difference in functionality in the sense that Win32 is a multitasking environment. > All you have to do is, to push the parameters onto > the stack or store them into registers and then > call the subroutine. Your "USER32.MessageBoxA" is > nothing but a subroutine within the address space > of your program and executed in user mode (and > isn't an OS call at all). Now you can argue, that > you don't had to write the function, Microsoft has > done this for you. But maybe I also hadn't to write > the DOS MessageBox function, a friend could have > done this for me. Exactly. And a program full of invokes is almost HLL. > You are arguing exactly like Randy: all you need > is a powerful library, then assembly programming is > trivial. If any function you ever need, is already > written and available in a library, then learning > assembly programming can be reduced to just learn > the call instruction. Agreed. HLL. > The only difference is, that Randy has written his > HLA library himself, whereas you have paid Microsoft > to write kernel32.dll, user32.dll, etc. for you. > > > I must admit, that I only know very few Win32 > functions, but as far as I know, MessageBox is > the only graphical output which doesn't require > a RegisterClass, so your example isn't typical. > > > Let's make a simple graphics program: Draw a red, > blue and green square on the screen with a black > background. If the mouse pointer is moved within > one of this squares, the background should change > to the color of this square. Show us the Win32 > assembler program and I will write the DOS > version. Then we can compare both programs and > decide which looks more like an assembler program > and which has less OS overhead. Easy in DOS :) What screen mode do you want? Is it to also include a rectangular window in which the squares reside? One we can move around and resize perhaps? Some things can be done with DOS and developed with DOS because their functionality is not dependent on a multitasking OS. Windows is made much easier in the sense someone has written lots of neat APIs to do much of the standard stuff programmers use and of course provide a standard environment to share code and provide a standard user interface. A HLL is really a means to call and pass parameters to a library of useful functions. They are programs written by writing a list of subroutines to call or maybe macros to insert. Some to set up control structures and so on... John.
From: f0dder on 31 Aug 2005 20:46 Evenbit wrote: > 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 :)
From: Betov on 1 Sep 2005 04:53 "JGCASEY" <jgkjcasey(a)yahoo.com.au> ýcrivait news:1125524554.521342.252410 @g43g2000cwa.googlegroups.com: > A HLL is really a means to call and pass parameters > to a library of useful functions. They are programs > written by writing a list of subroutines to call > or maybe macros to insert. Some to set up control > structures and so on... Evident. The OS calls are the OS calls, and there is nothing (or very poor things...) we can change to this. But, would you OS call be a DOS Int or a Win32 Api, the only thing that matters, for an Assembly Programmer, is that it is "Black Box" calls, and there is no difference, at this point of view, but one: The DOS Ints are way primitive than the Win32 Api, and do way less. This does not change an inch to the fact that Assembly programming is Assembly Programming, under whatever OS, as long as only a very high percentage of the Source are _NOT_ OS calls, neither in DOS nor in Win32 Programming. Betov. < http://rosasm.org >
From: Betov on 1 Sep 2005 05:09
Herbert Kleebauer <klee(a)unibwm.de> ýcrivait news:4316005D.167ECC72 @unibwm.de: > Did you read a single sentence of what I wrote? Yes. >> 1) You say that Win32 Asm is not Asm, because it calls >> to Api Functions. > > No, I said that I don't call it assembly "programming" This is your problem: What you "call assembly programming" is _your_ vision of Asm Programming, and your opinion, on this point has no interrest, at all, as it is irrational, > if you write an assembler source file where most of the code > fills in some data structures for OS calls or do the OS calls This does not exist in real Life Applications. I suppose that you base your comment on the Win32 Asm Demos, that, exactely, are about how to call for the Api. In real life Applications witten in Assembly, the percentage of Api calls is low. > whereas only a few lines are there which does the actual > computing. Read RosAsm Source, and go and search for the Api calls... Tip: There is a Menu Option for showing them to you, with counts, jumps to the instance, and all... > Now you only have to explain, why this "thousands of way > more advanced functionalities" are necessary for learning > assembly programming? I rarely talk about "learning assembly programming". Assembly is not a language for learning Assembly, mind you. >> Ridicoulous claim, with no base. One line is enough, in >> Win32 Asm to output a complex thing like a MessageBox. > > I said: "anything necessary to start assembly programming in DOS" > To be able to display a message box on the screen surely isn't > sufficient for learning assembly programming. There is no reason for learning Assembly with a dead OS, whereas it is way easier to learn with the actual one. >> Try to do: >> >> call 'USER32.MessageBoxA' &NULL, >> {'How are you?', 0}, >> {'Message', 0}, >> &MB_OK >> >> ... in Dos. And be prepared for around 40 Pages of very >> complex Source. > > > Now you are really joking ?!? The DOS version is: > > move eax,pointer_to_text > call MessageBox In case you did not notice, the most trivial and simpliest Api function implies having a complete Mouse and KeyBoard Management, default processing, priorities in Multi-Task, Graphism, and so on. Mind you, when i was writting my DOS-times Applications, i was used to have them working in Graphical Mode, with Mouse, Menus, and all... So, i have payed to know something about the simple overhead of having a decent Mouse Manager, in a DOS App. Betov. < http://rosasm.org > |