LoadModule vs LoadResident

[Oldsmobile_Mike]

If it is already present, it is already present. Delete intuition.library from LIBS: and off you go. Renaming is, as said, not necessary and does not even help.

So that I understand correctly, it's still looking in the LIBS: directory (at the old copy there), even though I'm explicitly telling it to load the modules from SYS:/ResidentModules/#?  ?

[guest11527]

So that I understand correctly, it's still looking in the LIBS: directory

No, Mike. It's in your ROM. I yet have to see an Amiga that comes without intuition in ROM. (-;

[Oldsmobile_Mike]

No, Mike. It's in your ROM. I yet have to see an Amiga that comes without intuition in ROM. (-;

Then why is LoadModule SYS:/ResidentModules/#?  failing to replace it?

But when I write the command as "LoadModule Libs:Intuition.library"  it works fine?

What I'm saying is, everything works fine. I just have huge and unwieldy long lines full of "LoadResident" and "LoadModule" commands in my Startup-Sequence. They're so long, in fact, that I can't add anything else to them. I hit the limits of character spacing in Ed, even.

I'm replacing just about every component in the ROM through these long and unwieldy statements and am trying to simplify by dumping all my modified libraries/devs/handlers all into one directory and just saying "Hey, LoadModule, just load everything in this directory" where I'm struggling. :confused:


Yeah yeah, one of these days I'll just break down and get the equipment to burn my own ROM's. :rofl:

[guest11527]

Then why is LoadModule SYS:/ResidentModules/#?  failing to replace it?

See above: You have already a V40 in ROM. You cannot replace a V40 in ROM with a V40 from disk, *UNLESS* you also specify "DOWNGRADE". You can replace V40 from ROM with V42 from disk if you would have it.

But when I write the command as "LoadModule Libs:Intuition.library"  it works fine?

No. It doesn't make a freaking difference. The matter *how* you load the modules does not matter. With AUTO, without AUTO, manually, with or without wildcards, all irrelevant. Once again:

You cannot replace a module in ROM with a module from disk if the latter has a version number lower or equal than the version that is already there. Already there = it is in the ROM of your machine.

It is really *that* simple. Exec resident modules work this way. There is no check for the revision. There is only a check for the version. If the version from ROM is newer or equal, LoadModule and also exec takes the version from ROM.

If you want to override this, add "DOWNGRADE". But then don't come back to me and tell me that your system became unstable. It's then your problem.

[Pat the Cat]

See above: You have already a V40 in ROM. You cannot replace a V40 in ROM with a V40 from disk, *UNLESS* you also specify "DOWNGRADE". You can replace V40 from ROM with V42 from disk if you would have it.

I think that's where a lot of us have been screwing up. That is what gives the user the control back, if they want to take the responsibility. I'm guilty of not knowing that.

Things are pretty much set to encourage using later versions of modules, but you don't HAVE to. If you do start doing that though, you might break bits other parts of the OS. Much more likely if you are downgrading to earlier resources (V number does not always tell the whole story here).

Which is fair enough, developers are encouraged to write new versions which address issues with the module. Not patch things up so that older software, which the developer might not have to test with. If the older software follows the rules, it should work anyway with an updated resource.

[Oldsmobile_Mike]

See above: You have already a V40 in ROM. You cannot replace a V40 in ROM with a V40 from disk, *UNLESS* you also specify "DOWNGRADE". You can replace V40 from ROM with V42 from disk if you would have it.

It's not a downgrade.  It's intuition.library version 40.86b7 from here, that was discussed "to death" way back in this thread.  Version in ROM is 40.85.  But I think I get it, now.  This goes back to something mentioned in one of the previous threads on this subject - that unless you specify the file directly, AUTO only reads the major version number (40) and not the full "40.86".  This is just an example, though - it's doing the same thing with all the libraries (like in Kolla's case, it was trackdisk.device).  Now I think I understand.

Ah well, so wildcards don't work, and AUTO doesn't work (with my particular requirements, anyway)... guess I'll keep doing it the "old fashion" way.  Thanks!  

If you want to override this, add "DOWNGRADE". But then don't come back to me and tell me that your system became unstable. It's then your problem.

Hey now, no need to get snippy.  From a layman's perspective I had assumed what I was trying to do was pretty simple: automatically load an entire directory full of replacement libraries, devs, and handlers, instead of having to spell out each one in the Startup-Sequence.  Didn't realize it would be so difficult, lol.    Thanks for your help, cheers!

[paul1981]

Have you tried wildcards to load all of them from your directory plus the DOWNGRADE option on the end as Thomas said? If he says it should work then it ought to.

[kolla]

Building custom kickstarts and softkicking is just so much easier, lol. Sadly, I have yet to find a softkicker that works with the SX32 and/or the Apollo-630, so there I have to use LoadModule. For the A600, it seems that all modules are loaded to chipram :p

[guest11527]

It's not a downgrade.  It's intuition.library version 40.86b7 from here

So it's a downgrade. How often do I need to say this again: *IF* you want to replace a ROM module with a disk module of the same or a lower release, you need to specify DOWNGRADE.

There is no discussion here. This is the way it is. There is no official 40.xxx something, and if there would be a new version of intuition, it would have a version number of 41 or above. It is *really* that simple.

This goes back to something mentioned in one of the previous threads on this subject - that unless you specify the file directly, AUTO only reads the major version number (40) and not the full "40.86".  

NO, NO, NO, and NO again. AUTO does not read version numbers. Version numbers are completely *UNRELATED* how you specify the file.

What is so complicated reading the specs. There are two very simple things here:

