Author Topic: ACAD, VBA, VB and the Vista operating system  (Read 2383 times)

0 Members and 1 Guest are viewing this topic.

DaveW

  • Guest
ACAD, VBA, VB and the Vista operating system
« on: March 15, 2007, 08:24:35 PM »
I currently have customers running my software on ACAD 2000i, 2002, 2004, 2005, 2006, 2007, and 2008 on the Vista OS. It has taken a few days, but we have found some interesting and undocumented facts about Vista.



I posted this on Autodesk's website. Here it is for those of you who may have missed it:




VBA to VB dll Activex binding issues in Vista

Okay, there are some issues with Vista and how VBA works with VB.

Many ocx's and dll's do not ship with Vista.
http://msdn2.microsoft.com/en-us/vbrun/ms788708.aspx

When you are creating your project and you add references to COM objects, VB runtimes, etc. make sure that the version of your file is the very newest. Vista only accepts the newest version of many of these files.
Many of the dll and ocx files that worked fine in 2K and XP will not work in Vista.

If you are using Installshield 11, not for Vista, it will install the wrong set of files. You can either get 12 or do dependency check of your dll with VB's package and deploy wizard, making a CAB file, and then search the Internet for the newest versions of each and then try those. Remember to turn off the feature/component in Installshield.

Next, VB6 service pack 6 seems to also have issues with Vista. Service pack 5 seems to work fine.

Certain dll's and Ocx's must be installed to the system32 folder or they will not work.

Dll's referenced from VBA must be registered on Visa. run, regsvr32 "your dll name". This was not required for many VB dll's before.

Dll's referenced from VBA will retain their original path. This did not happen before. As a result, your VBA dvb file will retain the old path pointing to the dll from your developer box.

It seems as though your only choice is to install the program yourself to c:\Program Files, then go back to ACAD and unload the dvb file, then reload the dvb from your installer build folder and reference the dll in your installed c:\Program Files. Then resave the dvb and repackage the installer. You will then have to tell your customers that they must install to the default c:\Program Files directory.

Well, this is what we have learned so far. Hope it helps some people out there.


Dave
« Last Edit: March 15, 2007, 08:28:49 PM by DaveW »

chobo

  • Newt
  • Posts: 24
Re: ACAD, VBA, VB and the Vista operating system
« Reply #1 on: March 16, 2007, 06:37:56 AM »
Thanks DaveW, very valuable info

Keith™

  • Villiage Idiot
  • Seagull
  • Posts: 16727
  • Superior Stupidity at its best
Re: ACAD, VBA, VB and the Vista operating system
« Reply #2 on: March 16, 2007, 09:38:42 AM »
I currently have customers running my software on ACAD 2000i, 2002, 2004, 2005, 2006, 2007, and 2008 on the Vista OS. It has taken a few days, but we have found some interesting and undocumented facts about Vista.



I posted this on Autodesk's website. Here it is for those of you who may have missed it:

Thanks Dave ... it is good that this information is passed along to those who may not know


VBA to VB dll Activex binding issues in Vista

Okay, there are some issues with Vista and how VBA works with VB.

Many ocx's and dll's do not ship with Vista.
http://msdn2.microsoft.com/en-us/vbrun/ms788708.aspx

When you are creating your project and you add references to COM objects, VB runtimes, etc. make sure that the version of your file is the very newest. Vista only accepts the newest version of many of these files.
Many of the dll and ocx files that worked fine in 2K and XP will not work in Vista.

I have found that in many instances, it is much easier to simply build my own controls ... I guess my suspicions are confirmed that Vista will require much more of that in the future, either that or a method by which we can instruct the OS to find and import the proper version of the files.

If you are using Installshield 11, not for Vista, it will install the wrong set of files. You can either get 12 or do dependency check of your dll with VB's package and deploy wizard, making a CAB file, and then search the Internet for the newest versions of each and then try those. Remember to turn off the feature/component in Installshield.

Good information .. although we don't use InstallShield, we may move more toward custom installers simply to resolve compatability issues.

Next, VB6 service pack 6 seems to also have issues with Vista. Service pack 5 seems to work fine.

We still use VB6 to maintain and develop some software, although most of the development will be moved to .net in the future. Are you saying VB6-SP6 does not work properly or the projects built with VB6-SP6 don't work properly. Although we don't have any plans to migrate to Vista in the very near future, it might affect the maintenence of some of our code.


Certain dll's and Ocx's must be installed to the system32 folder or they will not work.

Do you know if applies to only the OS dlls/Ocxs or might it apply to dlls and ocxs developed by third parties to be used in thier software. Right now we drop all of our files in the ..\Program Files\.. folder and don't bother moving them about on the hard drive .. it is simpler to maintain a single directory structure than to have files in dozens of locations all over the drive. This would most certainly affect our installations on Vista if the same rules are applied to our custom dlls and ocxs.

Dll's referenced from VBA must be registered on Visa. run, regsvr32 "your dll name". This was not required for many VB dll's before.

We have been doing this for some time now already as default. It allows us to get away from early binding .. one of the pitfalls we already discovered with regard to your next comment.


