Originally posted by: vinh-an trinh
Hello all, this is a great hack, but has anyone experienced weird compile error about vcspawn after a while?
I don't remember exactly what was the error message, cause now I'm on a new NT box. But at that time, the compiler or linker often complained about vcspawn. Rebuilding on another machine worked.
It might not be related, but I dare not to hack VC++ now.
Originally posted by: Stan
Since many people use NT as developing platform, would not
it be possible to use that obscure feature of specifying a debugger for a particular x.exe in the registry to do the job? Write a program that launches cl.exe or whatever you specify in its command line with idle priority and specify it as debugger for cl.exe or whatever VC component. What do you impatient guys think?
Or even better, rename vcspawn.exe to asdf.exe and name the
hooking program I propose vcspawn.exe and let it start asdf.exe with any parameters found in its command line:-)
I would expect this to work for Windows too.
One alternative that works up until at least VS 2003 (probably through 2008), is to set the priority of the IDE. The tools it spawns will inherit the IDEbs priorty.
ReplyOriginally posted by: Brad Pirtle
This is so awesome.
Cmpiles are better, but links really drag my machine down (its a big project).
Any ideas?
This should be automatic. VCSPAWN is in the Common folder because it is used to run all the tools, compiler, linker, resource builder, etc. Therefore if VCSPAWN runs is modified, it should run the linker as low-priority too. What may be happening is that it uses a different call to CreateProcess for the linker. There are two calls to that function in VCSPAWN.exe, so you should patch both (or just set the IDE priority to whatever you want instead).
ReplyOriginally posted by: Martynas
Hello,
Maybe you know how can I find those bits in newer vcspawn.exe version?
What you want to do is to look for the CreateProcess calls rather than a specific offset. Use a hex-editor to open the file, then search for that function (or the bytes: 0xff150810). There are actually two of these in the VCSPAWN.EXE of VS 2003 SP1 and probably other versions as well. Go back a few lines of machine code from there (~16 bytes) and you should find the priority parameter to the function call: 00020000.
ReplyOriginally posted by: Paul Tait
I'm lucky enough to have dual cpu box and I'd love to be able to use both cpu's for large builds, assuming of course that the I/O would become a bottle neck. Any ideas???
ReplyOriginally posted by: Mark Baker
Man, I've been wanting something like this for soooooo.. long. Especially when working with large projects, I'd have to keep taking breaks whenever I hit "build". Now I can go off and work on other files, read email, etc while the compiler happily runs in the background.
This is definitely a 4-star fix..
Nice job..
Mark
Originally posted by: John Curtis
I can now use my 'top of the range' PC, previously it was go and get a coffee time.
ReplyOriginally posted by: AlexS
I should consider it as a major design issue of VC.
Nothing against your patch but
the thing that wont get influxed is the hang alike situation when VC
does its dependency checking (most likely from inside the application
main window) before launching the compilers and other components.
This comes especially obvious if the project is getting bigger.
My only hint for such case is to select certain sub
projects to do compile checking in this case.
Originally posted by: Dug Birdzell
I was using a separate computer for mail, news and bug tracking since builds were monopolizing system resources.
this modification works amazingly well. about half of the development group at my company have made this fix and rave about it.
-dug
Originally posted by: Matt Renzelmann
The title says it all. Excellent job! It works perfectly.
Reply