OSDev.org

This thread has started to focus on the possibilities of making a "secure" language.

There have been attempts in the past, and I'm sure the post-mortem of BitC would be really interesting to this crowd: http://www.coyotos.org/pipermail/bitc-d ... 03300.html

These days, we have rust moving in the "secure" language direction.

Who exactly pauses the code? Who manages it here? Isn't is an act of management?

This is IDE's part of job and it is common for managed and unmanaged environments.

Who exactly is responsible for locating "where in memory the old version of the function was"? Who is responsible for "frees that memory in the running process"? Are those actions acts of management?

Who exactly allocates foreign process's memory? Isn't it an act of management?

Who allows the linker to do it? Or in other words - who exactly manages process's memory. Isn't it an act of management?

Who manages this sequence?

I hope you have noticed how often the word "management" was used. Next I want to remind about my and Brendan's contradiction, which I describe as borrowing of automation features by unmanaged solutions from managed ones. Brendan raises objections about "independence" of the features. But my reply was about the way the features have taken place in unmanaged solutions. This way had been completed by managed environments much earlier than many unmanaged solutions (or now they can be called partially managed) started to implement exactly the same managed activities. The managed environments just had shown the way for unmanaged solutions. And even if it was possible to see the way before the raise of managed environments, only the managed environments had implemented a full set of management features and proved to the world the efficiency of such solutions (in terms of size of involved developer community and development time reduction). Nobody before had courage to collect all required managed features in one environment. And after the way had been shown, we have voices around who speak loudly that they always have known the way and they still need no help from managed environments. But they alway are very eager to implement managed features as a part of their own solutions.

Exactly the same situation you have shown above - you have just demonstrated the power of managed solutions, next you agreed that such features are very useful, next you have proposed steps for unmanaged solutions to adopt solutions, borrowed from managed environments.

And after it all you just have to say that you still disagree with the way that is shown by managed solutions, for the complete absurdity of your claims will be as visible as ever possible.

This can be done without runtime management, but the consequence is the lack of debugging information in case of a program crash.

Here we again have just a clear adoption of managed features.

GUI or any other library is out of scope of the managed vs unmanaged discussion. As it was pointed out earlier, any library is just the "x" in the comparison "x+y>x+z".

Here again you need a manager, that stops a process, introspects it's memory and registers and so on. It just a part of any managed environment. But managed environments include much more than this single part. And because of the very existence of the managed environments it is possible to modify code at runtime. But if you pretend that a managed environment, that is split into obscure parts, like in case of one part belongs to an OS and another belongs to something else, can not be called managed or at least "very close to managed", then again you just show the absurdity in your claims.

Your solution is seems as incomplete. So it can be called "very close to managed". But because I don't know how you use pointers in your solution, I can't be sure. May be your solution is still safe and then it can be called managed (in case other unknown parts include managed features also, which is very likely).

Hi,



I noticed that the word "management" was both misused and used out of context.

A child might know exactly what "string" means in general (e.g. very thin rope) but have no idea what "string" means for programmers, or what "string" means for physicists. These are all the same word, but that word has very different meanings in different contexts.

You are like that child and the word "string". You might know what "managed" means in general; but you seem to have no idea what it means in the context of "managed languages" and "managed execution environments". You think it's about how fancy the IDE is, or whether the libraries are large, or if there's integrated debugging, or whether an application pauses something when you press a button(!), or whether something is able to find some free RAM. Most of these things do have something to do with "managed in general"; but none of them have anything to do with "managed languages" or "managed execution environments" where the context is very different and where "managed" has a different and more specific meaning.


Cheers,

Brendan

This is an accurate summary of this thread.

If you prefer to shift the discussion into an area of personally your definition of the word "managed", then you have to give the definition first. But the main problem is that you deny any possibility for the word "managed" to be defined in another way.

And what's wrong with the traditional definition of management? What's wrong with automatic management of computer related things for us? And why do you see it too different when some people talk about ropes as long thin objects, about programming strings as long thin objects and about physical entities as long thin objects? The similarity is absolutely visible, why do you refuse to see it?

The automation shines in scripting and in managed environments, automation is accepted by many unmanaged solutions, automation is conquering the world of programming, but you still prefer to think that it is in no way close to managed solutions and only unmanaged ones rule the world. But how it is possible to forget about Java, C# and all those scripting solutions? Or you just refuse to honor the priority of managed solutions in the area of automation? Ok, if you want, just forget about managed solutions. But the real world shows that managed solutions win the game and total automation is a direct consequence of the success of managed solutions, they just proved the direction is absolutely viable and efforts always will be rewarded.

Hi,



I gave my definitions already.



Your definition is like "Everything is managed, even a goat that manages to eat a burrito. Wheeee!". It's completely meaningless and nothing like the definition of "managed" that any programmer has ever used.

