Jobs

[HiddenDragon]

What jobs can you expect to find that require assembly use? Or, what jobs that require assembly more than any other language? I would imagine embedded systems and optimizing parts of speed-critical programs.

[Twister]

Writing boot and parts of kernel code.

[HiddenDragon]

That can't be too widespread though. Seems like that would be a relatively small niche.

[Twister]

Actually, I am mistaken. There are many things that use assembly; here is a relatively small list:

• Writing boot code
• Writing parts of the kernel
• Disassembling/Reverse-Engineering
• Debugging
• Optimizing routines
• Writing for embedded systems or controllers
• Writing viruses :bdg

[the_mart]

I had a recruiter try and hook me up with a job which required C++ and x86 assembly skills. The role involved writing software to be used inside weapons of mass destruction (or small scale destruction, at least)! I wasn't really up for that though. Besides, back then my assembly knowledge was limited to making some lights flash on a PIC microcontroller board after pushing some switches.

[donkey]

I read somewhere, though I can't find the reference anymore, that Windows still contains thousands of lines of hand written assembly language. I imagine nothing is left that is written in MASM since it is no longer really supported by any Microsoft compiler (except ml64) but apparently there is a lot of code using compiler intrinsics and inline assembly.

However, if you're looking for work in programming, don't rely on assembly as more than a footnote on your resume, learn a language that will have at least a hope of getting you a placement. The reality of it is that assembly is a bit archaic and should be treated as nothing more than a hobby language that might be useful once or twice in your programming career, but more likely will not apply to it at all. The modern use of assembly is limited to a subset of high level languages, the era of stand alone assembly language is dead and will more than likely remain so except in a very few specialized fields, and the worst thing you can do is to start your career by limiting your career path to only a fraction of a percent of the available jobs.

http://www.youtube.com/watch?v=5QA7u0CftYE

[hutch--]

This much I know about Microsoft, they do not produce expensive tools for hobbyists, even if hobbyists use them. MASM was supposed to have died back in the middle 1990s yet Microsoft have kept spending corporate money rewriting it over and over again and they do it one obvious reason, they have a use for it. Current 32 and 64 bit versions date 2010. 64 bit Microsoft C compilers do not support inline assembler and you must write separate modules in MASM if you need assembler code. 32 bit versions still support inli8ne assembler but it is not recommended due to interference with internal optimisation techniques and register usage.

For the job market, keep in mind that any job that is advertised will start in the bottom end of programming, not the obscure top end where most work is passed to people who already know how to write specialised code in their own field. Look at C++, C# and the JAVA and similar market for entry level employment if you are specifically interested in writing code, a wider IT expertise is more saleable than just programming skills and these tend to come from graduates in the IT field. Modern VB and Delphi no longer have enough market share to matter.

[oex]

This much I know about Microsoft, they do not produce expensive tools for hobbyists, even if hobbyists use them.

They need the old parts to keep Bill running :lol

[donkey]

This much I know about Microsoft, they do not produce expensive tools for hobbyists, even if hobbyists use them.

Well, I wouldn't call MASM an expensive tool, the basic work is done and expansion and maintenance is really rather inexpensive when all you do is strip out any feature that might be difficult to port. Especially when you're talking about a company the size of Microsoft with the budgets it deals with, a couple of programmers with some spare time between major language releases could handle it. Any tool  can be maintained pretty cheaply, and Microsoft doesn't even do much of that with MASM, after all there are bugs that have never been dealt with such as the large data allocation bug which has been around for years but never resolved. On the other hand, updates to my other Microsoft tools such as MSVC/C++  and Frontpage are frequent and you can bet that bugs are quickly taken care of once reported. What do you think the life expectancy of a bug like the data allocation one would be in MSVC++, not long I wager. If it wasn't for the lack of inline 64 bit support in Visual Studio compilers, I doubt that MS would have bothered with ml64 at all. I mean if they had meant it as a viable language do you think they would have crippled it like they did with ml64 ? The simple fact is they didn't see it as important enough to expend the money or effort of extending all of the legacy functionality of ml32  into newer versions. That coupled with the rumor that MS may drop 32 bit Windows as early as 2013 leaves MASM a crippled shadow of what it once was.

