What do you think about managed code and OSes written in it?

[HoTT]

Originally it was Microsoft who coined this term. They assume a runtime engine performs some management tasks.

I know this article, but I don't think it's a good one. Actually I have a hard time to accept managed code as anything but a marketing term. Managed Code = runs on a virtual machine? What python? Is python managed code by your definition?

And another benefit of the managed environment is it's abilities to manage software maintenance, software performance monitoring, software bug reporting, software development cycle, detection of software usage patterns, software run time optimization, enhanced environment security and reliability, hardware independence and most probably something else that I've just missed here.

Sorry, but this sounds like: A managed environment is something than manages things. Which sounds pretty circular. All of it can be gained without an virtual machine, though.

[embryo]

For an example; for the message passing I typically use for my OSs, all IO is transferred via. "message buffers" . The messages appear as fixed size (2 MiB) arrays of bytes (regardless of actual message size) and the compiler can statically check that you're not reading/writing beyond the end of the 2 MiB array of bytes, and no run-time bounds-checking is needed for any IO of any kind.

But if it is a smaller than 2 Mb data size that you need? And compiler thinks the code is correct while in fact I can use your code to read the buffer's content after the length of the data that is smaller than 2 Mb.

If you can turn the checks off, then it's no longer "managed" (e.g. malicious code can turn the checks off).

It's a yet another management option. My software can manage my code and it can compile my code whenever my algorithm is thinking it is safe to translate a code into unmanaged form. If I make mistakes when create an algorithm, then it's a security and reliability vulnerability, but it's common human's deficiency for both types of environments, managed and unmanaged, so this part of the equation can be safely reduced.

Switch to a better unmanaged language and the problem can disappear (a managed language is *not* necessary).

Of course a managed language is not necessary, just like for stone age human it was unnecessary to make some sanitation every day. But history tells us that such approach tends to be generally negative for a human.

Managed languages are inadequate for the checking, inadequate for constructing a suitable error, and inadequate for delivery the error appropriately.

I hope you have some proof for such words.

In your example of a browser engine; a managed OS (that relies on a managed language for security/isolation) can not trust the browser because the browser is not "100% managed".

But if it's a managed environment (managed OS), then there will be no unmanaged code except the compiled by the environment (OS). So, we can trust any browser.

A memory-safe language running on a VM which is itself written in an unsafe language (e.g. the JVM is written in C, most Javascript engines are written in C/C++) is also vulnerable to memory safety bugs in the VM itself.

It just as vulnerable as a human being is vulnerable to it's own mistakes. So such "vulnerability" is applicable to any form of a software and introducing it in a discussion "managed vs unmanaged" is a mistake.

[embryo]

Actually I have a hard time to accept managed code as anything but a marketing term. Managed Code = runs on a virtual machine? What python? Is python managed code by your definition?

I don't know how the Python's interpreter is implemented. But it definitely has some features of a managed environment. The question is only to what extent the features are copied from a managed environment.

Sorry, but this sounds like: A managed environment is something than manages things. Which sounds pretty circular. All of it can be gained without an virtual machine, though.

Compiler compile compilers. Yes, it is a circular statement. But we can easily understand the bottom line of the circular statement and the value of a compiler. Is it possible to compile without compiler? Is it possible to gain advantages without managed environment?

[HoTT]

The question is only to what extent the features are copied from a managed environment.

