Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have rather big executables (about 25-35 MB). Because I want my users to easily execute my application, I don't want them to install a bunch of DLL's, just xcopy-install is OK for me (and my customers). Because my software is often run from a network drive, and my customers' networks are not always reliable, I link my executables using the /SWAPRUN:NET option. This guarantees that the whole EXE is loaded in memory before the application starts, and prevents crashes if the network connection is dropped while my application is running.

This worked fine so far, BUT ... under Windows Vista, if a network folder has lots of such executables (10, 50, 100, ...) then opening this folder in the Windows explorer takes a lot of time (minutes!). Especially, the visualization of the executables' icons takes a lot of time. This problem did not appear on Windows XP.

Today, I found out that the problem is caused by the /SWAPRUN:NET option. If I remove this linker option (or disable this flag with EDITBIN), than the Vista Windows explorer immediately shows all icons. Disabling this flag is not really an option (see reasons above).

Is there another way to tell Vista that it should not load the complete executable file if it only needs to show the icon (or other version information) in the explorer?

share|improve this question
1  
FWIW, the IE Team hit this problem a few years ago with our installers; for us, it's worse because we can have dozens of installer versions in a single folder. Yes, the entire image gets copied across the network, even for datafile only loading to get the icon resources. The workaround is a bit insane; you can remove that flag and have the first thing your app does when it runs fault in the entire binary. There was some sample code for that in Microsoft Systems Journal back in 1999 or so. We decided not to take it to that extreme. –  EricLaw Apr 25 '12 at 14:07
    
We're now doing exactly that (using the code of that exact same article). It's indeed an insane solution since the /SWAPRUN flag was added just to solve this kind of problem. Still no decent problem or workaround available in Windows? –  Patrick Apr 26 '12 at 18:05

1 Answer 1

up vote 0 down vote accepted

This was confirmed by Microsoft to be a problem, but apparently it will not be solved. Only solution is to remove /SWAPRUN:NET.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.