Think about the acronym GNU: "GNU's Not Unix" - see how it defines itself?
Likewise a GNU/Linux system can recompile itself. Even if you use
proprietary tools to develop for linux, those tools have to work in that
Unfortunately the Windows environment is not self-defining. It's defined
by seperate proprietary software. This leads to the heart of our problem:
There are many different Windows developer platforms. Even though the end
user has only a few options (95, 98, ME, NT or 2000) The developer has
all those platforms to test multiplied by the number of possible
That's a major problem for an open source project, because every supported
development tool is a different platform. Also, when those development
tools are proprietary, each version can be a different platform, because
you can't tell every developer to buy the latest version of the tools, and
if your port maintainer has the latest version of the tools, he may not
be able to test how well his port works with older versions.
Using a Free, self-defining development environment is the closest you can
get to making a single, actually maintainable, Windows version of any open
source software. (Well, there is another option, only support one version
of one proprietary compiler, but that falls apart as soon as some
determined character starts a port to his own compiler/version)
Not only is the free development environment available to all developers,
but you can also often require users to upgrade to a newer or customized
version of a free tool, because the new version is also available to
Crystal Space is not a little utility that can easily be recompiled on
many platforms. Instead it's a complex system in it's own right that is
extremely difficult to maintain on multiple platforms - especially
platforms that refuse to adhere to any standards.
If we were all employees in the same department of the same software
development company, the idea that we were all using different compiler
setups to develop a complex library like CS for the same target would be
So should we continue to use this laughable approach just because we don't
have a manager telling us to "get our act together"?
I don't think we should. I think the most important thing is putting
together a windows port that any windows user can build for themselves,
regardless of what proprietary tool versions they own.
Now I do understand that there are good reasons why we have been bending
over backward to have ports of CS to many different proprietary
development environments and versions. But those reasons have a lot to do
with the way things _have_been_ and that strategy is completely
ineffective for the way things _need_to_be_.
The various ports have allowed more people to work on CS, and more people
to try out the end-products, but eventually many of those ports will fall
apart, and few of them have ever been as up to date as the various
non-Windows GCC ports.
Waiting for someone to come along and update those old ports is just a way
of saying "we accept that one attempt at a windows port failed to endure,
maybe it will work out next time." I don't think it will work out.
Rather than accepting failures, we should try to turn them into
opportunities to make our project better.
One idea along those lines is to stop using MSVC project files and use the
same makefile system for all platforms. At first this seems silly. First
of all it's a superficial solution to a deeper problem. and second, why
use a command line tool when you have a nice IDE like MSVC?
But on the other hand, how many windows developers are "lagged" in their
ability to use and contribute to the latest version of Crystal Space
because they wait for the MSVC project files to be updated? Many
people will just abandon the project when they can't get it to work with
the project files we distribute with CS. Other people will lose interest
as they get tired of the "lag time".
It is easy to download and use GNU Make and other GNU utilities. Even if
this strikes some MSVC users as "strange" or "inconvenient", learning the
makefile system is a one-time cost for a solution to a long-term problem.
This message is getting a bit longer than I planned :-)
Any replies are welcomed.
Post by Paul Garceau Post by Jorrit Tyberghein
Can someone explain to me why people like Thomas Hieber and
Martin Geisse seem able to develop on Windows just fine and why
all those other people are reporting problems?
I can only attribute this to the development environment they
are working in and how they define their projects locally.
There is an offhand possibility that the later the msvc/c++
release the less it conforms to ansi standards.
Linux is an ansi-standard development system, unlike the MSVS
based development environments which rely on msvc/c++
compilers/linkers (idiosyncrasies, MS headers, MS macros) to
MSVC/C++ is non-ansi standard, and if you force ansi-standard
compliance for msvc/c++ (this occurs in both the Borland/Inprise
based compilers AND the MSVS based compilers) by setting
switches which force strict-ansi , you can run into a great deal
of problems when working with msvc/c++ builds.
It is very subtle, in that some MSVC/C++ calls are very similar
syntactically to ansi-standard calls, but in fact are not ansi-
standard at all.
What this indicates is a conflict between the compilers being
used. Assuming that everyone is using the exact same hardware,
the exact same release of the MSVS version and the exact same
system configuration as Martin or Thomas, imho, is a mistake.
For instance, all of the gcc ports for Windows are, by their
However, in order to get them to work with MS source code,
these ansi-standard compilers (mingw, cygwin) must mutate to
accomodate what is, basically, a non-ansi standard approach to
building CS in order to work with the Win32 API. (No, I am not
making a veiled comment about the positives and negatives of
developing with MSVC/C++).
In terms of CS Development, this means that there are a great
deal of pre-definitions assumed when it comes to msvc/c++
development. These "pre-definitions" have to do with the .dsp
and/or any other project oriented definitions (including the
differences between 'gnu-make' and 'nmake" requirements) that
are assumed for MSVC/C++ (both overt and subtle).
To put in another way, there is a specific mindset required for
MSVC/C++ development. One that really has nothing to do with
the mindset of the Linux C/C++ developers (or any Gnu-C/C++) in
terms of how something is assembled or put together, even the
the source code is, for all intents and purposes, "identical".
That is, it is designed to produce a specific product for a
The Linux source, is, in essence, the core source-code or "base-
line" of CS. Any variations that occur with regards to this
Linux/Gnu C/C++ baseline directly influence whatever variations
become necessary further down the road in order for the "core"
source-code to work with other operating systems.
As the variations to the Linux baseline increase, so too does
the liklihood that something that works quite nicely under a
Linux system will not work at all under something like a Windows
system. This latter (The Win32API source code), in turn, must
then be modifed or "mutated" sufficiently to maintain base-line
functionality comparable (in a very general sense) to the Linux
The binding "glue" for all this, at least for CS, is the core
source-code of CS. Beyond that, as graphics drivers, sound
drivers and network drivers are added, a phenomenon begins to
occur that is metaphorically similar to making multiple copies
of the same original document when using non-digital methods of
ie. The greater the amount of copies the less similar the final
copy looks when visually compared with the original copy. It
may also be seen as a "dilution" of the image, or in this case,
the source-code in question. This might also be considered
Software rot itself, or the "likliness of software rot
occurring" increases proportionally to the amount software being
handled and/or "bolted-on" to the baseline source-code as it is
defined for the Linux development environment. Here we are
referencing the interface between the non-Linux OS and the Linux
I am not referring to the CS API here. I am referring to what
happens on the other side of the CS API when the system on the
other side of the CS API (relative to the CS Core) is an
operating system developed by MS.
A very large piece of software (in terms of the amount of
source-code lines -- not binary images) will be more likely to
have instances of "rot" associated with it than something with a
smaller amount of source-code lines (eg. hellowin.cpp, hello.c
are "not vulnerable to software rot" by nature of their
If we then start adding plugins or "enhancements" to that core
collection of source-code (in this case, CS), we increase the
"liklihood" or "probability" that software rot will occur and
will manifest itself in the form of something like missing
drivers...not because the drivers aren't there or because they
aren't being built, but because of the way the source-code, for
lack of a better reference, dictates assumptions for those
drivers and how those drivers "must" be used and/or "loaded for
The builds themselves are not a problem, they all compile and,
for the most part, link just fine. It is how the various facets
of the CS API and the Win32 API attempt to interact with each
other that seems to be at the root of the problems recently
appearing with CS "Fatal Errors", etc.
Anyway, that is my take on the situation.
Post by Jorrit Tyberghein
Post by Torlach Rush
Memory allocated by malloc/calloc etc. is not released when
functions lose scope except when using smart pointers (an MS
implememtation I believe, and in fact these would still produce
the debug assertion failures). I dont think its a good idea to
leave unwanted/unused memory lying around. Aside from
performance issues, doing so will eventually bring any system
Hospitals KU Leuven BELGIUM
People who used magic without knowing what they were doing
usually came to a sticky end. All over the entire room,
-- (Terry Pratchett, Moving Pictures)
Crystal-main mailing list
Nothing real can be threatened.
Nothing unreal exists.
Crystal-main mailing list
__ __ _ _ __ __
_/ \__/ \__/ Seth Galbraith "The Serpent Lord" \__/ \__/ \_
\__/ \__/ \_ ***@krl.org #2244199 on ICQ _/ \__/ \__/
_/ \__/ \__/ http://www.planetquake.com/gg \__/ \__/ \_