Uh, that's a lot of info to process, thanks all three of you for the answers, I'll just try to answer the few, randomly, which I have an answer for currently.
mk79 wrote:Most executables either have no extension at all or "_exe". But in a foreign land one should obey foreign customs, so ".exe" is the best choice I think.
But well, FPC has a tendency to follow the target platform convention instead. So of course it doesn't do .exe on Mac or Linux, or Amiga for that matter, on Atari for example it will generate '.TTP' or '.GEM' extension, depending on if you compile a GUI program or not, etc. And I get that on QL the dot doesn't serve as separator, but it's not a problem. Anyway, I'm just saying that it's possible to change. But whatever y'all think.
NormanDunbar wrote:Provided a job is showing a cursor, usually a flashing one, then you can press CTRL-C (I know!) to switch tasks to that flashing cursor.
Well, that's the thing. In this case FPC doesn't show a blinking cursor, just tries to do a blocking read from STDIN. Maybe that's not opened with the right settings or something, but it certainly works with EXEC_W. No idea.
Another point to look into then. (Trying with Q-emuLator still. I don't know, trying with such a tiny system has its charm, for me...)
tofro wrote:C68 solves the same problem elegantly by providing a global variable "char *_endmsg" containing the "Press any key" in its C library. The linker will pull in this symbol (and display the message) if it's not defined in a program. You can override this linker symbol in your own program by defining your own string or setting the pointer to NULL, which disables both the message and the wait for keypress. If something similar (weak, overridable library symbols) is possible in FreePascal, it would be the most convenient mechanism.
Yeah, something like this is certainly possible, but probably not with symbol override as FPC doesn't really support weak symbols (there are ways, but it's just very messy), so "Press any key to exit" as string will always end up in the executable anyway, even if it's not used in the end, but something similar can be easily invented. Same with the consetup idea, although I'm not sure how many internal APIs there need to be exposed to work well. So that requires some thought. But it's not impossible.
The channels stuff still needs some more processing from me to fully understand, but it's already a lot more clear, and it's quite helpful what y'all wrote, thanks.
Few bits from me: courtesy of Marcus Sackrow, the other suspect behind FPC Amiga port beside me (I'm more a compiler and low-level guy, he likes to work on GUI stuff and high level), there's now a regular QL build with a Linux/x86-64 cross compiler, mainly for the purpose to notice immediately if the build breaks due to some changes made by others. I will get e-mail notified in this case. But regardless, the build outcome is available here, in case someone wants to try:
https://build.alb42.de/fpcbin/, search for the fpc-?.?.?-m68k-sinclairql.tar.gz
(Not linking the file directly, because the compiler version might change in the future, and the file is regularly updated.) The Linux/x86-64 binary of FPC works on any distro, because it doesn't use any libraries from the system, not even libc, it goes directly to the kernel syscall interface. So any Linux works. One still need to supply vasm/vlink binaries though.
Also, this made possible another neat trick - Marcus added Sinclair QL support to his online FPC compiler, where one can just paste Pascal snippets, and then download a QL binary.
It's available here:
http://build.alb42.de/onlinefpc/ Select "Sinclair QL" from the drop down menu to get a QL binary. I wonder if this is the world's first online compiler for the Sinclair QL...
Also check Marcus' blog, he posts a lot if interesting stuff he works on, almost all of them Pascal related. It shows the things FPC makes possible on low end or niche systems, with a single developer. (My recommendations:
an OpenStreetMap client,
a spreadsheet app with .xlsx support,
a Wolfram Alpha frontend, or
a small raycaster engine.) Such stuff should be possible for the QL (and compatibles) if we manage to get the support libraries advanced enough, that is.