Skip to content

Dzonatas/Program

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

.NET Domain Assembler

Based on information technology currently charted to year 2040.

Program

  • Visualized cloud assemblies
  • Simulated versus real kernel interaction
  • Compiled to C
  • Pure .NET parser

Is there any simple explanation besides code comments?

Yes, the word infrastructure as layered on kernel systems is quite different from typical integrated circuits. This solution does not compete with .NET platforms that layer above its standard assembly layer. If we can visualize Debian.COM's package system with each significant .NET instruction contained in its own package, then we can fully implement the infrastructure as charted. Every layer above this either depends on the integrated circuits or its selection of instructional packages. It is quite opposite from an object-oriented file system, as commented.

And, how about compatibility with Microsoft's mscorlib?

System.Object becomes phantom and exercises itself under compilation (see ECMA335 newarr vs newobj instruction, and box types), so there is no direct one-to-one relationship with Microsoft's mscorlib as an API with run-time singularity. This forseen compatibility issue is due to serialization paradigms and that Microsoft had not finished assimilation of C++ to .NET 1.0. The domain assembler either resolves the code paths or uses more generic instructions. Literally, there is no alternative unless the compile-to-intermediate-language process prevents System.Object affinity.

Limitations

Certain recursion and polymorphic code will not be published under free open source. This justifies the inconsistent GUID(C)s produced at each compile.

Any simple test run?

  1. get clone --depth 1 https://github.com/Dzonatas/Program.git /tmp/Program
  2. cd /tmp/Program
  3. make tests
  4. make clean

It runs faster but why does compilation seem slower?

Supposedly, the built-in virtual filesystem (or compressed mini-ISO image) is specially made for faster compile-time access in Microsoft's and Xamarin's build of .NET/Mono. That requires some kernel emulation for fully portable security attributes, "trust". The load time of that emulated file-system image is the primary tradeoff to the non-cached filesystem. Besides native optimizations and hypertext prefetches, there are hybrid systems that make raw "inventory" access much faster at cost of size, but that hybrid inventory is beyond the interest of this "simply explained" program that currently compiles with Mono.

Market Analysis

Standard, "10 program lines."

Status

There is no standard for System Exception Handlers (SEH) in C99.

About

.NET Domain Assembly Parser

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages