Contemplating the Migration 
Author Message
 Contemplating the Migration

I have been developing a suite of VB6-SP6 Apps for the path 2+ years.  These
apps are fairly robust and have been deployed operationally on a limited
scale.  There is approximately 30 to 40K lines of code.  A big question of
the user base is "Will these apps work on Vista or Windows 7?".   A valid
question.  The Apps heavily use XML 4.0, tie to an Access 2003 database, and
rely on a small set of active X controls, and integrate with Office 2003.  
I've received a lot of help from this community over the past couple of years
to over-come hurdles in the projects - which I greatly appreciate.  So...  
where do I go from here?

Initial attempts to get things to function on Vista have been unsuccessful.  
Primary issue is getting the VB6 run-time to install.  My IS2009 install
package fails even though it is set to install on a Vista box.  I have not
spent much time with Vista and figure my user base will go from XP to Windows
7 since the new OS is just around the corner.

I know that Windows 7 has a virtual XP option...  but that seems like a
limited solution to VB6 not running on these newer OSs.

So my question...  do I migrate to Dot Net or should I consider another
path?  I could possibly use JAVA...  What about C-sharp?  I've seen reports
that VB2008 isn't all that it was cracked up to be.  I've also heard rumors
that people are moving away from Dot Net as it hasn't lived up to the
expectation or hype that it was given...

Any thoughts on the best migration path would be appreciated.



Sat, 05 Nov 2011 02:23:05 GMT  
 Contemplating the Migration

Quote:
> A big question of
> the user base is "Will these apps work on Vista or Windows 7?"

My VB6 apps work fine from Windows 95 to 7.

Quote:
> The Apps heavily use XML 4.0, tie to an Access 2003 database, and
> rely on a small set of active X controls, and integrate with Office 2003.

No problem here.

Quote:
> Initial attempts to get things to function on Vista have been
> unsuccessful.
> Primary issue is getting the VB6 run-time to install.  My IS2009 install
> package fails even though it is set to install on a Vista box.

The reason for this is that the VB6 runtime files are protected under Vista,
including their registry entries, so you can't update them nor even register
them. They are at SP6 anyway, so there is no point to try to update them.
The solution is to NOT install or register the VB6 runtimes on Windows
Vista/2008/7, so check for the OS version, and if it's Windows 2003 Server
or below, then update the runtimes. Microsoft said there is no plan to
include the VB6 run time after Windows 7, so after 7, update the VB6 runtime
as usual.

In the article below, all the files under the heading "Supported and
Shipping in Windows Vista, Windows Server 2008, and Windows 7" are
protected, so don't update or register them, just make exception in the
installer for these files.

Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008
and Windows 7
http://msdn.microsoft.com/en-us/vbasic/ms788708.aspx

Quote:
>  I have not
> spent much time with Vista and figure my user base will go from XP to
> Windows
> 7 since the new OS is just around the corner.

Besides the installation issues above, many of the things that broke some
VB6 apps started with Vista, so if your app works under Vista, it will work
under 2008/7. The main issue with Vista is changes in security, or how most
home users run as administrators in 2000/XP. Users who are members of the
limited "Users" group don't have write access to the sub folders under
"Program Files" and HKLM in the registry. They can read from these
locations, but can't write to them. In Vista, if you write to some of these
locations, it's redirected to another file. Search the newsgroups for
SHGetSpecialFolderLocation() for details.

But more importantly, when you call an API function with a flag like
ALL_ACCESS, usually the function fails with access denied error. This
happens under Windows NT4 too, but in Vista, the admin have a split
token(two personalities if you will), the default behaves as if the user is
member of "Users", and when elevated, behaves as Administrator. So if under
Vista, your program works fine when you right click and use "Run As
Administrator", then you have permissions issues.

The most common API calls that fail are OpenProcess(), RegOpenKey(Ex),
OpenFile(), CreateFile(), and VB's Open statement. Basically check any
function that has "Open", or "Create" in it's name, and any function that
manipulate files or folders. Use only the flags that you need.

Quote:
> So my question...  do I migrate to Dot Net or should I consider another
> path?

A VB6 app uses less resources than a DotNet app, so you have to add more
memory to run the newer OS'es, even more if you use a terminal server since
memory usage multiplies per process. See this article:

http://blogs.technet.com/markrussinovich/archive/2005/04/16/the-comin...



Sat, 05 Nov 2011 05:17:11 GMT  
 Contemplating the Migration