When the port of the Microsoft Macro Assembler (MASM) to the x64 hardware platform was undertaken we decided not to port the high level language construct support, which include INVOKE, .IF, .ELSE, .WHILE, etc (not to be confused with the conditional assembly directives IF, ELSE, WHILE, etc). There were, of course, a number of reasons including fundamental differences in calling convention, exception handling, etc. Support for x64 exception handling alone would likely require a complete redesign of the directives currently used to support exception handling at the assembly language level. And while MASM is very important to a number of users, we decided to invest our resources in keeping MASM up to date with the steady stream of new processors.

But we do periodically get a request for putting the high level language constructs in ML64.EXE so we will keep the option open. For now, though, we have no plans to do so.

Thanks for using MASM!
Visual Studio (and MASM) Product Team

Yes, a ringing endorsement of Microsoft's commitment to MASM now and in the future...

32 bit versions still support inli8ne assembler but it is not recommended due to interference with internal optimisation techniques and register usage.

Where did you find that ?

Because the inline assembler doesn't require separate assembly and link steps, it is more convenient than a separate assembler. Inline assembly code can use any C variable or function name that is in scope, so it is easy to integrate it with your program's C code. Because the assembly code can be mixed inline with C or C++ statements, it can do tasks that are cumbersome or impossible in C or C++.

[hutch--]

 :bg

Most of this is old news, we knew some years ago when members contributed to MSDN queries that ML64 would not support the older ML 6.0 directives. Its no big deal for folks who came from a background of writing mnemonic code.

the comments on MASM "bugs" fails to grasp what MASM has always been, a tool for screwing together mnemonics and the reason why they have never bothered to tweak the large data allocation is simply that it does not matter, they don't use it that way. MASM has never been consumer software, it has always been a bad mannered old pig that you had to understand to get it to work. Its pre-processor is a good example of something you can get to work but that is bad mannered, quirky and obscure in its documentation. If you want nice soft friendly consumer programming software, use VB.DOT.NOT.WHO.CARES.

As MASM hits its 30th year, it has outlasted all of its doomsayers, names that only the old fellas remember yet in 2010 Microsoft updated both the 32 and 64 bit versions. The slow development of ML64 has as much to do with the pace of 64 bit OS acceptance and the time lag to properly cater for it. the shift from 16 bit Windows to 32 bit Windows took years and the early tools were crap, much like the current 64 bit tools are at the moment.

With the comments on VC 32 bit, you are confusing convenience and performance, yes it is convenient to cobble together a little assembler as inline code but you get nothing for nothing. if you ever bother to disassemble current 32 bit VC output at an algorithm level you will see that it does many things that do not interface well with arbitrary register allocations as are done with inline asseembler code and while the compiler WILL work with inlined assembler, you pay the price of the compiler having to adjust around the inline code register usage.

This is why MASM has the same object module format, so it can produce separate modules that are linked in with the rest, yes it is inconvenient but it interfaces with lower overhead than inlined code.

[oex]

Re: Jobs.... When the language dies out completely you can expect to receive a doctors salary :lol

[HiddenDragon]

Thanks guys, I've done a bit of C++ but not nearly enough. I'll try to get back into that as well.

[donkey]

As MASM hits its 30th year, it has outlasted all of its doomsayers, names that only the old fellas remember yet in 2010 Microsoft updated both the 32 and 64 bit versions. The slow development of ML64 has as much to do with the pace of 64 bit OS acceptance and the time lag to properly cater for it. the shift from 16 bit Windows to 32 bit Windows took years and the early tools were crap, much like the current 64 bit tools are at the moment.

And in all that time they never stripped it of almost all functionality... until now. MASM survived because it was still a viable tool for general programming tasks, it is more and more difficult to say that. JWASM, FASM and others will fill the gap however.

With the comments on VC 32 bit, you are confusing convenience and performance, yes it is convenient to cobble together a little assembler as inline code but you get nothing for nothing. if you ever bother to disassemble current 32 bit VC output at an algorithm level you will see that it does many things that do not interface well with arbitrary register allocations as are done with inline asseembler code and while the compiler WILL work with inlined assembler, you pay the price of the compiler having to adjust around the inline code register usage.

