[RESOLVED] VB6 build slow on Win 7

It seems this might have been a common question but a search of the forum doesn't find anything.

Microsoft says VB6 is supported on Win 7 (x86 only) to I tried it. The IDE works fine but the build is too slow to be usable.

A VB6 project that builds the .exe from the command line in six-seven minutes on XP took 1:20 on a modern (i5/4GB) Win 7 x86 machine with nothing extra installed beyond the dev environment.

I could see it was slowly trucking along making VB*.tmp files, so I let it run. A working executable finally popped out the other end. The CPU was 25% and the disk queue was essentially zero. What was it doing for an hour and 20 minutes?

Any ideas on what's causing the slowdown?

Quote:

---

Originally Posted by jvinton

Microsoft says VB6 is supported on Win 7 (x86 only) to I tried it.

---

No, they don't. The last version supporting VB6 development was Vista. Of course compiled VB6 programs are supported on Win7 with a few limitations.

And some people have gotten the IDE and compiler to work on Win7, but it isn't "supported" at all.

Quote:

---

Originally Posted by jvinton

A VB6 project that builds the .exe from the command line in six-seven minutes on XP took 1:20 on a modern (i5/4GB) Win 7 x86 machine with nothing extra installed beyond the dev environment.

I could see it was slowly trucking along making VB*.tmp files, so I let it run. A working executable finally popped out the other end. The CPU was 25% and the disk queue was essentially zero. What was it doing for an hour and 20 minutes?

Any ideas on what's causing the slowdown?

---

Sounds pretty weird.

Of course you should have set appcompat shims to disable Aero and always "run as administrator" (or better, added an elevation manifest) on VB6.EXE anyway. Did you do this?

I have windows 7 64bit.
It works great for me only problem was i had to Run As Administrator VB6.EXE.
No VB6.EXE does not support 64bit, but a windows 7 64bit does support 32bit software, so i do not see the problem for not running on windows 7.

As for your 1 hour and 20 minutes, it must of been a HUGE program, or else there is something wrong with your system, because mine builds any .exe as fast as any other windows.

Or maybe VB6 didn't get installed properly. Both phases of the install must be run "as admin" or you risk lots of things being registered in virtualized locations. This might result in a ton of clunking along as registry accesses get tried and retried as they're redirected to the VirtualStore section.

It still sounds very strange though. Almost like your user profile has been relocated to a server over the network or something.

Thanks for the quick replies.

Max187Boucher:
I don't know about relative sizes but this is probably larger than most VB apps. It's a commercial app that's been evolving for about 13 years. I checked several years ago out of curiosity and I remember stats something like 350K lines of code (probably including whitespace), 100+ forms, 100+ Crystal RDC reports, many in-house and 3rd party controls, etc.

dilettante:
When I started this test yesterday, VB installed okay and I could make a simple .exe from the IDE. However, I had a bunch of trouble getting my project to load & run with F5. I'm not good at taking notes so I'm not certain what tweaks I made to get it going, but but I rolled back everything that didn't work and the progect now runs normally in the IDE.

I see now that I set VB6.exe to run compatible with XP SP2 and run as administrator. I think I did the XP SP2 thing because I was having trouble loading some older ActiveX controls.

I didn't think to disable Aero on the dev machine. I'll try that. The built app runs fine on Win 7/8 with Aero enabled.

Regarding MS support of VB6 on Win 7, maybe I mis-read this doc. Maybe it's a gray area. Does running vb6.exe /make from the command line mean I'm using the unsupported part?

http://msdn.microsoft.com/en-us/vstudio/ms788708.aspx

I'll test with various compatibility/Aero settings and report back.

Thanks for your help.

As a test I tried to build one of my server projects under both Windows 7 x64 and Windows XP to compare times. In both cases it took 6 seconds to build the exe start to finish. Boath machines running Phenom 2 processors both 3.5 ghz XP box is a 4 core and 7 box is a 6 core. No noticeable difference in build time on either box.

