eheheh, i think hutch got you. ;) i almost forgot the fact that x86 works with byte. ehehe, real programmer = is dead. who care! :)
Posted on 2001-07-01 08:57:00 by disease_2000
Hmm. Then by the arguement that Hutch goes, MASM32 is actually not for me as I'm not a programmer at all, just a novice. But then again, I'll still keep on learning ASM as I believe that I'll come to the stage where I can use MASM or SpAsm to write. Actually, It's not important which program you use. It's the end-product that's significant. If we can build programs with ASM that's good enough to rock the ppl of other languages off their seats, then that's good! Debating about true assembly is not very fruitful, i think it's just having each of us pennying in our 2 cents. Of course, when we build programs, the important thing is time and output. If we can build a program with MASM32 as it's "powerful" and user-friendly, thus shortening our production-time, so why not use it? This way we could allow programs to be developed faster, allowing feedback and updated versions of the programs to be made. Well, to me, this means improvement in the Computing Industry. The only thing that we need though is the knowledge to program in that assembler. This is also why we have this forum set up.(I believe so.) It would be slow and inefficient to code in binary. Though Masm32 was produced for programmers, allowing them an option to program in assembly, I still think that spreading the knowledge to anyone interested is good-willed.(just my opinion, as i did not produce Masm myself) I must say that ASM is not an easy language. U have to know quite a low of things to be able to code in it. So, just teach those who are willing to absorb and learn. For those who did not have the patience to carry on, it's useless to teach them as they would give up on their own.
Posted on 2001-07-01 12:51:00 by JCL
If you want to write something confusing and convoluted then it helps to know how to program at two (or more :)) levels and then make something in between.

 db 033h ;jump here
 db 0C0h ;or jump here
 db 0EBh, 001h
 db 033h, 0C0h, 0EBh, 001h
 db 090h
Does this have a place in the development of REAL applications? Yes, but very very small place. :) The same can be said for self-modifying code. Another example would be to write a COM object where the source code is not open to the public, and then within your programs use hidden dependancies of your implementation. This would provide an added feature to you (like the code above), but this breaks the whole idea behind COM. This message was edited by bitRAKE, on 7/1/2001 1:09:07 PM
Posted on 2001-07-01 13:07:00 by bitRAKE
eheheh, i think hutch got you. [;)]
Yup :D
Posted on 2001-07-01 14:20:00 by bazik
JCL, interesting. this is the first real piece of though from you that i really like. :) bazik, you're not the only one. he got me aswell! :D to be honest. i'm not the type who would sit and write everything in assembly (in the 32bit world i mean). I use VC++. (if the task are small, i go for masm. if it's big, i sometime go for vc++) but when comes to 16bit coding, i go for masm 100%. (16bit is where my heart is. this mean that my asm skill is always active.) :) This message was edited by disease_2000, on 7/3/2001 5:12:34 PM
Posted on 2001-07-03 17:07:00 by disease_2000
True asm? To me that means _control_ of every byte that appears in my program. But if I don't get such control then I'm in some language intermediate between asm and a high-level language. Like betov I am dubious about things like PROTO, INVOKE, PROC, if/endif, and so on. With these notions MASM is moving away from asm toward C and HLL's. To be "true asm", the language does not need to imitate the Intel opcode manual. And it's still "true asm" if the build process uses utilities other than an assembler and linker. Examples: -- a utility that reads asm source and writes a filtered version of it, which then goes to an assembler. (This is one way to write a macro preprocessor, or to get control of the import table and export table in the PE.) -- a utility to paste in a resource section (not an obj). -- a utility which generates a macro representing binary data of any origin: @strings macro db 041h,0F2h,00Dh,... db 0E6h,0D1h,0D0h,... endm So, on my wish-list for an ideal assembler, the two top items are: -- zero overhead from the assembler (and linker, if any) -- easy customization of the build process.
Posted on 2001-07-04 23:55:00 by Larry Hammick