a) the file MUST be named like the module inside. The module is "intuition.library", so the file must be named "intuition.library".

b) if the version number of the module in the file is below or equal to the version number in ROM, you MUST specify DOWNGRADE.

Ah well, so wildcards don't work, and AUTO doesn't work (with my particular requirements, anyway)... guess I'll keep doing it the "old fashion" way.  Thanks!  

AUTO does work, and wildcards also *DO WORK*. Just name the thing correctly, and use proper versions. YES, I DID TEST THIS.

Hey now, no need to get snippy.

At some point, enough is enough. I explained multiple times. I wrote a spec, I provided examples. If you still do not read them, and instead invent any other "explanation", I really do not see how I can possibly help you.

 From a layman's perspective I had assumed what I was trying to do was pretty simple: automatically load an entire directory full of replacement libraries, devs, and handlers, instead of having to spell out each one in the Startup-Sequence.  Didn't realize it would be so difficult, lol.    Thanks for your help, cheers!

And exactly that works. Put all the replacement stuff in one directory, then run

Code: [Select]

LoadModule mydirectory/#?
YES, IT IS REALLY THAT SIMPLE.

And once again, if you want to use any hacked up versions that conflict with the versions in ROM, and do not advance the version number, this becomes

Code: [Select]

LoadModule mydirectory/#? DOWNGRADE

And once again, the file names must match the module names. Thus, the thing needs to be named "intuition.library" and not something else. In particular, *NOT "intuition_blablabla.library".

If you look into LIBS:, then the "mathieeedoubbas.library" is also named "mathieeedoubbas.library" and not "mathieeedoubbas_v45.library". It is the very same simple principle. Don't tell me that things "don't work" if you still do not read *carefully* what I have written.

[guest11527]

Building custom kickstarts and softkicking is just so much easier, lol.

Not for people that don't read instructions. It's the same problem all over.

For the A600, it seems that all modules are loaded to chipram :p

If that's the only memory that is MEMF_KICK, then that's the way it is.

[Minuous]

There is no check for the revision.

Why is this? Eg. V45.1 is of course an upgrade compared to V45.0, but would be considered incorrectly to be a downgrade by LoadModule.

[Pat the Cat]

Why is this? Eg. V45.1 is of course an upgrade compared to V45.0, but would be considered incorrectly to be a downgrade by LoadModule.

It's always a downgrade if it's the same broad version, because it is ALIEN to the release the system is currently using. That might be the release on the ROM, it might not. The system just cannot tell from the V number.

The replacement might work well, it might not, but it forces the user to think about these issues. The system can't tell really, but assumes new V whole numbers are genuine upgrades.

I figured there had to be some way for manual selection of libraries, but I couldn't find a definite "this is correct" method.

Thank you ThoR. I did not post that earlier, I am truly grateful.

Please, don't be too harsh on Mike, it's mostly my (garbled) recollections that led to the issue being discussed.

I set you on a wild goose chase Mike - but at least there WAS a goose at the end. Sorry for the amount of confusion raised, but at least we did get a definite solution.

[guest11527]

Why is this? Eg. V45.1 is of course an upgrade compared to V45.0, but would be considered incorrectly to be a downgrade by LoadModule.

I haven't designed "struct Resident" and the resident system of exec. That's the way it is. There is no "revision" information in the resident structure, only a version information:

Code: [Select]

struct Resident {
    UWORD rt_MatchWord; /* word to match on (ILLEGAL)   */
    struct Resident *rt_MatchTag; /* pointer to the above       */
    APTR  rt_EndSkip;           /* address to continue scan     */
    UBYTE rt_Flags;             /* various tag flags            */
    UBYTE rt_Version;           /* release version number       */
    UBYTE rt_Type;              /* type of module (NT_XXXXXX)   */
    BYTE  rt_Pri;               /* initialization priority */
    char  *rt_Name;             /* pointer to node name */
    char  *rt_IdString; /* pointer to identification string */
    APTR  rt_Init;              /* pointer to init code */
};

The system - exec and LoadModule - cannot and does not possibly distinguish between a 45.1 and a 45.2.

Thus, whether you replace a 45.3 by a 45.10 or a 45.1 looks all the same to LoadModule, and to exec, and to all the rest. Thus, without a check, you could replace a 45.3 by a 45.1, and that's not desired. You could also replace the ROM version with an older version, and that's not desired either.

"DOWNGRADE" is the "yes, I really know what I'm doing" switch, and tells LoadModule not to worry about versions. It cannot tell anything about revisions.

[guest11527]

If that's the only memory that is MEMF_KICK, then that's the way it is.

There is, BTW, a switch "NOMEMFKICK" to try "MEMF_PUBLIC", i.e. generic memory for the modules. I do not know whether this works on your machine, it is really a matter of how the memory is added to the exec memory list. I afraid you just need to try it....

[Oldsmobile_Mike]

"DOWNGRADE" is the "yes, I really know what I'm doing" switch

I think what's confusing to a layman is the name "downgrade".

Thanks for the help, guys. Like I said before, all of my custom modules work fine when I load them the old fashion way. Will just keep on doing it like that, lol. :lol:

[Pat the Cat]

This could partially explain why CBM or anybody else really were not in a hurry to release new versions. It's only one byte, you can't go higher than V255. But, what could be done maybe, with the LOADMODLUE issue, is for the command to scan the file name it is loading, and maybe add a query with a toggle off you had to set, to prompt the user. That's a lot more complex and less elegant really.

I think the way it is implemented is OK. It does the job, AND it really does make you, the end user, take responsibility for what you are doing.