This web page has i386 Win32 and ARM WinCE cross-compiler zips that include everything needed (no install necessary) to test FPC 2.4.2 with the fpGUI 0.7 release (Aug 2010):
http://www.turbocontrol.com/easyfpgui.htm

The i386 Linux version is almost ready. Email me if you want to test a private copy of that distro.

Paul Breneman wrote

This web page has i386 Win32 and ARM WinCE cross-compiler zips that include everything needed (no install necessary) to test FPC 2.4.2 with the fpGUI 0.7 release (Aug 2010):  http://www.turbocontrol.com/easyfpgui.htm

Nicely done, thanks Paul.

Thanks for fpGUI!

Please check your spam folder for an email from me. Or just send me an email and I'll reply to it. We had some email discussion on 16-Jan-2010. I could use your help on a few items with the i386 Linux distro that isn't on that page yet.

Paul Breneman wrote on 11/13/2010:

If you downloaded the i386 Win32 111310 version to see what fpGUI controls look like, you might consider downloading the new 111410 version from today. Not only are the two simple programs from yesterday still there, but the source for the fpGUI uidesigner program is now included so you can compile and run that program. And, of course, the uidesigner program itself is a good example of a more complex fpGUI program.

Great !

I's like to take a look at the ARM-Linux cross tool chain !

Special request: remote debugging vie Ethernet would be very desirable.

Thanks a lot !

-Michael

BTW.: Would it be possible to compile Lazarus with that distribution to allow for native development on ARM/CE and ARM/Linux ?

Thanks for your work,
- Michael

Note that I wrote that i386 Linux is almost ready. ARM Linux isn't coming soon unless there is an official release for that platform, and that hasn't happened since the 2.2.2 release.

Special request: remote debugging vie Ethernet would be very desirable.

Indeed!

This only concerns the toolchain. All you need is gdbserver for your target machine and an arm-linux-gdb on your host machine.

Henry

Thanks Henry for that info.

I try hard to write Pascal programs without using pointers and without allocating or deallocating memory. If the RTL is reliable (when it does those things behind the scenes) then all of *my* bugs are logical (and shouldn't crash the program) and usually a few debug or log messages will be all that is needed (and many times I don't even need those). That has worked very well for me since 1985 since the TurboPascal RTL always seemed *very* reliable. In 1995 the VCL wasn't quite as solid but still pretty good...

And since Pascal strings can contain nulls I never have to allocate buffers in my communication programs but rather I just use (safe) strings there as well.

I'd like to take the minimal distros and add a simple option to use MSEide and it supports debugging from what I understand. Then maybe extending that with remote debugging would be the next item.

I know that you and many other experts on this list already have this stuff figured out, but I've had to spend my time on a lot of other things. The minimal distros started out as my method of trying to reduce things as much as possible when I started programming on ARM Linux. I am amazed at how simple the Free Pascal "hello world" distro is, so it has been quite an education for me to go all the way down to that and then build things on top of that in various ways.

Are there other open source development tools with which I could do Windows and Linux minimal distros? If so I'm interested in adding those to the web site.

It is neat how, especially for Windows, there are basically no requirements. Well, I guess ZIP support wasn't in the OS before XP so that is one requirement. :) Right now I'm trying to figure out how to provide something for the Linux distro that works as simply as the compile.bat does on Windows.

Yesterday at work I started using the latest Win32 and WinCE minimal distros to develop a very simple fpGUI program for a nice PDA. I'll develop mostly on Win32 and test occasionally on WinCE and the actual device. It is nice to use the fruits of my *long* day Saturday. :) Most of all I'm thankful for the great Free Pascal and fpGUI tools that allow such efficient development environments!

I guess I wrote what should be a blog article somewhere... :)

MSEide is ready to work with remote gdbserver and gdbproxy. I even use it for C development with AVR32.

Martin

Paul Breneman wrote

I try hard to write Pascal programs without using pointers and without allocating or deallocating memory.

OOpps. How is this possible :) ? But in what way does this help on that issue ? I do see that memory allocation/deallocation is a source to very hard to find bugs, but avoiding it makes may things close to impossible.

-Michael

That is good to know. Thanks Martin!

Indeed !
So this should be possible with Lazarus, too. It would be great to see someone here who successfully tried it. :)

-Michael

I don't doubt that there are certain domains where application-level memory allocation/deallocation is very necessary. But for the type of programs I usually write it isn't. I've written a lot of machine control projects with TurboPascal starting in 1985. The only strings (short) at that time were still long enough for the serial data buffers I needed.

In 1985 I started working on an existing real-time video editing program written in PDP-11 assembler. In the early 90s I ported that to pure TurboPascal (no assembler) with ~50,000 source lines. The only interrupts were for the keyboard and also a video timing interrupt (50 or 60 Hz) and about one-third of the code lived in the timing interrupt routine. One system had 24 RS-422 serial ports (38,400 baud) in an inexpensive RadioShack Tandy 386 computer, which was the main computer that controlled about $2 million of digital video editing equipment. Quite a funny picture in a way (a peasant running a rich kingdom)...

Several fellows who developed such PC-based editors before me had to use expensive and complex intelligent multi-port serial port cards but thankfully I waited just long enough that the 16550 UART (with the 16 byte FIFO) had arrived on the scene so my system was much simpler. All of the commands (during the real-time recording) were 16 bytes or less so using 16550 UARTS it all worked without interrupts for the serial ports.

I just went back and searched the ~50,000 likes of source, and there is not a single New/Dispose (nor Mark/Release) in all of my code. My program never crashed (even at the beginning beta stage) and I never used a debugger but rather a little logging when needed.

All video editing is now done with fast computers but here is a freeware version of that program that can utilize 9 serial ports: http://www.brenemanlabs.com/MachOne5.htm
http://www.brenemanlabs.com/Mach1I.htm

One of my favorite authors (Jack Crenshaw) likes TurboPascal a lot, and (if I remember right) years ago he wrote something along the lines of: When I compile a C program I'm surprised if it runs the first time, but when I compile a TurboPascal program I'm surprised if it doesn't run the first time.