What are features of a managed environment? (Now it's an evironment and not code anymore?).

Compiler compile compilers. Yes, it is a circular statement. But we can easily understand the bottom line of the circular statement and the value of a compiler. Is it possible to compile without compiler? Is it possible to gain advantages without managed environment?

The key difference is that there is an non-circular definition of compiler: An A-B-Compiler translates programs from language A to language B.

[Rusky]

• the compiler/language doesn't support compile time checking to prevent it, even though it's 100% possible to do so; or

It is not possible in every case to check array bounds at compile time. What you can do at compile time is verify that only the necessary run-time checks are used. As HoTT said:

Many languages use bound checking by default and remove the checks where it can be statically proven they are not needed. Another approach would be to reject all programs where it cannot be proven, which usually will require to add a manual check.

Comes down to the ~same number of run time checks.

No matter how sophisticated your range type system, there will always be useful programs that, if they are not to be exploitable/crashable, must have runtime checks added by either the compiler (verification of ranged type conversion) or by the programmer (explicit ranged type conversions), even if it's nothing more than "take these 4 input bytes, check that they represent an integer in this range, otherwise error." This is a property of any turing complete language (actually a much bigger class of languages), not just of lazily-designed languages.

I would be very interested to see a useful language design that actually does all the checking at compile time. You'd upturn a lot of results in mathematics and computer science with it. Please describe your language design that does this or we're just going around in circles.

"security vulnerabilities" is an very unlikely worse case in a properly designed system and isn't even close to a guaranteed outcome for extremely badly designed systems.

Let's take the Linux kernel as an example of an "extremely badly designed system," because you've strongly disagreed with its design decisions in the past, and it's written in C, a language which does no bounds checking at compile time or runtime. In the year 2014 alone, there were at least 21 buffer overflows, where at least 6 of them resulted in remote code execution, and several others led to information leaks or security measure bypasses.

Now let's look at your imaginary well-designed system, but without bounds checks (because, paraphrasing my claim and your response, "when languages don't do bounds checking, security vulnerabilities are still very unlikely"). What would be different from Linux? Probably better APIs for I/O that don't rely on the programmer to manage the sizes of arbitrary-sized buffers, probably better protocols that don't involve as much indexing into buffers based on external data. But those are only guidelines, and programmers are human, and one of your core tenets of language design is that the compiler should do as much checking as possible, so why not combine better APIs and protocols with statically-enforced bounds checking?

In your example of a browser engine; a managed OS (that relies on a managed language for security/isolation) can not trust the browser because the browser is not "100% managed". Whether or not the malicious code's author thinks you should trust their virus (because they wrote most of the virus in "safe" code and a small part in "unsafe" code) is not particularly relevant when it comes to the OS and/or end user's trust.

I'm going to quote HoTT again:

However none of this requires managed code. Whatever that is.

I'm not talking about managed systems. Hardware checking is great, compile time checking is great, not trusting programmers is great. I'm not talking about that at all. When I brought up trust, I was talking about tools to help programmers write the better-designed systems you're talking about, not user/OS/program trust.

There will always be times when you need to punch through the usual protections to implement abstractions or improve performance. But those times don't have to be "anywhere in your entire program any programmer felt like it." They can instead be "only in specifically marked locations that are easy to find automatically when something does go wrong," and those specifically marked locations can further be automatically banned by the compiler in most of the program.

[embryo]

What are features of a managed environment? (Now it's an evironment and not code anymore?).

Yes, it is an environment. The code alone can not be managed just because of missed manager.

The main feature of a managed environment is it's ability to do some job for you automatically. When you have finished your coding the only action you are required to execute is just handling your code to the environment. And it doesn't make a difference if the environment is running under Linux or Windows, is powered by x86 or ARM processor. The environment manages all the differences in a transparent fashion. Also it applies to such things as performance, debugging, learning, speed of development, security, reliability and so on.

Compiler compile compilers. Yes, it is a circular statement. But we can easily understand the bottom line of the circular statement and the value of a compiler. Is it possible to compile without compiler? Is it possible to gain advantages without managed environment?

The key difference is that there is an non-circular definition of compiler: An A-B-Compiler translates programs from language A to language B.

And where are the circularities in the definition of a managed environment or language? Environment manages code written in a special language, that is called by Microsoft guys "managed". And the environment itself is much more manageable by a human than all the combinations of OSes and hardware with different tool-chains and libraries. It is just much simpler and the simplicity delivers new quality of coding, it is faster, more reliable, secure, requires less learning and just more fun.

[HoTT]

The main feature of a managed environment is it's ability to do some job for you automatically.

Well gcc links libraries automatically for me. So C + gcc is a managed environment?

When you have finished your coding the only action you are required to execute is just handling your code to the environment. And it doesn't make a difference if the environment is running under Linux or Windows, is powered by x86 or ARM processor. The environment manages all the differences in a transparent fashion.

So, managed code is code running on a VM, like Java-VM? If I'd write a VM whose bytecode would be equal to the x86 instruction set, would it be a managed environment?

Also it applies to such things as performance, debugging, learning, speed of development, security, reliability and so on.

How does a managed environment manages those things? What does that even mean?

And where are the circularities in the definition of a managed environment or language?

Well, you'r saying that a managed environment is something that manages things for you. That's like saying a operation system is a system that operates.

[embryo]

Well gcc links libraries automatically for me. So C + gcc is a managed environment?

There is a software life cycle, which starts when you are coding and ends when an application is uninstalled. And you can compare the one step you have pointed out (gcc links libraries automatically) with the whole life cycle of your code. It's like driving a car and driving one wheeled device with pedals only.

So, managed code is code running on a VM, like Java-VM? If I'd write a VM whose bytecode would be equal to the x86 instruction set, would it be a managed environment?

If you provide your VM with your code and everything else is managed by the VM, then yes, you have a managed environment.

Also it applies to such things as performance, debugging, learning, speed of development, security, reliability and so on.

How does a managed environment manages those things? What does that even mean?

For performance it is about a particular hardware knowledge and run time information availability. Debugging means you never have to scrap your head in a search for some mystique problem, but you always have all required information to find a bug. Learning is about a standard design of a language, about the same libraries for any possible platform, about the same rules that manage the environment on any platform and so on. Speed of development is about simplicity and quick debugging. Security is about liquidated unmanaged code vulnerabilities. Reliability is about not crashing your application because of simplest bugs.

But all those benefits can be discussed in much details and it would be better to create a thread per benefit for this purpose.

Well, you'r saying that a managed environment is something that manages things for you. That's like saying a operation system is a system that operates.

If you will get a definition of the word "operates", then I can point to similarities and differences here.

[HoTT]

But all those benefits can be discussed in much details and it would be better to create a thread per benefit for this purpose.
HoTT wrote:
Well, you'r saying that a managed environment is something that manages things for you. That's like saying a operation system is a system that operates.

If you will get a definition of the word "operates", then I can point to similarities and differences here.

While I find this discussion interesting and I do have a genuine interest in it, I don't think I'll ever get an usable definition of managed code from this thread. With usable I mean one that given a programming environment makes answering the question: "Is this a managed one?" easy. So, I'm giving up.

[AndrewAPrice]

Originally it was Microsoft who coined this term. They assume a runtime engine performs some management tasks.

I know this article, but I don't think it's a good one. Actually I have a hard time to accept managed code as anything but a marketing term. Managed Code = runs on a virtual machine

I always thought managed code just means code that runs under the .Net framework. As a professional software developer, I never hear Java code referred to as managed code. It's a .Net term.

[HoTT]

I always thought managed code just means code that runs under the .Net framework. As a professional software developer, I never hear Java code referred to as managed code. It's a .Net term.

Yes, that's why I said it's a marketing term. But apparently it's used differently in this thread, otherwise embryo would just have said managed code would be code that runs on the CLI-VM on the topic of this thread would be "What dou you think about .Net and OSes written in it?".

[Rusky]

embryo tends to use it to refer to C#, Java, and anything else with a similar paradigm to Microsoft's "managed code." He also tends to conflate advantages it happens to have with the entire package of features, thus the confusion.

[Brendan]

Hi,

I always thought managed code just means code that runs under the .Net framework. As a professional software developer, I never hear Java code referred to as managed code. It's a .Net term.

Yes, that's why I said it's a marketing term. But apparently it's used differently in this thread, otherwise embryo would just have said managed code would be code that runs on the CLI-VM on the topic of this thread would be "What dou you think about .Net and OSes written in it?".

embryo tends to use it to refer to C#, Java, and anything else with a similar paradigm to Microsoft's "managed code." He also tends to conflate advantages it happens to have with the entire package of features, thus the confusion.

Yes.

As far as I'm concerned; "managed" only means that the environment detects problems at run-time for more than just security/isolation purposes.

My definition has consequences:

• If problems are detected at compile time, then none are left to be detected at run time and it's not "managed".
• If hardware performs the run-time checks (e.g. someone built a CPU that uses Microsoft's CLI as it's native instruction set that honours the run-time checks) then it is still "managed".
• If nothing performs the run-time checks (e.g. someone built a CPU that uses Microsoft's CLI as it's native instruction set that does not do the run-time checks) then it is not "managed".
• If the hardware doesn't do the run-time checks, then they can be done in software (either by a compiler injecting run-time checks into native code or by using an interpreter or JIT compiler) and it'd still be "managed".

Mostly this means that (for my definition); "managed" doesn't necessarily mean that software does the run-time checks and doesn't necessarily mean executables can't be native code.

Also (for my definition), "managed environment" has nothing to do with the source code or language (e.g. you can execute C in a managed environment, or execute C# in an unmanaged environment) and has no effect on the time it takes for developers to actually write code (but can slightly improve the time it takes developers to find and fix bugs in code they've written).

A "managed language" is a language that's designed for a managed environment, and this has nothing to do with whether the code is actually executed in a managed environment or an unmanaged environment.

Finally, a "managed OS" is an OS where all (user-space) code executes within a managed environment (and has nothing to do with whether that code was written in a managed language or not). In this case; because the code is running in a managed environment it's "relatively safe" to avoid using the hardware's protection mechanisms for security/isolation (e.g. the Singularity research project). Note that "relatively safe" here means "100% safe, if and only if you can guarantee there's no bugs in the compiler or run-time environment, and no hardware faults".

In my opinion; the best possible approach is to use an unmanaged language (where the programmer's hands aren't tied behind their back) and provide a managed environment that developers can use before releasing their software (e.g. something like valgrind maybe) and also provide an unmanaged environment that end users use after the software is released. This "dual environments" approach gives you the benefits of faster bug detection/fixing for developers while also giving you the benefits of max. performance for end users. Of course the disadvantage here is that it's a lot more work to create the compilers/environments needed to support "dual environments".


Cheers,

Brendan

[embryo]

I don't think I'll ever get an usable definition of managed code from this thread. With usable I mean one that given a programming environment makes answering the question: "Is this a managed one?"

A managed environment has set of features that defines it. It's like when we want to ask "is this a car?". A car has many features and the whole set of features makes a car distinguishable from a bicycle, from a motorcycle, from a quad bike or from whatever else.

In particular most important features of a managed environment include:

1) It has it's own "safe" language (which is a subject for separate thread because of the big volume behind the word "safe").
2) The language is compiled into intermediary form that is the same for any possible platform.
3) It has a standard set of libraries that define such non-standard operations as file or network access or GUI calls.
4) It has a runtime that is capable of code management activity. It means a code can be introspected, changed, recompiled or affected in some other way for some important reason (like speed increase due to JIT compilation).
5) The runtime prevents running code from influencing anything else except of strictly defined set of areas.
6) The runtime is operated in the same manner on any possible platform (it makes it "managed", but now by humans).

The lack of any feature from above makes an environment unmanaged. Or if you prefer to see everything in a strict line without breaks, then the lack of a feature makes an environment much less manageable and much less convenient for a human.

[embryo]

embryo tends to use it to refer to C#, Java, and anything else with a similar paradigm to Microsoft's "managed code." He also tends to conflate advantages it happens to have with the entire package of features, thus the confusion.

I use the term "managed" in the context of osdeving. I prefer to develop a manged OS and it represents a managed environment, but the language that had been chosen for the OS is Java. That's why I mix Java and Microsoft's ways. The Microsoft's way is about OS-wide managed environment, but Java way is about runtime environment only. And to combine them both (and advantages of both of them) I decided to create another OS-wide managed environment, but with Java as a base language.

Also it is worth to note that I see the term "managed" as suitable for definition of a safe and easy to use environment in both cases, when it is OS-wide or when it is in form of a runtime only.