startup directory

[radad]

Various demos and other progs that I have tried to use make an assumption about where to load the rest of the stuff from. ie irx files, images, or config files. They usually attempt to load from the host or from cd (and sometimes the hard drive).

What I would like to propose is that these softwares load these files from the same directory as the elf itself was loaded from. The arg[0] given in main will tell you the full name of the elf file including the directory and device it was loaded from. At least this occurs with the tests I have run. Maybe this wasn't always the case or maybe it depends on the loader you use.

Admittedly it is up to each individual author how this works for their program. I just wanted to put the idea out there. So what do you think of it? Will it work?

[Drakonite]

Most recent stuff grabs from where it was loaded from already. TTC requires it be able to load from host: so there is a bit of a standard right there ;)

[cheriff]

And for older stuff, I guess you can hexedit things from cdrom: to host: if need be.
I think i did that once or twice to get a demo to play....

[blackdroid]

What I would like to propose is that these softwares load these files from the same directory as the elf itself was loaded from. The arg[0] given in main will tell you the full name of the elf file including the directory and device it was loaded from. At least this occurs with the tests I have run. Maybe this wasn't always the case or maybe it depends on the loader you use.

Indeed argv has not always been around, as far as I remember it was introduced in one of the latest pukklink releases, as far as I know naplink does not support argv. so its abit out in the open really. The thing is you can always try to find on cdrom, if that fails try from host. and so on, as a rule TTC has always wanted demos to load their bloat from host: ( not host:/ wich some have, and imho is bad practice ).

[dlanor]

I may be somewhat of a newb at PS2 coding, but not at coding in general, and so I know that while use of 'host:' may possibly be better established than argv usage on the PS2, this is certainly not true for C programming on other platforms. Surely it would be better to follow common standards.

Don't misunderstand me here. I have nothing against the use of the 'host:' device as such. It is a fine way of getting access to files adjacent to a program launched from a PC. What I have something against is only the use of that device by default, making it hard to use the same program in a different context.

I've seen comments to the effect that some program launchers don't init the stack properly for argv[0] to work right (true/false ? which ?). But if that is the case, isn't that what we need to change first, rather than introducing PS2-specific methods where such are NOT needed ? (Introducing such methods where they ARE needed would be different, of course, and perfectly fine by me.)

I realize that it may be hard to enforce standard usage 'after the fact', if a lot of software exists which lack that implementation, but that can be solved by making some extra 'wrapper' programs which could be used to link such an old-fashioned launcher to a newer program, such that the new program sees an argv-compatible stack though the old launcher didn't create it directly, relying on a wrapper program to do that.

Of course, that would only be an interim solution, until all (or most anyway) of those old launchers can be replaced. The gain from this temporary solution would be that we could already switch to the generic methods for our main programs, and still secure proper functioning with present launchers by use of the extra wrapper programs.

Best regards: dlanor

[Drakonite]

I may be somewhat of a newb at PS2 coding, but not at coding in general, and so I know that while use of 'host:' may possibly be better established than argv usage on the PS2, this is certainly not true for C programming on other platforms. Surely it would be better to follow common standards.

Don't misunderstand me here. I have nothing against the use of the 'host:' device as such. It is a fine way of getting access to files adjacent to a program launched from a PC. What I have something against is only the use of that device by default, making it hard to use the same program in a different context.

I've seen comments to the effect that some program launchers don't init the stack properly for argv[0] to work right (true/false ? which ?). But if that is the case, isn't that what we need to change first, rather than introducing PS2-specific methods where such are NOT needed ? (Introducing such methods where they ARE needed would be different, of course, and perfectly fine by me.)

I realize that it may be hard to enforce standard usage 'after the fact', if a lot of software exists which lack that implementation, but that can be solved by making some extra 'wrapper' programs which could be used to link such an old-fashioned launcher to a newer program, such that the new program sees an argv-compatible stack though the old launcher didn't create it directly, relying on a wrapper program to do that.

Of course, that would only be an interim solution, until all (or most anyway) of those old launchers can be replaced. The gain from this temporary solution would be that we could already switch to the generic methods for our main programs, and still secure proper functioning with present launchers by use of the extra wrapper programs.