Thanks for the very informative post...  You jogged my memory on the VB6
pieces in Vista...  I'll have to try to manually load my apps onto Vista and
just run them.  I do access the Registry and store user specific application
parameters...

Does Vista protect the CurrentUser keys in the same way as LocalMachine
keys?  Guess I'll find out when I try...
Also...  does it matter which version of Vista is installed?

I'll update my installer to do checks or just create a simple Vista/Windows
7 installer.

Thanks...  

Quote:



> > A big question of
> > the user base is "Will these apps work on Vista or Windows 7?"

> My VB6 apps work fine from Windows 95 to 7.

> > The Apps heavily use XML 4.0, tie to an Access 2003 database, and
> > rely on a small set of active X controls, and integrate with Office 2003.

> No problem here.

> > Initial attempts to get things to function on Vista have been
> > unsuccessful.
> > Primary issue is getting the VB6 run-time to install.  My IS2009 install
> > package fails even though it is set to install on a Vista box.

> The reason for this is that the VB6 runtime files are protected under Vista,
> including their registry entries, so you can't update them nor even register
> them. They are at SP6 anyway, so there is no point to try to update them.
> The solution is to NOT install or register the VB6 runtimes on Windows
> Vista/2008/7, so check for the OS version, and if it's Windows 2003 Server
> or below, then update the runtimes. Microsoft said there is no plan to
> include the VB6 run time after Windows 7, so after 7, update the VB6 runtime
> as usual.

> In the article below, all the files under the heading "Supported and
> Shipping in Windows Vista, Windows Server 2008, and Windows 7" are
> protected, so don't update or register them, just make exception in the
> installer for these files.

> Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008
> and Windows 7
> http://msdn.microsoft.com/en-us/vbasic/ms788708.aspx

> >  I have not
> > spent much time with Vista and figure my user base will go from XP to
> > Windows
> > 7 since the new OS is just around the corner.

> Besides the installation issues above, many of the things that broke some
> VB6 apps started with Vista, so if your app works under Vista, it will work
> under 2008/7. The main issue with Vista is changes in security, or how most
> home users run as administrators in 2000/XP. Users who are members of the
> limited "Users" group don't have write access to the sub folders under
> "Program Files" and HKLM in the registry. They can read from these
> locations, but can't write to them. In Vista, if you write to some of these
> locations, it's redirected to another file. Search the newsgroups for
> SHGetSpecialFolderLocation() for details.

> But more importantly, when you call an API function with a flag like
> ALL_ACCESS, usually the function fails with access denied error. This
> happens under Windows NT4 too, but in Vista, the admin have a split
> token(two personalities if you will), the default behaves as if the user is
> member of "Users", and when elevated, behaves as Administrator. So if under
> Vista, your program works fine when you right click and use "Run As
> Administrator", then you have permissions issues.

> The most common API calls that fail are OpenProcess(), RegOpenKey(Ex),
> OpenFile(), CreateFile(), and VB's Open statement. Basically check any
> function that has "Open", or "Create" in it's name, and any function that
> manipulate files or folders. Use only the flags that you need.

> > So my question...  do I migrate to Dot Net or should I consider another
> > path?

> A VB6 app uses less resources than a DotNet app, so you have to add more
> memory to run the newer OS'es, even more if you use a terminal server since
> memory usage multiplies per process. See this article:

> http://blogs.technet.com/markrussinovich/archive/2005/04/16/the-comin...



Sat, 05 Nov 2011 05:49:02 GMT  
 Contemplating the Migration

Quote:
> Thanks for the very informative post...  You jogged my memory on the VB6
> pieces in Vista...  I'll have to try to manually load my apps onto Vista
> and
> just run them.  I do access the Registry and store user specific
> application
> parameters...

> Does Vista protect the CurrentUser keys in the same way as LocalMachine
> keys?  Guess I'll find out when I try...

No, current user keys and AppData folder(per user) are fully
readable/writable. It's only the machine wide settings and locations that
are read-only.

Quote:
> Also...  does it matter which version of Vista is installed?

No.

Quote:
> I'll update my installer to do checks or just create a simple
> Vista/Windows
> 7 installer.

You can just copy the EXE, and register any DLL or OCX you need and their
dependencies(if any) for testing.


Sat, 05 Nov 2011 08:23:40 GMT  
 Contemplating the Migration