Project tested is not huge only 336K when compiled

I do not use VB in any compatibility mode, I simply set the shortcut to run as administrator and have saw no issues under Windows 7 x86 or x64 to date

If you wanna speed up VB6's IDE, just goto vb6s properties, and check Disable Desktop Composition. I've been using vb6 in windows 7 64 bit pro for the past 2 years and it works great. Compiling is not an issue either.

I do not know anything about what Jacob posted (Disable Desktop Composition), but i found this link while i was looking on how to Disable Desktop Composition, if this is any help...

http://www.vbforums.com/showthread.p...-automatically

Jacob:

Desktop composition is disabled on vb6.exe. I've had trouble with that before.

I changed the compatibility on vb6.exe to Win 7 (desktop composition=disabled, run as admin=enabled). Not sure what's the difference, on a Win 7 machine, between no compatibility and Win 7 compatibility...

It's building from the command line now (1 hour & counting).

I agree that VB6 mostly runs on x64. That's my regular machine and I use VB6 all the time for ordinary work but it (VB6 on Win x64) can't handle this particular project and it's definately unsupported by MS so it's too risky to go down that road.

For quite a while I've been running VB6 in either XP Mode or VMWare VMs in order to maintain this project but that's not a real solution.

So I built this Win 7 x86 machine just for this project. I don't like the idea but I'll build a dedicated XP machine if I have to. This app is still selling and making money so it must be maintained and enhanced but I can't justify the expense of a total re-write in .NET unless I had an an investor/partner to help kick this app into the next decade.

Quote:

---

Originally Posted by jvinton

I changed the compatibility on vb6.exe to Win 7 (desktop composition=disabled, run as admin=enabled). Not sure what's the difference, on a Win 7 machine, between no compatibility and Win 7 compatibility...

---

Do you notice any difference in performance as opposed to how the IDE was setup before?

Since you are running from command line are you also running CMD as administrator?

Quote:

---

Originally Posted by Nightwalker83

Do you notice any difference in performance as opposed to how the IDE was setup before?

---

I had to do something at about 1:05 of the build. When I returned at 1:30, it was complete. There may have been an improvement in the build time with the Win 7 compatibility setting but it's insignificant.

Quote:

---

Originally Posted by DataMiser

Since you are running from command line are you also running CMD as administrator?

---

Good point. The build runs from a batch file that adds line numbers and then builds the .exe. The line numbering phase works as expected. I'll set the .bat to run as admin and report back.

http://www.vbforums.com/showthread.p...ng-the-VB6-IDE
:p;):p

Quote:

---

Originally Posted by jvinton

Good point. The build runs from a batch file that adds line numbers and then builds the .exe. The line numbering phase works as expected. I'll set the .bat to run as admin and report back.

---

Why not just set CMD to run as admin regardless via the "Privilege Level"?

Something that may or not be related to the slow build problem:

Since the advent of XP, I've copied the same VB6.exe.manifest file into the \VB98 folder so the IDE would assume the XP style. On this new computer VB isn't recognizing the manifest so the IDE shows the classic style (default vbButtonface rectangle buttons). Code below.

Do you think this behavior with the manifest means anything regarding the slow build?

Quote:

---

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="Microsoft.VB6.VBnetStyles"
type="win32"
/>
<description>VBnet Manifest for VB6 IDE</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>

---

How big is the project you are trying to compile? Does the slowness only occur with this particular project?

Quote:

---

Originally Posted by Nightwalker83

How big is the project you are trying to compile? Does the slowness only occur with this particular project?

---

I don't know how to compare "big". I'm a solo developer and I don't see others' code. Check my reply to Max187Boucher at 05:08 today for some detail.

