If you do not hesitate wasting 500Kb of extra memory, then all needed core perl and Tk library text files could be managed to go into single one.

I mentioned such approach yesterday, at node Re: How much of Perl can be removed?

Dark side of my approach - my "require" function is somewhat "unsupported" and do not even understand versions (it just ignores them).

Courage, the Cowardly Dog
things, I do for love to perl...

There's good advice above about pre-caching modules. If, however, the problem is loading data off of the CD, then you might have another option:

• If you can require that customers have a net connection, get fresh data via HTTP request.

The benefit of this scheme is that data is alway fresh. You don't have to send new CDs to customers each time your specs change. There will be a slight delay (which you can mitigate by caching data).

Then again, you might benefit from trying to slurp all of your data into RAM at startup.

If you can require that customers have a net connection, get fresh data via HTPP request

Alot of the people using this CD will be out in the field and don't have access to a net connection. We may do something like that for updates but cannot require it to run the CD.

I have the program get 90% of what it needs off the CD at the startup now. It is running through all but 1 of the menus without having to spin up. The last menu uses a directory structure that is over 400 directories so I don't think there is too much I can do about that.

I would like to thank all of you for your help.

You could of course use the event loop and access the CD every 100 ms, that would keep the CD spinning. But I'm sure that won't be appreciated by the users.

Abigail

I propose you to start your script with "loading" all your modules and shared libraries that your script can use.

You have a set of files that are perl modules, or bootstrap files, or shared libraries. Then at the very beginning of your script you call some subroutines from each of those modules. For example, create hidden Entry, fire some events that will be processed by your script (keystrokes, mouse movements, and so on). Then create listbox, do something with it, and so on. After that destroy those widgets without even showing them.

Once your shared libraries will be loaded from CD-ROM into memory, system will not read them second time, so your problem will be solved.

Courage, the Cowardly Dog
things, I do for love to perl...

The modules are not the only thing that need to be loaded into memory. The program itself is a couple thousand lines and there is a directory structure on the CD that is required for another part of it.

A ramdisk seems to be a good way to go, if I can find out how to do it.

Okay, (I just shared my experience)...

But creating a RAM drive is very OS-dependant thing, and most OSes do not allow that... I can't imagine how ramdrive could be created on any of Win32 systems. (Yes, I imagine it is possible for Win95 after some fight with config.sys and rebooting, but this is way harder than creating just temporary directory via standard modules).

OTOH initially you asked how to load your program into memory - I can share my vision on this. If your program needs something more (what is it, namely?) then there should be another way to cache that data (or part of it) into memory, using similar approaches.

Courage, the Cowardly Dog
things, I do for love to perl...

What about creating a dynamic ramdrive and copying the script into there?

Can you somehow bootstrap the code into a browser, and launch it from there, so it sits in the cache and namespace of the browser session? Something like "Read the docs in your browser, click here to demo the app".

There's no way to "cache" the script yourself, through your perl code, other than to do something like the solutions above. You're dealing with a mechanical limitation (the cdrom spindown), and that's not something you can modify or adjust with your perl code. Work around it.

I wanted to stay away from putting things on their hard drive, so that won't work.

I am confused about your bootstrap suggestion, I have no idea how I would do that and why it would be associated with a browser.

A ramdrive would be great, I will see if I can find out how to do that. Thanks for you help.