OSDev.org

Brendan wrote: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".

Then what about learning time problems, for example? Can they be detected at compile time?

Brendan wrote:

• 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".

Then what about a security manager, that never was a part of any bytecode?

Brendan wrote:

• 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".

Then what about runtime checks for invalid pointers? How it is possible to determine that the pointer is valid (i.e. it's value should be x-4 instead of x)?

Brendan wrote: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.

Run time checks only define no managed environment.

Brendan wrote: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).

Well, then just define an algorithm for detecting all possible incorrect pointers. And the I will accept your definition without any problem.

Brendan wrote: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.

Managed language is a part of a managed environment. Nothing will be managed if the system is split into some parts. Language without environment is unmanaged just as the environment without language is unmanaged too.

Brendan wrote: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).

It's the same as above - just define an algorithm for detection of incorrect pointers.

Brendan wrote: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 this case everything in the universe is "relatively safe". But if we notice that the "relatively safe" is a property of everything, then it will be a much simpler and still absolutely honest comparison if we just remove the "relatively safe" part from both compared sides. Just because x+y>x+z will always be the same as y>z.

Brendan wrote: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".

There's just no need for such duality. All it is possible to combine in one single managed OS. If you are in a development stage then your environment just doesn't remove anything useful for debugging, runtime statistics and other stuff. But if you have decided that your code is as safe as if you will never be ashamed of it, then you can tell the environment that your code is "great" and it will compile it with all optimizations possible and run it under hardware protection as a purely native application.