Yes, the slow build only occurs with this specific project but it's a different animal in terms of size and scope but I don't have anything similar to compare. I have no trouble building ordinary projects on the new machine but these "ordinary" projects tend to produce executables in the 10K-100K range. The project that concerns me creates an exe of about 8MB P-code/16Mb Native with another 8MB if I add symbols to a PDB.

I do not have anything that big to test and I don't use Crystal. My projects range from very small up to near 2 meg for the main exe. I don't think I have any that exceed 2 meg in VB6 and even the ones that are close to 2 meg are very large projects with lots of code and several reports. So far have not saw any issues compiling any of them. I have not copied any manifest to the Windows 7 machine.

You really don't need to select Common Controls 6.0 on the IDE, but an elevation manifest avoids the risk that unwanted appcompat shims will be auto-applied by Windows.

Note that "desktop composition" is Aero. Also that selecting elevation via Properties (run as admin) applies an appcompat shim as well. It works, but it isn't the preferred approach since it still tells Windows to treat VB6.exe as a "legacy" program. This has side effects.

But I don't see how any of this contributes to slow compiling.

Running it from the command line does nothing to magically make it supported on Win7. As I said before it should work, but that has nothing to do with VB6's support status - which is expired now on any version of Windows in any case.

Quote:

---

Originally Posted by jvinton

Something that may or not be related to the slow build problem:

Since the advent of XP, I've copied the same VB6.exe.manifest file into the \VB98 folder so the IDE would assume the XP style. On this new computer VB isn't recognizing the manifest so the IDE shows the classic style (default vbButtonface rectangle buttons).

---

In Windows 7 you need to implement the manifest directly into the VB6.exe. (via Resource Hacker)
See following: http://www.vbforums.com/showthread.p...ues&highlight=

Quote:

---

Originally Posted by Krool

...manifest directly into the VB6.exe.

---

Thanks Krool. I wouldn't have thought of doing that to someone else's .exe.

I added your VisualStylesAndRequireAdmin.res to VB6 and rebooted but the VB IDE still has the classic style. Maybe the elevation part worked and the style part didn't? Do you know how to test?

I think I found the problem with the slow build but I need to test more to make sure I can reproduce & isolate the bad actor. Your mod to VB6.exe may be involved but since the visual hasn't changed, I'll have to test with the original VB6.exe to verify the fix.

I'll report back after more testing.

Quote:

---

Originally Posted by jvinton

Good point. The build runs from a batch file that adds line numbers and then builds the .exe. The line numbering phase works as expected. I'll set the .bat to run as admin and report back.

---

Sorry to hijack the thread with an OT request - but what are you using to add lines numbers to your code before building from the command line? Is it a custom program, or something freely available?

There is a brilliant free add-in for VB itself called MZTools which has many useful features, including adding line numbers. You can find a link at the bottom of my signature.

jpbro:

I see that si_the_geek also has something about line numbering that you may find useful. It may be more modern and have more options than what I use.

I got this numbering thing many years ago as a code example (I’m guessing because I can’t find a record of paying for it). I may have modified it slightly but I’m not the original author.

The included .exe is wrapped in my digital signature only because I don’t like distributing unsigned executables. It doesn't mean that I own it. I don't. I'm just passing someone else's good work along.

I’ve been using it for many years and it works well. You can download (source & .exe) from the link below. I’ve included a sanitized version of the batch file I use (NumberAndBuild.cmd).

www.planesoftware.com/downloads/LineNumbering.asp

GoingUp! is a utility that embeds an elevation manifest in an EXE as well. It creates a backup of the original so if things go bad you can revert easily.

Back on the slow build topic--

I have good news & bad news to report.

The good news is that I made a few changes and the build time went from about 01:20:00 to about 00:02:30. Wow! I'm stunned.

The bad news is that I can't account for what happened.

I've been paying attention & taking notes and I haven't made changes to this isolated machine other than what I've listed below.

The butterfly on my left shoulder is saying "it's fixed; don't worry; move on" but the bird on my right shoulder is saying "you should get to the bottom of this because it might happen again and you'll need to know what to do"