Dll's referenced from VBA will retain their original path. This did not happen before. As a result, your VBA dvb file will retain the old path pointing to the dll from your developer box.

It seems as though your only choice is to install the program yourself to c:\Program Files, then go back to ACAD and unload the dvb file, then reload the dvb from your installer build folder and reference the dll in your installed c:\Program Files. Then resave the dvb and repackage the installer. You will then have to tell your customers that they must install to the default c:\Program Files directory.

This became apparent when we started developing code for Microstation. It seems that Bentley is already ahead of the curve with regards to their implementation of VBA .. as they already store the path to the referenced files. We have had to do away completely with early binding in Microstation, and from the sound of your post, it may be necessary to do the same for AutoCAD in the future.

Well, this is what we have learned so far. Hope it helps some people out there.


Dave


It will certainly help me, thanks again for taking the time to post it.
Proud provider of opinion and arrogance since November 22, 2003 at 09:35:31 am
CadJockey Militia Field Marshal

DaveW

  • Guest
Re: ACAD, VBA, VB and the Vista operating system
« Reply #3 on: March 16, 2007, 01:43:55 PM »
We still use VB6 to maintain and develop some software, although most of the development will be moved to .net in the future. Are you saying VB6-SP6 does not work properly or the projects built with VB6-SP6 don't work properly. Although we don't have any plans to migrate to Vista in the very near future, it might affect the maintenance of some of our code.

Some projects do not work properly. To downgrade you must uninstall VB6 and reinstall. The add service pack 5. We found that a few good coders out there had mentioned it in different forums and found it to be true.


Certain dll's and Ocx's must be installed to the system32 folder or they will not work.

Do you know if applies to only the OS dlls/Ocxs or might it apply to dlls and ocxs developed by third parties to be used in thier software. Right now we drop all of our files in the ..\Program Files\.. folder and don't bother moving them about on the hard drive .. it is simpler to maintain a single directory structure than to have files in dozens of locations all over the drive. This would most certainly affect our installations on Vista if the same rules are applied to our custom dlls and ocxs.

I really do not know. Our dll runs fine from the Program File directory.

It will certainly help me, thanks again for taking the time to post it.

You are welcome. Glad it helped.

I just want to point out my real reason for pushing the issue with Vista.
I personally cannot stand it. With all the clicking to allow this or that I feel like I am being punished for the holes in the MS source code. I really feel MS does not have any clue what an end user is looking for. It is as though they are punishing the world for their mistakes in coding. It seems pretty nasty overall to me.

On the flip-side, and this is what is important, Vista 64 is immune to rootkits. Vista 32 is also, provide you do not get yourself infected, because once infected the virus or trojan can turn off the protection from rootkits. This is suppose to be fixed in service pack 1 for Vista.

Let me give you an example:

Here is an update from MS labeled critical.
http://www.microsoft.com/technet/security/bulletin/MS06-040.mspx

It has a few revisions and the last time I looked it was not included in the automatic updates. I have contacted MS and pointed out that they missed adding it to the list. So, they may have added it now.

This exploit, and this is only one example, allows any 12 year old with access to to precompiled modifications to the AFX2005 FU rootkit to exploit your machine. All they need are the tools that work, and there are now over 20 variants, and your IP. They are in for good. These are rootkit trojan servers that allow complete control of your box. They cannot be detected by ANY and I mean ANY anti virus software!!! The real robust ones put the OS into a virtualization. The OS and anything installed in cannot be trusted to determine anything because the problem is outside the OS where it cannot be seen. FYI, this effects Linux and Unix too. All you can do is monitor all processes in and out of memory, at great system resource expense, to try and catch it when it tries to hook an exe in memory or the handle of a kernel mode driver. You can do this with programs like blacklight and unhackme. Even if you catch on that something is going on, you cannot get rid of it unless you have the time and ability to do a scan of the hard drive from an external source, unbooted, and also know how to hex out the right places. It is just faster to reinstall the OS, even if it takes a few days. The rootkit is outside the OS and can hook any process at any time. It can see all the processes running, so that it can see you trying to detect it and jump to the handle of a process that has just been scanned and/or just disable your scanning software all together. The better (worse) ones do not disable anything to remain stealthy. Now I am not going to post links to these exploits, but let's just say that I am very concerned that there may be an explosion real soon. Most people will never know that their computer is really infected and how their credit card info, etc. was lifted.

While I am editing the post I figured I would mention that if your computer "is" exploitable, that there are many different variations on this process. They hacker can just load it in memory and when you reboot, it is gone. Why bother installing anything at all when they can walk in anytime they want anyway!?!

With all that said, our customers depend on our software to make them money. It is hard enough to get non-IT people (blue collar workers) to do backups. It seem better to try and support the move to an OS that is basically immune (at this current time) to the worst Internet exploit and infection ever seen.

Later...

« Last Edit: March 16, 2007, 02:08:59 PM by DaveW »

sinc

  • Guest
