SMSQ/E Executables

[tofro]

Hi,

I asked advice from Wolfgang Lenerz.

Who had a quick look at the code, that seems to be true (the file is given the extension"EX"), but he did not didn't really investigate any further (file dv3_msd_drset_asm).
The file date is in 1998....

So it would seem, that an executable file coukd be stored on a FAT12 Floppy Disk and the executable information still be in tact.

I do not know whether this works or not.

SMSQ/E has a way to encode data space size of executables (and nothing else) into the file name. If you name a file with the extension "_ex?", replacing the "?" with a digit, SMSQ/E will execute that file with "?" k of data space. That's quite a crude way of encoding header information. It's especially unsuited for programs built with C68 which often need bigger than one-digit data space ("unzip", for example, needs over 50k of data space, "zip" about three times that). TURBO-compiled programs often are similar (My "qjewels" program has an experimentally determined data space size of 16k).

For some, especially assembly programs, that method can, however, be useful (QMAC, for example, is happy with 4k of data space)

And yes, it works (for QMAC, not for unzip or qjewels)!

The old QPC2 (until v4) manual mentioned that functionality, but I can't find it in the newer v5 manual. With most of the non-QPC SMSQ/E versions lacking the DOS device I tested this on, I'm also not sure if this behavior is QPC-specific or not. I might have a go on the Atari.

EDIT: Just tested that on Q68: It will execute "fat1_qmac_ex4" just fine.

[Peter]

SMSQ/E has a way to encode data space size of executables (and nothing else) into the file name.

Terrible. I don't have the slightest idea why SMSQ/E doesn't support the XTcc trailer instead.

[tofro]

SMSQ/E has a way to encode data space size of executables (and nothing else) into the file name.

Terrible. I don't have the slightest idea why SMSQ/E doesn't support the XTcc trailer instead.

That's likely a performance thing. Parsing a file name (which you have anyways) for a digit and multiply by 1024 is way simpler than open the file, seek to the end, seek XTcc trailer size backwards (remember: possibly slow media like floppies), parse, know the data space.

Agree it's crude. That's probably the reason why it's a nearly forgotten feature

[Peter]

SMSQ/E has a way to encode data space size of executables (and nothing else) into the file name.

Terrible. I don't have the slightest idea why SMSQ/E doesn't support the XTcc trailer instead.

That's likely a performance thing. Parsing a file name (which you have anyways) for a digit and multiply by 1024 is way simpler than open the file, seek to the end, seek XTcc trailer size backwards (remember: possibly slow media like floppies), parse, know the data space.

Why seek to the end and then backwards? The file length is known, so just seek to length-8, check for XTcc and the next 4 bytes are the dataspace as longword.
Also, as excuting a binary means loading the whole file anyway. So why not check for the XTcc trailer afterwards, reducing the overhead to zero?
Or is the dataspace strictly required before loading?

[tofro]

Or is the dataspace strictly required before loading?

Of course it is. The first thing EX does is allocate memory in one piece for the program plus the data space (done by MT.CREAT, which wants both the program size and the needed data space). Then load the binary into the beginning of the allocated space, then activate the job.

[Peter]

Or is the dataspace strictly required before loading?

Of course it is. The first thing EX does is allocate memory in one piece for the program plus the data space (done by MT.CREAT, which wants both the program size and the needed data space). Then load the binary into the beginning of the allocated space, then activate the job.

I don't know MT.CREAT. Probably you mean MT.CJOB?
Since any additional data space magic is an SMSQ/E change anyway, I'm not sure about a strict dependency on MT.CJOB. Maybe it is possible to split allocation in into two phases.

[tofro]

Or is the dataspace strictly required before loading?

Of course it is. The first thing EX does is allocate memory in one piece for the program plus the data space (done by MT.CREAT, which wants both the program size and the needed data space). Then load the binary into the beginning of the allocated space, then activate the job.

I don't know MT.CREAT. Probably you mean MT.CJOB?

Indeed I do - my memory is apparently getting worse

Since any additional data space magic is an SMSQ/E change anyway, I'm not sure about a strict dependency on MT.CJOB. Maybe it is possible to split allocation in into two phases.

Well, you could use the HOKEY system - But that has other, even more severe, implications. And, of course, you could fiddle with internal tables and the like. Whatever you do, existing programs (like file managers or FileInfo, for example) would still use MT.CJOB. So, changing "EX" alone wouldn't cut it. Trying to change the inner workings of a 40-year-old system is likely to open up a can of worms (or worse).

[Peter]

On second thought, using MT.CJOB seems possible. TRNSP could be used only for data and the job header, while the code is in a previously allocated area, where it was loaded before calling MT.CJOB. MT.CJOB can optionally use this absolute start address. If I remember correctly, I already used this method for QLwIP.
Of course, software which uses it's own routines to execute a file wouldn't know about the XTcc trailer.
But if one or two file managers could be updated, and SMSQ/E itself supports it, a large improvement already.

Of course I'm likely to have overlooked something... but we are talking an additional feature. It does not keep old software from sticking with what we have.