About varocarbas.com

--

About me

--

Contact me

--

Visit customsolvers.com, my main website

--

Valid markup

--

Valid CSS

--

© 2015-2017 Alvaro Carballo Garcia

--

URL friendly

--

Optimised for 1920x1080 - Proudly mobile unfriendly

R&D projects RSS feed

All projects in full-screen mode

PDFs:

Project 10

Project 9

Project 8

FlexibleParser code analysis:

UnitParser

NumberParser

Tools:

Chromatic encryption

(v. 1.3)

Pages in customsolvers.com:

Upcoming additions

Failed projects

Active crawling bots:

Ranking type 2

(
)

FlexibleParser raw data:

Unit conversion (UnitParser)

Compound types (UnitParser)

Timezones (DateParser)

Currently active or soon to be updated:

Domain ranking

NO NEW PROJECTS:
Project 10 is expected to be the last formal project of varocarbas.com. I will continue using this site as my main self-promotional R&D-focused online resource, but by relying on other more adequate formats like domain ranking.
Note that the last versions of all the successfully completed projects (5 to 10) will always be available.
PROJECT 8
Completed (26 days)

Introduction >

Compilation & CoreRun.exe

Completed (47 days)
Completed (19 days)
Completed (14 days)
Security implications of open CoreCLR (CoreRun.exe)
Completed on 05-Feb-2016 (26 days) -- Updated on 23-Nov-2016

Some of the conclusions of this project aren't applicable anymore.
To know more about all this, read "OVER-8-MONTH-LATER UPDATE" in the Open .NET & CoreCLR section.

Project 8 in full-screenProject 8 in PDF

As already explained in the first section and in various parts of the previous project, the quality of the code in CoreCLR (but also in CoreFX & Roslyn) is certainly high: good and clear structure, efficient algorithms, helpful comments, etc. Any experienced .NET programmer should be able to start working with it almost immediately. On the other hand, compiling a more or less relevant portion of the code is a different story.

Note that the .NET Framework is a huge and very complex project which has been systematically improved during the last quite a few years by a relevant number of different people; only this issue should be enough to not expect it to be immediately adapted to a so relevant change like "suddenly" becoming open source. But there is still another issue, the ultimate responsible for having created this project, which is much more relevant here: the bipartition underlying the whole .NET Framework and what it implies. That is, only part of the information required by a .NET executable is contained in the file itself; the remaining bits are taken from the .NET libraries present in the given computer (e.g., automatically installed with Windows). The CoreCLR repository includes the source code of some of these libraries (the most basic ones) and that's why validating the compilation outputs isn't easy. How telling the aforementioned executable to rely on the .NET libraries generated by the last compilation?

Building and using a new version of the CoreCLR libraries requires from a not-too-simple multi-step process which is explained in detail in the corresponding documentation. One of the outputs of this process is the file CoreRun.exe, which answers the aforementioned question (how telling the executable...?) and represents the main reason for having started this project. Basically speaking, CoreRun.exe allows to directly modify the pure essence of any .NET executable (i.e., telling it to rely on a modified version of some basic libraries) and this project analyses whether this fact represents a real security threat.