On 3/11/2012 5:28 AM, Jakub Piotr Cłapa wrote:
On 28.02.12 06:42, BGB wrote:
but, anyways, here is a link to another article:
http://en.wikipedia.org/wiki/Shannon%27s_source_coding_theorem
Shannon's theory applies to lossless transmission. I doubt anybody
here wants to reproduce everything down to the timings and bugs of the
original software. Information theory is not thermodynamics.
Shannon's theory also applies some to lossy transmission, as it also
sets a lower bound on the size of the data as expressed with a certain
degree of loss.
this is why, for example, with JPEGs or MP3s, getting a smaller size
tends to result in reduced quality. the higher quality can't be
expressed in a smaller size.
I had originally figured that the assumption would have been to try to
recreate everything in a reasonably feature-complete way.
this means such things in the OS as:
an OpenGL implementation;
a command-line interface, probably implementing ANSI / VT100 style
control-codes (even in my 3D engine, my in-program console currently
implements a subset of these codes);
a loader for program binaries (ELF or PE/COFF);
POSIX or some other similar OS APIs;
probably a C compiler, assembler, linker, run-time libraries, ...;
network stack, probably a web-browser, ...;
...
then it would be a question of how small one could get everything while
still implementing a reasonably complete (if basic) feature-set, using
any DSLs/... one could think up to shave off lines of code.
one could probably shave off OS-specific features which few people use
anyways (for example, no need to implement support for things like GDI
or the X11 protocol). a simple solution being that OpenGL largely is
the interface for the GUI subsystem (probably with a widget toolkit
built on this, and some calls for things not directly supported by
OpenGL, like managing mouse/keyboard/windows/...).
also, potentially, a vast amount of what would be standalone tools,
could be reimplemented as library code and merged (say, one has the
shell as a kernel module, which directly implements nearly all of the
basic command-line tools, like ls/cp/sed/grep/...).
the result of such an effort, under my estimates, would likely still end
up in the Mloc range, but maybe one could get from say, 200 Mloc (for a
Linux-like configuration) down to maybe about 10-15 Mloc, or if one
tried really hard, maybe closer to 1 Mloc, and much smaller is fairly
unlikely.
apparently this wasn't the plan though, rather the intent was to
substitute something entirely different in its place, but this sort of
implies that it isn't really feature-complete per-se (and it would be a
bit difficult trying to port existing software to it).
someone asks: hey, how can I build Quake 3 Arena for your OS?, and
gets back a response roughly along the lines of you will need to
largely rewrite it from the ground up.
much nicer and simpler would be if it could be reduced to maybe a few
patches and modifying some of the OS glue stubs or something.
(tangent time):
but, alas, there seems to be a bit of a philosophical split here.
I tend to be a bit more conservative, even if some of this stuff is put
together in dubious ways. one adds features, but often ends up
jerry-rigging things, and using bits of functionality in different
contexts: like, for example, an in-program command-entry console, is not
normally where one expects ANSI codes, but at the time, it seemed a sane
enough strategy (adding ANSI codes was a fairly straightforward way to
support things like embedding color information in console message
strings, ...). so, the basic idea still works, and so was applied in a
new context (a console in a 3D engine, vs a terminal window in the OS).
side note: internally, the console is represented as a 2D array of
characters, and another 2D array to store color and modifier flags
(underline, strikeout, blink, italic, ...).
the console can be used both for program-related commands, accessing
cvars, and for evaluating script fragments (sadly, limited to what can
be reasonably typed into a console command, which can be a little
limiting for much more than make that thing over there explode or
similar). functionally, the console is less advanced than something like
bash or similar.
I have also considered the possibility of supporting multiple consoles,
and maybe a console-integrated text-editor, but have yet to decide on
the specifics (I am torn between a specialized text-editor interface, or
making the text editor be a console command which hijacks the console
and probably does most of its user-interface via ANSI codes or similar...).
but, it is not obvious what is the best way to integrate a text-editor
into the UI for a 3D engine, hence why I have had this idea floating
around for months, but haven't really acted on it (out of humor, it
could be given a VIM-like user-interface... ok, probably not, I was
imagining more like
