Jump to content

Talk:Managed code

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Bijeshvm (talk | contribs) at 06:50, 21 July 2006. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Is this not a stub?

I came here looking for lots of information and resources about managed & unmanaged code, differences, etc., pros & cons, but found just this. A little disappointing, especially given Wikipedia's technical group of authors. I'll mark it as a stub.

Java and LISP

Do they fall under the definition of managed execution environments, or is this only done by .NET and clones?

Convoluted sentence

"However, unlike most of these traditional interpreter/compiler hybrids, the .NET virtual machine also supports multiple pre-compiled binaries in the executable in a form similar to the Apple Universal binary format."

"Executable" is an adjective, being used here as a noun. Presumably meaning "executable file" (common programmers' shorthand) but should be explicit in an encyclopedia with a broad audience. But is a binary file; what does it mean to have "multiple pre-compiled binaries" in a single executable file? Each relates to what? A different module? A different language? Etc. this is just really confusing. This is not the only confusing thing about the sentence, but I'm at the end of my day here & not thinking clearly enough to spell it all out. If someone understands what is meant here, please reword more clearly. Thanks. - Jmabel | Talk 07:21, 9 February 2006 (UTC)[reply]

Hmm, still convoluted but perhaps a little clearer 82.133.105.218 14:32, 7 March 2006 (UTC)[reply]

Copyvio?

Most of the meat of this article is pretty much a verbatim copy from the Abrams blog entry linked in "External links". This probably needs fixing.

I'd remove the copyvio, but even if I wasn't instantly reverted by some accretionist for daring to remove text, all it would leave would be a dicdef and some incomprehensible ramblings about universal binaries. Then again, given that "managed code" is basically just a buzzword for a bunch of derivative technologies anyway, maybe that would be rather appropriate...

Haeleth Talk 17:41, 6 March 2006 (UTC)[reply]

Too many undefined terms

I think I know some of what is being described but this is thanks to fitting the terms into prior knowledge, rather than the terms adding new knowledge. I am here because on moving to a new cpu we had to install a new compiler (having lost the previous compiler's installation disc, and it being no longer supported anyway) and in the first test (after handling annoying differences in interpretation of logical expressions) the new code ran slower by quite a lot: 104 secs vs. 74 and the .exe file was also much larger 5.4MB vs 1.4MB. Urgh. I have yet to try a comparison between optimised versions. With the old (non .NET) compiler a particular prog. ran in a third of the time so there is a lot of scope.

If I follow the first part correctly, my new .exe file is not directly executed. Instead, on activation rather than load its code and start running, it invokes the ".NET framework" which extracts from it information suitable to produce code that runs on the specific model of computer it is about to be started on. This processor presumably offers op codes A,B,C but not X,Y,Z so those portions of my .exe stuff that contain appropriate versions (as generated by the compiler) of functions or sequences of statements are selected, and not others and the resulting code, when executed, will run faster than would code that uses only the commonly available op codes found on "all" cpus. Possibly, other changes might be made as well?

But if this is so, my code is running slower than that produced by the non- .NET compiler.

The term "runtime environment" is bothersome jargonspeak meaningful only to the cognoscenti of that jargon. Is "runtime" noun or an adjective, or, either?

If I follow this section correctly, my prog. when running, does so with code having been generated in a standardised form so that its execution can be monitored by an outside prog. (possibly on a different computer) so as to display the state of variables and other data aggregates, the nature of such variables being known. That is, the equivalent of a memory map as produced by the original compilation, relates every storage location to the type (logical, character, integer, floating-point, etc) so that the bits may be displayed helpfully. Further, array bounds and suchlike can be checked. The monitoring prog. can stop the running of my prog. and via the "framework" it has been fitted into, the values of variables at that point can be inspected.

So there are three entities: my code executing (as selected from my .exe file as produced by the compilation of my prog.), the .NET framework that is controlling it (possibly producing new code selections only as new portions are invoked), and possibly a monitor prog. that is inspecting this execution and is reliant on the various conventions.

Possibly, it is compliance with the various conventions that is slowing my prog. since the preparation time is small compared to the millions of times that certain loops are iterates in 77 seconds.

Regards, NickyMcLean 21:47, 26 April 2006 (UTC)[reply]

merge w/ byte-code

i think its the same phenomenon (concept) and it should be moved to appropriate (new) section in that article --NickShaforostoff 09:40, 1 May 2006 (UTC)[reply]

Why merge?? Managed code is compiled prior to running whereas bytecode does not have to. Example: SWEET16 is not compiled but interpreted directly by a virtual 16 bit computer implemented in a few hundred bytes of 6502 code. The same goes for p-code. Managed code is too tightly integrated in the Microsoft world to warrant a merge and no doubt both articles will expand significantly over time. You could possibly defend a merge with typical Just-in-time compilation systems such as java bytecode (though early implementations used plain and slow interpreters) and Lua bytecode. My experiences with assembly programming over a few decades tells me that two articles will be more useful and managable (no pun). Having said that a good overview article relating these themes and contrasting them would be useful as well as proper linking between the articles. For instance the articles Just-in-time compilation and P-Code machine do not link to byte-code. --15:11, 14 May 2006 (UTC)
FOR merge - The main concept of a non-directly-machine code is the same, regardless of trivial non-platform related differences. --Procrastinating@talk2me 13:42, 11 June 2006 (UTC)[reply]
AGAINST merge - conceptually, the terms are distinct. 'byte-code' describes the output of a certain kinds of language compilers. The term is not limited to .NET languages. The term 'Managed code' was popularized by Microsoft and applies specifically to the .NET environment. Furthermore, it would be quite possible to merge a compiler and a JITTer such that the output of the compiler is machine code that is .NET managed: then you have managed code without byte code. Leotohill 18:11, 11 June 2006 (UTC)[reply]
Against merge. Managed code is a term specifically coined by Microsoft for .NET to refer to code that operates in the CLR. Bytecode can be created by any compiler for any language for any framework. We can't exactly put every single one into the Bytecode article. --Casiotonetalk 14:00, 29 June 2006 (UTC)[reply]

Info for beginners

Good talk on on the managed code is available at www.developer.com/net/cplus/article.php/2197621