... the German federal parliament will be elected later on this year. Both parties of the big coalition (SPD+CDU) have to use the Summer to prepare voters for the election. And passing a law that protects children in some way will gain them big plus points with most family fathers and mothers (and probably others, as well). During the EU parliament election earlier this month, CDU was leading the polls, and SPD had lost some influence. Many people are sick of this coalition, mainly due to the highest taxes in German history for tobacco and fuel, plus an unusual erosion of social benefits that had unexpectedly taken place during the Schroeder (SPD) government a few years back. Many people will vote for the Left Party (Die Linke) or at least The Greens (Die Gruenen) instead, but it remains to be seen if the power of CDU and SPD can be broken that had us in their grip for decades. Career-driven politicians do not necessarily act in the interest of the people ... this problem has already existed since ancient Rome. BTW, ex-chancellor Schroeder is now board member of GazProm, a Russian gas giant.

Some years ago, I've developed a concept for the AI layer of my DELOS operating system that can generate UIs automatically. But it's mostly vaporware still.

There are custom solutions for disabled people on the market -- if you have health insurance, you can ask them if they are going to pay for it.

BTW, I always worry about things like accessibility, but employers for instance don't pay attention to that, and programming APIs for accessibility often dramatically increase the complexity of an application. That's why so few applications make use of accessibility functions. That must be changed someday. Thanks for the reminder. If I can, I will incorporate some of your ideas into an easy-to-use GUI framework, that frees the programmer from all extra work associated with it.

Really? There's absolutely NO material that could withstand the impact? How about something elastic then, that bounces the birds off? ... Bah, I'm disappointed with compound material research.

... you don't worry either. Put a grille in front of every engine, hard enough to withstand the birds. Automated cleaning systems could then get rid of bird goo during flight, if necessary. How about non-stick teflon?

FileNET can be monitored using Tivoli TME 10 and the FileNET integration module and/or CALA (cenit Advanced Logfile Adapter). This way, you can automatically react to problems. BTW, there's another post up there from someone who had a better time with FileNET. ;)

In fact, the BCPL block introducers and terminators are "$(" and "$)", respectively. However, in modern versions of BCPL published by Richards, they've been replaced by "{" and "}". BTW, CPL was a nice language, but difficult to implement, as it tried to use ordinary math syntax, like "ab+c" would mean "a * b + c", for instance. It also depended on the Atlas character set, which used 1024 distinct characters (including overlined and struck-out characters). I once wrote a CPL terminal in Java for fun (and discovered that Java is capable of real-time screen emulations in 60Hz on any platform).

