Challenge: AmigaOS command to start executables.

[Photon]

Thank you for so many responses. Let’s navigate options and find a promising solution.

Copse, thx. Looks like some thought went into the hunk parsing, it may inspire a solution.

Meynaf, from a commandline argument. If system() only uses functionality in ROM, it might be worth a look to see what it does.

Olaf Barthel, sweet! Yes, that one looks familiar. Within the limited scope of this command, will it be compatible with KS 1.3-3.1? If Execute() and SystemTagList() only use functionality in ROM, they are viable. Python is fine, pseudocode is fine, and it will become asm in the end.

Tomas Richter, this is why I ask. If hunk parsing is unnecessary, all the better. I wouldn’t be surprised if we find a command to do this, compatible on KS 1.3-3.1, on a Fish disk from the early days. KS2.0 brought many changes, and code compatible with all Amigas is since then quite rare.

Unfortunately Execute() requires Run, which is not resident when booting a floppy. If SystemTagList() doesn’t, you would still need to write code to switch between the two.

Regarding compatibility problems, this is why I emphasize “start”. After the program is correctly loaded into memory and relocated, all kinds of compatibility issues might happen. Writing compatible programs is up to the author of the program being started (as always, even within Workbench).

And regarding your last statement reacting to Babel’s System() wrapper, turn again to the challenge description. The extra features you describe are not required to fulfill the challenge.

A/b and AestheticDebris: It’s technically always incorrect to clear BSS data - you’ve specifically asked to declare variables that have no value set. However, in the interest of running as many programs as possible, even those that rely on this bug and therefore don’t clear the necessary variables, it should be possible with a parameter for the command. Since usage is tied to the exe and not the OS it’s running under, BSS should ideally behave the same on all KS versions if possible.

Alkis: This seems promising, he wraps it in some preparation and finishing up code. Maybe some ideas here can be adapted to do it, if the ideas are upwardly compatible.

-~-

I'm one person and will try to find time to get some of these ideas working.

Meanwhile, I will prepare a bootable blank disk image with a Test program on it, or you can post an exe and I will try - let's say A500 1.3, A600 2.0, and A1200 3.1 is a pass for now, and we can find edge cases later.

I will make something up with a CODE hunk which needs reloc and data in DATA_C and BSS.

I'll post it here, CU in a bit.

[Photon]

'StartTest.adf' (- whee, imaginative names!) is available here. If your browser manages you for you and has reduced functionality, use this link.

