What is really in the header of binary files?

[tofro]

Derek, if you are cross compiling and importing into a QDOS environment then you have no choice.

My own workflow involves using SMSQmulator which has a virtual drive watching a native system directory. I copy the executable there and then create the resource fork (as it would be known on a Mac) to give the memory size. I then mount either a Microdrive image or a floppy image and copy the file onto there. The image can then be used in a vDrive or a Gotek on a real machine.

My workflow does often include non-QDOS file systems as well. But I only keep my source files there and edit them using modern IDEs. Compilation and linking is done natively (regardless whether it's S*Basic, C, or assembly, that is, "_o" and "_rel" files live on a DOS file system, which is absolutely fine), and that's as easy as an "ALT-TAB" away, normally to a RAM disk and then I decide where to finally put my binary in the QDOS world.

Keeping the source files on a host file system has the added benefit of being able to seamlessly use a code repository like git or SVN which helps me greatly with restoring older versions of code if I have messed up something and overall seeing where I was, what I was up to, and where I have last made changes when returning to an old project after some time. This has greatly improved my productivity.

[Peter]

You normally shouldn't need to reboot a multitasking system.

Of course. I was just referring to the task of getting the file length for setting an executable's dataspace once, on a 128K machine, if the file is too large to coexist with a Toolkit. (TK2 could almost be considered part of the OS...)

[ql_freak]

toolkit prior to actually loading it to memory, then reboot.

NEVER EVER!

The QL is a (was the first affordable) Multitasking computer. You normally shouldn't need to reboot a multitasking system. I have had running my QL (in my days) often nearly a week without rebooting AND thereby also writing programs in (Lattice-) C or (and) Assembler.

Actually, nothing on the Multi-Tasking box says "don't reboot" :) Especially on the non-expanded QL we're talking about, multi-tasking will not be very much "multi" due to memory restrictions.

As far as I can remember to my 128 KByte time (but 2x720 KByte 3,5" Floppy drives) at least an editor could run in parallel with an Assembler (I think I used Metacomco at the beginning). On a PC: 1) Start editor, 2)load source (former editors didn't store the last file nor loaded it automatically) and edit, 3)exit editor, 4)start assembler (on DOS you had at this time to type the command line and there was NO history!), 5)start program for testing, quit when finished, GO TO 1).

On QL Start editor once, load source once, start assembler once (I think there were assemblers where you have to enter the source filename only once) then: 1)Edit source, 2)save source, 3)CTRL-C to assemble code to executable, 4)CTRL-C (to SuperBASIC) to start program for testing, quit when finished, CTRL-C GO TO 1

I.e. except from you program executable you mustn't load anything from disk/microdrive as on PC and the whole circle has one step less.

It was even possible to compile K&R C with the Lattice C compiler (distributed by Metacomco) on an unexpanded QL(!). As phase 1 of compiler was too large to fit in free memory, phase 1 used partly the screen memory (spurious pixels appeared in lower part of screen).

p.s.: You could even thanks to permanent SuperBASIC define some procedures (e.g. 100 DEF PROCedure ex
110 EXEC'FLP1_MyDoWhatIamThinkingProgram'
120 END DEFine) to start your program simply with: ex

[ql_freak]

My own workflow involves using SMSQmulator which has a virtual drive watching a native system directory. I copy the executable there and then create the resource fork (as it would be known on a Mac) to give the memory size.

BTW: This is also possible on Windows if you are using the NTFS file system (which now nearly all Windows user are using IMHO). As the HPFS file system of OS/2 NTFS supports IMO so called Extended Attributes albeit Windows programs seem not to use it. On OS/2 the Extended Editor used it to support different character styles (e.g. bold) in files which are else pure ASCII. The formatting is stored in the extended attributes, so you could compile a source with e.g. keywords in bold cause the compiler only sees the ASCII letters.

Hint: Could IMHO be implemented in PC-Emulators to store the QL file header on files stored on the native file system.

[Peter]

My workflow does often include non-QDOS file systems as well. But I only keep my source files there and edit them using modern IDEs. Compilation and linking is done natively [...]