And there are other problem areas with VB6 on Vista, some of which have been
overcome so not yet.

IDE problems executing:
    SendKeys
    INI routines.
  These seem to be OK in the comple app.

Compiled app problems:
   Transparancy handled differently - no click-through with Vista Aero on.
   This kills one of my apps.
   My tooltip rouines that work OK on XP blow up the screen on Vista (aero
off) and I have to reboot to clear.  Have not had time to troubleshoot this
so I just use a different method to show a tip.

Why do we  not have a place to register all the Vista related problems so we
can keep up with it?
Trying to find these in the newsgroup is difficult for me.

Quote:



> > Thanks for the very informative post...  You jogged my memory on the VB6
> > pieces in Vista...  I'll have to try to manually load my apps onto Vista
> > and
> > just run them.  I do access the Registry and store user specific
> > application
> > parameters...

> > Does Vista protect the CurrentUser keys in the same way as LocalMachine
> > keys?  Guess I'll find out when I try...

> No, current user keys and AppData folder(per user) are fully
> readable/writable. It's only the machine wide settings and locations that
> are read-only.

> > Also...  does it matter which version of Vista is installed?

> No.

> > I'll update my installer to do checks or just create a simple
> > Vista/Windows
> > 7 installer.

> You can just copy the EXE, and register any DLL or OCX you need and their
> dependencies(if any) for testing.



Sat, 05 Nov 2011 10:05:01 GMT  
 Contemplating the Migration
On Mon, 18 May 2009 19:05:01 -0700, Bee

Quote:

>Why do we  not have a place to register all the Vista related problems so we
>can keep up with it?

In terms of peer support there is

traffic, mostly misguided posts about non-VB Vista compatibility.

As you say though it would be handy if there was a common repository
of VB/Vista issues and solutions.
--
Alfie [UK]
<http://www.delphia.co.uk/>
If you tell the truth, you don't have to remember anything.



Sat, 05 Nov 2011 14:45:49 GMT  
 Contemplating the Migration
On Mon, 18 May 2009 11:23:05 -0700, Brian

Quote:

>Initial attempts to get things to function on Vista have been unsuccessful.  
>Primary issue is getting the VB6 run-time to install.

I have successfully run my VB6 application on XP2, Vista and Windows 7
Beta using a separate manifest file. That is, zero installation! Just
copy the files, including OCXs, to a new folder, create a shortcut,
bingo! I even managed to run the app off a DVD.

See here: http://www.littletyke.myzen.co.uk/ktn/index.html

MM



Sat, 05 Nov 2011 21:12:52 GMT  
 Contemplating the Migration
On Mon, 18 May 2009 14:49:02 -0700, Brian

Quote:

>Thanks for the very informative post...  You jogged my memory on the VB6
>pieces in Vista...  I'll have to try to manually load my apps onto Vista and
>just run them.  I do access the Registry and store user specific application
>parameters...

>Does Vista protect the CurrentUser keys in the same way as LocalMachine
>keys?  Guess I'll find out when I try...
>Also...  does it matter which version of Vista is installed?

>I'll update my installer to do checks or just create a simple Vista/Windows
>7 installer.

>Thanks...  

Brian, have a read of my recent posting in this thread.

MM



Sat, 05 Nov 2011 21:14:51 GMT  
 Contemplating the Migration

Quote:

> And there are other problem areas with VB6 on Vista, some of which have been
> overcome so not yet.

> IDE problems executing:
>    SendKeys

Fix:
http://visualstudiomagazine.com/articles/2007/11/13/vb-statement-agai...

Quote:
>    INI routines.

Huh?  What's the problem there?
--
.NET: It's About Trust!
 http://vfred.mvps.org


Sun, 06 Nov 2011 01:09:19 GMT  
 Contemplating the Migration


Quote:

>>    INI routines.

> Huh?  What's the problem there?

Probably permissions on where to save INI files, not the INI functions
themselves.


Sun, 06 Nov 2011 02:10:08 GMT  
 Contemplating the Migration

Quote:



>>>    INI routines.

>> Huh?  What's the problem there?

> Probably permissions on where to save INI files, not the INI functions
> themselves.

True, if going for apppath under programfiles.
--
.NET: It's About Trust!
 http://vfred.mvps.org


Sun, 06 Nov 2011 02:21:15 GMT  
 Contemplating the Migration
Hi,

MM schrieb:

Quote:
> On Mon, 18 May 2009 11:23:05 -0700, Brian

