Hyperion Entertainment Message Boards

Posted: **Thu May 30, 2013 1:17 am**

Belxjander wrote:I'm aware of LoadSeg NewLoadSeg and InternalLoadSeg for 68K
Other than the LoadSeg documented in the Autofocus for DPS.library I have not seen other vectors...

Have a look at the; interfaces/dos.h file, there are 6 different loadseg vectors that can be called.

Excluding 68K loadables with OBSOLETEInternalLoadSeg(), you can reduce that to about 5 slots;
OBSOLETENewLoadSeg(), OBSOLETENewLoadSegTagList(), OBSOLETENewLoadSegTags(), OBSOLETELoadSeg(), LoadSeg()
Until dos.library 53.74 most of those were duplicate code and needed to be patches separately.

After 53.74, the OBSOLETENewLoadSegTags functions calls the OBSOLETENewLoadSegTagList function internally,
and those stubs now just call LoadSeg(), and if it is not an overlay hunk loadables, which calls OBSOLETELoadSeg(),
it will now call LoadSeg().

So, you really need to do version checks.

Posted: **Thu May 30, 2013 3:10 am**

@ColinW:

So in effect the majority of entrypoints now rely specifically on the "LoadSeg()" method of the DOS.Library main interface?

Just those comments alone I am thankful for... as I was intending to try and patch the bare minimum required.

@ThomasRapp: in your example

Code: Select all

/*----------------------------------------------------------------------------*/
/* New LoadSeg routine                                                        */
/*----------------------------------------------------------------------------*/

	BPTR newLoadSeg (struct DOSIFace *Self, CONST_STRPTR name)

	{
	// call original routine
	BPTR result = oldLoadSeg (Self,name);

	// send result as message to the main program
	send_msg (name,result);

	return (result);
	}

mostly differs from my own in the use of message passing...

Code: Select all

/*
	WARNING!!! RUNNING FROM dos.library/LoadSeg() CONTEXT!!! WARNING!!!
*/
BPTR LCALL_LoadSegVMM(struct DOSIFace *Self,CONST_STRPTR Name)
{
	BPTR rc=NULL;
	rc=XCALL_LoadSegDOS(Self,Name);
	return(rc);
}

yet my code... has some kind of self-calling setup happening... THAT is what I want to work out so that I can stop it...

This is driving me nuts...

Posted: **Thu May 30, 2013 8:34 am**

Your code looks like it is used in a library (using SelfBase and so on). You know that to run a new version of your library you first have to expunge the old copy from memory? Usually closing all programs using the lib and then entering avail flush is sufficient, but to be really sure to use the new version you should reboot. Otherwise you are always testing the same old version, no matter how often you recompile.

Edit: here is a completed example which uses exactly your code: http://thomas-rapp.homepage.t-online.de ... r_filter.c
And it works. So the problem is not in the code you published but elsewhere.

Posted: **Thu May 30, 2013 9:24 am**

@ThomasRapp: full reset of the machine every test.

If it is a failure elsewhere and that code is working properly then I need to look at shifting it into the process I embedded into the Library

I wonder if it is due the ramlib special context and opening DOS.library there?

I'll try again tonight

From the embedded "Polymorph-VMM" context... I make a different error... however... THIS IS NOW SOLVED...

Thank you all for your help in clarifying the problem.

Hyperion Entertainment Message Boards

[SOLVED] Method patch example request...ideas?

Re: Method patch example request...ideas?

Re: Method patch example request...ideas?

Re: Method patch example request...ideas?

[SOLVED] Method patch example request