That sucks. When I think back to the times of the old Donkey Kong arcade, Nintendo's start into the business, that's a huge step backwards. The feel of controlling Mario was unparalleled at that time. How little do they pay attention to the fun factor nowadays. Everytime a video game makes me angry, I wonder why I keep playing such things at all. The player should have fun playing, not gnash their teeth at having to play the same stupid scene for the umpteenth time, just because it is too hard for the casual player. (The scene in TP when you have to guard the wagon of the sick prince comes to mind; I completed it once only out of sheer luck after hundreds of failed attempts; to me, that's not the meaning of fun ... )

In Okami they managed to foul up a wonderful game with a series of stupid minigames that have nothing to do with the game itself. But you cannot proceed if you don't complete these minigames. Regardless, I at least managed to complete Okami after 50+ hours of gaming. But the replay value is drastically reduced if you have to fear to play those minigames again...

Indeed, riding a bike can be lots of fun. I did that a lot when I was younger, and it added a lot to my life.

A couple of years ago, I broke a leg doing a harmless thing, because my lack of movement had eroded my leg muscles, and now I have sheet metal in my leg and can never ride a bike again, I cannot bend my leg as needed anymore! :(

I don't know ... Unreal Tournament (2003/2004/3) is quite okay, just a straight out shoot 'em up.

Okami was quite good in retrospect (except the minigames).

Starfox Adventures ... that's a nice one, but gets unnervingly difficult later on in the game, just as Zelda.

Serious Sam ... a mindless shoot 'em up, that doesn't claim to make sense at all. :)

Halo I & II perhaps ... but there's always the same opponents. Most fun are the alien weapons.

Yeah, it's quite okay -- the only thing for me to complain about in that game is the lack of realism. Like when cops appear out of nowhere right behind you, or when pedestrians walk only the same road you are on, disappearing around the next block. Only some houses can be walked into ... it's sad how little attention they paid to those details. What I like about GTA is how you can drive various vehicles and stuff. But the damage system is a bit off, even the slightest touch can wreck your car, etc.

That's a problem affecting most of the games. They're useless without sound. In Halo and other FPS, you need to hear the enemy approaching ... without sound, that's very difficult. Even if there's a radar, you can't look at the radar all the time. There should be text messages like "enemy 50 ft behind you to the left" or something. ;)

Yeah, I want that too. And I'm also annoyed if I cannot save at arbitrary points. I'm a programmer, and once I had to tell an acquaintance who's game programmer how to save the level information. My goodness, is that so difficult? To save a couple of positions?

If game development nowadays wouldn't be so time consuming, I would make some really good ones! :)

BTW, one the best of the cheap game saving methods I found in Okami. It doesn't save the exact position of the wolf, but there are so-called "memory gates" which store your memory when you walk through. If you die, you're resurrected at these points. You can also save at every teleport mirror. Luckily, these are spread around at strategic places, so you never have to worry of replaying an entire level if you die. Also, the wolf has to eat to keep her stomach full, and she doesn't die when she still has life force in her. That's one of most elaborate "life" concepts in games I've seen.

Yup, don't neglect your health, especially if you're overweight! :)

This avoids especially knee problems (which I know first hand! ;) ).

Have you tried Unreal Tournament 2003, 2004 and 3? UT2004 is quite good and plays on moderate hardware. UT3 is even better, but unfortunately requires much better hardware. I hope they fixed all the bugs in UT3 in the meantime. Would be great if it ran stable all the time. The graphics alone in UT3 (if maxed out) is worth seeing. All the nanoblack technology in UT3 is awesome ...

Was it really worse with the Wiimote? I had the Cube version, and I didn't like the controller setup, I was pissed that it was impossible to reconfigure the controls. Among the worst things in the game is controlling the horse during battle: The horse stops at the tiniest pebble lying on the ground, but walks around dead bodies from the enemies. If the horse stopped, and you press the A button, the hero climbs off the horse ("NOO!!"). I cannot tell you how much that enraged me. All those scenes in which I had to accomplish a task in a set time annoyed me to no end. The only scenes I liked were those with the wolf and Midna. I never got to get even the Master Sword or what's it called, because I got stuck at some scene. Twilight Princess to me completely sucked. I'm just a casual gamer, and a Zelda n00b, and I'm never going to buy a Zelda game ever again. I hated that the area gets closed down at various points and makes it impossible to scour earlier places for stuff. The selection of articles is very small for a fantasy game, also. Trading and stuff is also impossible. I liked Okami on the PS2 much better. But both have unnecessary time-restricted parts that only seem to serve to draw out the playing time. I'm too old for this kind of rubbish, I guess.

How so? The API (the interface) does not prescribe how its implemented. Implementation can always vary.

Furthermore, new APIs can be considered at any time. However, a standard interface never changes in a way that breaks compatibility.

POSIX conformance is not just a matter of supporting a specific function, but also if the function behaves according to the standard. On GNU, Linux, et al., this is still being worked on.

Not so long ago, Linux provided a poor implementation of the POSIX standards (especially regarding threads, signals, and asynchronous I/O), and was far behind BSD, Solaris and AIX. Solaris too suffered from many problems. For some years, AIX was the only UNIX-like OS that I've seen that provided a reasonable implementation of these features. BSD also seemed pretty good when I used it for some years. Gladly for us developers, Linux has been catching up in the past years, however. Manual pages have been cleaned up to provide less misleading information also, a good development.

