The Un-Official Proxomitron Forum

my fellow U-OP's,

not sure if such a beast exists, but i'm looking for something to "accelerate" the start-up load times for applications, not my OS start-up load time (which is the only thing i keep coming up with when 'Googling')...

basically, running MS Excel with several "add-ins"...
NO, any "Open Office" or "602 Pro PC Suite" type of replacement for MS Excel is NOT acceptable - i will NOT sacrifice the superiority of MS Excel just to INEFFECTIVELY combat the greed of the 'empire'...


would seem to me that something like this would exist somewhere:
1) run 'app accelerator' - let it 'monitor' PC...
2) open the app that you want 'app accelearator' to "accelerate"...
3) return to 'app accelerator' - tell it the app has been loaded, speed 'er up, then it "rewrites" a new .exe file that you run in the future instead of the "normal" .exe, whereby the new .exe is much more efficient at loading not only the .exe, but whatever else it loads during its "start-up load time"...

Isn't WinXP doing that anyway? I haven't booted into XP for a long while, but IIRC it was creating an optimized stub for all launched executables ("prefetch" directory).

sidki

correct, WinXP creates .pf files in a 'prefetch' directory...

but those .pf files are, from what I've seen thus far, strictly related to the .exe file it "parallels"...

it doesn't do anything in regards to "speeding up" the .dll's, for example, that are loaded when that .exe is ran...


I am hoping to be able to find something that not only "effects" the .exe, but the .dll's (and, for the MS Excel case, .xla's) that are loaded as well...

I mean, I'm no programmer, but if the "idea" has come to my mind, then it would seem that is would have certainly came across the mind of a programmer...

follow-up:
still experimenting, but did stumble upon "Petite 2.3" which was able to compress my "excel.exe" file from its original 8.76MB to 4.45MB (and that was with it set at 'level 4' of NINE levels)...

also found "nBinder 3.6.1" (which appears more promising in regards to .dll's and .xla's) - haven't tried it yet...


I'll post back any findings...


edit: scratch "nBinder"...

I think petite just compresses the files for easier distribution, it doesn't actual speed up the loading. It's a packer.

conclusion:
project abandoned...

ProxRocks;

ProxRocks Wrote:conclusion:
project abandoned...

Whoa there, pardner, not so fast!

Shea was a bit incorrect. What Petite and its like do is compress the .exe in a format that can still be used directly by the CPU - they don't just LZW the main proggie file. In essence, the time it takes to "de-compress" from this format is taken directly from CPU cycles that would otherwise be spent waiting for the next instruction to be loaded in from disk. By loading a compressed set of bits/bytes, and spending time to de-compress them, many more bits/bytes have actually been loaded into memory than would have been so by merely reading directly from the HD.

Now, with all that said....

What you're really looking for is an image of what's already been loaded into memory. The so-called '.pf' file is exactly as you described, with one important exception, what was prefetched was merely any .dll file needed for that application - it was loaded at boot time into an optimum slot (as chosen by the OS) in upper memory. No other prefetching was, is, or will be, done. A simple debugger will verify this, should one wish to play around. (But that means that you'll need a second machine to watch the boot process through a console cable. Don't ask. )

The next best method of capturing your desire is to recall that the old '.com' files were actually nothing more than memory images! If you can find a linker/binder that will do so, you can "recompile" a small (repeat small) .exe file into a .com file. But wait, Excel is over 8 megs, just a wee tad too big, right? Yep, sure is - .com files can be no larger than 64Kbytes!! So, what's a poor hacker to do?

I've not done this in a long time, but it seems to me that you possibly could use ResourceHacker to pull out all of the ancilliary stuff from the exe, compile those into (yet) another .dll file, and then link/bind the remaining stuff into a .com file. That resultant .com file should then load into memory quicker than a lawyer diving after a default judgement.

What won't happen, in any event, is the pre-loading of any .xl? sheets. Why not? Because they aren't part and parcel of the overall application schema - they are personal, and therefore can't be optimized ahead of time. (Wait - didn't I see a shareware utility out there somewhere that promised to convert an .xla sheet into a .dll??) Well, I suppose you could find something that will take a snapshot of your entire memory contents at the moment (right after initial loading?), and then upon command from a desktop shortcut, that image could then be restored to memory. That would be ideal, but it would have to play nice with whatever is already loaded, right? I'd lay money on that not happening, at least, not easily.


Oddysey

lol, you've got me pegged...
my Excel pull-down menu's have already been 'diced and sliced' with ResourceHacker (more out of 'just to see if it can be done' than for any real "benefit")...

I believe you may be on to something - converting those .xla's to .dll's...

I'll see if that opens any windows, doors, or drawers...


edit: still trying to "hack" Excel into showing TWO rows of 'tabs' at the bottom instead of only one - ideas towards that end are also welcomed...