Get WB params without using main() ?

Is it possible to get your program's Workbench-supplied parameters withOUT reading them from main(int argc, char** argv) ?

It depends on what you want to do instead. If your program does not have a main() routine, then you need to handle the wb startup message on your own anyway.

With a main() routine, some compilers offer an external global variable called _WBStartup or something similar.

But the most common way is to check if argc == 0 and then use ((struct WBStartup *)argv).

Edit: example startup code if you link your program without the C runtime (i.e. if you don't have a main() routine): http://eab.abime.net/showpost.php?p=664723&postcount=18
and a similar example in Asm: http://eab.abime.net/showpost.php?p=671760&postcount=22

@thomas
The program has a main(), but I cannot access it. I can't access it's global variables either!

As you can see in the example code I've edited into my above post, the Workbech parameters are sent to your process' message port. The startup code fetches the message and stores it into argv and/or _WBStartup. If you don't have access to either, then it's lost.

@thomas
OK, thanks! At least I know this is 'impossible' now. I had thought about trying to directly read it off the stack, but that doesn't seem a very easy or reliable thing to do...

Have a look at the include file; dos/startup.h
It shows how to start a basic dos process up without c-lib
startup code or argument parsing.

Using the workbench message you can fetch the arguments
by using; wb_msg->sm_NumArgs and wb_msg->sm_ArgList to
walk through the struct WBArg * array arguments and using wa->wa_Name to get the (icon.library) diskobject; dobj = iicon->GetDiskObject( wa->wa_Name );
Then you can use iicon->FindToolType() to fetch the individual tooltype strings you require.

Look around for some example code.

@colinw: you didn't even understand the problem, did you?

@Thomas
Quote:
Maybe that's because the problem, as stated, makes no sense. How could a program have a normal main() but not have access to the arguments or global variables? Maybe I'm dumb but to me having a main() implies standard startup code with arguments accessible. Otherwise you can have custom startup code as Colin has suggested. Am I missing something here?

@Thomas. Colin appears to have answered the question as asked, (as did you) however Chris is doing something very odd if he can't access main.

@ChrisH: You might get more useful help if you say what you are doing.

Quote:

I cannot imagine that too. But IMHO that's no reason to give an answer which has no relation to the question. Why didn't you simply ask him "how can that be"?

maybe he is loading it dynamically. But i'm doing only some assumptions..

@thomas:

colinw´s answer made perfect sense as an answer to ChrisH´s initial question. Like your first answer. And with more details than yours. So, wheres the problem?

@ChrisH:

broadblues hit the nail

The unability to access even global variables is shown by which evidence? gcc error message? Crash?

@all
I didn't imagine such a simple question would generate so much controversy & so many questions! The simple answer is that I am patching some AmigaOS functions called by another program, and I wanted to find out what WB arguments were passed to that program.

With Shell arguments this is easy (just use FindTask(NULL) to access the program's Task structure), but sadly nothing like this seems possible for WB arguments.

Hope this solves the mystery

@ChrisH:

Well, the first question you made here wasnt a mystery at all. thomas´ and colinw´s first answers were the solution to this. This solution should work in any normal case.

The mystery started when you stated that you´re unable to access main() and/or global variables

Your explanation is a bit confusing... you want to get the WBArgs of your patch program (FindTask(NULL))or the WBArgs of a foreign task, running already? In the first case, use thomas´ and colinw´s solution. Simple as that (and it works until you do something really weird within your startup code or use a very weird compiler).

In the second case its not so easy...

@whose
Not sure how it is possible to misunderstand what I wrote , but it is "the second case".

Quote:
The first question actually stated "withOUT reading them from main(...)".

Okay so you have program A launched by workbench, and then program B needs to find out what program A args are?

I'm guessing then you have neither a debug version of program A or it's source?

But program A was launched from workbench by you, so you know what args you called it with. So contrive in some way to call program B with the same args. Or even get program B to start program A via system or something?

Why are you trying to patch AmigaOS functions? Sounds very dangerous (unless you are trying workout how they are being called maybe, as some kind of reverse engineer, not a runtime hack...)

You've only succeded in deepening the mystery

Quote:

Easy... FindTask(NULL) gives back the pointer to the task control block of the calling task (here: program A, the patching one).

If you want to get the task control block pointer of a foreign task (program B, the one calling the patched functions), you have to supply a task identifier (the task name) in order to give FindTask() a chance to work properly

Thats why it was very confusing. You tried to find your own task, and then it should have been as easy as nothing to use the solution mentioned by thomas/colinw

Back to topic: I dont think that there is a very simple solution to trace back the task who is calling a patched OS function, and its even more complicated to get more information about this tasks internals (like globals and function entry points). Lots of register ping pong and stack backtrace, not to mention segments, relocation/symbol tables etc. etc.

Finding the calling task should be the easiest part, as there is a global task list. IIRC it contains all information necessary to find out, which task "owns" a certain address (the callers return address on the stack).

With this information, you should be able to find the tasks task control block pointer and over there the contents of the WBStartup message, including WBArgs.

Edit: I could imagine that this is the way FindTask(NULL) works internally. Backtracing the callers return address, found on the stack.

Obviously this couldnt work from within library functions (even patched ones), as FindTask(NULL) would find a return address belonging to the library´s code segment, which is not registered with the global task list. FindTask(NULL) should return an error indication then.

Quote:

Snooping into the args passed to a different program sounds like a very risky and dodgy thing to do. I sincerely hope that this is for personal use only, because it's just asking for trouble.

Hans

@whose Quote:
I am afraid you misunderstood me AGAIN (or I misunderstood you this time...). What I want to do is exactly the opposite of what you state and it appears to be not possible.

I don't actually care about the Task Control Block at all, it was merely an example of how program A reading (CLI) arguments of "program B" *is* possible. But the same feat is not possible for WB arguments.

@Hans
Since I am *not* doing any "argument snooping" by patching (it's simply not possible) you don't have to worry!

@broadblues Quote:
It is not dangerous at all. In fact it was very common thing to do for AmigaOS 3.x & earlier. (Sure, at least some of those patches caused problems, but that's generally because the people doing it were not very careful & didn't know the right way to do it.)

RunInUAE patches AmigaOS4 without any problems...

@ChrisH:

No problem... in the essence we had the same thoughts (finally ). Reading CLI/WB parameters of one task by another task.

But with the task control block I gave you a hint where to find the corresponding WBArgs you search for. For OS3.x systems it IS possible to fetch those arguments, but it is NOT easy to do so. You have to dig deep into structures of the OS for this. Somewhere in the dark depths of the system you will find the WBStartup message, which was send to the corresponding task when it was loaded.

Some examples how to get more internal information of a foreign task you could find in e.g. the DICE source code (aminet). Those nasty little old debuggers often worked the way you want, including library function patching

Hans stated the important already: It is very dangerous to do such things, and not very compatible, too.