Talk:Managed code

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
???	This article has not yet received a rating on Wikipedia's content assessment scale.
???	This article has not yet received a rating on the project's importance scale.

Disadvantages?

The article mentions benefits, but not any drawbacks to using/developing managed code. I'd guess that there are some trade-offs such as restrictions imposed by the runtime environment. However, I'm no expert and haven't found any secondary sources to list any trade-offs. —Preceding unsigned comment added by ElliottHoffman (talk • contribs) 21:02, 29 April 2008 (UTC)[reply]

I think, the biggest disadvantage is bad performance. Virtual Machines normally always have a bad performance, although the performance can be inhanced by using Pacifica/Vanderpool, but it is still much slower then when the code is executed directly. Java and .NET programs are also not known for good performance. --MrBurns (talk) 00:35, 12 November 2008 (UTC)[reply]

Agreed, someone needs to put up the disadvantages. Virtualization can be very slow and these days people are moving to virtualizing while they virtualize making the situation worse. —Preceding unsigned comment added by 99.224.115.100 (talk) 04:44, 23 May 2009 (UTC)[reply]

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. --Casiotone^talk 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 —The preceding unsigned comment was added by Bijeshvm (talk • contribs) 21 July 2006.

Windows only?

The article seems to imply that managed code is a Windows-only thing. But I've heard that Linux also supports it. --Smithfarm 10:11, 20 August 2006 (UTC)[reply]

Hmm. Might now. Microsoft did build this in a way that it could be ported to other OSs, but for years no one did. And, of course, some MS types, speaking loosely, refer the Java environment as "managed". Does anyone know anything concrete on this? - Jmabel | Talk 00:47, 21 August 2006 (UTC)[reply]

The answer is only one click away. The first sentence of this article says "... or other CLI implementations from The Mono Project or the DotGNU Project. " and the second sentence of the Mono article says "Mono can be run on Linux, FreeBSD, UNIX, Mac OS X, Solaris and Windows based computers." Leotohill 04:44, 21 August 2006 (UTC)[reply]

Added technical Tag

This page is probably incomprehensible to the average person. Nrbelex ^(talk) 21:38, 4 October 2006 (UTC)[reply]

Why is using Managed Code supposed to be difficult?

It has been widely written that writing programs with managed code is more difficult than with unmanaged code, that it has "steep learning curve". For instance "First VB gets the axe. What’s next COBOL?" Posted by David Berlind, http://blogs.zdnet.com/BTL/index.php?p=1141 . Search Google for "managed code difficult learning curve" for much more.
Nothing in the article explains why this would be. Interpreted, byte-coded, or JIT-compiled languages are not usally harder to use than others. And Visual Basic was interpreted before it used managed code. —The preceding unsigned comment was added by 207.178.223.83 (talk • contribs) 16 November 2006.

Probably this is with reference to people who did not have previous experience with object-oriented languages and large software libraries. - Jmabel | Talk 01:09, 19 November 2006 (UTC)[reply]

Major cleanup (truncation)

I've rewritten the intro and deleted most of the other content. I think that what remains is all that is needed. The other content is available in the linked articles, and in better form there.

Leotohill 04:07, 19 July 2007 (UTC)[reply]

Actually, the language has no effect

"The programming language used to create the program determines whether it will run as managed code or not." Wrong. All you need is a bytecode compiler that supports your language. 202.89.155.252 00:06, 7 August 2007 (UTC)[reply]

Not sure I understand what you are saying here, but in any case I suspect that the statement as written is correct for all practical purpose. Of course, any program can theoretically be converted to an equivalent program in another language, but we really don't want to muddy the waters here. Leotohill 14:51, 9 August 2007 (UTC) :[reply]

"I suspect that the statement as written is correct for all practical purpose" Not necessarily. Some languages, eg, OCaml, supports bytecode execution and native compilation. Any language can do this, its just a matter of whether someone actually spends the time to implement it or not. Some languages have a number of targets supported in one form or another. For example, Python has its own virtual machine, Jython for JVM, IronPython for .NET etc In any case, the article describes this well enough now, so ignore me --84.203.194.18 (talk) 13:27, 23 March 2009 (UTC)[reply]

Interpreted language

This article content doesn't belong to the prosed target location, managed code isn't interpreted... It could be merged into .NET Framework or the Common Language Runtime, but it seems to be useful to keep it in this simplified version. --89.152.177.195 (talk) 05:48, 8 November 2009 (UTC)[reply]