I'll listen to the bird.

The following is what I did since I last posted.

- Begin: build time 01:20:00
Disable AV
Disable Win search indexer
Disable Diskeeper
Apply Krool's patch to VB6.exe
(I know -- bad to make multi changes when troubleshooting)

- Reboot: build time 00:02:30 Wow! Fixed! Let's walk backwards through the changes to isolate the culprit.
Enable AV

- Reboot: build time 00:02:30 (AV isn't the problem)
Enable win search indexer

- Reboot: build time 00:02:30 (Indexer isn't the problem)
Enable Diskeeper

- Reboot: build time 00:02:30 (Diskeeper isn't the problem)
Copy VB6.exe from MSDN CD & overwrite the VB6.exe with Krool's patch

- Reboot: build time 00:02:30 (Krool's patch isn't the problem)

So I'm back to the beginning, right?

Now it's working at blinding speed and I believe everything is set back to state before this test. However, I cannot reproduce the original problem with the slow build.

Wha? I rolled back everything I'd done between the 01:20:00 build time and the 00:01:30 build time. Why didn't the slow build reappear? What did I do that fixed it? Why can't I recreate the original problem?

Maybe Krool's mod to VB6.exe made a persistant change in the registry that I won't notice until I must move/reinstall in the future. I'm not in the mood to format/reinstall in order to troubleshoot this thing but maybe that's necessary.

This appears to be a normal troubleshooting exercise but the test results are making my brain burn. I need some cooler heads to help me with this before I think myself into a circle.

Arrrgh-

So it sounds like your performance improved after adding a manifest to VB6.exe that declares it to be a Vista-aware application (note that Win7 and even Win8 are really still "Vista" in most important ways). This is what a trustInfo node in the manifest does no matter what requestedExecutionLevel you set there.

No trustInfo node (or no manifest at all) signifies a "legacy" application (in terms of the Trusted Computing Initiative).

There is an SxS cache (WinSxS folder) in Windows, and it is possible that the manifest info is still there to "haunt" you even after replacing the EXE with a naked one.

Quote:

---

Originally Posted by dilettante

...it sounds like your performance improved after adding a manifest to VB6.exe

---

I can sense that y'all are getting weary of this thread. Me too. We're almost at the end so please keep your grip for another day or so.

Yes, Krool's manifest insertion into VB6.exe seems have been the fix for build performance but there are some loose ends I'd like to tie up.

Krool's manifest has two parts (sorry--there's probably a correct term for "parts" in a manifest but I'm ignorant at that level so you'll have to squint & read between the lines). Let's assume that the first part (elevation) worked and solved the slow build problem.

If that's true, why didn't the second part (visual style) work? The VB6 IDE is still in classic mode.

In other words, if the visual style part of the inserted manifest didn't change the appearance of the VB6 IDE, how do I know if the elevation part of the inserted manifest affected the build performance?

Another loose end is why, after replacing the patched version of VB6.exe with the original from the MS CD, did the "fix" (fast build) continue to work? If the patched version of VB6.exe solved the problem, why didn't replacing it with the original version cause the slow build problem to resurface?

I'd like to get to the bottom of this freakish change in build time but the reality is that it's working now so I must move on.

I hate, hate. hate this mentality

http://www.youtube.com/watch?v=xWwUJH70ubM

Check the "compatibility" tab of the VB6.exe to ensure that there is no fault on that side. (That is also a persistent config somewhere in the registry; even when replacing a .exe)
Also you need to enable the visual styles in general. In Windows and in the "compatibility" tab.

@jvinton,

So, you can't remember which code you changed?

Quote:

---

Originally Posted by Nightwalker83

@jvinton,

So, you can't remember which code you changed?

---

I remember everything that's happened. I've been quite methodical during this process and have been taking notes.

I'm willing to declare that this problem with the slow build ihas been resolved. I'm new to this list. Am I supposed to award points or somesuch to everyone who spent their valuable time helping me?

As of this morning, the build time on my project is now remarkably fast. That's fantastic news but I'm unsettled because the normal build time has been in the six-seven minute range for about 10 years on Win2k & XP on current hardware. As the hardware gets upgraded & faster, Win and the app also get bigger so performance has been flat for many years.

Now, on This new box with Win 7, the build time is less than two minutes. I've been sleeping with this project since 1998 and I've never seen such a fast build. I'm going to cross my fingers and whistle as I walk past the cemetary.

VB6.exe is marked as no compatibility mode, run as admin is enabled, desktop composition is disabled.

The loose ends are:

- I can't reproduce the problem so I can't put a finger on the cause. I've rolled back every change I made to the original Win 7 install from a few days ago with only a few exceptions. AV, Indexer & Diskeeper are running, the dev environment and supporting 3rd party stuff, and RescouceHacker are installed, but it's essentially a clean/normal machine. The BIOS is essentially default (I don't fool with overclocking, etc.)

- I think Krool's embeded manifest fixed it but I deleted the patched file and I'm now running the original VB6.exe from the MSDN CD, so apparently Windows did something to itself that persists something. I don't know how else to explain why the original VB6.exe is now working so well. My mental task this morning is to decide if I want to troubleshoot this down to the gnat's ass by formatting and installing from scratch to recreate the original problem.

- The VB6 IDE is in classic visual mode. I can live with this but it begs the question of whether Krool's manifest patch actually fixed the main problem.

If anyone wants to use me to get to the bottom of what caused/fixed the slow build, I'm willing to start over. It's not a very big task, although this copy of Win 7 x86 is probably running out of activations. Let me know. I owe you.

I think your work is done. I really appreciate the help everyone has given to me. I don't usually monitor forums so if you want to contact me, send to jvinton at planesoftware dot com

Quote:

---

Originally Posted by jvinton

- The VB6 IDE is in classic visual mode. I can live with this but it begs the question of whether Krool's manifest patch actually fixed the main problem.

---

- About the VisualStyles I have no clue. I have tested this also and it worked.

- You can test if the "RequireAdmin" part worked of the embedded manifest as following:
Uncheck "run as admin" in "compatibilty" tab so that the VB6.exe (the patched one) is in default mode.
Restart computer to ensure windows regs it properly.
Then when you start a .vbp file you should get a prompt by the UAC whether you want to allow the application to proceed. That is an indicator that this is working.
It is needed to test this with a .vbp file, because the "run as admin" in the "compatibility" tab is only effecting when you open the VB6.exe directly.

Hi,
I want to report my experience on this problem:
I have a Win 7 64 with VB6 SP6 with several VB6 project.
All compilations works well.
I gave a project to one my collaborator wich have the same OS.
He modified the code and gave me back the source.
Now, on my computer I have both the project:
The original Project take about 22 second to generate a 5236 Kb Exe file.
The New One takes 1:22 Minutes of which 60 seconds are for the link (I see that the compilation progress bar in the IDE disappears, but the cursor remains in standby mode and I can see the OBJ file)
But in other case the new project take more minutes to compile. The original one always compile fast.
From within I understand that is not a OS problem, but something that I don't know in the code.
All the reference in the project are identical.
Hope this can help.
If you find any solution I'm also interesting, thank you.

Quote:

---

Originally Posted by jvinton

- I can't reproduce the problem so I can't put a finger on the cause.

---

Hmm - what I'm missing in all your "rollback-steps" is an info about that here:

Quote:

---

Originally Posted by jvinton

Good point. The build runs from a batch file that adds line numbers and then builds the .exe. The line numbering phase works as expected. I'll set the .bat to run as admin and report back.

---

Maybe you set the *.bat to run in Admin-Mode - and this setting is still in place?

If yes, then this is definitely a change you should rollback too.

Olaf