Hello!!!
What are you think about future of windows programming with ASM?
What about f##ing .NET technology and LongHorn?

P. S.: I'm not a windows programmer, I use asm to programming microcontrollers.

I believe in the future of assembly, is the future of windows that is not so clear...
...it may seem a typical trolling, but it is not. MS is giving the advice of not longer support win32api and imposing in many ways the use of their technology as the only way to interface to the operating system. In other words, they want to convert all programmers in scripters at the cost of performance.

For certain fields this cost is unacceptable and the lack of alternatives means to migrate to another development platform.
Something that have already happened in *serious* realtime applications and is happening in embedded systems as well.

In the beginning I thought that writing window apps in asm is a slow process and c++ was the answer. Now I think that coding win32 in asm is a little bit faster since you dont have to deal with pointer and variable casts.

MY MAIN POINT: ASM's weakness is the portability, but since win32 runs only on machines with x86 processors, win32asm is going to remain solid until there is Windows.

I think, that the future of ASM is not a problem of language, but problem of programmers.
Programming with VB (for example) is simple way, but if you like assembler, then we will programm BEST programms.
Generally, asm-coders knows processor better, then scripters

I must strongly object to that (not just because I'm a linux zealot but:)
There is linux and MenuetOS to name two examples of where (f)asm has a/is the future.
We are still needed to make use of the latest extensions of the CPU, eg, MMX and /SSE[1-3]?/ - I think for instance gcc supports some of it's instructions, not sure how or if it does parallising though. -- Stil carefully crafted asm is better than compiler ouput, as you unlike the compiler can think in different patterns - the compiler just uses the instructions that it has been programmed to recongnize as the best for a certain condition. (though it might have eaiser in some perspectives, like better predicting how code will work in piplelines if it will stall, and how great the probablillity of an branch is)

asm has a future. The more M$ restricts us, then more people start using alternatives (linux etc.)

I have written medium size project both in C and NASM. I can really advise anyone to use assembler. The speed is low only if you don't know how to do some common things. If you've learn it, the speed is even higher then when using HLL. And the quality of code is better, though C compilers now can produce VERY good code.

As to .NET, I think that we have to examine the Windows system. Firstly, 32-bit programs are to run on any Windows. Secondly, .NET is probably just a front-end based on WindowsAPI.

Some guys from wasm.ru had carried out the experiments, thay say Windows2003 has a usual kernel with well-known dlls (kernel32, user32, etc.). But this could be an emulation of old system (I don't sure).

btw, a serious question. Does the (newest) MASM allow anything but driver development for windows?

I have a lot of examples for MASM which are not related to driver development. Generally, any assembler should allow you to write any applications, because the assembly language is a substitution for machine code and any other program is compiled into the machine code.

But I don't like MASM. It is very complex for me to understand. I perfer FASM.

Maybe the assembler allow to write anything. But what about the (aberrating) EULA?

However, I think you would make a much better impression to an employer nowadays if you say that your favourite language is C++ rather than ASM (although the second one suggest deeper knowledge in computer science).

proveren, I think the employer would prefer one who knows C++ well but prefers asm over one that knows C++ well but doesn't know asm - so I think knowing asm is a great thing to put in the CV

Well, the most important thing that makes the knowledge and usage of C necessary is buyer's anxiety that they may have problems with finding a suitable person for modification assembly language sources in the future. On the other hand, C is widely used, if you have C sources you can easily find a person to modify the program.

The portability is the second thing, but not important in Windows' world. Windows mainly runs on PC's, that's why writing unportable programs in assembly language is enough.

Generally speaking, every processor architecture has it's own strengths and using well-portable language can negate them.

>The portability is the second thing, but not important in Windows' world.
as for every service pack a little less backwards compabillity(/portabillity)... right?

I mean portability across machines (processors). Windows runs on IA-32, Itanium and AMD64. IA-32 is used most widely. I hope in the future AMD64 will be a common place.

..

Ataway, Adam. If you search hard enough, I'm sure you can dig up some threads from before 2004, too.

[content deleted]

Assembly exists because the hardware presents a configurable interface - that interface could be Java/DotNET bytecode and it would still be assembly language. As long as efficiency of system resources is a concern people will code in assembly language. Even a 1% improvement in compiler code generation, or a 10% improvement in a specific application can have broad effects.

I would even argue that some people have a natural tendacy to be better at low-level work than others (be this a good thing™ or bad thing™), but I'm a biased asshole (talk about crack).