Old messages (part II)

[admin]

Marco Radossevich 3.22.2005

I'm very happy to see increased activity on this site, at least in this forum.

Me too, but please... change the forum script, please !

[admin]

Samuel A. Falvo II 3.22.2005

2AlexLanguages: The choice of language is 100% as important as the choice of kernel. Using the
right language can often result in a substantial decrease in the number of bugs upon release, and
can quickly hasten release time. You can use the argument that "MacOS was rewritten in C, so
Pascal can't possibly be all that good." That is a logical fallacy: Apple rewrite MacOS in C to

(a) adhere to the fad that C created, and
(b) make it easier to up-port to MacOS X (which is basically Unix, which of course, is written in C).

And yes, C/C++ *are* fads. I can't tell you how many 15+ year programmers I've spoken with who
don't know the first thing about C++. I abandoned C++ as a serious development language close to
8 years ago, so C++ has changed rapidly since then. Now we have C#, which unlike Java, is actually
viable as a *SYSTEMS* programming language, possessing the clean architecture of Java, the garbage
collection of Oberon (since CLR is essentially an Oberon runtime), and it runtime compiles to native
code.

In short, it's got the ingredients to relegate C to the same category that we'd normally talk about
assembly language -- "use only when you really, really, really need it." (E.g., to write the initial C#
runtime.) I agree that the kernel should be written in a consistent language. But do not discount
Pascal (note that although OS/2 and Windows are all written in a C-based dialect, ALL API calls
are Pascal-style calls. This was because both IBM and OS/2 had distinct plans to support Pascal
since, at the time, Pascal was growing in popularity QUITE rapidly), and especially don't discount
Oberon.

C and its immediate ilk are traditionally very, very, very weak languages, requiring much more
programmer effort to write good, clean code. As far as I'm concerned, if someone wants to hack
the base OS/2 system, they're just going to have to learn the language it's written in. Unix hackers
had to. MacOS hackers had to. Smalltalk hackers had to.

Finally, who cares what language it's written in ANYWAY? When coding applications, it doesn't
matter what language it's coded in because all interaction with other processes are going to be
done via system calls and/or shared memory anyway.

The only time the choice of language becomes an issue is when writing DLLs. And even then,
who is to say that you can't write an extension to a Pascal compiler to support "C"-style calls,
just as C compilers support "Pascal"-style calls?

Frankly, I see the choice of Pascal in the development list quite refreshing. I don't like the idea
of using C for C's sake.

BTW, I'm familiar with assembly language (x86, 68K, MIPS, basic PowerPC, 6502, 65816, 68xx,
808x, Z80-series), BASIC, C, C++ (old), Forth, Io, basic J (APL successor), Java, basic K, Lisp,
basic Modula-2, Oberon(-2), Perl, Python, and practical Scheme. So I feel I have some degree
of objectivity when it comes to choosing a programming language. C is a decent systems-level
language. But do not mistake it for the only, let alone the best, such language.

[admin]

Samuel A. Falvo II 3.22.2005

Oh, and how can I forget?! I also have strong exposure to REXX (more precisely ARexx), via
AmigaOS 1.3 and AmigaOS 2.04. I can't believe I forgot that!

[admin]

Alex Bervoets 3.23.2005

2Samuel: it was not my intention to claim that C is superior for the
job. There are other languages that are safer (pointers, type safety, ...) and can do more with
less lines of code, resulting in shorter development and testing times. However, these weaknesses
are also C's strengths : very fast, complete memory allocation/deallocation control, inline
assembler, ...

Moreover, these weaknesses are addressed today in modern C/C++ compilers, source code
analysis tools and external libraries (object reference counting, C/C++ garbage collectors,
RAD tools, ...).

There are also safer variants of C/C++ : the D programming language, see
http://www.digitalmars.com/d/index.html . My primary reason for suggesting C/C++ is its
large programmers base, see http://www.tiobe.com/tpci.htm . IMHO, developers are more
eager to join a particular open source project when they're already accustomized with the
environment, programming language and tools. Taking into account that most open source
contributors do this in their scarce spare time, and that learning a new language takes a
certain amount of time, I can very well imagine that open source projects based on popular
programming languages are more successful in their quest for developers. Every ICT bachelor
student (at least in my country) has to follow C and C++ courses. A second issue is the
availability of tools, compilers and external libraries for the particular programming language.

