Don't you just love assembly language.

[Damos]

I have been programming now for over 20 years, mainly C & C++. I have spent lots of money on packages such as visual studio and text books. I found that programming in C++ very frustrating:
1. Theres too much behind the scenes stuff going on as in the common runtime libraries, and especially MFC.
2. Talk about bloated .exe's everything you program generates megabytes of binaries.
3. Programming with visual studio is not intuitive, you get good programmes going but you have no idea of how you got there or what exactly your program is doing.

I have been using masm32 & radasm now for just under a year and I have found the experience very satisfying
Ironically my productivity has gone up ten fold, I spend a lot less time debugging my code.
I say ironically because one of the main criticism of assembly was that it was supposed to be long winded, this, however has not been my experience.
I have learned so much about the windows sdk since programming in assembly, and I still haven't got a text book on programming in Assembly: I don't need one.(I have over 20 text books on MFC and visual studio, read them all two or three times and I still struggle.)
This site in particular has been a god send and the masm32 package with it's example sources is brilliant.
I estimated that I have spent over £4000 on programming software and books over the years, and now I just have masm32 and radasm installed on my machine. Visual studio 2005 is collecting dust on my shelf.

Bravo to all concerned with the masm32 package and this site!! :bg

[travism]

Over 4000 euro? Wow. I always used all the free stuff from the sites I could find, but Ive been programming in c/c++ for some years now. I still write alot of projects in it (mostly C), but i do understand what you mean by the frustration and debugging. I remember writing programs in C/C++ and looked at the output and was like now HOW did it get that big? from such a simple application. :) all in all nice post though :)

[TmX]

2. Talk about bloated .exe's everything you program generates megabytes of binaries.

Hard drives these days are getting bigger, bigger, and also cheaper.
It's a good thing to waste 'em.

:green

[kromag]

Well, don't the compilers have to take into account things such as hardware configurations and what not?
So unless we code in masm/asm... generically enough to target the same audiences we would have to do some redundancy wouldn't we?

I was thinking about that last night too!
How do you target a large audience with your software written in MASM32 for say AMD and Intel, properly?

I know speed won't be the same for each routine etc... so wouldn't you have to do as aforementioned which is a form of bloat itself?
---
Will.

[Mark Jones]

Nice post Damos, it's good to see another recognizing the inherent value in assembler. While not perfect, assembler is still a great tool to have in our programming arsenal -- arguably the most beneficial at that. It really is a shame that some people chide it so.

[Hard drives] ... It's a good thing to waste 'em.

Since when is wasting anything  a good idea? :bdg

Seriously. Consider the following two scenarios:
1. Application A is made in C++ with the MSI installer. Total download, 4MB.
2. Application A is made in assembler with the NSIS installer, total download: 200kB.

Now imagine this application becomes insanely popular overnight, and you are paying to host the software. If one million users download the application in one month, that's at least 1M*4MB = 4TB of data, plus all the HTTP traffic! I would not want to be the one getting that bill... The assembler version however, would only total 1M*200kB = 200GB... still a lot, but that's 20x less data being transmitted than the C++ version.

Also consider the network bandwidth being used. Would it be expected that the entire overall internet latency be higher if everyone was transmitting huge files for longer durations? If so, then would latency and bandwidth improve if everyone was instead transmitting smaller files for shorter durations?

[drhowarddrfine]

Not to mention smaller code runs faster.  At some point, all that code runs and can't help speed.

[kromag]

Nicely put Mark!

On a side note; I had posted elsewhere on these forums about wanting to see/develop a way to make a cross-platform way of writing assembler but in a fashion that could be optimized for each platform and hardware setting.

I know this could be done efficiently! When I have time I was planning on setting up an OSS area on a few repositories and showing my Idea fleshed out in some form like UML or just pseudo the basic approach I would like to take on getting there.

I only know about Intel tho and not too much about others, as far as op addresses/codes/mnemonics goes!

Perhaps a few here could help or maybe have even done something similar  :bg
---
William J.L. III

[Vortex]

Hi Damos,

You can remove all the unnecessary components to produce small C executables :

- Turn off the default C run-time libraries.
- Move the speed critical code to asm modules.

Attached is an EXE ( size = 2048 bytes ) compiled with MS Visual Studio Express 2005

[attachment deleted by admin]

[jj2007]

Looks very similar to \masm32\examples\exampl07\smallwin\smallwin.asm :wink

   invoke LoadIcon, hInst, IDI_APPLICATION
   mov wc.hIcon, eax

    wc.hIcon         = LoadIcon(NULL, IDI_APPLICATION);

Question: Is there any good reason to use LoadIcon(NULL, .. instead of LoadIcon(hInst, ... ? As far as I can see, the icon will not show up in the caption with NULL.

[Vortex]

Hi jj2007,

Here is the explanation from Win32 Programmer's reference :

hInstance

Identifies an instance of the module whose executable file contains the icon to be loaded. This parameter must be NULL when a standard icon is being loaded.

[Rainstorm]

Am still learning & i enjoy doing stuff in assembly.

Damos wrote. .

I have been programming now for over 20 years, mainly C & C++. I have spent lots of money on packages such as visual studio and text books. I found that programming in C++ very frustrating:..
..I have been using masm32 & radasm now for just under a year and I have found the experience very satisfying
Ironically my productivity has gone up ten fold, I spend a lot less time debugging my code.

..assembly being the only language i know (a bit of), much appreciate you sharing your experiences & thoughts on other languages, while drawing an analogy with assembly..especially after you've programmed in them for so long. - cause in your post you addressed some of the areas i've wondered about before, & expressed your opinions on them. ;  )

i guess the only thing is portability to a foreign platform.
just a thought, like it wouldn't be too bad even if the porting was not balanced..like you make an app for one platform & it functions the best on that.... but if it could still be ported if needed to another platform.. even if it didn't perform as well there.....

laters
-

[ecube]

yeah masm is great but it has its issues aswell. I use masm for everything from small projects to incredibly large scale 1's and some issues i've come across is

limitation on .if,.elseif etc (forget the exact number but can be fixed by putting some code that uses .if etc in a static link lib and adding that way)


procedure stack size(if you alloc to much memory via local variables in a proc your program will compile but may simply not load/or work correctly) the stackprob macros fix this issue, they're on the board somewhere)

the .if comparison by default is unsigned comparison...which to me was a major issue having to convert it. replacing with .if sdword ptr watever fixes it)

code executes to fast...(this one I still haven't figured out and people look at me like i'm crazy when I try and explain it, but basically alot of times my code will execute *too fast and will cause serious issues in the application, using a invoke sleep in various places seems to help)

createthread not creating the thread properly(i fixed this 1 by having my program block and wait for a signal from the new thread that it was created successfully, seems to have fixed it...)

floating point math(very easy in c++,very hard for me in masm)

stack variables containing garbage(this ones a biggy, if you don't rtlzeromemory local proc buffers, alot of times they'll have garbage in them which can effect what your procedure is doing with string output)

myproc
local mybuf[255]

if you just use mybuff without invoke Rtlzeromemory,addr mybuf,255 or similar can cause issuses!


theres more issues i'm sure, can't think of any atm.