Well, obviously the way Microsoft is going seems to be promoting .NET languages and .NET code. I am thinking they will probably phase out the Win32API before they phase out any of their .NET APIs (purely speculation though).

Anyhow, it would be of tremendous advantage to have the internals (and, more importantly why and where) of what makes a program a .NET program, in the PE file, that is.

I am thinking (in fact, pretty much certain) that how it is implemented is a small interpreter embedded into each .NET application and that interpreter interprets the MSIL code which then executes it based on the underlying machine architecture (which, for now, is x86 and Win32, but could change in an instant---probably will be IA-64 and Win64 soon)

Obviously, I do NOT want to be stuck with having to use higher level languages in order to create .NET applications (if I absolutely HAD to make a .NET application, which I'm also going to try to avoid for a while, but I think it inevitable). I do NOT want to be forced into using C# and Visual Basic .NET and Managed C++.

I personally think this whole .NET thing is exceptionally ugly/etc, but, hey, I don't make the rules here...just play by them:p As such, I still enjoy and appreciate as much of power and grasp as I possibly can on any situation. Regardless, I still need to be able to make .NET applications at some point. I'd rather do it through assembly language than through a higher level language, if that is possible.

Any information on this (or speculation) would be appreciated:)

Besides, it would be a grave travesty if all of the efforts of the entire Win32 asm community were thwarted in an instant if Microsoft decided to port their OS to various other processors, go .NET all the way, and implement all of the processor-dependent and OS-dependent things within the .NET interpreters, wouldn't it?
Posted on 2004-03-06 00:00:45 by ShortCoder
Heya, I share your opinions and worries too! As a professional programmer, in VB 6, Delphi and all flavours of C++, I'm resisting the Dark Side of programming (.NET) for as long as I can! As far as I know, Microsoft is already planning a replacement of .NET, can't remember what it was called and I'm not sure if it's a complete rebuild, or an "upgrade" or something along the lines of ... "built on .NET architecture". My personal belief, is that Microsoft can have .NET, and they can keep it, market it, promote it, support it etc. But no matter how much they try, the heart of operating systems, the Kernel, Drivers and any area where speed is critical will still be written in Asm.

I also believe Microsoft will never be able to completely remove the API. 1) API calls are faster than .NET calls, this is essential in many situations! 2) They need to maintain backward compatability with older software, that is of course one of Microsoft's strongest selling points. 3) People developing Drivers for example, writing them in Asm will often need to make system calls directly from Asm, and can make these system calls to nothing but API's.

After all, computers don't think in terms of objects, and that's what the .NET framework is all about. Everything becomes an object. You want a Thread? Create an object of type System.Thread. Personally, I detest this idea!

My opinion, I wouldn't worry about the future of assembler or assembler programming.

Regards
Posted on 2004-03-06 11:53:30 by SubEvil

But no matter how much they try, the heart of operating systems, the Kernel, Drivers and any area where speed is critical will still be written in Asm.

Not really... C and C++, with a very few routines written in asm, like the ZeroPage function (for speed) and stuff that just can't be written in C (some processor setup, lowlevel mutex stuff, etc).

There will be native code for years to come, same with the win32 API. And once it's phased out, there will probably still be emulators available. SO if you're going to program in .NET, you might as well do it "the proper way" - there will hardly be much advantage in writing in MSIL, since the code is JIT'ed to native code anyway.

But of course you can do it, afaik Microsoft provides both an assembler and disassembler for MSIL, plus a .NET specification. It's ported to FreeBSD, and there's the opensource MONO project.


You want a Thread? Create an object of type System.Thread. Personally, I detest this idea!

The WIN32 API is already *heavily* object-oriented, and so is the NT kernel. Only small parts of both are written in an object-oriented language (C++), but that doesn't change it's OOP-ness. OOP is a good idea, even assembly programmers are starting to realize this.
Posted on 2004-03-07 15:16:05 by f0dder
Anyhow, it would be of tremendous advantage to have the internals (and, more importantly why and where) of what makes a program a .NET program, in the PE file, that is.
As fodder suggested, check out the Mono project, it is an open source port of the .Net framework, which means all the source is available.

I am thinking (in fact, pretty much certain) that how it is implemented is a small interpreter embedded into each .NET application and that interpreter interprets the MSIL code which then executes it based on the underlying machine architecture (which, for now, is x86 and Win32, but could change in an instant---probably will be IA-64 and Win64 soon)
Incorrect. The files are still have a PE type header, but they are not PE files. And the JITter is part of the .Net framework, it is not embedded in each file.