A third issue, if we're using several different programming languages is the availability of
cross-language bindings. Just my 2 cents.

[admin]

Samuel A. Falvo II 3.23.2005

Alex: I find the idea of having to resort to an external program to ensure proper program
structure is maintained absolutely repulsive. That is the compiler's job.

C's weaknesses are precisely that: Weaknesses. C is very fast -- but so is Oberon. I encourage
you to download and install Oberon System 3 Native to give it a test drive. I think you'll be
pleasantly surprised. In fact, Oberon is likely to experience more rapid progress in the area
of compiler optimizations because a number of issues with C/C++ just don't crop up, like
aliasing for example. And while I do agree that having a grotesquely huge developer base
already familiar with C to draw from is nice to have, it's not a strict requirement.

Case in point: Darcs. This formerly unheard of source management tool is written in Haskell.
To build it, you must install Glasgow(sp?) Haskell compiler. Apparently, more and more people
are comfortable doing this, as now-a-days, it seems like at least one e-zine or other publication
is writing something on or in support of Darcs.

My two cents is just this: C is a decent language with a long history of serving as a systems-level
programming language. If I choose to make a contribution to this project, I'm quite likely going
to end up doing most of my coding in C and assembly. But don't make the mistake of treating C
as the only viable systems language, and don't assume programmers can't learn a new language.

[admin]

James McCarte 3.23.2005

Well, this is all way over my head. I was just excited to see some work on OS/2, and wanted
to have a chance to do some programming, which I haven't done in 20 years......so I guess I'll
just have to wait for some programmming requests, and hope y'all don't mind a novice
programmer on the team.

[admin]

Cristiano Guadagnino 3.23.2005

Hi all, nice to see activity. As one of the "founders" of osFree and one of the early coders,
I want to remind anyone that this kind of discussions has already taken place. There are a
few guidelines at http://www.osfree.org/index.php?gobaby=coding, while a more precise
and stringent guideline was used by early coders (I authored this early coding guideline).

Bottom line is: we prefer coding in *plain* C, because of the large availability of tools,
because it has the widest audience and enables the widest number of developers, because
it is the language in which OS/2 was written and many of the internal development tools
are thought to be used by C compilers.

This DOES NOT MEAN that other languages are not accepted where it does not poses
problems, and where a good open source compiler exists. Compiler must use the OS/2 API,
NOT some kind of translation layer such as EMX.

I happen to prefer pascal (Samuel, modern Pascal compilers does not have any problem
using C style calls, and hence DLLs written in C), but have used plain C up to now to do
osFree development. I would suggest to anyone to have a look at the already existing
code to get an idea.

Let's not waste too time in this language war, as Samuel says there are really no problems
nowadays mixing languages together, especially when it comes to high level tools. For the
system-level part I would stick to C.

Also, I would avoid most exotic languages for the sake of maintainability.

[admin]

Cristiano Guadagnino 3.23.2005

To Yuri, Sergey: if you agree, I would reactivate the old yahoo-groups mailing list, changing
it to a moderated, closed-membership list, to keep the old "trolls" out (you know who I mean).
I volunteer to moderate the list, and to do membership administration. As activity increases
this forum is showing its limitations.

[admin]

Alex Bervoets 3.23.2005

Samuel: these analysis tools do exist for a lot of programming languages. If used properly,
they can dramatically improve the quality of the code during the development phase.
Development of such an analysis tool is a science on its own and they're often more
expensive than the compiler.

Fortunately, compilers have evolved a lot also: optimizers, profilers, ... Microsoft also
attempts to add source code analysis to Visual Studio. So there's clearly a shift from
external tools to compiler built-in code analysis. And while I admit that some
programming errors are unique to C/C++, I'm also convinced that it's possible to
(unintentionally) mess up code in any programming language.

C/C++ only allows a greater mess You can avoid a number of C/C++ pitfalls, eg the
array range overflow pitfall: use an array template class with bounds checking
instead which throws an exception when you try to access the array outside its
boundaries, similar like in Java.

