Re: [DotGNU]Dotgnu written in C#?

[DrDiettrich]

Rhys Weatherley wrote:
> The goal of pnetC is to be able to run any arbitrary ANSI/Posix C code on top
> of the CLI in bytecode-compiled form.

This is fine, but...
 
> There are literally thousands of interesting Free Software libraries written
> in C that can be leveraged once we have the basic platform in place.  Much
> more than C#, VB, Java, etc can provide on their own.

I found serious problems with GNU/FSF software, which I would like to
discuss now. Currently everybody concentrates on the freely available
source code, whose availability is assumed to be the one and only
critical point. But even if I see the need for legal institutions like
the FSF, for defending the freedom of source code, the actual procedures
unfortunately restrict the use of just that freely available source code
to specific platforms. At least has an author the right and chance to
determine, on which or for which platforms his code will compile, by
creating the (in)appropriate configure/make scripts!

If you think that source code and a compiler is sufficient to really
create running programs, then you certainly never tried to build even
the simplest GNU program on a non-Unix system :-(

The relationship between source code and executable code is perverted in
GNU-C projects into a tight net of dependencies, each of which can
prevent the creation of executable code. Let me roll up this process
from the end:

1) Before the linker can create the executable module(s), all object
modules and libraries must be available. OK, so far.

2) Before the compiler can produce object code, the sources must run
through the preprocessor. In this stage any number of dependencies and
modifications can be introduced by #defines and #includes. In most C
projects it's near impossible to figure out, which code really will be
compiled, without inspecting the output of the preprocessor.

3) Before the preprocessor can run, some source files must be
configured, and the #defines for the preprocessor must be defined. With
enough dependencies it's almost impossible to determine a working
configuration manually.

4) The source processors are called from make, based on Makefile(s).
These files also can contain references to other programs, which may
report errors and stop the whole build process.

5) The host and target platform specific settings must be determined.
Since the user cannot do this himself, without appropriate
documentation, ./config must be used to evaluate the environment(s) and
create the makefiles and the according settings. Unfortunately config
has some fixed opinions about platforms, and consequently will deny
service for totally or partially unknown platforms, like Windows.

6) Because an author can not know on which platform his code may be
compiled later, he describes the project in a somewhat platform
independent way, in Makefile.am, which later is used to build the
Makefile.in and the final Makefile.

7) All that work is done in an appropriate shell, which must cooperate
with all the make tools.

In practice every step will fail on the first try, unless the project
has been extended to properly work on a specific host/target
combination, and the user has set up his system with all (really?)
required tools and libraries of the appropriate version. When an upgrade
of some component is required, in order to fulfill the requirements of a
project, this can require an almost endless Rattenschwanz of downloads
and upgrades, with exactly the same problems as for the original project
of interest.

This is why I consider the currently available "free" software to be not
really free, in contrast this software is bound to a specific but
unspecified environment. And what's worse, software which is written
only for a specific platform, or software which is written for an
unspecified platform? :-(


IMO all of the steps above the mere compilation should be eliminated
from a really free software project. All dependencies between code
modules must be described in a compiler and platform independend way.
All dependencies must be specified as /what/ must be done, and not as
/how/ something should be done. Only then it's possible that a user can
adopt such a project to his own platform and development environment.

This goal of platform and environment independence certainly is
achievable. Free software should be either general in nature, so that it
will run on any platform without modifications, or it will be designed
for specific platforms or libraries, which then can be assumed as
available and conforming to their own specifications at build and/or run
time.

Currently all these dependencies are hidden in the project configuration
information and the required tools. Most of these dependencies can be
resolved by one or more platform specific libraries, which must be
implemented only once for every platform. In the case of C-ish projects
a unique set of header files can be used to compile GNU projects. As
with the libraries, one or at least very few platform specific header
files can be created once for every platform and compiler. Instead of
checking for the availability of some features (alloca, bmove...) and
according modifications to the source code (#if...), only the definition
of the required feature is required which then can be implemented in the
library or (typically) in a simple macro #define in the standard header
files.

All these prerequisites are static, i.e. no modifications are required
for building specific projects. Of course there can exist more complex
build steps, than only compiling and linking a number of source modules
and standard libraries, like when bootstrapping an compiler or library
itself. But these steps should be described in a general way, so that
the user can perform all these steps himself, in case one of the scripts
or tools doesn't work as expected by the author of the project.


This is why I vote for a (new?) Integrated Development Environment,
which replaces the current config-make-install chain, and most
pertaining tools. This environment comes pre-configured for every
system, and/or can be configured by the user. The author of a free
software project only has to tell that IDE /what/ must be done, and has
to leave it to the IDE and/or user /how/ this will be done. Only then a
software project can be considered as really free, not only as freely
available, but also as freely compilable.

I also vote for an (automated?) translation of existing C projects into
C#. Then the better error checking features of C# (or at least C++) can
be used to comb out some lurking bugs in many projects, and the
resulting source code will be really platform independent. Let pure or
extended C code die away ASAP, in favor of more stable, portable and
bugfree software!

BTW, by the migration of C code to C++ or C# I don't mean necessarily
introducing classes and other OO stuff. In contrast I mean the
elimination of typecasts and #defines and #ifs as far as possible, in
general all provisions which allow an compiler to check the source code
in the best possible way. A migration to C++ will allow to still use gcc
for the creation of native executables, if this really is a requirement.

DoDi