For reference, here's the Wikipedia page for Managed Code (which reflects Microsoft's own definition). Notice how is says nothing about how large the libraries are, or how fancy the IDE is, or any of the other irrelevant nonsense you've been relying on?

It is also different to my definition, in that their definition requires an implementation of the Common Language Runtime while my definition is more generic/less strict.



If you'd like to use the traditional definition (the definition Microsoft used when they invented the term) instead of my "less strict" definition; then that's fine. In that case; Java is an unmanaged language because it doesn't use Microsoft's Common Language Runtime.



Let me repeat this (again) - none of this has ever had anything to do with managed vs. unmanaged in any way whatsoever.

I don't poke fun at people with disabilities; so I need to ask you a slightly personal question: Do you have a learning disability?


Cheers,

Brendan

Yes, your definition was as follows:

Next goes another definition:

It says:

Now you can see that Microsoft's definition and your's are two significantly different definitions. At least it means that you tolerate some variations of the subject. And as I have described earlier, my definition includes the need to combine two different approaches - Java's platform independent environment with Microsoft's platform dependent, but holding almost all features of Java approach. My simplified definition was given here.

From my definition you can see that code management includes everything that is perceived as useful. Managing code execution is very useful activity, because it allows to introspect code execution state and to update the state in any desirable manner. So, I have absolutely viable ground for calling activities like code execution as "managed", especially if we consider that the runtime environment, that actually executes our commands, is in fact a part of an entire managed solution/environment.

I have shown that my situation differs from pure Microsoft's or Java's variants. So, let me repeat (again) - if you don't want to call it "managed" for some personal reason, then you can call it however you want, but the simple logic shown above just tells us that there is a place for different definitions and, even if you dislike it, I still can use one, that is more suitable for my situation. And also I can extend my definition for it to include the Microsoft's and Java's variants. And in the same way it includes non-scripting solutions, it can include all scripting languages, just because scripting is performed in safe manner with the help from an environment, that manages scripted code.

But I agree, that my definition differs from the orthodox one (and in fact I hardly can call it "definition"), given in the Wikipedia.

For our conversation to continue without some "poke fun at people" I agree to give you a right to think that I "have a learning disability", if it makes you feel better, of course.

Hi,



And that is exactly where the problem is. You've gathered all the things you consider useful, even though most of these things were done by unmanaged languages well before Java "borrowed" them, and then you're pretending they have something to do with either "managed languages" or "managed execution environments" (while also failing to distinguish between languages and environments).

Let's take a look:

2) The language is compiled into intermediary form that is the same for any possible platform.

The original versions of C++ were compiled into intermediary form that is the same for any possible platform (which was called C). Does that mean the original versions of C++ were managed? What if I "compile" 80x86 assembly into an intermediate form (80x86 machine code) and run it inside Bochs on any possible platform (including ARM, powerPC, Sparc, Itanium and whatever else has a C compiler able to compile Bochs; and also including Windows, Solaris, Linux, FreeBSD, etc)?

3) It has a standard set of libraries that define such non-standard operations as file or network access or GUI calls.

That includes both C and C++ (these languages are quite old and were designed long before GUIs existed, so naturally the libraries for these languages don't include 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).

Yes and no. Yes "managed" means some sort of run-time capable of detecting programmer errors. The rest is wrong - e.g. nothing prevents the use of JIT for an unmanaged language.

If I compile Java down to native code without any of the run-time checks (e.g. array bounds checks, null reference checks, etc) does it suddenly stop being a managed language? If I compile some C code and execute it within a "valgrind managed virtual machine" does C suddenly become a managed language?

5) The runtime prevents running code from influencing anything else except of strictly defined set of areas.

This still includes assembly, C and C++ (where the run-time is an OS that uses paging and/or segmentation to isolate processes, and where that "strictly defined set of areas" are the areas defined by the executable loader, the heap, etc).

6) The runtime is operated in the same manner on any possible platform (it makes it "managed", but now by humans).