However, this 'safety net' will be on the expense of raw speed. And while the
overhead in this example seems minimal, consider the overhead if we want to add
realtime processing capabilities to a kernel written in a language with a garbage
collector. I don't want to claim that C is the only viable systems language, it's only
my personal opinion that having a huge potential developer base could be a serious
advantage. Neither do I assume that programmers can't learn a new language.
If my boss says to me "we have a new project X for our very important customer Y
and it's a requirement that development will be done in language Z on platform P,
get yourself familiar with Z and P", then I will start learning language Z and platform
P and get the job done.

Now, in the open source world this seems to work a little bit different: having to
learn a new language in order to join a project seems to be some sort of barrier
for some people, at least that's my personal observation: I'm also interested in open
source databases (PostgreSQL, Firebird, SapDb/MaxDb, Ingres). Now when SAP
released its SapDb into open source back in 2001, people were exited because it
was a very stable, mature, enterprise-grade DBMS. The only competition back than
was PostgreSQl, although laking several enterprise-grade features. Unfortunately,
SapDb was written in a Pascal dialect and the source code had to be translated to C.
This was IMHO one of the reasons why this project failed to attract a lot of new
developers. SAP failed to build a community and ultimately handed SapDb over
to MySQL. Now compare this to Firebird (Interbase) and Ingres, they both seem
to have a wealthy community.

Don't get me wrong, there's nothing wrong with Pascal, it's a very powerful language.
Its popularity was growing in the 90's and its successor Delphi was amazing.
Unfortunately, Microsoft controlled the OS and the Windows API, promoted the
MSVC IDE with MFC as the de facto standard RAD environment for Windows and
then Sun brought out Java which became very popular in a short timeframe. To
be honest, IMHO the best system language in terms of raw speed and memory
load is assembly language. Unfortunately, this would be a nightmare
concerning development, bug fixing, attracting new developers, ...

So far my ranting. I hope that you can understand my point of view. My only
concern is to accelerate the OS/3 development. I'll give Oberon a try next
weekend.

[admin]

Samuel A. Falvo II 3.23.2005

I was doing some research on how OS2LDR/OS2BOOT/uFSD stuff works. I found this following article,
which I hadn't remembered finding before: http://www.belgrove.com/os2/warpboot/warpboot.html .
This is pretty interesting. It's almost exactly like GRUB. The primary difference between GRUB and
OS/2's boot manager is that the boot manager lacks built-in filesystems and executable format support,
and that the kernel image it loads is fixed (OS2BOOT and OS2LDR, period). It also scans for bootable
partitions on start (extremely Amiga-like!! I hadn't known it did this!), instead of relying on a
hand-established list of OSes to boot. For each partition that

(a) is marked bootable,
(b) has a uFSD embedded at a fixed location relative to the partition's boot sector,

the partition should appear in the boot manager's list of bootable volumes. (Oh, AND
it supports extended partitions on each volume too.) Each filesystem you write for OS/2
is expected to implement a "SYS"-like API which is aware of how to embed its own uFSD
onto the partition's boot sector area. You typically get only 2.5KB of space to do this with
-- as such, uFSDs often only recognize the root directory of a volume.

Anyway, the boot sector code uses the uFSD that is grafted onto it to load in OS2BOOT
(the miniFSD) and OS2LDR (the actual stage-2 boot loader which ALSO is OS/2 2.x and
later's microkernel, which I learned from http://www.belgrove.com/os2/hshk/hshk.html).

The miniFSD is exactly like the uFSD except that it could be aware of subdirectories at
this point. I'm not yet sure if OS2BOOT/LDR are LX-formatted executables, or the equivalent
of COM files. Considering how little space exists in the boot sector for code, I suspect the
latter. But once OS2BOOT is installed and OS2LDR is running, it doesn't matter -- OS2LDR
is expected to (as with GRUB's stage 2 loaders) just "know" proper executable formats from
which to load and dynamically apply fixups to the binary image.

Gosh, this information is hard to find, but once found, is a treasure-trove of useful data.
I suppose my next question is, does OS/2 support "executable format plugin" architecture?
E.g., we all know that OS/2 on x86 uses LX-formatted .EXEs. For OS/2-PPC, it's ELF format
executables. Are there any plans to migrate away from LX-formatted EXEs in favor of ELF,
even for x86? This would greatly aid porting OS/3 to other platforms, I think. And yes, I'm
definitely having a ball learning about this stuff.