3 ms·

I just wrote 18,000 programming language statements in Visual Basic .NET, in files with 80,000 lines including comments, blank lines, etc., compiled much of it

by graycat 11y ago

I just wrote 18,000 programming language statements in Visual Basic .NET, in files with 80,000 lines including comments, blank lines, etc., compiled much of it with a command line script with line programPath = dq || SystemRoot || , '\Microsoft.NET\Framework\v4.0.30319\vbc.exe' || dq and give the rest to the Microsoft Internet Information Server (IIS) to compile and run as Web pages, and it all works, but, still, I can't make any sense out of the OP at all. E.g., my command line compiles result in a file with extension EXE. What's in that? Sure, I have the Microsoft .NET Framework 4.0 installed, and the VBC.EXE invoked as above is, of course, one of the files in the installation of that .NET Framework. When from a command line I just run that script that runs that VBC.EXE, I get nice output showing the command line options for the program -- simple, direct, explicit, terrific. So, how do I connect what that .NET Framework 4.0 VBC.EXE does with the discussion in the OP? BTW: Why use Visual Basic .NET instead of C#? C# borrows too much of the old C syntax, and Visual Basic has syntax more traditional and more like that of Pascal, PL/I, Fortran, etc., and I find that more traditional syntax easier to write and read and less error prone. But, likely and apparently, the difference between C# and Visual Basic .NET is mostly just syntactic sugar anyway. By the way, where does the famous CLR -- common language runtime -- enter this picture? Thanks.

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.

by graycat 11y ago

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.