That is just wrong, you should first check by building a program using MSVC 2010 before you make comments about the functionality of inline assembler in that language. I have never run into a problem regardless of what registers I use and "arbitrary" register allocations are arbitrary for a reason so that the compiler can coexist with inline assembly, the code is analyzed and conflicts are resolved within the compiler. I am not defending VS here, merely stating a fact that I have seen in practice. If you have an example of inline code causing a MSVC program to fail then post it because I have never found one. For optimization of a specific block of code it can be done equally as well with inline assembly as with MASM they produce the same code.

This is why MASM has the same object module format, so it can produce separate modules that are linked in with the rest, yes it is inconvenient but it interfaces with lower overhead than inlined code.

Just because Microsoft has not changed its OBJ format for quite some time does not say anything about how they regard MASM today, if they change the format then upgrade MASM to the new format I would be impressed but stating that because they haven't changed it in 20 years is an indication that they still regard it as a primary tool is a bit off. When Win32 and IA-32 architecture was released MASM and the Intel assembler were in step and fully functional, Intel doesn't even bother to make an assembler anymore and Microsoft is stripping theirs.The fact that in new versions they have not bothered to port most of the functionality does speak to their opinion of MASM.

Its easy to go on with the wishful thinking, I do hope that there is a renewed interest in MASM at Microsoft but I won't be holding my breath. Microsoft is dedicated to portable managed code and there is no reason for them to change that. As more and more software is being run outside of the traditional desktop and on non-traditional processors like the ARM etc.. portability is more of an issue than ever. Managed code allows a level of security that is necessary in an environment where many people with a cursory knowledge of assembly is cracking software and writing virii. Many of the best assembly programmers I know have had RE and Virus pages or have written how to articles for cracking programs. You were one Hutch. Eventually if you keep using your toys to break things, mom's going to take them away.

Anyway, back to the original topic, learn JAVA and C++, you have a better chance to find a job, keep assembly as a hobby and maybe one day you can impress your boss by writing something in assembly.

[hutch--]

 :bg

I have heard most of this stuff before, A86 was going to be the MASM beater, then TASM was going to be the MASM beater and so on and so on but at the end of the day MASM has 2 current versions in 2010, the 32 bit version that has all of its masm 6.0 capacity and a functional 64 bit version that they upgrade to match new instruction sets. i have no particular beef with any of the current assemblers for the x86 32/64 bit market but as before, MASM in whatever form will still be there when the rest have disappeared.

Before you make comments on using CL.EXE you should perhaps do a bit of work with it, I have about 20 years of C compilers and still have VC98, VCTOOLKIT2003, VS2005/2008/2010. I still own the disks for C version 6.0 (1990) but I could not garrantee they still work. I primarily use VCTOOLKIT as its optimisation and libraries are better than the later versions. Now while you may have learnt to cobble a bit of C++ together, these days i mainly use a C compiler to build and test C algorithms as the internet is still awash with 25 years of C code and contrary to your assumptions, the optimise options in these CL version does not use Intel ABI register rules but performs internal optimisation with its own register usage with most of its assumptions as RISC compiler theory.

RE your assumptions on "managed code", you cannot garrantee that it will still be there in a few years time, where did OLE, COM and the rest of this junk go ? While you may have collapsed down to the view that assembler is only suitable for writing viruses, you may need to get the idea that most of this crap is written in C++, VB and a host of other scripting languages, very few binary viruses have been written in assembler for years as most of these cockroaches don't have the skill to do it.

Tread with caution trying to re-interpret my history on the internet (get that egg scraper out). In conjunction with Iczelion I launched MASM32 straight into the cracking market to displlace it with application software design and it basically succeeded in destroying most of that market. You appear to have confused your own association and support of a number of virus writers with events that occurred well before you were around.  :green

[donkey]

Tread with caution trying to re-interpret my history on the internet (get that egg scraper out). In conjunction with Iczelion I launched MASM32 straight into the cracking market to displlace it with application software design and it basically succeeded in destroying most of that market. You appear to have confused your own association and support of a number of virus writers with events that occurred well before you were around.  :green

:bg Now Steve, everyone who has been around for more than a few years has read your articles at Fravia, probably have them archived somewhere as they were truly inspired.

At any rate, in all the years that MASM has survived Microsoft has never removed functionality without replacing it with something better or more powerful. They did in 2005 and its been 5 years and they don't seem to be in any big hurry to bring it up to at least a par with the Win32 version, you can read this any way you like. For myself I neither use MASM or make a living of any sort from programming so I treat assembly as a hobby along with MSVC.