>> Initial attempts to get things to function on Vista have been unsuccessful.  
>> Primary issue is getting the VB6 run-time to install.

> I have successfully run my VB6 application on XP2, Vista and Windows 7
> Beta using a separate manifest file. That is, zero installation! Just
> copy the files, including OCXs, to a new folder, create a shortcut,
> bingo! I even managed to run the app off a DVD.

> See here: http://www.littletyke.myzen.co.uk/ktn/index.html

> MM

Works here on my WIN XP SP3 box.

One question: which tool did you use to create the manifest?

--
Ulrich Korndoerfer

VB tips, helpers, solutions -> http://www.proSource.de/Downloads/



Mon, 14 Nov 2011 09:39:29 GMT  
 Contemplating the Migration

Quote:
> [Addressed to MM] Works here on my WIN XP SP3 box.
> One question: which tool did you use to create the manifest?

It also works here on my Vista SP2 setup. I'm not sure what tool MM used to
produce the manifest but it might be Make My Manifest. I've used it for only
a short time myself purely for test purposes at the moment (version 0.6.6)
and it seems to work fine so far:

    http://mmm4vb6.atom5.com/

Mike



Mon, 14 Nov 2011 11:38:34 GMT  
 Contemplating the Migration
On Thu, 28 May 2009 03:39:29 +0200, Ulrich Korndoerfer

Quote:

>Hi,

>MM schrieb:
>> On Mon, 18 May 2009 11:23:05 -0700, Brian

>>> Initial attempts to get things to function on Vista have been unsuccessful.  
>>> Primary issue is getting the VB6 run-time to install.

>> I have successfully run my VB6 application on XP2, Vista and Windows 7
>> Beta using a separate manifest file. That is, zero installation! Just
>> copy the files, including OCXs, to a new folder, create a shortcut,
>> bingo! I even managed to run the app off a DVD.

>> See here: http://www.littletyke.myzen.co.uk/ktn/index.html

>> MM

>Works here on my WIN XP SP3 box.

>One question: which tool did you use to create the manifest?

Gr? Gott! I used Make My Manifest. See: http://mmm4vb6.atom5.com/

I first downloaded
http://home.comcast.net/~bvocs/miscdls/MMM-0-6-6.exe

and was also, like comments elsewhere on the web, a bit wary, since it
is an .exe.

Now in my Downloads folder I've also got MMM-0-6-6.ZIP, but I'm blowed
if I can find the link I got it from! Perhaps Bob knows where it's
hiding! The ZIP contains:

Readme.txt
Mmm.exe
Mmm.ini
Using MMM.rtf
Mscomctl.ocx
Comdlg32.ocx
Tlbinf32.dll

I found I could NOT use the installer MMM-0-6-6.exe on Windows 98SE
(it just loaded, then immediatly exited), but it DID work on XP.

Unfortunately, the MMM web site doesn't appear to have been updated
for several months now, so I don't know what's happening about future
developments.

By the way, I'm very pleased to hear that Know The Notes works at your
end! Yours is the FIRST actual, concrete confirmation of this! Thanks.

MM



Mon, 14 Nov 2011 16:45:07 GMT  
 Contemplating the Migration
On Thu, 28 May 2009 04:38:34 +0100, "Michael Williams"

Quote:



>> [Addressed to MM] Works here on my WIN XP SP3 box.
>> One question: which tool did you use to create the manifest?

>It also works here on my Vista SP2 setup. I'm not sure what tool MM used to
>produce the manifest but it might be Make My Manifest. I've used it for only
>a short time myself purely for test purposes at the moment (version 0.6.6)
>and it seems to work fine so far:

>    http://mmm4vb6.atom5.com/

>Mike

From one Mike to another, thanks to you, too, for your confirmation!

MM



Mon, 14 Nov 2011 16:46:00 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Tips on migration from Access 97 to Access 2002

2. sql server connect. Migration Access->sql server

3. Data Migration for MS Access

4. Access 97 ---> Access 2000 migration

5. FoxBase 2.0 Migration to Access 97

6. Application Migration VB4 to VB5

7. Migration Schedule+ to Outlook 2000

8. Excel 97 to XP migration

9. User Migration and changing Document Properies

10. Migration Office 95 - 20000

11. pst migration

12. Mail migration from Lotus Notes to Outlook 2000

 

 
Powered by phpBB® Forum Software