3 ms·
Thanks for the progress. I've used virtual machines for decades, e.g., IBM's VM with the interactive CMS (Conversational Monitor System). In what sense is t
by graycat 11y ago
Thanks for the progress.
I've used virtual machines for
decades, e.g., IBM's VM with
the interactive CMS (Conversational
Monitor System).
In what sense is the Microsoft
CIL/CLR a virtual machine?
E.g., does it have any
security properties, e.g.,
restrictions via some
attribute control lists?
The CLI is a virtual machine
only in the sense that
the byte codes are not
actual machine instructions
for any real processor core
but are just some intermediate
code instructions
for an imaginary machine
that does not really exist
and, in that sense, is virtual?
So, on Windows,
say 7, 8.1, 10, Windows Server
of some year, etc., suppose
I take a file A.VB I've
typed in with Visual Basic .NET
source code, give that file A.VB to the
.NET program
VBC.EXE, which is in the collection
of .NET files, and get out from
running VBC.EXE
file A.EXE. Now A.EXE has
CIL byte code?
Why byte code? Or, in
what sense can each code
be only one byte long?
Does this byte code
mean that it would be
the same for running on 32
bit Intel x86 processors,
64 bit Intel processors,
ARM processors, etc.?
The CLR part is mostly
run time, that is,
code my program A.VB
and A.EXE needs to run,
that is, in old terms,
a library to be
linked in via a
linkage editor?
Then with .NET on Windows,
the JIT work also plays
the role of a linkage editor?
One old trick was, don't even
bring in the code to be linked
and, really, don't even link to
that code and, instead, as the
program runs and such code
gets called, that is, an
attempt is made to use it,
in case that happens (which
maybe often it won't),
there is a software fault,
interrupt, or some such
and the JIT code, still
in Windows and still
available to run,
only then, after the interrupt,
actually gets and links the code
that is needed but so far
was missing?
Another old trick was,
really, never bring that
library code in the user's
program, do link to it,
but have the code it
part of the user's address
space that is shared with
all the user address spaces
or even in another security
ring -- maybe Microsoft
is also doing some such trick?
I just outlined the Windows
Global Cache, e.g., mostly
from DLLs instead of EXEs?
Okay, I can see the point, as
in the OP, of
the effort for native. Indeed,
I've suspected that on Windows
frequently used programs
are kept in a cache somewhere
and, likely, ready to
read into an address space
or part of a process
as fast as possible, maybe
even with the usual
address relocation
work already done. So,
this looks like an
under the covers version
of native for Windows?
Ah, I just looked up Microsoft's
ngen, and maybe what I just
described was ngen?
I've seen no very clear documentation
of these issues. I've been
guessing at what happens, and that's
not so good.
Thanks for the tutorial.
- wvenable 11y agoSome of your questions are because there is a lot of overloaded terminology. Virtual Machine, for example, has two meanings: 1) A system virtual machine provides a complete system platform which supports the execution of a complete operating system (OS).[1] These usually emulate an existing architecture, and are built with the purpose of either providing a platform to run programs where the real hardware is not available for use (for example, executing on otherwise obsolete platforms), or of having multiple instances of virtual machines leading to more efficient use of computing resources, both in terms of energy consumption and cost effectiveness (known as hardware virtualization, the key to a cloud computing environment), or both. 2) A process virtual machine (also, language virtual machine) is designed to run a single program, which means that it supports a single process. Such virtual machines are usually closely suited to one or more programming languages and built with the purpose of providing program portability and flexibility (amongst other things). An essential characteristic of a virtual machine is that the software running inside is limited to the resources and abstractions provided by the virtual machine—it cannot break out of its virtual environment. The CLI is the second type of virtual machine and something like VirtualBox, VMware, and IBM mainframe VM's are the first kind. > Why byte code? Or, in what sense can each code be only one byte long? Again, it's not "byte code" it's "bytecode" which is defined here: https://en.wikipedia.org/wiki/Bytecode https://en.wikipedia.org/wiki/Bytecode "Bytecode, also known as p-code (portable code), is a form of instruction set designed for efficient execution by a software interpreter"
- graycat 11y agoThanks. Okay, I know some about the details of IBM's VM and a little about VMware. I have wondered: The way VM has worked on IBM mainframe instruction set has been partly due to an accident of the design of that instruction set and, then, some extensions for VM. Really, that way, tough for the program running to know if it is running as a virtual machine or not. So, in particular, the program running on VM can be using privileged instructions and not know that it doesn't really have access to the real hardware. So I've wondered if the Intel x86 instruction set also has this accident and, thus, can run operating systems that use privileged instructions but not know they are running on a VM. Or maybe the ability to run on a VM was from some extensions to the Intel instruction set. Do you know? Does the Microsoft CLI/CLR software have some security features beyond just any native program in, say, Fortran or assembler running in an address space, process, or whatever Microsoft calls where a program runs? I'm beginning to get the prerequisites for reading the OP, that is, understanding what the long standard alternative to native code has been. Heck, I can understand native code -- at one time I entered some simple programs via the computer console sense switches. And I printed out the object listing from a Fortran compiler and went over the machine language instructions one by one. I discovered that even for some simple code and a good Fortran compiler, assembler could be faster by a factor of several. Just read the Wikipedia article. Nice and easy. Thanks.