I've uploaded a new PalmOS port to
ftp://ftp.freepascal.org/fpc/dist/palmos-1.0.5

readme.txt:
----------------------------------------------------------------------------- This is the PalmOS port of FPC 1.0.5 m68k. It is
compiled for a Win32 host system.

To install it, simply extract it into your \pp (FPC folder).

If you don't have FPC installed it doesn't matter, simply extra the zip files into any folder, c:\pp is recommended) and extend your path variable with a path to bin\palmos.

If you don't have installed the PalmOS support in C:\pp, you've to change the paths in bin\palmos\ppc.cfg.

The directory pp\demo\palmos contains a small demo. Compile it by executing the batch file do_make.bat and load the generated pilrctst.prc into the Palm OS emulator or into your Palm device. The demo is a Pascal port of the pilrctst.

This is only an alpha port so don't expect too much. Especially the Palm OS interface provided by the palm unit is very poor.

Further depends on the feedback I'll get about this port.

Any help is welcome. Especially I'am looking for more (and bigger) test programs.

Florian ()
-----------------------------------------------------------------------------

Enjoy!

There are already 2 very good pascal compilers for the palm platform in late beta. One will be pretty cheap when it ships. The other thing is that Palm inc has just acquired Be Inc's assets, so you can probably kiss goodbye to the 68k Palm OS with in the next year or so. Palm will either move to BeIA or a hybrid - probably on a PowerPC/Risc processor.

This of course sucks for me, because I just got underway with the Be API wrapper for the FPC BeOS port :(.. it look like BeOS is dead and burried....

http://biz.yahoo.com/rf/010816/n16293414.html

Matt

you wrote

There are already 2 very good pascal compilers for the palm platform in late beta. One will be pretty cheap when it ships. The other thing is that Palm inc has just acquired Be Inc's assets, so you can probably kiss goodbye to the 68k Palm OS with in the next year or so.

I don't think that this happen that fast. If they give up the m68k PalmOS support, they've no chance against WinCE. The big advantage of the PalmOS is the large number of applications.

Palm will either move to BeIA or a hybrid - probably on a PowerPC/Risc processor.

I'am still not sure, if a handheld needs a faster processor than the m68k. Ok, if it runs WinCE :) . I can't imagine a serious application which needs more than the speed of a m68k. And a faster processor consumes always more battery power.

Maybe Speech regnition would be nice, but it even doesn't work on a desktop PC.

This of course sucks for me, because I just got underway with the Be API wrapper for the FPC BeOS port :(.. it look like BeOS is dead and burried....

Hmmm, personally I've already the opinion for 1 or 2 years that BeOS is dead but I thought the people making the BeOS port know it better :)

Me too (I was on BeOS lists a 1 1/2 years ago, but I decided to do FreeBSD first).

I also have the feeling that Darwin attracts a lot ex-Be fans. I don't know why, since it seems to lack the visual make up of Mac OS X, so it is pretty much a YABSD (Yet Another BSD, but this time with Mach)

Quoting Florian Klaempfl :

At 00:56 17.08.01 +0100, you wrote: I don't think that this happen that fast. If they give up the m68k PalmOS support, they've no chance against WinCE. The big advantage of the PalmOS is the large number of applications.

PalmOS 5 has always been billed as being on non M68K hardware. Palm have been making their API 'generic' and processor independent for quite a few years. In fact, one of the jobs that John Marshal started, when Palm hired him to continue the GCC port he was at that point maintaining, was to remove all the Mac-isms in the API (there were a lot of typed pointers, which are a hang over from MacOS which was originally written in Pascal.) The PalmOS 3.5 API is really, really different to the PalmOS3.0 API for example.

The Palm is woefully underpowered. I had a Gameboy emulator for my Handspring - it used up half the battery power I had left in 10 minutes. In normal ussage, that should have lasted for about two weeks.

I personally would love to use an OS on a handheld that is non M$, but has real power. I would have opted for Epoc on the Psion, untill they dropped out of the consumer market recently. I would love to see BeIA on a Palm device :-)

Hmmm, personally I've already the opinion for 1 or 2 years that BeOS is dead but I thought the people making the BeOS port know it better :)

BeOS died some time around march. Be more or less dropped it like a hot potato. Now that Be Inc is unlikely to continue - the writing is on the wall. We (the users) hoped that it wan't so, but... ah, well.

I'm really wondering now if the Be port is worth the effort. I think I'll continue for fun.. After all FPc was ported to the Amiga, and that died for me in about 1992 :-) Hopefully Be will release BeOS R6 as a parting gift to users.. I can only hope anyway!

Quoting Marco van de Voort :

I also have the feeling that Darwin attracts a lot ex-Be fans. I don't know why, since it seems to lack the visual make up of Mac OS X, so it is pretty much a YABSD (Yet Another BSD, but this time with Mach)

Somebody should port Opentracker (www.opentracker.org) to Darwin. That would rock.. Incidentally, does Darwin have a journalling file system?? Where does one get a copy from??

I had a look at AtheOS, but it didn't want to know about getting installed on my spare box. Shame, because it looked very BeOS like, API wise etc.

I've recently tried QNX too.. it's got a lot better with the 6.1 release.. still don't like it though.

Matt

No, there is no journalling filesystem for it yet, though I think there are people who are trying to port ReiserFS to it. You can get it from <http://www.opensource.apple.com>, but the 80x86 version is very limited at the moment: it requires a motherboard with an Intel 440BX chipset and a BIOS that fully supports the El-Torito boot spec to be able to boot/install.

