LoadModule vs LoadResident

[Pat the Cat]

I'm trying to figure out something dumb and this is a piece of the puzzle.  What, exactly, is the difference between the LoadResident command and the LoadModule command?

(besides that LoadModule seems to be newer and have more features)

Are there certain modules/libraries/etc. that can only be loaded with one or the other?  Is one more "reset-proof" than the other?  From what I've seen they seem to be pretty interchangeable...

I think LoadResident started more as a way to have a resource kept handy by the OS, rather than loading it from disk. C commands, executables that were going to be used a lot. Helped a lot with a using a floppy system sometimes, if you didn't have to load the resource repeatedly. Also true of other things, but not so good for selecting a different age or version of system module, like a different version of device, handler, library etc. IIRC you had to get everything in place before the magic "binddrivers" command in a WB 1.3 startup system. After that point, you were kind of locked in to what you had setup previously. Not for executables, but for system modules.

LoadModule uses more "joined up thinking" in the matter, lets you change things like exec.library, maybe. Things that LoadResident could not handle.

That could be why some stuff works on both, some you have to use one or the other for, to get correct operation. LoadResident was good, but it was not fool proof in the early days. I think LoadModule is what you should mostly use for 2.0 onwards really. The delayed release of 2.0 caused a lot of issues in the matter. Certainly it did for me.

Confused the hell out of me at the time. I was trying to answer the phone in one hand while asking questions over the phone in the other hand, and usually both receiving and transmitting the wrong information. Developers in theory were better informed, but they were not paying money to answer "casual questions" from non-developers, even if they were friendly enough to chat.

[Pat the Cat]

Looks pretty good. Not sure why you are doing a Version >NIL, but making Assign resident is a very smart thing to do, any Amiga age. PATH was good for making resident too, you wanted multiple paths to look for things that might be in different places.

I kind of remember 1.3 so vividly because it was always a big deal, getting things setup before the drivers got bound, on a bootable disk release. You could put the lines after that, but your LoadWB might not activitate properly unless things were set "just so" prior to that. Binddrivers was like a "glue in place" action.

WB 2.0 onwards was much nicer for that sort of thing, you might get error messages, but at least the system would startup, in some form or other. Getting a "LoadWB failed" error code and a DOS prompt was not a trivial thing, it meant I had screwed up massively somewhere already. L handler, Dev or library, setpatch, etc. Something was setup wrong.

I guess having an ENV folder was a key concept change. You wanted to tailor an environment, just use that properly. Nice idea, didn't always work, but it was a clear direction rather than a mess of spaghetti.

You could have your regular libs, devs etc in the "correct" place, and put any upgrades or downgrades in ENV and use that module instead. Saved a lot of deleting, copying, renaming stuff. Maybe that was the whole point of ENV. Most people didn't really use it, but they might have if somebody had oversight and direction of the issues.

[Pat the Cat]

Hmmm... depends on the syntax of the command. It might be OK with wildcards, after a CD. It's been too long since I used Amiga wildcards, but in theory they work with most commands.

CD Fullpath/Newmodules/
Loadmodule *.* AUTO

That way you can keep all the new stuff in a separate folder, but don't forget to CD back to SYS:S or have PATHs all lined up. Else the system might get a bit lost about locating and running the next line of startup-sequence. Unlikely, but it does no harm to be "correct as you can".

Sometimes is is helpful for system changes to be reported, and you can redirect that output into a logfile somewhere, rather than output the messages to NEWCON: or the starting shell window or whatever.

Paths are a double edged sword. While they help with getting the system to find the right pieces, they do also add a bit of overhead, and can confuse things mightily if you have multiple HDF images stored and PATH'd out. Use wisely, it's not a shotgun really.

[Pat the Cat]

Hummm.  Trying the above (including renaming the files and using *.* wildcards) but keep getting various "object is not of the required type" and "already resident - object already exists" errors.

Will keep poking at it.  Not a huge priority, just had a few minutes of free time tonight and thought maybe I'd get lucky...

Well, might be the intiial CD. Commands like that are very sensitive to what they're pointing at, and exactly where the system is looking, when they are run. Unless the new module replaces an existing module just right, I would expect some errors. Maybe they have to happen in a certain order? Hmmm... L handlers, Dev devices, Lib Libraries. It depends how dependent the new ones are on each other? That would make sense. If a device needs a library, you have to make the library available first. Likewise, if an device needs a handler, you need the handler first?