To test if the challenge is met, put your command (let's call it Start) on this disk image, boot it, and type 'Start Test'. The Test program works on all Amigas (using a 680x0 CPU and native graphics, that is).

If it shows a little multicolor duck plotted on a black background* and returns to CLI on left-click, it fulfills the challenge on that Kickstart. (If 1.3 and 3.1 is OK, the rest should be OK and you can leave other testing to me.)

Test has a CODE section which needs a DATA_C section and a BSS section. It has 48b of reloc in all 3 sections. Hunks should be hunky dory - alert me if not!

* I've modified the program to never clear the bottom 80px of the screen. Please add something to use chipmem to the disk, run that, then Start Test to check if BSS is cleared. (Garbage in lower part = not cleared.)

Cheers

[a/b]

Originally Posted by Photon

A/b and AestheticDebris: It’s technically always incorrect to clear BSS data - you’ve specifically asked to declare variables that have no value set. However, in the interest of running as many programs as possible, even those that rely on this bug

It's explicitely stated in DOS technical ref manual that BSS hunks are zeroed by the loader when they are allocated.
And that's what the loader in ROM always did (up to 256KB due to a bug if KS <2.0, and fully if >=2.0).
Not to be confused with "code+bss" or "data+bss" hunks, where you shouldn't expect the trailing bss part to be cleared, unless you are 100% sure you run on KS2.0+.

[Thomas Richter]

I still don't get it. Here is the solution: Type "Test" on the shell. Done. Do I now win a price for being obvious?

The shell does nothing else than LoadSeg(), then starts the loaded program. Execute() does the same - actually, it does exactly the same - it creates a shell, and tells the shell to load its argument and start it.

[copse]

Originally Posted by Thomas Richter

I still don't get it. Here is the solution: Type "Test" on the shell. Done. Do I now win a price for being obvious?

The shell does nothing else than LoadSeg(), then starts the loaded program. Execute() does the same - actually, it does exactly the same - it creates a shell, and tells the shell to load its argument and start it.

I don't think the differentiation or use case this enables has been described. The original post hints there is one and makes a point of saying "the OS already does this" isn't the answer.

Personally, I find the topic interesting even if this hasn't been explained. But it is not uncommon on this forum for people to ask questions and not clearly state their intent and for discussion to proceed onwards happily.

[Photon]

Thank you for answers. o7

Originally Posted by a/b

It's explicitely stated in DOS technical ref manual that BSS hunks are zeroed

I'm stating that that is technically incorrect, but more importantly, is not a requirement to meet the challenge. In other words, the solution may initially do as it wishes, as long as the variables are correctly allocated, and then we can have a look.

Originally Posted by Thomas Richter

I still don't get it. Here is the solution: Type "Test" on the shell. Done. Do I now win a price for being obvious?

The solution is a piece of code in the form of a command that takes the path to the executable file as parameter. This has been made clear several times. The simplest case is the "Start Test" in the post you replied to.

Originally Posted by copse

I don't think the differentiation or use case this enables has been described. The original post hints there is one and makes a point of saying "the OS already does this" isn't the answer.

Personally, I find the topic interesting even if this hasn't been explained. But it is not uncommon on this forum for people to ask questions and not clearly state their intent and for discussion to proceed onwards happily.

The challenge, if anything, is clarified beyond belief: Unfortunately, for a program or a piece of code to load and start an executable, "the OS" doesn't already do this. It's written to requires files outside the ROM Kickstart, and exact behavior depends on Kickstart version, i.e. Amiga model (at least this is currently the case - until proven otherwise by a piece of code).

The goal (for the third or perhaps fourth time) is to do that without those files, hence the provided blank disk with a sample executable. This is the problem to solve, and the solution should start the executable on all Amiga models i.e. Kickstarts.

Assemble or compile your solution, name it Start, put it on the disk, boot it, and type "Start Test". If Test loads and starts correctly, we are somewhere.

[meynaf]

Originally Posted by Thomas Richter

I still don't get it.

Imagine the OP wants to write a library function that will allow running a program from within another, without any external dependency (Execute does not always match this requirement) and working on all OS versions (forget about RunCommand or SystemTagList, which are v36).

[hooverphonique]

Originally Posted by Photon

Test has a CODE section which needs a DATA_C section and a BSS section. It has 48b of reloc in all 3 sections

Reloc in a BSS hunk? As you say, it only contains uninitialized data (or zeroes), so what does that do?

[Thomas Richter]

Originally Posted by meynaf

Imagine the OP wants to write a library function that will allow running a program from within another, without any external dependency (Execute does not always match this requirement) and working on all OS versions (forget about RunCommand or SystemTagList, which are v36).

I'm not quite clear why "Execute()" is not, at least in this particular case. One problem it does have is that you do not get hands on the result code of the command, but that was not requested as functionality. That was probably the only reason why I wrote code for it in the 1.3 times as otherwise "Execute()" works well enough.



What I find a bit ironic is that "writing a library" for this functionality creates an external dependency. (-; Wasn't that to be avoided? Anyhow, please excuse my outburst of irony.


Anyhow, let's suppose you want the return code, and you want to run it under 1.2, and you want to overlay your process with another command, and you also want to run programs with BCPL binding such as those that come in C: of the 1.2 workbench, then the code from Ralph Babel's book is the right start. There is also a similar library function in the Aztec C linker library ("fexec()" is its name), and if that is not enough, I have something similar available in my collection should it be really needed. It boils down to pretty much the same trick Ralph has to offer, so there is nothing extra to be learned. If you know how his code works, you know how mine works, too.



The very short version is try "Execute()", and only for the very rare case that this is not sufficient, look for something else, but please provide some insight why "Execute()" is not enough then. I gave one possible reason.

[alkis]

I'll give you my actual constraints. The code that I uploaded was the heart of a "make" command line tool, that spawns sub-tools for the compilation. So, yeah, result code was important.

Also, self-imposed limitation, should work (1.3-3.1) on just a bootable floppy with no c: (why distribute commodore copyrighted code when you can avoid it).

[Photon]

BSS symbols addresses must still be relocated, Execute() requires C:Run on 1.3, and yes.

I had a little time now. I've started from scratch and gave LoadSeg a fixed string for now, and gave jsr 4(a3) a copy of the entry registers. This works and I can ponder what else I should fix to make it proper. I already do folder navigation and stuff in another part of the program I'll plug this into, so I don't need that.

I guess the jsr 4(a3) needs the same stuff you get on CLI program entry, but I haven't seen it documented exactly. a2/a5/a6 comes from an offset in dosbase, and maybe some process / CLI struct. And a stack. But I'll avoid fixed-size stackframes as in System0.

Have a good one. Gn o/

[meynaf]

Originally Posted by Thomas Richter

I'm not quite clear why "Execute()" is not, at least in this particular case. One problem it does have is that you do not get hands on the result code of the command, but that was not requested as functionality. That was probably the only reason why I wrote code for it in the 1.3 times as otherwise "Execute()" works well enough.

Execute may need the Run command, that's the sole reason.
So yes, it's normally perfectly able to do the requested job, but not on all OS versions that are the target.

Originally Posted by Thomas Richter

What I find a bit ironic is that "writing a library" for this functionality creates an external dependency. (-; Wasn't that to be avoided? Anyhow, please excuse my outburst of irony.

That depends what kind of library this is. If it's included with an include directive, it is no longer an external dependency.

Originally Posted by Thomas Richter

The very short version is try "Execute()", and only for the very rare case that this is not sufficient, look for something else, but please provide some insight why "Execute()" is not enough then. I gave one possible reason.

Same as above. Run command under 1.x, that's all.

Originally Posted by Photon

I had a little time now. I've started from scratch and gave LoadSeg a fixed string for now, and gave jsr 4(a3) a copy of the entry registers. This works and I can ponder what else I should fix to make it proper. I already do folder navigation and stuff in another part of the program I'll plug this into, so I don't need that.

You may eventually have issues with self detaching programs. This has to be checked (or, in general, anything that would not work with a debugger).
Else the only thing i see is programs using parameters. As the name of the program is itself in the parameters you have to properly "eat" it.

[Thomas Richter]

Originally Posted by Photon

I guess the jsr 4(a3) needs the same stuff you get on CLI program entry, but I haven't seen it documented exactly.

It depends what you want. If you look into my AmigaDOS documentation, you find there what is required *by today*. Loading a0/d0 with the arguments is *not* sufficient (see there, in the chapter on RunCommand). The arguments are in three places: The registers, in the process structure, and in the buffer of the input file handle.


That is *not* yet everything you need to do for BCPL which has additional requirements, and those are highly obsolete and it makes little sense to document this nonsense anymore.

[Thomas Richter]

Originally Posted by meynaf

Execute may need the Run command, that's the sole reason.

Why is that a reason? Actually, it is good enough for everything else in 1.3, so why make an exception here? The 1.3 SetPatch relaxes this requirement by only requiring that "Run" is resident, which is easy to arrange. Thus, you do not have to swap disks in order to be able to Execute().

Originally Posted by meynaf

You may eventually have issues with self detaching programs. This has to be checked (or, in general, anything that would not work with a debugger).

That goes mostly for unloading programs and checking the segment in the cli structure. Again, Execute() or System() solve that problem.

[meynaf]

Originally Posted by Thomas Richter

Why is that a reason? Actually, it is good enough for everything else in 1.3, so why make an exception here? The 1.3 SetPatch relaxes this requirement by only requiring that "Run" is resident, which is easy to arrange. Thus, you do not have to swap disks in order to be able to Execute().

OP said the goal is to not require files from any WB disk or any existing WB installation. Requiring Run or SetPatch goes against that goal (assuming nothing has to be required at all, not only at the time we run the actual program).

Originally Posted by Thomas Richter

That goes mostly for unloading programs and checking the segment in the cli structure. Again, Execute() or System() solve that problem.

Yes they do solve that problem, but they don't match the OP's goal.

[Photon]

Originally Posted by Thomas Richter

It depends what you want. If you look into my AmigaDOS documentation, you find there what is required *by today*. Loading a0/d0 with the arguments is *not* sufficient (see there, in the chapter on RunCommand). The arguments are in three places: The registers, in the process structure, and in the buffer of the input file handle.


That is *not* yet everything you need to do for BCPL which has additional requirements, and those are highly obsolete and it makes little sense to document this nonsense anymore.

If you actively want to discourage supporting KS1.3 and BCPL, please state this outright.

For this challenge, scatter-loading the object file into memory is the first step, and correct execution of the code the second step.

What is needed currently is the register contents relied upon under KS1.3-3.1, if a CLI command is chosen as the executable. From those register contents, the resources you must create that they point to. And then hopefully done