Obviously, I do NOT want to be stuck with having to use higher level languages in order to create .NET applications (if I absolutely HAD to make a .NET application, which I'm also going to try to avoid for a while, but I think it inevitable). I do NOT want to be forced into using C# and Visual Basic .NET and Managed C++.
Why not? What is wrong with them?

I personally think this whole .NET thing is exceptionally ugly/etc, but, hey, I don't make the rules here...just play by them
You could look at it the other way, and say it is also beautiful. MS has sunk a lot of money and development time into .Net, and they stand to make a huge amount of money in return. Also, the .Net framework has been very well architected and well written.

I'd rather do it through assembly language than through a higher level language, if that is possible.
You can code in MSIL, although it is not asm as you know it.



Besides, it would be a grave travesty if all of the efforts of the entire Win32 asm community were thwarted in an instant if Microsoft decided to port their OS to various other processors, go .NET all the way, and implement all of the processor-dependent and OS-dependent things within the .NET interpreters, wouldn't it?
As an asm programmer, you mean nothing to MS. It is MS's intention that the .Net framework be ported to as many platforms as possible (one reason why they released Rotor), it is also their intention that as many platforms and devices as possible run some form of Windows. This is definately a "world domination" tactic, and has every chance of succeeding where Java failed.
Posted on 2004-03-07 16:53:47 by sluggy

As fodder suggested, check out the Mono project, it is an open source port of the .Net framework, which means all the source is available.

Will do:) http://www.go-mono.com right?

Incorrect. The files are still have a PE type header, but they are not PE files. And the JITter is part of the .Net framework, it is not embedded in each file.

Interesting! So, are you basically saying that the Windows loader first checks to see if a program is a .NET program and, if it is, then sends it off to the .NET interpreter to convert it to a legit PE file, and then sends that back again to the Windows loader which finally loads and executes it? That's more complicated than I thought, but probably has a lot less performance overhead though, as it would be done only at start of program invocation rather than each MSIL instruction having to be interpreted every time it was encountered.

Why not? What is wrong with them?

Nothing is wrong with them if you like programming in that paradigm. Personally, I like close to 100% control of what my program is. I'm the kind of guy that likes to make files based on their binary specifications rather than using external APIs geared towards those types of files if I can help it! YES I like reinventing the wheel a lot IF it means I then gain a better understanding of internals in the process. My ultimate goal is to be able to program any sort of program for any OS in pure hexadecimal. Yes, I realize that might sound crazy, but I'm not planning on making all my programs in pure hex---more of a "Hello World" in as many different executable formats on as many different OSes as I can type thing---mainly a personal proof-of-concept thing for me. If I manage to accomplish this incredible task, then I will know I have a very intimate knowledge of programs on each of those OSes. With this knowledge, I then will be nearly unimpeded in any programming endeavours. Code in C# or Visual Basic .NET or Managed C++ and you wouldn't have this degree of internal control. I never said I would not program in those languages, just that I did not want to be forced to programming in any one (or a few) programming languages.;)

You could look at it the other way, and say it is also beautiful. MS has sunk a lot of money and development time into .Net, and they stand to make a huge amount of money in return. Also, the .Net framework has been very well architected and well written.

Perhaps--depends on your personal paradigm, I'd say.:)

You can code in MSIL, although it is not asm as you know it.

Then add MSIL to the list of things I will try to learn;) It seems necessary to know MSIL backwards and forwards to even hope to accomplish making a .NET program in hex, so I should then learn it.:)


As an asm programmer, you mean nothing to MS. It is MS's intention that the .Net framework be ported to as many platforms as possible (one reason why they released Rotor), it is also their intention that as many platforms and devices as possible run some form of Windows. This is definately a "world domination" tactic, and has every chance of succeeding where Java failed.

True. However, if I succeed with my incredible (though not impossible) task, (yes, I am aware it requires I memorize all opcode hex values, but I see this as doable and a good test of self-discipline) it won't really matter what I mean to MS as I would then be able to (in theory) create my own low-level tools, compilers, and programming languages and port them to all those platforms. Somehow I trust things that I, myself, made/wrote more than any other software, but that's just me. If I also wrote my own compilers/etc, then I'd have nearly full trust in my programs.
Posted on 2004-03-08 04:38:35 by ShortCoder

Incorrect. The files are still have a PE type header, but they are not PE files. And the JITter is part of the .Net framework, it is not embedded in each file.

Iirc they actually are, but the entrypoint is just a call to some .NET manager code... it's only a very few instructions though, and the JITer + runtime is definitely NOT embedded in each and every executable, that would be plain stupid.


"Hello World" in as many different executable formats on as many different OSes as I can type thing---mainly a personal proof-of-concept thing for me. If I manage to accomplish this incredible task, then I will know I have a very intimate knowledge of programs on each of those OSes.

Not really. You will know a few simple system calls, a few CPU instructions, and a very limited subset of the executable format :tongue:. It's smarter to learn a few high-level languages and scripting languages really well, which enables you to work on more or less any platform, and focus on becoming good with assembly on a few platforms. Not much use in being half-assed on every platform on the earth...
Posted on 2004-03-08 08:32:37 by f0dder