I think that there cannot be any OOP in MASM at all! C++ rules in OOP! And no ASM at OOP programming party!
Posted on 2001-03-14 12:02:00 by IGosha
First seeing as C++ eventually compiles down to asm anyway surely anything thats possible in C++ is possible in ASM. But regarding OOP, as far as I can see its only a collection of structres that rigidly control how values get added and outputed plus it can proform it own operations on the values. Maybe I'm wrong about what OOP is but this is very possible in ASM. To quote something I read elsewhere, OOP is not a language, just a frame of mind. This message was edited by Zadkiel, on 3/14/2001 2:21:38 PM
Posted on 2001-03-14 13:18:00 by Zadkiel
Yes, it is certainly a state of mind. If you want to go outside the object definitions that is fine in ASM, but don't expect your code to work everywhere. Take COM for example: if you know after calling function X of Y, that ecx pointed to the private members of the object you just used. If you play with those properties directly, you destroy the object concept by crossing that boundary. There are many imaginary boundaries in life - they aren't crossed for reasons - not because they aren't crossable! Just my twisted view, bitRAKE
Posted on 2001-03-14 13:55:00 by bitRAKE
The main thing is that the Language must support abstractions. Abstractions from data types, even the computer where it is run (DCOM). But Asm does not support it at all. So it is not portable, not reliable enough to use for modern programming techniques. It is coming to death, considering that some time passes and there wouldn't be only Desktop PCs, but more other types - and ASM people wouldn't be able to port any app for more than one platform, even just one CPU.. So ASM is dead..
Posted on 2001-03-14 14:07:00 by IGosha
I remember java zealots telling the exact same thing about c++ :P
Posted on 2001-03-14 15:25:00 by Hiroshimator
Hi Language "MUST" support abstractions :) :D LOL The only thing that ANY language must support now is ASM... because you see..the compiler has to do the job of converting any "super trupper" OOP nonsense to ASM so that the micro can execute it....so unti you have micros that are programable in C++ or Java directly...you will ALLWAYS need ASM ans some guys that know ASM to make your compilers :) besides "abstractions" are a "mind trick" and are possible in any language...ASM or not... OOP and C++ and Java so called "High" level languages have some advantages for the corporations that OWN 1.000+ programmers but elsewhere they are just plain INEFICIENT ...the best way to make your 1 Gigaherts PC look and work like a 12Mega Hertz 286 is to use 1-2 layers of OOP :)... I have seen GEOS at work on a 286 with only 2Megabytes of RAM and a 512K video board....and Win2K CAN NOT RUN TAHT FAST even TODAY and it CAN NOT LOOK THAT NICE...of course it was written in ASM and the whole system was 64Kilobytes all, applications like WORD/ Excel and Draw/CAD where an extra 2Megabytes on HDD only that they worked MUCH FAster... Eh Micro$ did its best to kill that OS...and succeded...but the truth is out there :) OOP is equal with BLOATWARE and GPF and the easy way to make you pay more for hardware that works slower because of stupid software :) Problem is with yesterday born programmers that are tols and belive OOP crap... "modern programming techniques" usually means: let me do my job fast (for the money) and bad (for the users and their PC) ...with extra crypto notation things that takes about 1 month to even understand and actually dont mean nothing real :) and make you go more and more away from the machine...into the big lies...finally makeing you just a power user and not a system creator any more... I have to stop myself here... :) because i dont want to become more emotional... Bottom line: nobody keeps you here IGosha...jou can allways join a C++ OOP board on the net... PS TASM has a lot of OOP features ... like the ones you like so much...just that nobody seems to need them anymore :) when you can use the whole power of the computer...you learn to see THRU glamour OOP This message was edited by BogdanOntanu, on 3/14/2001 5:36:41 PM
Posted on 2001-03-14 16:28:00 by BogdanOntanu
Bravo BogdanOntanu! Well said! :)
Posted on 2001-03-14 16:43:00 by rainbird
======================================================= I think that there cannot be any OOP in MASM at all! C++ rules in OOP! And no ASM at OOP programming party! ======================================================= Sad to say, the world is full of examples of where OOP turns into OOP(s), bugz, bloat, opaque objects that cannot be fixed, objects that don't do what you want, memory leaks, object memory usage that duplicates the same code, the blunders just keep going. I agree with you in this much, C++ rools in OOP(s). I think Bogdan got it right, if you can't make the adaption to write real code in assembler, perhaps you should be working in C++ or Delphi where you can write big slow buggy code that does not perform. As far as code portability, OOP(s) aint all that portable either, the objects vary from one OS to another so what you end up with writing portable code is the lowest common denominator, usually console style applications that are slow and toothless. Feel free to join programmers of your own disposition on another forum if you don't feel you can write the real stuff, you will have many who feel the same way as you do. Regards, hutch@pbq.com.au
Posted on 2001-03-14 17:40:00 by hutch--
Funny, I seem to remember writing LOTS of OOP code in MASM just... well, today in fact. What was I thinking? Beats me.
Posted on 2001-03-14 17:46:00 by Ernie
OOP? CPP? Say what??? Maybe you would like the opinion of someone who has been a professional programmer for, going on, 4 decades... My first language was FORTRAN. I already had a years worth of experience on machines like the IBM 402, where "programs" were hard-wired, using plug-in boards. But to be able to "do it" with software was, well, way kool! I had a great teacher, a senior programmer at the Exxon R&D facility in NJ. I'll never forget my first look at that computer room, a football-field sized room, with 3 of the latest, state-of-the-art, IBM-360/65 mainframes. Banks of tape drives. Banks and banks of disk drives, each drive a whopping 7 megabytes! And I could "talk" to these machines!!! But we didn't talk the same "native" language. I was always good at math, but still, talking to a computer in algebra, making me think that way, just didn't seem natural. There must be a better way... Then I discovered COBOL. This was, well, WAY WAY KOOL! Now I could talk to the computer in ENGLISH!!! It didn't take long until I had my first core-dump on my desk. I had seen dumps from my FORTRAN programs, but it's ABEND routine did a great job at figuring out what was wrong, and pointing me back to the source line (and data) in my program that caused the problem. I didn't need the dump to figure out my problem. COBOL wasn't as forgiving (it did get better in later years). It made me look at the dump. It made me look at the "machine language" instructions (and data) that caused the problem. I didn't know it at the time, but I was learning ASSEMBLY language. I was learning how to talk to the computer IN IT'S OWN LANGUAGE!!! To make a long story short, I'll, once again, never forget the day that I saw my first ASSEMBLY language source program. I already knew what was going on from looking at dumps. I had my "green card" always at my side. I knew that a hex 47 was a B(ranch) instruction. But to be able to tell the computer what I wanted to do, without the assumptions and overhead of a "high level" language, like FORTRAN or COBOL was, well, WAY WAY WAY WAY WAY KOOOOOLLL!!!!!!!!!! I still do ASSEMBLY programming on the IBM S/390 mainframe. I also spent several years doing ASSEMBLY on computers like the 6502 (the core of the APPLE and ATARI computers), long before the PC was even a dream. And yes, I've been doing x86 ASM since day 2... While I was at it, I've programmed in BASIC (starting on the ATARI). I played with C (I still use Kernighan and Ritchie as my mouse pad). I've done serious work with languages that you've probably never heard of, like TAG (Telecommunications Application Generator), VERSACOMP (a composition, or typesetting language), I can't count 'em all... You talk about portability. What are you going to port to? Once you know what machine language (aka ASSEMBLY) is all about, the platform doesn't matter. It all comes down to basics. ADD, SUBTRACT, MULTIPLY, COMPARE, BRANCH, AND, OR, SHIFT... The specific syntax is easy, once you've got the idea. But does it really matter today? If you've got something that's going to beat the pants off of Intel, please let us all know! I'm looking for something to invest in these days... ... ... Anyway, end of rant. If you're in love with C++ then go for it. Just stay out of my way at the drag strip... :)
Posted on 2001-03-14 23:27:00 by S/390
Only one thing to add to the excellent views above. Whenever x86 chips are replaced (sometime after I'm dead :)) - those machines will surely execute x86 code! No matter what you program in, it helps to know how the machine is dealing with what your trying to do. Assembly language programmers are the ones who invented coding abstractions :P bitRAKE
Posted on 2001-03-15 01:16:00 by bitRAKE
The problem with OOP, is not that it is a bad idea per se, it is people are not taught to use it properly! Certain tasks will OOPify very well, while others will not. However current teaching (at least my own experience at University two years ago) seems to push new ideas without (enough) reguard for old methods. OOP has its place, mixing OOP and non-OOP is possible and also has its place, finally straight code also has its place. Problem with OOP is it requires a manager, and programmers rarely are managers! Organisation of the code, structures, meetings to decide structures, big diagrams showing dependancies etc. I hate them, I cannot write them, but I know their value, especially in big projects! But OOP is slow, and can go horribly wrong when done badly. So if you don't have a managerial team, or want plain FAST code OOP is probably a bad choice (and given what ASM is all about OOP in asm is usually a bit silly). The problem with this argument is that the old guys are too used to the old ways to see the good in the new, and the new guys are too blind to see that their new ways aren't always the best! Mirno
Posted on 2001-03-15 05:51:00 by Mirno
i'm with the guilty party. you spell it as OOP and i read it as MFC. at times i actually think they're the same. anyway, there's this site where they talk of clean, fast, reliable code it makes you think they're masm programmers, but they code with sans MFC MSVC++. they're at www.relisoft.com
Posted on 2001-03-25 04:15:00 by pixelwise
pixelwise, Gee, I thought this thread had died it's natural death long ago. So be it. :-) Anyway, I checked your link to relisoft. And of course surfed right to his artical on OLE's fatal flaw. Ummm, sad to say, but after reading his opinion there, I just can't take the guy seriously. He's missed the point entirely. Several points in fact, and it seems he's arguing more from an emotional standpoint then from a logical standpoint. Yes, if you define classes like he says, it's tough to get QueryInterface to work. So what's the point? If you start from a flawed example that doesn't work, it proves zero. It's not COM that's broke, it's the programmer. And it's such a simple fix too. He first makes IFooObj inherits from IFoo, but makes IBarObj direct. Heck, make it the same way, IBarObj inherit from IBar. Then IFooBarObj inherits both IFooObj and IBarObj, AND also impliments IUnknown, since it's got everything there and full knowedge of the interfaces it contains. I'm sure he wrote his ideas down. I'd sure like to see if "the ideas were accepted as valid" was also written down and signed by another MS employee. I just find it so funny to prove something is worng, but not being able to change it because the model is "fatally flawed" (his words). A fatal flaw has always meant to me an incorrect output at best, GPF at worst. It never meant there is already too huge a base of existing, WORKING code to change the basic definitions. Yes, it takes a bit of work to get COM to work in any language. So? COM isn't C++, it isn't VB, it's a protocal for intermodual communications. I just can't trust someone who doesn't get that. Besides, he thinks in C++, and that's a very bad way to think if you're an asm programmer. ---------------------------------- "What are you gonna do? Release the dogs?! Or the bees?! Or dogs with bees in their mouth so that when they bark they shoot bees at you?"
Posted on 2001-03-25 22:30:00 by Ernie
Damnit people are blind, expecialy people like IGosha there. Do you know anything about how languages work? languages like C, C++ and Java??? or VB or any other "High" level languages?? Well damnit your computer can only understand 1's and 0's and thats it, but the beautiful thing is that Asm can be converted directly into 1's and 0's it was made for each instruction to be a PERFECT match. so the line for C++ code would go: C++ code --> compiler ----> compiler translates it into Asm code ---> then into 1's and 0's. So are you saying Asm can not handle OOP? Because it can. Well then why dont we use it??? cuz its bulk code, think about it, everytime you use it your just increasing the size of the Asm code, with new fuctions and code, and thats just making it slow!! It discusts me to see languages like VB out there, all it is is dll calls, thats wack! All i have to say is your pretty lame if you think that C++ is so kewl or l33t or some shit cuz it has OOP, when it comes down to it Asm is kickin your ass and a good Asm programmer can do ANYTHING, we are not limited, we are united, you are nieve, brainwashed by big componys and standards.... who cares if most programming ferms use C++??? Hell its not your system, who cares if your code is bulkey and slow, its not your system resources your suckin up, its not your problem if your code sucks as long as it works. But thats ok, you can go join the weak fools who think this language or that is all l33t, mabe cuz its a new language, or mabe more people program in it then asm, or mabe you have been told that it is faster, well its not. You are the Weakest Link.... GOODBYE! -brad
Posted on 2001-04-08 14:13:00 by Rage9
It has always been the case that different languages do different things better than others, it used to be the case that if you wanted something quick, fast and dirty you wrote it in basic, if you wanted to write an operating system you wrote it in C and if you wanted something to go FAST, you wrote it in assembler. The concept of "objects" has been with us for a long time and it has been implemented in many different ways, the argument is not whether "object" style programming is OK but HOW the objects are implemented. Our friend displayed what his problem was with his post, he failed to comprehend assembler because his background was in VC++ style OOP so his post is just another loser on his way out. Other people will succeed in writing "object" style code in MASM because the basic power is there, its just that it has to be written. Regards, hutch@pbq.com.au
Posted on 2001-04-08 17:47:00 by hutch--
oop is a very, but really very powerful mechanism for programmers. just imagine you have an iso game w/ a big map. the user clicks on one tile, a house. a "normal" programmer (means, not using oop) would now find an ID for "house_1" and a ptr to a struct of the properties of the house, like inhabitants etc in his map. then he would make either a big, but really big, when you have 100s of types you can use, comparison w/ 100s of

mov eax, id
mov ebx, ptr_struct
.if id == ID_STREET1
  call Street1_OnClick, ebx
.elseif id == ID_STREET2
  call Street2_OnClick, ebx
and so on. he could also create a big lookuptable with all functions like

o equ 
ID_STREET1, o Street1_OnClick,
ID_STREET2, o Street2_OnClick,
etc. this would be more efficient. an oop programmer would just save one pointer to his class and then call the class-OnClick-Handler. this would be really efficient in the matter of speed. the other things w/ oop is that the handler, who gets the class, does not know what is this? this can also be a button or a static bitmap, the mouse handler ONLY calls the OnClick handler. no need for 100 different handlers for 100 different cases. it are all just "things" you can click. and oop in asm is not difficult. its as much as difficlut as creating a struct and putting ptrs to functions in it. i made it and i must say, in the beginning, where you have to create the oop-helper-macros, it was a liitle bit more work but later, it was soooo easy and so fast to add a new thing like in this example, a tree. you could also add OnMouseOver and Leave handlers with just the same code and no need for tables or anything even more complicated! when we talk from oop we dont talk from microsofts implementation of oop. or what microsoft thinks it should be. we talk of just a small structure with its members and its properties like this:

tClickHandleProc TYPEDEF PROTO pThis : PTR CStdClass, thePoint : PTR POINT, Button : DWORD
pClickHandleProc TYPEDEF PTR tClickHandleProc

struct CStdClass
  ; Standard handlers, has to be the same for ALL objects
  OnClick pClickHandleProc ?
  ; and so on  
  ; after all other standard-definitions come your own ones, in the house for example:
tEarnTaxesProc TYPEDEF PROTO pThis : PTR CStdClass
pEarnTaxesProc TYPEDEF PTR tEarnTaxesProc
  EarnTaxes pEarnTaxesPro ?
  ; now properties
  inhabitants dd ?  
and then you call it. of course, we are all alzy so we HAVE to use macros (to less ppl use them!)

  OnClick macro PtrToStdClass:REQ, Point:REQ, Button:=<0>
      invoke , PtrToStdClass, Point, Button
and then, instead of the big if-then-else above:

  mov eax, the_ptr ;instead of the found id
  OnClick, eax, o the_point, LEFT_BUTTON
the house onclick method looks like that

OnClick proc uses esi edi pThis : PTR CHouse, thePoint : PTR POINT, Button : DWORD
  mov esi, pThis
  assume esi : ptr CHouse

  [.. your code goes here ..]
  assume esi : nothing
  return TRUE
this is much -easier -more flexible -easier to expand -better to work on a team than the std-coding. so, when you use .IF instead of the old cmp...jcc, why dont you want to use the oop thingy? it is _really_ worth using it regards vineon
Posted on 2001-05-02 15:53:00 by vineon
Nice web site. I thought I will never find such site about Asm programming. Of course assembly language is not dead. It won't until processors will disappear. Incidentally, assembly language does not provide the ultimate in speed and efficiency to run an algorithm. The future computer model will probably not be based on the processor architectures we are used to nowadays. This will imply no more X86, Windows or any Unix flavours. But this is another story..
Posted on 2001-05-03 01:45:00 by TBi
There is one thing you all must know. I USED asm for programming Windows Applications. Wholly in asm. And I know that masm can be used for it. I know that it is not so hard. And the thing I realized about Asm being dead came after I used asm for a lot of time, create several "serious" software packages in asm, and then learnt C/C++. And only after I have tried to program in Delphi, Pascal, C, C++ and Asm I can surely say - Asm really does not have any features that will make me use it. It does really consume valuable time while your programs won't gain any speed (like it was in Dos). Sure, Asm can be used like inline code when using C++, but not instead of it. Now, people, have to go. See you later here! It's really a good source for Win32 Asm!
Posted on 2001-05-05 08:00:00 by IGosha
Obviously, this clown is going to show up here every month and a half and make some bogus comment. The bad thing with this is there are a lot of high powered brains reading this board, ones who will take their precious time to respond to mundane drivel if only to keep newbies from going down the wrong track. As I read his latest posting, he makes the claim that programs written in asm "won't gain any speed " over another language choice. As moderator of this section, I must impose my will here. Speed of general code does NOT belong in the COM section. Try Algorithms or General or something. That's not a topic for here. Therefor, I am closing this thread. something I dread doing, for speech is something sacred to me. Anyone in disagreement is quite capable of starting up another thread. So, IGosha, I close your thread for that reason. Don't let it hitcha in the butt on the way out. You *are* the weakest link. Good bye. This message was edited by Ernie, on 5/6/2001 10:59:34 PM
Posted on 2001-05-05 11:01:00 by Ernie