I have some VB6 applications which have run well under every version of windows since XP. Now we are going over to Windows 10 x64 we are finding our our GUI application is very slow especially in SQL operations etc. We run all applications elevated and played around with various options in the compatibility tab but nothing stopped it from being laggy.
Recently i have found a huge improvement if i run the compatibility troubleshooter. the first time we test it fails because we then have to retry with the admin rights but then it seems quite good.
What i dont understand is what the troubleshooter is doing differently to manually selecting options and also even though i then tell it to save the settings, the next time the application runs its laggy again and we run the troubleshooter. I've done a little research and can confirm the applications are all run from the local hard drive. We also keep the database on the local drive.
Just in case it helps, Running different builds of Win10 from Anniversary to a clean install today of Fall Creator. The Visual Studio IDE is installed under the Program Files directory (not program files x86) and i deselected the ADO, RDS ODBC providers as suggested somewhere on the internet (there are ADODB calls could this have anything to do with it). The IDE runs also with elevated permissions.
There are essentially 3 applications with 2 running in the background. All reference a couple of DLL files from a 3rd party and run several SQL calls to a local database. We have noticed if the database is being accessed elsewhere (even through Access so not repetitively) this also slows down the GUI. This system need to perform realtime tasks and so this laggyness is affecting the operation.
Thanks in advance for any suggestions
The correct, and fastest, latest software to run a VB6 program is only found in the "Windows 7, (SP3)" modes, with elevated (Admin) permissions. Since that version, there have been many safety features added to windows, which have to be "emulated", in order for VB6 programs to operate within certain safe limits. The cost was speed, nearly half the speed, which is measurable with most time-demo codes.
Setting compatibility mode to "Windows 7, (sp3)", and elevating your program to (admin), will return your program back to normal speed. Actually, it will be faster than it was on that version of windows, but only in some areas.
This should be done manually, or at the point of install, of your program. You have to add registry keys, based on where the program is installed and how it is named or identified. Prompting the user so they can OKAY the elevated (admin) access for your program.
Even though it's still working, it's really not optimized for new operating systems - of course it's just Windows. There were a number of programs that used to work on Windows XP and today do not work at all.
As the language son wanted with the interpreter rather than compiling it - of course there are other languages as if they had undergone many optimizations (eg python). Which greatly reduces the software.
I ran into the same issue and resolved it by Compatability options as below:
Right-click on "C:\Program Files (x86)\Microsoft Visual Studio\VB98\VB6.EXE" and choose the properties option from the popup menu
Select the Compatability tap from the properties windows
Under Compatibility mode, Select "Run this program in Compatability mode for"
Choose "Windows-XP (Service Pack 2)"
Click OK and execute VB6
Related
We have an ERP application which is built in VB6 and it was running just fine till a few of our customer upgraded all their systems to Win7.
This software is programmed in such a way that it registers a few plugins (found in plugin folder) which are COM based at runtime. Now when the software is run by user without setting Compatibility Mode and Run as Administrator setting it fails and crashes.
I know we can manually set both Compatibility Mode as well as Run a Administrator by right clicking on program executable and then going to its properties. But this looks very unprofessional.
I think there will be some way to tell Win 7 to automatically run a software in Compatibility Mode and Run as Administrator.
Please help me.
Compatibility is an administrative function, not a development or deployment function. It is better to fix the application where possible, especially to remove any requirement for elevation.
There are plenty of tools for investigating the issues so you can correct them. However globally registering "plug ins" at runtime is a nasty one. VB6 component self-registration is always global unless registry virtualization can redirect it. Why not create installers for the plug-ins that can run elevated once during installation?
There are ways to set compatibility less manually, even as part of installation - though Microsoft discourages this. Maybe take a look at:
Compatibility Fix Database Management Strategies and Deployment
However the effort required might be better spent on remediating the problem. Support costs will be less over time.
As the other answers have said, you shouldn't need to run all the time elevated.
If you want to register the plugins after its started (as a normal user), you can use ShellExecute() with the "runas" verb to run regsvr32.exe, or use COM elevation which has been discussed many times before.
You can indicate that an application must run as admin by specifying it in the Application Manifest, which in an xml file that you can either embed or deploy with your application.
Once your application is running with admin rights it should be able to register and load the plugins. You should not need to run in compatibility mode to access the COM plugins.
I have an application written in Delphi 2006 that was working fine in Windows XP. I packed the application using Inno Setup, using Program Files as the default folder. A few users migrated to Windows Vista and Windows 7. The issue here is that the application creates some files inside its installation folder by its own. This was working in XP but in Windows Vista the users were having problems with the created files (they don't appear and so on). After investigating the users' reports I discovered KB 927387: "Common file and registry virtualization issues in Windows Vista or in Windows 7."
Running the application with administrator rights just solves the problem, but that is (I think) an awful workaround. I would like to know if there are any directives or tips for making the application compatible with Vista and 7, because more users will migrate to these OS soon.
You need to re-write your application to store its files in the proper locations, even in XP, but especially in Vista onwards, particularly if UAC is enabled. This is becoming more and more important to get right as Microsoft keeps locking down and enforcing its security models with each new OS version. The rules for how to properly manage application- and user-related files is documented on MSDN, for example: "Application Specification for Microsoft Windows 2000 for Desktop Applications, Chapter 4: Data and Settings Management" and "Application Specification for Microsoft Windows 2000 for Desktop Applications Appendix A: Best Practices" (yes, they are old, but are still quite relevant). Look at SHGetSpecialFolderLocation(), SHGetFolderPath(), SHGetKnownFolderPath() and other related functions to help you.
For Vista/Win7, your app can't put the files in a subfolder of Program Files / Programs unless UAC is turned off or the app is running as elevated. Note that "elevated" does not necessarily mean "logged in as Administrator." Non-administrator users can elevate, and Administrator isn't necessarily elevated.
If the app does attempt to write to Program Files but is not elevated, the OS will either block the app or "virtualize" the write (put the files somewhere else), depending upon how UAC is configured. Neither one helps the app succeed at what it was trying to od.
So it needs to put them somewhere else. Where depends on why the files are being created, and you haven't told us that. You can read this article to learn about the options. Note that in addition to the user's AppData and Roaming folders, there is also an "All Users" (shared) profile.
You should probably look at this article and screencast, which discusses UAC in depth from a Delphi point of view.
Files you create for use by your application other than at installation time should go into the ProgramData directory if its global to the workstation, or into the users ApplicationData directory if its specific to the user.
For cases where you absolutely must place a file in the program files directory, you can use com to request elevation. This is discussed in great detail, and delphi specific bits are also available. One example that I have used this is in patching my users installation base. They are warned by UAC that the system needs to make changes, so if your doing this as an automated task, you might need to rethink the logic to be more user driven.
Here is another article, by Zarko Gajic, which shows how to get different system directories. Also have a look at this related question.
I had a similar enquiry here (Stack Overflow).
In the end I realised that I needed to put my application into Program Files at install time (requiring UAC/elevation) and then store my app's data in the user's App Data folder. I had to change the way my program generated 'default' configuration settings and also where I was saving this stuff, but it was worth the effort in the end - we ended up with something that installs and runs fine on XP, Vista and Windows 7.
The only UAC hit we get is at installation time, which makes sense to me (and you get a similar hit at install-time on the Mac too). We didn't have any data that would be common to all users in this particular case but I would have looked at the Program Data special folder if that had been the case.
The installer software we use (Setup Factory) made this fairly straightforward (we just wrote a small bit of code to detect XP versus Vista/Win7 and choose the right special folder accordingly). It would be easy to do this in Inno Setup too, from what limited experience I have of it.
My application needs administrative access and I want it to run without any hassles in Windows 7.
I have the following options
1.Ask the user using the application to turn off UAC. This is a last resort option and would hate to do that.
2.Embed a manifest in the application that says elevate to adminstrator privelege. This will work but it seems that it will bring up a dialog requiring users consent every time a user runs the application.
3. Configure the application to run in Windows XP compatibility mode. This works, but i had to do this using explorer->application properties. if can I do this programmatically during installation time, I would really prefer this option. My question is if there is any way to achieve this.
regards
Ganesh
Try making an application compatibility shim that says your app needs the XP compatibility mode, and distributing it with your app. A shim is a means for administrators to simplify installation of a 3rd party app that needs compatibility settings - it saves them tweaking each PC individually. You can probably roll it into your install program with a little ingenuity.
I've gotten pretty used to dealing with the UAC dialog, running Vista for the last 2 years. If it bugs you, I have to wonder how much experience you have using post-XP OS'es.
As a user I think there are two ways to look at it:
The program inherently requires admin. For these, I very much appreciate the dialog, as I know it means nobody's going to sneakily run that thing in the background on me and modify my system.
The program inherently does not require admin. Most programs only need admin to auto-update themselves (and probably shouldn't need it then). My attitude is that these programs are poorly-designed. Such a program should only invoke AUC if it discovers it needs to update, not every single frigging time I start it up. This is a security issue too, as any buffer overflow someone finds in the entire program puts me at risk.
Localize the need for UAC as much as you possibly can. The best would be to put in a separate executable. (eg: an "updater")
I have a VB6 app that formerly worked perfectly on a Vista machine as a scheduled task, but it will no longer open on the same machine. The app generates export files in a specified folder with no direct output on the screen. I get no errors, no missing references, just absolutely nothing.
The machine is running Vista Business 32-bit, UAC is disabled with a single administrator account, and automatic updates are turned off. The app resides in a non-protected folder, and the export files are put in a folder on the desktop. The client swears that the only change they made to that computer since I installed this app was installing Norton Antivirus, which has never caused problems before with our software.
In addition to the normal VB6 references, the app references Microsoft Scripting Runtime (scrrun.dll), and Microsoft DAO 3.6 (dao360.dll). Both of these files are present and registered on the target machine, along with all the other VB6 dependencies. I added MsgBox statements at the beginning of Sub Main() just to see if anything is being executed, and its not. Disabling Norton yielded no results, nor did reinstalling VB6 runtime to rule out any corrupted libraries. Not once did I get any messages, error or otherwise from my app.
I've never had an issue like this before and I'm completely stumped. Is there anything else that could be causing this?
Edit - The app does not run even when I run it manually, so the part about it being a scheduled task is irrelevant to my problem, sorry for including it.
The user has full administrator credentials, no compatibility mode was needed on the initial test which at the time, was done on this very machine I am having the problem on. For grins I tried compatibility mode for XP and 2000, still nothing.
Try to inspect - if you can access them - the Event Viewer messages. Maybe you will find some tell-tell signs in there...
You could try running the program in Windbg, a free standalone debugger from Microsoft. Compile your VB6 EXE into native code with symbols (create PDB files) and you will be able to debug your application in Windbg.
I would guess one of two things will happen.
Windbg will fail to load the EXE. Presumably with an error message that will identify your problem.
Windbg will load the EXE, and you can single-step through to see what happens.
Here's a 2006 blog post by a Microsoft guy about using Windbg with VB6, and 2004 blog post by another Microsoft VB guy with a brief introduction to Windbg.
Has the user changed their password? That will cause the scheduled task to fail until they re-enter the password on the task.
Have you tried running the process directly, instead of as a scheduled task? I'm far from an expert, but it may be that any errors being generated are not showing up because the program is running as a task.
I have switched to Vista recently and I wanted to keep UAC turned on, as I agree it increases computer security a lot. Some developer tools I use regularly require running elevated:
PIX for Windows
Visual Studio 2005 (elevated privileges seem to be needed for debugging and for IncrediBuild to work)
mapped and substed drives: The elevated process does not seem to see the drives I have mapped in my user account. This article describes the problem, but I am not sure how could I implement its final suggestion to "map these drives in the context of the elevated login".
I have experimented with many suggestions I have found, Compatibility Administrator seemed quite promising, but the result was still not what I wanted. When I used RunAsInvoker, there was no UAC prompt, but the Visual Studio did not work. When I used RunAsAdmin or RunAsHighest, it worked, but there was the prompt.
Is there any way how to teach UAC to remember some particular application should always run elevated and never prompt me about this, or some other way how to allow me launching VS elevated without the prompt? If there is no way to do it, does there exist some security reason why it cannot be done?
Try:
Administrative Tools -> Local Security Policy -> Local Policies -> Security Options -> User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode = Elevate without prompting.
I've had to turn UAC off for my 2008 dev system also, despite similar feelings about wanting to be able to use it. It's just too painful to need to keep track of the running context of every single application in order for things like drag/drop between windows to work, or interacting with remote systems, or debugging scenarios, or any number of other tasks. UAC was a good idea in theory, but there seems to have been so little effort put in to making it functionally useful for real-world power users, that at the end of the day, the only feasible solution is to disable it entirely.
Windows 7 will purportedly be somewhat better with eliminating the constant prompts, but unless they really work to address all the cross-application and remote access issues, it's still going to be a non-starter for anyone other than novice users. Here's to hoping they eventually get it to be actually usable.
VS 2005 was a pain in Vista, and there's a lot of little gotchas even when running as administrator. See if you can upgrade to 2008, which works a lot better on Vista.
Unfortunately UAC prompt is mandatory in windows Vista, when UAC is enabled.
One solution that worked for me is to have a elevated command line and a bunch of non-ui shell scripts that run elevated from there for some tasks.
Also to debug I've setup another computer in which I can run a remote debugging session, it is a bit tricky to configure with VS 2005, the plus is that if you crash/hang the remote session it didn't crash your main computer :)
PD: VS 2008 is slightly nicer in vista than VS 2005 give it a try if you can.
As far as I'm aware, you can't get everything you want (UAC on, VS working without prompts).
However, there's a better workaround than "have someone else test it with LUA:" A Virtual PC. Use Virtual PC (free from Microsoft) to create a guest operating system. Install Vista and set up a regular user as well as your default admin. Test your apps on that VPC using the regular (non-elevated) user. This at least gives you the early indication of LUA issues without too many major headaches.
I agree that it's a bit of a pain (and I've noticed VS2008 doesn't bug me with UAC prompts under Vista nor Win7 beta), but it is what it is. VS2005, particularly in debugging, requires elevation to attach to processes, etc.
For the record, my current "solution" to this problem, after a few days of experimenting with it, is:
turn UAC off
make sure somebody else tests the application with a Standard User Acount on a regular basis
... i.e. use the same pattern which worked in WindowsXP before.
I would like to see some other solution, but so far nothing I have tried gave me all of what I want, i,e. UAC on, Visual Studio working and no prompt on running VS. I would like to keep UAC on, but it was too annoying for me to confirm the elevation every time I run the tools.
Norton has an interesting tool to de-tune UAC and make it a little easier to live with...at the cost of feedback about what programs you run going to Norton. There is a good write-up about it here:
http://www.betanews.com/article/New_Norton_Vista_tool_trades_UAC_for_online_feedback/1223668881
The download is here:
http://www.nortonlabs.com/inthelab/uac.php
Finally, there is an interesting little tool to "snooze" UAC which costs $5 (30 Day trial). I can't vouch for either tool as I have not tried them personally.
http://www.uacsnooze.com/