Re: ACAD, VBA, VB and the Vista operating system
« Reply #4 on: March 21, 2007, 12:14:07 PM »
I personally cannot stand it. With all the clicking to allow this or that I feel like I am being punished for the holes in the MS source code.

You are coming to a sad realization.  Do you wish to Allow or Deny?   :-D

DaveW

  • Guest
Re: ACAD, VBA, VB and the Vista operating system
« Reply #5 on: March 22, 2007, 12:12:05 PM »
Here is a link to files that may be missing on Vista.
These are newest versions download from MS.
The rar file is about 6 1/2 meg.

The readme file has the original download links location from MS.
I got this list originally from http://www.ppreview.net/Forum/topic.asp?TOPIC_ID=245
Many thanks to the Admin there for posting all the links.
I then downloaded them all and packaged them all up and the link to one download is below.

Note that you must unregister a previous version of the same file and then register the new one. If you fail to regsvr32 /u the ocx or dll and then just register the new one it most likely will tell you it succeeded, but it still will not work. It seems that if you just copy over the old file and unregister the the new one the unregister will still work and you can then just reregister the new one.

http://MillLister.com/dlls-and-ocx-files.rar

Microsoft Controls for Visual Basic 6.0

Microsoft ADO Data Control 6.0 (OLEDB)
MSADODC.CAB

Microsoft Chart Control 6.0 (OLEDB)
MSCHRT20.CAB

Microsoft Comm Control 6.0
MSCOMM32.CAB

Microsoft Common Dialog Control 6.0
COMDLG32.CAB


Microsoft Data Bound Grid Control 6.0
DBGRID32.CAB

Microsoft Data Bound List Controls 6.0
DBLIST32.CAB

Microsoft DataGrid Control 6.0 (OLEDB)
MSDATGRD.CAB

Microsoft DataList Controls 6.0 (OLEDB)
MSDATLST.CAB

Microsoft DataRepeater Control 6.0 (OLEDB)
MSDATREP.CAB

Microsoft FlexGrid Control 6.0
MSFLXGRD.CAB

Microsoft Hierarchical FlexGrid Control 6.0 (OLEDB)
MSHFLXGD.CAB

Microsoft Internet Transfer Control 6.0
MSINET.CAB

Microsoft MAPI Controls 6.0
MSMAPI32.CAB

Microsoft Masked Edit Control 6.0
MSMASK32.CAB

Microsoft Multimedia Control 6.0
MCI32.CAB

Microsoft PictureClip Control 6.0
PICCLP32.CAB

Microsoft RemoteData Control 6.0
MSRDC20.CAB

Microsoft Rich Textbox Control 6.0
RICHTX32.CAB

Microsoft SysInfo Control 6.0
SYSINFO.CAB

Microsoft Tabbed Dialog Control 6.0
TABCTL32.CAB

Microsoft Windows Common Controls 6.0
COMCTL32.CAB

Microsoft Windows Common Controls-2 6.0
COMCT232.CAB

Microsoft Windows Common Controls 6.0
MSCOMCTL.CAB

Microsoft Windows Common Controls-2 6.0
MSCOMCT2.CAB

Microsoft Windows Common Controls-3 6.0
COMCT332.CAB

Microsoft Winsock Control 6.0
MSWINSCK.CAB


Microsoft Objects and Libraries
Microsoft Data Access Components
MDAC20.CAB

Microsoft Data Access Components
MDAC_TYP.CAB


Microsoft Data Binding Collection Object
MSBIND.CAB

Microsoft Data Formatting Object Library
MSSTDFMT.CAB

Microsoft Data Report Designer v6.0
MSDBRPTR.CAB

Microsoft DHTML Page Run-time Library 1.0
MSHTMPGR.CAB

Microsoft OLE Automation Library
OLEAUT.CAB

Microsoft Remote Data Object 2.0
MSRDO20.CAB

Microsoft Remote Automation Library
msracli.cab

Microsoft Stock Property Page Object
msstkprp.CAB

Microsoft WebClass Library 1.0
MSWCRUN.CAB

Microsoft Visual Basic 6.0 Run-time Components
VBRUN60.CAB

Microsoft Visual Basic 6.0 Virtual Machine
MSVBVM60.CAB
 
« Last Edit: March 22, 2007, 01:03:28 PM by DaveW »

DaveW

  • Guest
Re: ACAD, VBA, VB and the Vista operating system
« Reply #6 on: March 22, 2007, 12:59:40 PM »
I personally cannot stand it. With all the clicking to allow this or that I feel like I am being punished for the holes in the MS source code.

You are coming to a sad realization.  Do you wish to Allow or Deny?   :-D

Problem is:
If I am on Vista and using a laptop with a bluetooth mouse and get that question, I loose the mouse, then have to use the touchpad to answer the question, then have to press the function key and F2 to turn off wireless and bluetooth radio, wait a few seconds, then press the function key and F2 to turn back on the wireless radio, then wait a few more seconds, and finally I have the mouse back. Of course with all of the pop-ups for allowing this or that using a laptop with a bluetooth mouse and Vista is beyond frustrating!!!!!!