It's a puzzle trying to work out the priority, but there  should be  a pretty simple concept behind that.  Can't work it out now.

Yes, the AUTO flag of new LoadModule will look in  certain paths for certain filenames, it is all very detailed described  in the documentation. Only thing not described so well is which modules  it will look for automatically.

"*.*" is wrong platform, what you would want is "#?.#?".

Whatever. A wildcard is pretty much the same basic concept, but the way it's handled is kind of unique to each platform.

So I guess maybe wildcards with paths and assigns, or you really do have to put things in the right place... nah, that doesn't make sense, you don't have an AUTO option unless there's a manual option too, somehow. Manual you retain control, automatic could do any kind of system without you being aware of what's really happening,

[Pat the Cat]

I think the order it all happen is pretty important, but the logical choice is - alphabetical order. Think of Exec as managing fast food deliveries around a town called Amiga.

First, exec needs to know about any changes to customers and supplier. That's the devices. A device on the Amiga is like a map reference, giving bus size of data (portion size), also things like rate of production, and finally a map of controls. So a device is kind of like an entry in an businessman's card index - it doesn't do anything much on it's own, but it gives the fast food delivery service some kind of idea of how fast the fast food appears, or is needed for consumption. (Devs).

Next, the handlers are like the pizza delivery folks. They actually run around, organizing the scheduling from the different providers and customers. L also includes filesystems, but a filesystem needs hardware to live on, so getting filesystems moduled up first doesn't make sense to me. You need the card list of customers and suppliers (Devs) before the delivery people can start running around carrying fast food from one place to another (the L handlers, filesystems and similar).

Finally, in cases where a customer or fast food provider is very popular, and has a lot of business, a library of common interactions is very helpful. Rather than having lots of different transalators for everyone to talk to each other, you arrange commonly used translators in a big group. You don't need the translators to begin with, they come last. First the pizza has to go from one place to another. It's only on the customers doorstep, or the pizza houses serving counter, that common transactions happen between multiple elements.

It sounds logical to me, but maybe not true in ALL cases. things like maybe 68040.library you want at the beginning, not the end. You want it to happen first. Because that's the processor, a critical system. Kind of like the boss to the universal pizza company, Exec Pizza Deliveries Inc. If the boss gets mad being kept waiting, or is given an order they don't understand like an instruction that is software implemented on that processor, the whole business has a hard time and can't operate properly.

If you go - find out the critical system modules first, then do devs, l, libs. And generally that order. That should work, if I'm thinking straight.

[Pat the Cat]

The order in which modules are loaded depends on their priority, which is coded into the module, and - for exec and expansion - also on the system.

OK. I was trying to find a logical path to do the same thing by hand, giving me the choice of which modules should have more recent versions added.

If AmigaOS doesn't do this, OK. It makes we wonder why there's an AUTO option to LOADMODULE if the inverse, manual, has no effective meaning.

This sounds to me like how 3.5 onwards, ie PPC capable OS, implemented this idea, of being able to use more advanced versions of system files than were supplied with the initial release.

Being PPC friendly might be the real reason for this. I can't for the life of me see why though. That's OK, on a bad day I can't see the end of my nose very clearly.

[Pat the Cat]

You can certainly manually define which modules you want to replace. AUTO is a "please replace any ROM modules you find on disk" option. AUTO can be combined with manual module selection, BTW. No worries.


Manual allows to select which ROM modules to replace, and which additional (!) modules to place on the list.

Neither manual nor AUTO has any impact on the order in which modules are initialized (or whether they are initialized).  That is really up to the module to decide.

So loadmodule decides which modules to load, and - if manual - where to take them from, and which modules to load, but not the time at which they are initialized. The order on the command line does not have any particular meaning.

I see. Some modules need to be initialized, reset, in order to get a proper start condition. They are kind of "undefined" when LoadModule gets them available.

Some are not like that, but you have to power them up, reset them, in the right order.

That is coded into the module? Hmmm... must make replacement very tricky sometimes.

I guess it does make sense to use "Auto" option rather than wildcards. Not that wildcards are bad, but they will present the options to the command in a pseudo random order with some filesystems. If you have an AUTO option (supposedly) and the real deal is coded into the modules anyway, this can't work. The filesystem plays back the files in a strange way. It's almost certainly going to be the WRONG way, for 3.5 onwards. Unless you hack the module or modules, and that's no guarantee you'll improve matters at all.

[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.

[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.

[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.