Then what about runtime checks for invalid pointers? How it is possible to determine that the pointer is valid (i.e. it's value should be x-4 instead of x)?

It's the same as above - just define an algorithm for detection of incorrect pointers.

It's a false assumption that you can in a language like C guarantee that every pointer points to an allocated memory slice or that every native language is like C. However it's possible to design a language where all pointer values are valid by construction or correctly bounds checked. Of course you'll need to forbid most pointer arithmetic.

Hi,

embryo wrote:

Brendan wrote: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".

Then what about learning time problems, for example? Can they be detected at compile time?

I'm not sure what you mean by "learning time problem". Does it have anything to do with (e.g.) someone repeatedly explaining that source language has nothing at all to do with whether or not the final executable ends up being executed in a "managed environment", and then a second person spending the best part of an entire week failing to learn such a basic idea?

embryo wrote:

Brendan wrote:

• 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".

Then what about a security manager, that never was a part of any bytecode?

What about goats? They have nothing to do with anything I've said too, so they shouldn't be forgotten either!

embryo wrote:

Brendan wrote:

• 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".

Then what about runtime checks for invalid pointers? How it is possible to determine that the pointer is valid (i.e. it's value should be x-4 instead of x)?

Who says a language has to have pointers to begin with? Please note that valgrind does determine if pointer/s are valid (and does it by running native code inside an instrumented virtual machine so that it can detect a wide variety of different types of errors).

embryo wrote:

Brendan wrote: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.

Managed language is a part of a managed environment. Nothing will be managed if the system is split into some parts. Language without environment is unmanaged just as the environment without language is unmanaged too.

A managed language is typically used in conjunction with a managed environment; but this is not a strict requirement and (as I've mentioned previously several times and you've ignored) you can have an unmanaged language like C running in a managed environment like valgrind, and you can have a managed language like C# running in an unmanaged environment.

embryo wrote:

Brendan wrote: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".

There's just no need for such duality. All it is possible to combine in one single managed OS.

Wrong. As soon as an OS allows (managed or unmanaged) code to execute in an unmanaged environment it is no longer a managed OS - it's just an OS that supports an (optional) managed environment.


Cheers,

Brendan

Brendan wrote:I'm not sure what you mean by "learning time problem".

I mean that the same set of language rules, libraries and usage patterns requires less learning than a multitude of rules, libraries and patterns in case of unmanaged approach.

Brendan wrote:Does it have anything to do with (e.g.) someone repeatedly explaining that source language has nothing at all to do with whether or not the final executable ends up being executed in a "managed environment", and then a second person spending the best part of an entire week failing to learn such a basic idea?

The managed environment requires less learning to run an application that is programmed for the managed environment in a managed language. And your language will meet the fate of all other unmanaged languages when a user will be required to learn some new knowledge every time he wants to run an application on different platform. And of course, embedding platform independence in a language without an environment that is able to run a program in such language, will require a lot of work from you in form of the same, but stripped down managed environment for each platform.

Brendan wrote:

embryo wrote:

Brendan wrote:

• 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".

Then what about a security manager, that never was a part of any bytecode?

What about goats? They have nothing to do with anything I've said too, so they shouldn't be forgotten either!

The security manager defines bounds for what is allowed and what is disallowed when a program is executed under managed environment. In your case it is a programmer that will be required to write such manager in every application instead of using a standard one from the managed environment. And if you prefer not to use such manager then the security of your application is compromised.

Brendan wrote:

embryo wrote:

Brendan wrote:

• 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".

Then what about runtime checks for invalid pointers? How it is possible to determine that the pointer is valid (i.e. it's value should be x-4 instead of x)?

Who says a language has to have pointers to begin with?

It's about your statement, that insists on a program being managed while it in fact is not managed. To be managed a set of features is required and your statement misses that set. Also your statement has missed to note what language you are expecting to be used, so I have a viable base to suppose that the language is C.

Brendan wrote:Please note that valgrind does determine if pointer/s are valid (and does it by running native code inside an instrumented virtual machine so that it can detect a wide variety of different types of errors).

The pointer is valid if points to a different object, or even if it points to some data, that has nothing to do with any object. The consequence of such "valid" pointer is some unpredictable application behavior. In case of managed environments there is just no chance that a problem like this can ever exist. So, it is about the fact that you just extend the range of possible problems by refusing to accept a managed environment.

Brendan wrote:A managed language is typically used in conjunction with a managed environment; but this is not a strict requirement and (as I've mentioned previously several times and you've ignored) you can have an unmanaged language like C running in a managed environment like valgrind, and you can have a managed language like C# running in an unmanaged environment.

The combination of a managed language with managed environment makes it possible to achieve many advantages that were mentioned before. If you split the combination and get just one part of it then the interdependencies within the combination are lost and, for example, an arm that is detached from a human and attached to an elephant will be of much lesser value because the elephant is designed to accomplish it's mission without an extra arm and the arm is designed to accomplish it's mission in combination with a human.

Brendan wrote:As soon as an OS allows (managed or unmanaged) code to execute in an unmanaged environment it is no longer a managed OS - it's just an OS that supports an (optional) managed environment.

No, it's just a label on an application for it's user, that reminds the user about some dangers, related to the application. If somebody thinks that his application requires no management and as a result will have some speed increase, then a managed environment just agrees to run the application, but marks it as dangerous and runs it under hardware protection to prevent a situation when any other application can be affected by the dangerous application. And user of the dangerous application should be notified about possible less stable behavior and other risks (such as buffer overflows and so on). So it is still managed OS, but with option to allow some applications to run dangerously in hope that it will lead to some speed increases. And please note, that unmanaged approach has no similar option, it just unable to provide a managed environment as an extra option.

HoTT wrote:

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?".

From how this thread started, I think the OP's intended topic was "What do you think about OSes that execute bytecode instead of the architectures machine code?"

Which doesn't necessarily mean "safe". You can have manual memory management and arbitrary pointer arithmetic in bytecode.

Pros:
- Portability - your executables could run under OS on smartphones, tablets, PCs, embedded devices.
- More fun if you like making your own architecture and compilers.
- Potential optimizations you can perform at AOT/JIT compile time.

Cons:
- More complexity because you need to make your own compilers that output your bytecode and an interpreter/JIT compiler that can run it.
- Difficulty porting existing software if you can't easily port a compiler for a popular language to your bytecode.
- Optimizations can't be done at a lower level than the bytecode (such as hand optimized assembly or optimizations that the developer's compiler can do but not the OS's).

- Portability - your executables could run under OS on smartphones, tablets, PCs, embedded devices.

Providing different binaries for different platforms is not that hard.

- More fun if you like making your own architecture and compilers.
- Potential optimizations you can perform at AOT/JIT compile time.

Not unique to a managed user space.

- Optimizations can't be done at a lower level than the bytecode (such as hand optimized assembly or optimizations that the developer's compiler can do but not the OS's).

I'm missing is a unique advantage of a managed user space in this discussion. That you cannot write a kernel in a managed environment should be clear, someone has to write that VM first.

Hi,

embryo wrote:

Brendan wrote:I'm not sure what you mean by "learning time problem".

I mean that the same set of language rules, libraries and usage patterns requires less learning than a multitude of rules, libraries and patterns in case of unmanaged approach.

Brendan wrote:Does it have anything to do with (e.g.) someone repeatedly explaining that source language has nothing at all to do with whether or not the final executable ends up being executed in a "managed environment", and then a second person spending the best part of an entire week failing to learn such a basic idea?

The managed environment requires less learning to run an application that is programmed for the managed environment in a managed language. And your language will meet the fate of all other unmanaged languages when a user will be required to learn some new knowledge every time he wants to run an application on different platform. And of course, embedding platform independence in a language without an environment that is able to run a program in such language, will require a lot of work from you in form of the same, but stripped down managed environment for each platform.

This has nothing to do with "managed environments" and everything to do with differences between different languages.

As far as learning goes; old managed languages (e.g. Pascal and its P-code, Lisp) are much easier to learn than newer managed languages (Java, C#, both with massive libraries); and old unmanaged languages (C) are much easier to learn than newer unmanaged languages (C++). It would be foolish to compare an old managed language to a new unmanaged language and decide that "managed" is easier to learn, and equally foolish to compare an old unmanaged language to a new managed language and decide that "unmanaged" is easier to learn.

embryo wrote:

Brendan wrote:

embryo wrote:Then what about a security manager, that never was a part of any bytecode?

What about goats? They have nothing to do with anything I've said too, so they shouldn't be forgotten either!

The security manager defines bounds for what is allowed and what is disallowed when a program is executed under managed environment. In your case it is a programmer that will be required to write such manager in every application instead of using a standard one from the managed environment. And if you prefer not to use such manager then the security of your application is compromised.

For things like whether or not a process is allowed to use networking, which files it can access, if there's disk or memory quotas, whether it can fork/spawn child processes, who it can communicate with, etc; all of those things are built into the OS and/or kernel, have nothing to do with the process itself, and have nothing to do with "managed vs. unmanaged".

embryo wrote:

Brendan wrote:Please note that valgrind does determine if pointer/s are valid (and does it by running native code inside an instrumented virtual machine so that it can detect a wide variety of different types of errors).

The pointer is valid if points to a different object, or even if it points to some data, that has nothing to do with any object. The consequence of such "valid" pointer is some unpredictable application behavior. In case of managed environments there is just no chance that a problem like this can ever exist. So, it is about the fact that you just extend the range of possible problems by refusing to accept a managed environment.

For languages like C/C++, pointers that point to something of a completely different type are perfectly valid. There's even language features designed specifically to allow this (type casts, unions). Complaining that a managed environment doesn't whine about things that are perfectly valid for the language it's designed for is silly.

embryo wrote:

Brendan wrote:As soon as an OS allows (managed or unmanaged) code to execute in an unmanaged environment it is no longer a managed OS - it's just an OS that supports an (optional) managed environment.

No, it's just a label on an application for it's user, that reminds the user about some dangers, related to the application. If somebody thinks that his application requires no management and as a result will have some speed increase, then a managed environment just agrees to run the application, but marks it as dangerous and runs it under hardware protection to prevent a situation when any other application can be affected by the dangerous application. And user of the dangerous application should be notified about possible less stable behavior and other risks (such as buffer overflows and so on). So it is still managed OS, but with option to allow some applications to run dangerously in hope that it will lead to some speed increases. And please note, that unmanaged approach has no similar option, it just unable to provide a managed environment as an extra option.

What exactly would be the difference between a managed OS that allows code to run either in a managed environment or an "unmanaged but with hardware provided isolation" environment, and a normal OS that allows code to run in either a "unmanaged but with hardware provided isolation" or a managed environment?

You're mostly saying that a managed OS is the same as an unmanaged OS. It should've been obvious to you that this is nonsense when you were writing it.


Cheers,

Brendan

HoTT wrote:

- Portability - your executables could run under OS on smartphones, tablets, PCs, embedded devices.

Providing different binaries for different platforms is not that hard.

If you consider all costs then it is obvious that for majority of developers it is hard to get used to a different platform. New hardware, new libraries, new toolchain, new OS, new device features - this requires a lot of time for all things to be used efficiently. And if somebody has such experience it doesn't mean that everybody can spend so much time with ease.

Brendan wrote:As far as learning goes; old managed languages (e.g. Pascal and its P-code, Lisp) are much easier to learn than newer managed languages (Java, C#, both with massive libraries); and old unmanaged languages (C) are much easier to learn than newer unmanaged languages (C++). It would be foolish to compare an old managed language to a new unmanaged language and decide that "managed" is easier to learn, and equally foolish to compare an old unmanaged language to a new managed language and decide that "unmanaged" is easier to learn.

For a developer to be productive it is a requirement to use a lot libraries. So, with some simple language like Pascal a developer needs to learn libraries. Next requirement is OS-specific knowledge. Again a developer should learn about new OS. Next requirement is toolchain knowledge. Again the developer should learn. And this learning process is repeated for every OS/hardware/toolchain/language/set of libraries. All this represents an environment, where developer works. In case of managed environment there is a need to learn just one environment. In case of unmanaged languages - developer needs to learn every environment he is required to support code for.

So, if we speak about managed/unmanaged, then it is the environments, that we should consider, but not only languages. And if we compare learning time for one environment (managed) and many environments (case for unmanaged languages) then it is obvious that many is more than one, that's why it is harder to learn.

Brendan wrote:For things like whether or not a process is allowed to use networking, which files it can access, if there's disk or memory quotas, whether it can fork/spawn child processes, who it can communicate with, etc; all of those things are built into the OS and/or kernel, have nothing to do with the process itself, and have nothing to do with "managed vs. unmanaged".

Here again we have to learn new knowledge for every OS. Next we should write at least new scripts for every OS. And every OS required an administrator with new skills. Now consider a managed OS, which delivers the same set of feature on any platform, supports just one set of scripts or whatever applications are required for it's management, requires an administrator with just one set of skills. And of course, it requires just one set of skills from developers. What variant costs more?

And there is another problem. An OS specific administrative options are general enough to be useless for some special cases. That's why it is easier to write an application server, that is designed with a specific goal of running specific applications, and implement all the flexibility we need in this one server instead of writing some flexibility extensions for every OS. And you can see the success of such approach in Java application server market.

And all this is possible because of managed environment which requires just one set of skills and knowledges.

Brendan wrote:Complaining that a managed environment doesn't whine about things that are perfectly valid for the language it's designed for is silly.

My complaints are about the whole type of bugs, that managed environment can exclude from programmer's life and unmanaged languages can't. Just because it is the responsibility of some environment to handle errors of such type (would it be standalone or embedded in every compiled program).

Brendan wrote:What exactly would be the difference between a managed OS that allows code to run either in a managed environment or an "unmanaged but with hardware provided isolation" environment, and a normal OS that allows code to run in either a "unmanaged but with hardware provided isolation" or a managed environment?

The difference is in developer's approach to the application development. Managed environment requires one and only one input for it to manage. Unmanaged OS allows input in any form (scripts, exes, plain binaries). So, the developer expects that if he writes code in a native form (unmanaged), then there will be better performance. But in fact developer looses all the benefits of managed environment while hoping for better performance. And it is the managed environment, that makes managed code useful on an unmanaged OS. It means that it is not the unmanaged OS, that provides developers with the managed option, but it is in fact managed environment developers. When some OS runs an application it just doesn't care about is it managed or not, but when managed OS runs application it cares a lot about the choice of a way the program can be executed. So, unmanaged OS provides nothing for a managed environment developer, while managed OS provides an option of dangerous execution with better performance (just like unmanaged OS, but with additional and useful safety checks and notifications).

If you consider all costs then it is obvious that for majority of developers it is hard to get used to a different platform. New hardware, new libraries, new toolchain, new OS, new device features - this requires a lot of time for all things to be used efficiently. And if somebody has such experience it doesn't mean that everybody can spend so much time with ease.

You're conflating things. You can use the same libraries, the same toolchain, the same OS on another hardware platform.

What do you mean with device features? If you want to use the different device features in a managed environment without further effort you must somehow abstract them. This can be done in an unmanaged environment as well.

Platform independence is not a managed environment feature.

Hi,

embryo wrote:

Brendan wrote:As far as learning goes; old managed languages (e.g. Pascal and its P-code, Lisp) are much easier to learn than newer managed languages (Java, C#, both with massive libraries); and old unmanaged languages (C) are much easier to learn than newer unmanaged languages (C++). It would be foolish to compare an old managed language to a new unmanaged language and decide that "managed" is easier to learn, and equally foolish to compare an old unmanaged language to a new managed language and decide that "unmanaged" is easier to learn.

For a developer to be productive it is a requirement to use a lot libraries. So, with some simple language like Pascal a developer needs to learn libraries. Next requirement is OS-specific knowledge. Again a developer should learn about new OS. Next requirement is toolchain knowledge. Again the developer should learn. And this learning process is repeated for every OS/hardware/toolchain/language/set of libraries. All this represents an environment, where developer works. In case of managed environment there is a need to learn just one environment. In case of unmanaged languages - developer needs to learn every environment he is required to support code for.

So, if we speak about managed/unmanaged, then it is the environments, that we should consider, but not only languages. And if we compare learning time for one environment (managed) and many environments (case for unmanaged languages) then it is obvious that many is more than one, that's why it is harder to learn.

Um, "managed environment" is about the environment the final executable is executed within, and not about the environment the programmer writes source code in. Almost all of the things you're saying here have nothing to do with managed vs. unmanaged, and everything to do with whether you're (e.g.) creating Java with a plain text editor (notepad) and typing "javac HelloWorld.java" manually at the command prompt; or whether you're using a nice IDE (that integrates editing, building and debugging) like VisualStudio to develop C++ code.

Note that if you stick to the language's standards, unmanaged languages can be very portable - you don't have to care about OS specific knowledge (but you can choose to care about OS specific stuff you want to, either for performance or for functionality that wasn't covered by the language's standards).

For libraries, it mostly depends on how old the language is. Old managed languages (like the old versions of Pascal that used P-code) and old unmanaged languages (C) have very few libraries; and newer managed languages and newer unmanaged languages have many more libraries. However, for managed languages it's natural for the language designers to realise performance sucks and shift performance critical things into the library where it can use native code and not managed code, so for managed languages there's a tendency towards "more libraries" just because managed sucks. However, this is not a strict difference between managed and unmanaged and it's only a "natural tendency" - managed languages don't have to do this, and there's nothing preventing unmanaged from doing it.

Also note that libraries take time to learn. A (managed or unmanaged) language with a large number of libraries takes a large amount of time to learn, and a (managed or unmanaged) language with a small number of libraries can be learnt much faster.

As far as libraries themselves go; regardless of whether your using a managed or unmanaged language; your code is either optimised for your specific case or your code is worse than it could be. Libraries are optimised for a general case and can't be optimised for your specific case. Sometimes it's a huge reduction in developer time for an insignificant reduction in performance/quality, and sometimes it's a small reduction in developer time for a significant reduction in performance/quality.

embryo wrote:

Brendan wrote:For things like whether or not a process is allowed to use networking, which files it can access, if there's disk or memory quotas, whether it can fork/spawn child processes, who it can communicate with, etc; all of those things are built into the OS and/or kernel, have nothing to do with the process itself, and have nothing to do with "managed vs. unmanaged".

Here again we have to learn new knowledge for every OS. Next we should write at least new scripts for every OS. And every OS required an administrator with new skills. Now consider a managed OS, which delivers the same set of feature on any platform, supports just one set of scripts or whatever applications are required for it's management, requires an administrator with just one set of skills. And of course, it requires just one set of skills from developers. What variant costs more?

Here again, it has nothing to do with managed vs. unmanaged, and continually repeating the same incorrect assumptions won't make it true. There is no reason why a normal ("unmanaged") OS can't provide the same APIs on very different platforms; and there's also no reason why multiple different normal OSs can't provide the same APIs on very different platforms (e.g. Solaris, FreeBSD, Linux, all supporting the same POSIX APIs).

embryo wrote:

Brendan wrote:Complaining that a managed environment doesn't whine about things that are perfectly valid for the language it's designed for is silly.

My complaints are about the whole type of bugs, that managed environment can exclude from programmer's life and unmanaged languages can't. Just because it is the responsibility of some environment to handle errors of such type (would it be standalone or embedded in every compiled program).

Except that "whole type of bugs" is almost nothing relevant and doesn't justify sacrificing the performance/quality of the final product that end users are given.

Yes; languages like C/C++ are crappy and there's far too much implementation defined and undefined behaviour, and far too many things that prevent bugs from being detected at compile time. This has nothing to do with "managed vs. unmanaged" and everything to do with "unmanaged vs. unmanaged" - it doesn't change the fact that the majority of those problems can be fixed by a different unmanaged language; and doesn't change the fact that "managed" isn't justified.

embryo wrote:

Brendan wrote:What exactly would be the difference between a managed OS that allows code to run either in a managed environment or an "unmanaged but with hardware provided isolation" environment, and a normal OS that allows code to run in either a "unmanaged but with hardware provided isolation" or a managed environment?

The difference is in developer's approach to the application development. Managed environment requires one and only one input for it to manage. Unmanaged OS allows input in any form (scripts, exes, plain binaries). So, the developer expects that if he writes code in a native form (unmanaged), then there will be better performance. But in fact developer looses all the benefits of managed environment while hoping for better performance. And it is the managed environment, that makes managed code useful on an unmanaged OS. It means that it is not the unmanaged OS, that provides developers with the managed option, but it is in fact managed environment developers. When some OS runs an application it just doesn't care about is it managed or not, but when managed OS runs application it cares a lot about the choice of a way the program can be executed. So, unmanaged OS provides nothing for a managed environment developer, while managed OS provides an option of dangerous execution with better performance (just like unmanaged OS, but with additional and useful safety checks and notifications).

Please learn to read. I asked about differences between "managed OS that allows unmanaged code execution vs. unmanaged OS that allows managed code execution", and you've written about "managed OS that doesn't allow unmanaged code execution vs. unmanaged OS that doesn't allow managed code execution". You've also repeated the same false assumptions that you've continually got wrong elsewhere.

The only reason you think "managed" is better is because 99% of your argument/s have nothing to do with managed vs. unmanaged.


Cheers,

Brendan

Hi,

As a quick (but hopefully interesting) summary...

We both want a fancy IDE that integrates editing, building and compiling.

We both want portable source code, such that (where possible) the same source can be run on completely different architectures (80x86, ARM, whatever). I only care about my OS and don't care (and don't want) applications intended for my OS to run on other OSs or applications intended for other OSs to run on my OS; but (I assume) you do care about that.

I want a language where as many bugs as possible are detected at compile time or before; and I want this integrated into the IDE. This includes simple stuff (like the IDE highlighting syntax errors in red while you type) and more complex stuff (like the IDE compiling the program in the background periodically and highlighting compile-time errors while you type). You haven't indicated a preference here, but I'd assume you'd want this too.

I also want a language where unit testing is an inbuilt feature; and an IDE that automatically runs the unit tests in the background and highlights things that failed their unit tests while you type. You probably haven't thought about this, but I think it's important to detect all the bugs that can't be detected automatically (with or without run-time tests).

I want to make sure malicious code can't trash other processes. I'd assume you want that too.

You want large libraries that programmers can use to reduce development time. I want services that programmers can use to reduce development time instead (and I don't want any libraries at all).

I want to use the same IDE, tools and programming language for normal/portable applications and for things like boot code and kernel (that can't be 100% portable and can't be "managed"). I assume you want different languages (one "safe" language for applications and one more powerful/lower level language for boot code, kernel, etc) with twice as much to learn and different tool-chains to mess with.

I want a "managed execution environment" that developers can use while developing (e.g. that's used when the IDE is running unit tests in the background and also used by the IDE's integrated debugger). You want that too.

For the "almost 0% of bugs" that aren't detected before compiling, aren't detected during compiling, aren't detected during unit testing, and aren't detected by the managed environment the developers use while developing; you want to sacrifice performance for end users, while I don't think that (given all of the above) there's any sane reason that justifies it.


Cheers,

Brendan

HoTT wrote:You can use the same libraries, the same toolchain, the same OS on another hardware platform.

Then you need some safe language. Or else how can you circumvent issues like endiannes, for example?

HoTT wrote:Platform independence is not a managed environment feature.

The platform independence is a consequence of design decisions. And such decisions are made under heavy influence of a target environment. If environment is managed, then it defines just one possible solution - the platform independence is a must. If environment is unmanaged, then designer has a choice and such choice much often is decided in support of platform dependable libraries. Here you see that managed environment insists on some design decisions and doing so it realizes it's internal component interdependence (like human's arm and human are interdependent). And unmanaged environment just doesn't care for any interdependencies and accepts even such creatures like an elephant with a human's arm.

It seems that unmanaged environment gives you more freedom, but it gives it to you for a cost of being less productive. Or you can create your own simplified managed environment and run it within unmanaged environment, but the cost here is the managed environment creation.

Then you need some safe language. Or else how can you circumvent issues like endiannes, for example?

Why should endianess be a problem and why shouldn't I use a safe language?

And unmanaged environment just doesn't care for any interdependencies

No, look at e.g. Qt. They do care in an unmanaged environment.

and accepts even such creatures like an elephant with a human's arm.

I think that analogy is borderline useless.

What you're basically saying is: “When everyone would use my and only my platform (managed environment), developing for my platform would be platform independent”.

Brendan wrote:As a quick (but hopefully interesting) summary...

Yes, the summary is interesting.

But I want one more summary

It's about managed vs unmanaged. I define the difference as a harsh change in developer's perceptions. But you prefer to define the change as a gradual transition when one component can be added after another is already in use for some time. And your current component acceptance is at the position of compile and debug time compliance with the managed environment approach. As you can see it is just one step apart from a complete managed environment with a runtime part also present. Another point, that you agree with, is some benefits of managed environment runtime, that can be helpful, but as you see it, just in a very small number of cases. And here is a whole picture - we both see some benefits of the managed approach, but employ them differently. The only reason you still refuse the complete managed environment (with runtime part) is runtime's minimal significance (as you see it). But the way, you already have behind, just tells me that it is some time in the future when you finally accept the whole environment without any exclusion. Just because it's benefits can be rethought and it will lead to some positive decisions.

And another point - if somebody starts thinking in "managed" fashion, then it is almost predefined that the final result will be the complete acceptance of the managed approach. Just because of approach's internal interdependencies.

And now about your summary.

Brendan wrote:I only care about my OS and don't care (and don't want) applications intended for my OS to run on other OSs or applications intended for other OSs to run on my OS; but (I assume) you do care about that.

Yes, it is easier to care just about your OS and forget about others. But then you refuse to benefit from a great amount of a code, that is written for other environments. I prefer to use such benefit in form of Java code base. And another benefit is more probable community support in case of Java.

Brendan wrote:I also want a language where unit testing is an inbuilt feature; and an IDE that automatically runs the unit tests in the background and highlights things that failed their unit tests while you type. You probably haven't thought about this, but I think it's important to detect all the bugs that can't be detected automatically (with or without run-time tests).

Here I miss the point of unit tests. Who will write them? If it is a developer, then such "inbuilt" feature works just as an ordinary unit test runner program. I mean I see no difference between the "inbuilt" and traditional approaches.

And how it is possible "to detect all the bugs that can't be detected automatically"? I see it as if it tells that all bugs can be detected. But how can we detect all possible bugs?

Brendan wrote:You want large libraries that programmers can use to reduce development time. I want services that programmers can use to reduce development time instead (and I don't want any libraries at all).

Any service is built around some code. If we call this code "a library", then I see the difference with your approach in the way the code is invoked. And I suppose you understand that communication is expensive, then I conclude your invocation method is still very close to traditional call conventions. And if it is then I just see no difference between your services and traditional libraries.

Brendan wrote:I want to use the same IDE, tools and programming language for normal/portable applications and for things like boot code and kernel (that can't be 100% portable and can't be "managed"). I assume you want different languages (one "safe" language for applications and one more powerful/lower level language for boot code, kernel, etc) with twice as much to learn and different tool-chains to mess with.

Here we are more close than it is seen from your point of view. My way is about using the same language and IDE, but with some clearly defined separation between low level and high level code. One part of such separation is about defining low level code within a specially designated method. And second part is about assembler-like look and feel of the low level code. First part allows an easy way for a developer and a managed environment to recognize and to manage low level parts. Second part allows to leverage assembly knowledge base, that is accumulated by the humanity so far.

As far as I see, your approach is almost the same. You separate low level code in some function and use the same assembler-like syntax (or even more close to assembly than my code is) for implementation details.

So, I just don't see how it is possible to use your approach without learning assembly (twice as much to learn, as you say). And don't see another toolchain that you suppose I should mess with.

Brendan wrote:For the "almost 0% of bugs" that aren't detected before compiling, aren't detected during compiling, aren't detected during unit testing, and aren't detected by the managed environment the developers use while developing; you want to sacrifice performance for end users, while I don't think that (given all of the above) there's any sane reason that justifies it.

Ok, let it be our religious assessment of the bug percentage, that we can find after all tests are done. But my religion tells me that the percent is essentially more important than you assume. May be the exact number really can be less than 1%, but it's consequences for security and reliability can be too costly, and such cost can be much greater than <1% of a total development cost if we suppose that our environment is highly competitive.