The POSIX subsystem of Windows is (like Windows) of poor quality, and is not fully installed by default. I still remember the times when fork() didn't work (don't know if they fixed it). Methinks, Microsoft should throw out their proprietary kernels and use a UNIX-like kernel (a BSD, Linux, or Mach kernel). The Windows program loader and task scheduler still have some serious defects (as of Windows Vista). Like, it's not possible to terminate a process cleanly from the outside (disrupts DLL reference counters, for instance), programs are loaded in whole (leading to catastrophic performance during startup), and the task scheduler often switches away from a process for a long time (often with 50 ms delay whereas on Linux it's below the 1 ms granularity level), which makes it difficult to write timing sensitive applications on Windows.

Me neither! ;)

Microsoft made some grave mistakes during the 80ies, which are still affecting us today. Like, a virtual machine (while slow at that time), could have provided 32-bit environments already on 16-bit CPUs (a lesson learnt decades ago, in the 60ies, from the computers that existed back then: in a resource-constrained environment, provide a virtual environment circumventing the constraints). At least a 32-bit DOS could have been developed (Microsoft made an alliance with IBM on OS/2 but neglected its DOS). Thus, a number of incompatible DOS-extenders emerged, providing at least 32-bit addressing on 32-bit CPUs. Thus, Windows 1.x-3.x had to support 16-bit, and thus were written mostly with 16-bit environments in mind. There existed a 32-bit extension, called Win32s, but it was hardly used, for, at the time, 32-bit OSes had already been available from Microsoft. The idiocy goes on and on ...

A UNIX-like Windows could have saved the industry trillions of dollars, and hundreds of thousands of businesses would not have gone bankrupt due to costs related to Windows problems.

Exactly that. Hundreds of thousands up to millions of different API functions exported by ten thousands of libraries in their many (often incompatible) versions. There must be a consolidation of some sort someday, a convergence towards a predictable set of APIs. This is already happening, but at the current pace it will take years or decades to complete.

That's not an option if a program must be portable.

Then you've missed out on the recent software industry trend towards C# even on Unix platforms (through Mono, a .NET clone).

API = application programming interface
Standard API = standard application programming interface

As of now, there are a few select development environments that meet these criteria to some extent: Shell scripts (KSH et al), Perl, PHP, JavaScript (in web browsers), Java, and C#. This is because the languages and their libraries are more or less standardized, varying only little between versions (but even that can be a portability hurdle).

The C and C++ have been standardized too late a point in time, and the shock waves are still perceivable. Only in the past few years, compilers like GCC reached halfways compliance with C and C++ standards. Especially on UNIX-like systems, adoption of standards has been slow. Add to that the ineptitude of the standards comittees to provide standard libraries for vital aspects of real-world programming like multithreading and graphical user interfaces. Merely C/C++ bindings to existing standards in these parts would have been sufficient, perhaps with a reference implementation.

I've been working with C since 1986 and with C++ since 1992, and I have seen plenty of changes. It is funny how slow things can evolve in this fast-paced industry.

Thanks. I'll see to it. Tools like CMake cannot solve the underlying problem however: The non-existence of a standard API that is upward compatible to previous versions. The GNU build system encouraged proliferation of incompatible interfaces. I only need to look at the size of such tools like CMake to know the extent of the problem. Many UNIX applications are written in Java and C# nowadays to circumvent the problem a little, but even there it exists. Doth man ever learn from the past?

p.s.: OS/2 also supported DOS applications. On the other hand, Windows NT supported DOS, Windows 3.x, and OS/2 1.x applications in addition to POSIX applications (I don't know if that's still available in Vista, but on XP at least all of that still worked). Windows 95/98/ME were hybrid 16/32 Bit systems that had good support for DOS and Windows 3.1 apps.