Jonas

I was talking about _serious_ applications. I agree the Palm is too weak for action games, but with ChessGenius a usable chess program is available so you can
have fun with the Palm as well :) But if I want to play I'am using a real Gameboy or a PC, it's much more fun.

BTW: I think it would be better to figure out which C++ constructs in FPC would be required than making C wrappers. Does the BeOS interface use C++ exceptions or templates?

Hi!

Florian Klaempfl wrote

BTW: I think it would be better to figure out which C++ constructs in FPC would be required than making C wrappers.

Is it technically possible, to make C++-Libs directly accessible from FPC? That would be really fine for maybe accessing KDE-Libs without the need for C-wrappers.

Tschau!

Michael

Quoting Florian Klaempfl :

What I desire is a simple, portable system. Colour screen, Good Windows manager (along the lines of BeOS or KDE), optional keyboard, easily extendable, and with a built in development environment. Something the size of the Toshiba Libretto.. *not* a PC, not M$... a bash shell... I dream anyway.

BTW: I think it would be better to figure out which C++ constructs in FPC would be required than making C wrappers. Does the BeOS interface use C++ exceptions or templates?

I'll look into it. I don't know off the top of my head, but I believe there is no use of templates. The API, as far as possible uses plain ANSI C++ without many extensions. It does use Multiple Inheritence in places, but sparingly.

Matt

Templates as well as exceptions are ANSI C++.

I was working on this, parts of this effort are in 1.1 but some others aren't commited yet because it isn't ready. If there is a need for it, I'll finish it. But supporting all C++ features like exceptions and templates is too much work and requires really deep changes in the compiler and rtl.

Another problem is: the gcc handles
exceptions in another way then MSC++, the name mangling is different etc. About the C++-Builder I even don't know.

That would be really fine for maybe accessing KDE-Libs without the need for C-wrappers.

Does the KDE-Lib still base on the Qt lib? Then it is very hard work: the Qt libs require full ANSI C++ support, furthermore the Qt headers require a preprocessor for the signal/slot concept. How should this be implemented in FPC? With another preprocessor? Or with native language support? The first solution isn't very pascalish and the second, hmmm, I don't know.

Even Kylix uses a C wrapper; I don't think it is worth the effort; Creating a C layer in a structured/programmed way may be much more simple than trying to implement full C++ support. The performance impact of this extra layer will hopefully be quite minimal, when compared to the comparative slowness of the C++ libs.

Michael.

Quoting Florian Klaempfl :

Templates as well as exceptions are ANSI C++.

Let me rephrase ;)

It doesn't tend to use 'exteneded' features, such as templates, that cause confusion and convolutedness to code.

I'll look into it further, as I said. All my docs are at home right now.

Quoting Michael Van Canneyt :

I remember some of us on this list had this discussion when Kylix came out. We were divided.. I remember I was quite happy to use Kylix with it's wrapped and flattened API, but others 'poo pooed' it. They made bold statements about how it wasn't a propper thing to do and how FPC would never take this approach. In the real world, however, things are never all that simple. A flattened API is better than no compiler support, so I applaud Michael's foresight.

To be honest, at this point in time, with BeOS being in a completely unstable position, I can't see why we'd want to bother worrying about how the API calls are being made. After all, if there are no more updates to the OS, who will want or need the compiler?? Any support is better than zilch/nothing/nada/nil etc..

The 1.1 compiler can already compile the Qt.pas unit from FreeCLX with only a very small patch to Libc.pas to include two type declaration that are not in our system unit.

So if ppl want to experiment with Qt it is already possible. I didn't try it yet so i don't know yet how a sample program compiles and links.

Peter

The 1.1 compiler can already compile the Qt.pas unit from FreeCLX with

only

a very small patch to Libc.pas to include two type declaration that are

not

in our system unit.

Have you tried this with the windows version of QT.PAS? I Have Delphi 6, and I'd be interested to get FPC compiling simple QT Apps... This is only one step away from getting the CLX to compile (highly patched of course, with all the incompatible stuff removed.)

Have Borland made the QT Wrapper open source yet? I'd love to see this recompiled on other platforms with QT, so that we could use FPC on them to create simple GUI's ;-)

So if ppl want to experiment with Qt it is already possible. I didn't try it yet so i don't know yet how a sample program compiles and links.

Is there a binary distro of 1.1? To be honest I havent booted into Linux (except to set up a server so I could use DHCP on my network) for *ages*. I much prefer BeOS (*sob*)

Matt

I only tested it on linux to see if fpc could compile qt.pas.

Have Borland made the QT Wrapper open source yet? I'd love to see this recompiled on other platforms with QT, so that we could use FPC on them to create simple GUI's ;-)

See the Freeclx project at sourceforge

See the daily snapshots directory on the ftp site

Hi there!

About that mysql bug, I decided to try a snapshot release posted on the fpc site a month ago (snapshot-full-1_0_5beta.zip). This time the errors are more previsible: I have to add some bytes (about 50) after the Tmysql variable. Thix "fix" won't work on 1.0.4.

This should mean a bug on the mysql unit or the mysql C library itself. At least now I have something I can tell my students to do and provide a reasobale explanation (take care of those pointers...). Here's the working program with the hack.

But the sockets unit still don't work. It looks like it never returns EOF so the program keeps getting garbage.

[]s, Fernando Lozano