About varocarbas.com

--

About me

--

Contact me

--

Visit customsolvers.com, another side of my work

--

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

FlexibleParser (DateParser)

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 7
Completed (47 days)

Code overview >

CoreRun.exe

Completed (19 days)
Completed (14 days)
First contact with open .NET
Completed on 13-Feb-2016 (47 days) -- Updated on 19-Nov-2016

Project 7 in full-screenProject 7 in PDF

This project is about improving part of the CoreCLR source code; that's why recompiling the whole code (or, at least, the mscorlib library) seems an a-priori basic requirement.

Compiling all the code in the CoreCLR repository is not completely straightforward (although step-by-step instructions are available); even after being generated, the new libraries (e.g., mscorlib.dll) cannot be used right away, a quite logical consequence of what is being affected (i.e., some of the basic libraries used by all the .NET applications running on that computer). CoreRun.exe is one of the outputs generated when building the whole CoreCLR repository and allows any .NET executable to rely on the newly-created libraries. This file is so peculiar that the whole Project 8 is precisely focused on analysing its security implications.

The most relevant-to-this-project feature of CoreRun.exe is to have a noticeable impact on the performance of the given .NET file: the same executable under exactly the same conditions can be orders of magnitude slower when run via CoreRun.exe. Just this fact might not be too relevant on account of the goals of the current project (i.e., relative measurements of performance, where 5 vs. 10 is identical to 50 vs. 100), but these variations are definitely not-consistent what does represent an immediate deal-breaker.

Standalone applications will be used in all the performance-comparison tests; they will be run directly (i.e., as conventional executables on Windows), rather than via CoreRun.exe. On the other hand, CoreRun.exe will be used in all the tests confirming the identity between old/new versions of the code (i.e., all the numeric-type parsing methods, like decimal.Parse, tested against a big set of inputs by relying on the old/new mscorlib.dll).