This includes assembly/machine code (you'd be amazed how many different dialects of machine code the "Qemu managed environment" supports), and in the same way includes essentially all languages (managed or unmanaged). The only requirement here is that the CPU being used is Turing complete.

Basically; you're saying that all languages that have ever existed are "managed" for multiple different reasons. If you remove all the things that don't make any sense from your definition; you end up with my definition.



Raw machine code execution is a very useful activity, because it allows to introspect code execution state and to update the state in any desirable manner. Examples include the "debug.exe" that came with MS-DOS, GDB, the debugger built into a cartridge I plugged into a Commodore64 in the 1980s, etc. Of course the idea is far older - tools that allow you to inspect code execution state and to update the state in any desirable manner have probably existed (for native code) since the 1960s.


Cheers,

Brendan

A couple of observations:

The wikipedia definition of "managed code" is slightly inaccurate, and in serious need of "citation needed"s.

As far as I can see, the term originated with Microsoft when describing the CLI. The official definition is (from ECMA standard 335) and managed data is further defined as
The term 'managed language' is mostly a marketing term, used to describe languages that target the CLI. Managed code has since also been retrospectively used to describe other languages, e.g. Java. The only definition of 'managed environment' I can find relates to database access in Java.

Note how the reasonably broad description of 'managed code' given above could easily be applied to C++ (assuming RTTI and exceptions are enabled), however the ECMA document does seem to infer later on that the 'management' of code is similar to that of data - notably that a particular function can be rewritten at runtime and all references updated to it (similar to compacting garbage collection) so that a more optimized version can be used based on runtime profiling. However, if we stick to the strict definition of managed code then to answer the original question it is perfectly acceptable to write an OS in it, and in particular it does not require a runtime virtual machine (the code can easily be ahead-of-time compiled, with AOT compiled metadata alongside).

There are other associated elements of the CLR however which often do require some more significant runtime support. Particularly the enforcement of type safety (ensuring field and array accesses are always valid) and memory safety (ensuring applications do not overwrite or read other address spaces). Specialized bytecode is used to address some of these concerns, but as pointed out above there often are some runtime overheads too.

Regards,
John.

Yes, you can point to some technologies, that had existed before the managed environments get their way into our life. But the complete combination of technologies was introduced by Java. And world-wide adoption is the Java's achievement, but not of those separate technologies with a tiny market share (except C, which never had all the combination).

Adoption of the Java is the result of superior features, that Java delivers to developers. You can call those features "crap", but market share tells us about something different. And next were Microsoft and a lot of scripting languages.

The combination and implementation of a set of ideas makes the difference. An idea alone is not useful until it is implemented. And lonely idea implementations often fail to compete with implementation of a combination of ideas.

Do you see where the combination of required ideas was implemented here? Or there is just one separated idea?

Yes, there are libraries. But even basic libraries are different for different platforms.

Java is a managed environment. Without the environment the language is only a small part of a successful combination.

I can't remove things, that don't make any sense. Just because it is a combination, that wins.

Let's imagine a monkey. It has arms, eyes, head, brain. It is even capable of learning. And now let's compare the monkey with a human. We can see that they both are very similar. And we can see, that everything a human has, was developed and used long ago by many forms of life. And we can see that a human's performance is much worse than the performance of other animals (they run, jump, fight much better). But for some reason we distinguish a human from a monkey and think a human is superior to any animal. But why?

Because the term was coined by Microsoft for Microsoft's use, it's meaning is skewed for the Microsoft's sake.

I try to use this term just because it looks like a very suitable for many situation. And to be used in many situations it should be extended from original relatively narrow meaning.

And, by the way, Brendan's position is independent of the term. He just sees that there are better solutions, than those covered by the term "managed". And I disagree on that. But partially he is right, just because there are alway some drawbacks related to some new features. And if we discuss the drawbacks, then yes, there are better solutions of the drawback part. But the complex of all ideas and implementation is better in case of managed environment.

It should be noted that Java (as distributed by Oracle) doesn't come with an IDE or GUI designer. People use 3rd party tools like Netbeans and Eclipse. If your argument is that third parties offer compete solutions, then how is C/C++ (languages you keep referencing as unmanaged, because everything non-C/C++ could have some feature that makes it managed, according to your definition) different because QT Creator and Visual Studio bundles a compete environment together with massive libraries and all the tools you need?



Under your 'everything is managed in some way' definition, please give us some examples of an unmanaged environment. If there's no such thing as an unmanaged environment, what is the point of using the word 'managed' and not just calling it an 'environment'?

I guess I know what your response will be - "all environments are managed, some are just more managed than others" and some irrelevant ramble about monkeys.

(What is just said above isn't supposed to sound condescending, I'm just pointing out that your argument is full of fallacies.)

Hi,

Embryo; you are not arguing for "managed", and you are not arguing against "unmanaged". Instead, you are arguing for Java without caring if it's managed or not.

It's like saying "cars are better than motorbikes because I saw a purple car the other day and I like purple". I point out that there's no reason why you can't have a purple motorbike (or a motorbike with a horn, or an electric motorbike), and you just don't get it. You just keep saying stupid things; like "The adoption of cars is the result of superior features" (even though motorbikes can have the same features you've mentioned) and things like "But a car can be purple, and have a horn, and also be electric - it's the combination!" (even though motorbikes can have the same combination of features).


Cheers,

Brendan

That's nonsense and you should know that by now.

To summarize what Embryo actually argued:
- numerous arguments
- therefore managed languages are better (and therefore your first sentence is a lie)
- Java is an instance of a managed language
- C is an instance of an unmanaged language
- therefore by instantiation makes Java better than C (and therefore your second sentence is a lie)

Andrew was almost right. It just had to be purple cars instead of monkeys.

The topic title asks what we think of OSes written in a "managed language".

Who "manages" the kernel when the kernel is written in a "managed language"?

For example if you write your kernel in Java, does the kernel run in something akin to the JVM? If so, what is the VM written in?