But if you compile natively, your IDE won't be able to parse the compiler output for errors and jump there. Or did you implement that somehow?

I prefer to use cross-toolchains for C and short assembler code, so the build process can be fully automated, and errors lead me directly to the corresponding source code. Also has the benefit of the QDOS-GCC option, which produces significantly more efficient code than C68.

[stephen_usher]

By natively I mean native to the cross compiler system, not the QL side which, in the case of SMSQmulator, and emulator (ad hence non-native).

[tofro]

My workflow does often include non-QDOS file systems as well. But I only keep my source files there and edit them using modern IDEs. Compilation and linking is done natively [...]

But if you compile natively, your IDE won't be able to parse the compiler output for errors and jump there. Or did you implement that somehow?

I prefer to use cross-toolchains for C and short assembler code, so the build process can be fully automated, and errors lead me directly to the corresponding source code. Also has the benefit of the QDOS-GCC option, which produces significantly more efficient code than C68.

I have, in fact, implemented a minimal integration of QMAC's list files into MS Visual Studio Code that can ectract errors from there and jump to ERROR lines, and the same thing for Prospero Pascal. I was a bit more lazy with C68 (which is, indeed, simply set to "maxerrors=5" in my make files, because that is somewhat of home turf and I rarely have or want to handle more than 5 compile errors. S*BASIC is, however, a completely different story.

QDOS-gcc is somewhat different. I tend to read everywhere "it's miles better than C68". Well, in my opinion and experience, it isn't. It might be (significantly) faster for some benchmarks, but in reality it isn't really worth the hassle. I simply don't use it because I find 2.95 too cumbersome and old to work with (I'm using gcc on a lot of platforms in my professional life and simply cannnot look back. So, C68 isn't any better - on the contrary - in this respect, but I let it pass because "old platform"). I have set up a gcc 13 implementation atm that, admittedly, fails to supply most of C68's extensive library support, but somehow I think, the time when it was a legit target to be able to seamlessly compile Unix/Linux applications for QDOS is long gone. The fat compatibility layer QDOS-gcc 2.95 supplied simply doesn't make sense any more. "modern" Linux software doesn't fit by far, making Linux applications available on QDOS made sense 20 years ago. Today, the chance of making anything contemporary run on QDOS is basically zero. It already was a stretch back then, but today: No way. My gcc 13 libraries provide access to QDOS traps and that's it. I'm thinking about releasing that into the wild, but I'm not there yet (maybe I never will be consdering there's a lot of QPTR and Hotkey still missing...)

[Peter]

QDOS-gcc is somewhat different. I tend to read everywhere "it's miles better than C68". Well, in my opinion and experience, it isn't. It might be (significantly) faster for some benchmarks, but in reality it isn't really worth the hassle.

For example, the sound player for QIMSI is too slow on a 68008 when compiled with C68, but fine with QDOS-GCC. My experience is a very practical speed increase in various projects. Also QDOS-GCC has the benefit of inline assembly.

What do you mean by "hassle"? In most cases, code for C68 just needs to be recompiled.

I have set up a gcc 13 implementation atm [...]

That is impressive! I don't think code generation for 68K gets better with newer GCCs though.

Today, the chance of making anything contemporary run on QDOS is basically zero.

Still there is way more useful C code around in the world than SuperBASIC and QDOS assembler code.
Also C is still a good programming language where efficiency matters.
I wouldn't complain about a newer QDOS-GCC, but 2.95 is better than nothing.

It already was a stretch back then, but today: No way. My gcc 13 libraries provide access to QDOS traps and that's it.

Does this mean you prefer to program the QL in C without C library?

[Derek_Stewart]

Hi,

I have an interest in C programming and have been using the QDOS-GCC in Docker on a Linux computer.

I had silly idea, maybe too wine over Christmas, to compile QDOS-GCC on a modern x64 Linux computer, after a little struggle, I have nearly got it working, thanks to those nice QL chat blokes.

But this is a very old version of GCC, v2...

Is it possible to cross compike GCC v13 onto the QL?