5 ms·

What?

by kyberias 11y ago

What?

graycat 11y ago
What part of my question do you not understand?
- marvy 11y ago
  What is the question?
  - graycat 11y ago
    The question was: > So, how do I connect what that .NET Framework 4.0 VBC.EXE does with the discussion in the OP?
    - MichaelGG 11y ago
      It doesn't at the moment. .NET Native only applies to Windows Store (metro) apps. But in theory, it would work like a super-powered ngen.exe does (look up ngen if you don't know). But instead of still requiring a runtime installed, .NET Native will also link in the required bits of the runtime statically (the GC for instance). This model is old and has been discussed quite a bit. Mono has supported it for a long time. MS has been ideologically opposed to it for over a decade and only just recently reversed their opinion, probably due to limited resources on low-end devices that MS has now realised are important.
    - msbarnett 11y ago
      The VB compiler compiles your code, not into native machine code, but into an intermediate representation targeting the virtual machine defined by the Common Language Runtime. This intermediate representation is known as CIL (Common Intermediate Language), and it is the bytecode that the .Net CLR then JITs at runtime. This article is about compiling .Net code direct to machine code and skipping the whole CIL/CLR/JIT chain.
      - 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.

What?

graycat 11y ago

What part of my question do you not understand?

marvy 11y ago
What is the question?
- graycat 11y ago
  The question was: > So, how do I connect what that .NET Framework 4.0 VBC.EXE does with the discussion in the OP?
  - MichaelGG 11y ago
    It doesn't at the moment. .NET Native only applies to Windows Store (metro) apps. But in theory, it would work like a super-powered ngen.exe does (look up ngen if you don't know). But instead of still requiring a runtime installed, .NET Native will also link in the required bits of the runtime statically (the GC for instance). This model is old and has been discussed quite a bit. Mono has supported it for a long time. MS has been ideologically opposed to it for over a decade and only just recently reversed their opinion, probably due to limited resources on low-end devices that MS has now realised are important.
  - msbarnett 11y ago
    The VB compiler compiles your code, not into native machine code, but into an intermediate representation targeting the virtual machine defined by the Common Language Runtime. This intermediate representation is known as CIL (Common Intermediate Language), and it is the bytecode that the .Net CLR then JITs at runtime. This article is about compiling .Net code direct to machine code and skipping the whole CIL/CLR/JIT chain.
    - 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.