Best regards: dlanor

Your rant is worthless as it's already been said that the reason the old software doesn't use argv[0] is because at the time that didn't exist. New stuff almost always uses argv[0] now.
And for the record, there IS a program to fake host:, called fakehost oddly enough, which allows elf's to be loaded and read from the HDD as though it was host. It could be modified to use cdrom fairly easily I would assume. And btw, the fakehost functionality is builtin to ps2menu, and I would assume altimit as well.

[dlanor]

Your rant is worthless as it's already been said that the reason the old software doesn't use argv[0] is because at the time that didn't exist.

You may of course regard it a rant if you like, but it was in fact intended as a serious proposal.

New stuff almost always uses argv[0] now.

That in itself is good, of course, but I believe that there are issues with some of the launchers (at least so I've been told), such that programs which use argv[0] can't always evaluate it correctly, due to the launcher. This was the kind of issue I wanted to address. Perhaps I did so clumsily, and perhaps my info is wrong, but I don't see how that makes my post a rant.

And for the record, there IS a program to fake host:, called fakehost oddly enough, which allows elf's to be loaded and read from the HDD as though it was host. It could be modified to use cdrom fairly easily I would assume. And btw, the fakehost functionality is builtin to ps2menu, and I would assume altimit as well.

This 'fakehost' method (though quite interesting) is not at all what I had in mind, since it assumes programs to be written for host: file access which it then redirects. My proposal was for the opposite approach, providing a wrapper program to allow all main programs to use argv[0].

Maybe it was a bad idea. I'll let others be the judge of that. But if it is to be dismissed as such, it should not be due to being misunderstood.

Best regards: dlanor

[cheriff]

Once upon a time, wasn't it possible to differentiate between different launchers by their lack of argv/argc support.
eg: none -> some launcher
filename only -> some other launcher
path and filename -> well, read the path.

I'm pretty sure I've seen some stuff using this approach to know whether to load stuff from host cdrom, mc, etc.

And while we're on the subject of fakehost, Would it be possible to make it generic, redirecting between arbitary devices..?
So an iso-only demo could be run (after mounting the iso somewhere)
$ ps2client execiop redirect.irx cdrom host
$ ps2client execee host:demo.elf
That would have saved me half an hour of hacking someone else's elf just today!

[Drakonite]

My proposal was for the opposite approach, providing a wrapper program to allow all main programs to use argv[0].

Maybe it was a bad idea. I'll let others be the judge of that. But if it is to be dismissed as such, it should not be due to being misunderstood.

Best regards: dlanor

Bad idea would assume it was possible. Creating a generic method of intercepting all of a programs file calls and magically figuring out how to redirect it to argv[0] and managing to keep the same file tree intact... I'm done now.

[dlanor]

Bad idea would assume it was possible. Creating a generic method of intercepting all of a programs file calls and magically figuring out how to redirect it to argv[0] and managing to keep the same file tree intact... I'm done now.

This argument is pointless, as you keep mentioning things I never suggested, and because of those things reject what I did say.

I never suggested any form of redirection whatsoever.
You are the one who chose to interpret what I said that way.
All I suggested was a wrapper to clean up the way some launchers init the parameters and other parts of the environment for programs they launch.

Since it's not leading anywhere I won't post anymore in this thread.
Best regards: dlanor

[Drakonite]

You made no sense, so don't be mad at me for not understanding what you were saying.

Perhaps the best option is for you to write it so we can all see what you are talking about?

[niknpm]

All I suggested was a wrapper to clean up the way some launchers init the parameters and other parts of the environment for programs they launch.

Well if you're on about wrapper written within the client side sendors then this is pointless, as the main sendors that are used already support argv[]'s the ones that don't you haven't got access to source to modify anyway, namely naplink. So you're kinda stuck, unless you create an elf which contains all argv[]'s and then inturn perform an exec elf from the PS2.

Same goes for the ps2 lauchers, the only real two that are used PS2link and Naplink, of which only the source for PS2link is available, other launchers tend to be obsolete but some people still use them although not supported, so if you feel anything that should be changed on PS2Link, the code is on CVS.

Like other people have said, it's not clear what you mean by 'wrappers', but this is how I intepret it.