VB6 runtime is supported on Windows 7 
Author Message
 VB6 runtime is supported on Windows 7

Has anyone noticed that the VB6 runtime is now supported on Windows 7?

The support statement page - http://www.*-*-*.com/
- now says

The core Visual Basic 6.0 runtime will be supported for the full
lifetime of Windows Vista, Windows Server 2008 and Windows 7,which is
five years of mainstream support followed by five years of extended
support.

I don't know when it was changed, because it didn't say that a couple
of weeks ago, but it does now. Yippee!



Tue, 16 Aug 2011 06:29:17 GMT  
 VB6 runtime is supported on Windows 7
Hi Mark,


Quote:
> Has anyone noticed that the VB6 runtime is now supported on Windows 7?

> The support statement page -
> http://msdn.microsoft.com/en-us/vbrun/ms788708.aspx
> - now says

> The core Visual Basic 6.0 runtime will be supported for the full
> lifetime of Windows Vista, Windows Server 2008 and Windows 7,which is
> five years of mainstream support followed by five years of extended
> support.

> I don't know when it was changed, because it didn't say that a couple
> of weeks ago, but it does now. Yippee!

Yeh I think it only got updated this week as I saw MSDN blog posts about it
starting yesterday.  The page seems to have an ominous warning on it though
:

<quote>
VB6 runtime will ship and will be supported in Windows 7 for the lifetime of
the OS.  Developers can think of the support story for Vista being the same
as it is for Windows 7.  However there are no plans to include VB6 runtime
in future versions of Windows beyond Windows 7.
</quote>



Tue, 16 Aug 2011 07:10:51 GMT  
 VB6 runtime is supported on Windows 7



| <quote>
| VB6 runtime will ship and will be supported in Windows 7 for the lifetime
of
| the OS.  Developers can think of the support story for Vista being the
same
| as it is for Windows 7.  However there are no plans to include VB6 runtime
| in future versions of Windows beyond Windows 7.
| </quote>

So what?  Most developers worth their salt include necessary runtime files.
Go pedal your negativity someplace else.



Tue, 16 Aug 2011 08:12:18 GMT  
 VB6 runtime is supported on Windows 7

Quote:
> Has anyone noticed that the VB6 runtime is now supported on Windows 7?

  Thanks for that. I had been wondering about secondary
support. For instance, the RTB control wouldn't be much
good if there's no RichEdit v. 1 emulation. But the
page you linked is very clear and detailed, and it looks
like there's little, if anything, to be concerned about in
terms of secondary files.


Tue, 16 Aug 2011 12:59:43 GMT  
 VB6 runtime is supported on Windows 7
On Thu, 26 Feb 2009 14:29:17 -0800 (PST),

Quote:

>Has anyone noticed that the VB6 runtime is now supported on Windows 7?

>The support statement page - http://msdn.microsoft.com/en-us/vbrun/ms788708.aspx
>- now says

>The core Visual Basic 6.0 runtime will be supported for the full
>lifetime of Windows Vista, Windows Server 2008 and Windows 7,which is
>five years of mainstream support followed by five years of extended
>support.

>I don't know when it was changed, because it didn't say that a couple
>of weeks ago, but it does now. Yippee!

Yes, I have already successfully tested my VB6 application on Windows
7 Beta. It works absolutely fine.

MM



Tue, 16 Aug 2011 16:55:28 GMT  
 VB6 runtime is supported on Windows 7
On Fri, 27 Feb 2009 10:10:51 +1100, "Bill McCarthy" <TPASoft.com Are

Quote:

>Hi Mark,



>> Has anyone noticed that the VB6 runtime is now supported on Windows 7?

>> The support statement page -
>> http://msdn.microsoft.com/en-us/vbrun/ms788708.aspx
>> - now says

>> The core Visual Basic 6.0 runtime will be supported for the full
>> lifetime of Windows Vista, Windows Server 2008 and Windows 7,which is
>> five years of mainstream support followed by five years of extended
>> support.

>> I don't know when it was changed, because it didn't say that a couple
>> of weeks ago, but it does now. Yippee!

>Yeh I think it only got updated this week as I saw MSDN blog posts about it
>starting yesterday.  The page seems to have an ominous warning on it though
>:

><quote>
>VB6 runtime will ship and will be supported in Windows 7 for the lifetime of
>the OS.  Developers can think of the support story for Vista being the same
>as it is for Windows 7.  However there are no plans to include VB6 runtime
>in future versions of Windows beyond Windows 7.
></quote>

I think Microsoft is deparate to get some kudos from the general
public, who in recent years only got to hear the term "Microsoft" in
the context of major US or European anti-trust enquiries, all of which
seem to end up with Microsoft in the doghouse. Microsoft have had to
take on board that VB6 ain't going to die until there is something new
that is equal or better, which, of course, VB.Net is not. So I see VB6
support (in the sense of supported by the OS) being maintained for a
very long time indeed. Also, the revelation that reg-free com can work
very well from XP onwards means that there will be potentially many
more VB6 applications to bear fruit over the next few years. VB6 is
the best, the most productive, the all-round world-beating programming
system ever to have been invented and Microsoft, partially its
inventor, though initially reluctantly, has had to bite the bullet and
commit to it again in order to secure its own bottom line by not
pissing off the whole world continually in that arrogant manner of
five or so years ago.

By the way, who has been banging on the loudest over many years about
DLL Hell and that it could have been handled better by wrapping every
application up with all its functionality in one entity instead of
being spread around all over the place?

Moi.

Oh, and I've just checked the price of 1 terabyte internal hard drives
and they're down to around 130 bucks nowadays. That's an awful lot of
"duplicated functionality", which was always the bugbear people moaned
about as they continued to justify DLL Hell.

MM



Tue, 16 Aug 2011 17:15:47 GMT  
 VB6 runtime is supported on Windows 7

Quote:
> Microsoft have had to
> take on board that VB6 ain't going to die until there is something new
> that is equal or better, which, of course, VB.Net is not. So I see VB6
> support (in the sense of supported by the OS) being maintained for a
> very long time indeed.

   For better or worse, they're not really focused there.
The bigger compatibility problem going forward is likely to
be the "security" problem, with non-signed, non-MS code
of any kind being increasingly unwelcome. The idea is not
that you should switch from VB to VB.Net for Windows
software. The idea is that you should drop Windows
software, buy into the cloud fad, take up .Net, and eventually
use .Net with Azure, so that MS can have a tollbooth between
you and you customers, charging *you* for your customers'
uage of *your* software.

Quote:
> Also, the revelation that reg-free com can work
> very well from XP onwards means that there will be potentially many
> more VB6 applications to bear fruit over the next few years.

   I don't know how useful this is to people, but I've been
discovering the option to load reg-free COM objects lately.
It not only doesn't require registration. It also doesn't require
any special Windows version, or whathever other limitations
Microsoft's reg-free COM might have.

  This functionality never mattered to me before because I
avoid shipping OCXs or custom ActiveX DLLs. But recently I
decided that I'd like to add a DLL to a project and it seems
silly to have to deal with the potential problems of COM
registration when my DLL is going to stay in the program folder,
used only by me.

  I've adapted Matthew Curland's code, which is very compact,
and it seems to work just fine to create objects given a file
path and CLSID, with no registration needed. There's also a
version of that that was published by vbAdvance, although their
website seems to be gone now. And if I'm not mistaken, Olaf
Schmidtt also also offers that functionality in his tools.
(Sorry if I misspelled your last name, Olaf. I can never
seem to remember that spelling. :)

   I'm surprised that this method doesn't get much attention.
Other than requiring a slightly funky bit of assembly code it's
very straightforward. It just calls the APIs that Windows
would call if one were going through COM to create an object.
Unfortunately, although this method is quite simple, I don't have
a version that I feel I can legally post here in public or that I
can offer a link to. I have two versions myself, but they're
based on code that's not mine.



Tue, 16 Aug 2011 22:16:39 GMT  
 VB6 runtime is supported on Windows 7
The implication probably being that once MS stops shipping the run time they
will also stop
supporting it on that OS.


Quote:
> So what?  Most developers worth their salt include necessary runtime
> files.
> Go pedal your negativity someplace else.



Wed, 17 Aug 2011 00:49:15 GMT  
 VB6 runtime is supported on Windows 7



Quote:
>    I don't know how useful this is to people, but I've been
> discovering the option to load reg-free COM objects lately.
> It not only doesn't require registration. It also doesn't require
> any special Windows version, or whathever other limitations
> Microsoft's reg-free COM might have.

>   This functionality never mattered to me before because I
> avoid shipping OCXs or custom ActiveX DLLs. But recently I
> decided that I'd like to add a DLL to a project and it seems
> silly to have to deal with the potential problems of COM
> registration when my DLL is going to stay in the program folder,
> used only by me.

>   I've adapted Matthew Curland's code, which is very compact,
> and it seems to work just fine to create objects given a file
> path and CLSID, with no registration needed.

Be careful with the Curland-Code - it involves calling
a function from its function-pointer in a way, which
is not working (means crashing) on systems with
enabled execution-prevention IIRC.

Quote:
> There's also a version of that that was published by
> vbAdvance, although their website seems to be gone
> now.
> And if I'm not mistaken, Olaf Schmidtt also also offers
> that functionality in his tools.

The vbAdvance-Version was based on my first published
Code-Snippet here:
<
http://groups.google.de/group/microsoft.public.vb.com/browse_frm/thre...

But this older version is also not covering the potential
Execution-Prevention-issues in the right way.
I posted a CallFunctionByPointer-approach ca. one year
later, which is using the MemAllocation in the correct way:
<
http://groups.google.de/group/microsoft.public.vb.winapi/browse_frm/t...
(please look at ThreadEntry Nr. 8, which is the post
 where I got it "right" finally ;-)

Nonetheless I'd recommend to use the small (StdAPI)-Dll,
which I made for that purpose (DirectCOM.dll) - this Dll
is known to work without any Exec-Prevention-issues
on all systems from Win98 to Vista - and it is also safe to
use in threaded scenarios, where the "direct VB5/6-based"
approaches have shown some issues, and it also covers
Lib-Handle-Caching etc.

Quote:
> (Sorry if I misspelled your last name, Olaf. I can never
> seem to remember that spelling. :)

It is Schmidt - but there are also a lot of 'Schmitts'
"out there" (at least here in germany) <g>

Olaf



Wed, 17 Aug 2011 01:54:37 GMT  
 VB6 runtime is supported on Windows 7
Hi,

mayayana schrieb:

Quote:
> ...
>> Also, the revelation that reg-free com can work
>> very well from XP onwards means that there will be potentially many
>> more VB6 applications to bear fruit over the next few years.

>    I don't know how useful this is to people, but I've been
> discovering the option to load reg-free COM objects lately.
> It not only doesn't require registration. It also doesn't require
> any special Windows version, or whathever other limitations
> Microsoft's reg-free COM might have.

>   This functionality never mattered to me before because I
> avoid shipping OCXs or custom ActiveX DLLs. But recently I
> decided that I'd like to add a DLL to a project and it seems
> silly to have to deal with the potential problems of COM
> registration when my DLL is going to stay in the program folder,
> used only by me.

>   I've adapted Matthew Curland's code, which is very compact,
> and it seems to work just fine to create objects given a file
> path and CLSID, with no registration needed. There's also a
> version of that that was published by vbAdvance, although their
> website seems to be gone now. And if I'm not mistaken, Olaf
> Schmidtt also also offers that functionality in his tools.
> (Sorry if I misspelled your last name, Olaf. I can never
> seem to remember that spelling. :)

Download link is:

<http://www.thecommon.net/10.html>

And Olafs surname is Schmidt :-)

Quote:
>    I'm surprised that this method doesn't get much attention.
> ...

This surprises me too. Olafs dll for reg free COM is out since years,
and can handle ActiveX components (OCX) too. It does not depend on XP or
above and gives full control to the programmer.

The MS "official" ways for reg free COM are clumsy and handicapped. They
more obscure getting reg free COM to work than to actively support it.
Must be some marketing reasons behind why MS does so as it does.

--
Ulrich Korndoerfer

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



Wed, 17 Aug 2011 02:19:45 GMT  
 VB6 runtime is supported on Windows 7

Quote:



>>    I don't know how useful this is to people, but I've been
>> discovering the option to load reg-free COM objects lately.
>> It not only doesn't require registration. It also doesn't require
>> any special Windows version, or whathever other limitations
>> Microsoft's reg-free COM might have.

>>   This functionality never mattered to me before because I
>> avoid shipping OCXs or custom ActiveX DLLs. But recently I
>> decided that I'd like to add a DLL to a project and it seems
>> silly to have to deal with the potential problems of COM
>> registration when my DLL is going to stay in the program folder,
>> used only by me.

>>   I've adapted Matthew Curland's code, which is very compact,
>> and it seems to work just fine to create objects given a file
>> path and CLSID, with no registration needed.
>Be careful with the Curland-Code - it involves calling
>a function from its function-pointer in a way, which
>is not working (means crashing) on systems with
>enabled execution-prevention IIRC.

>> There's also a version of that that was published by
>> vbAdvance, although their website seems to be gone
>> now.
>> And if I'm not mistaken, Olaf Schmidtt also also offers
>> that functionality in his tools.
>The vbAdvance-Version was based on my first published
>Code-Snippet here:
><
>http://groups.google.de/group/microsoft.public.vb.com/browse_frm/thre...

>But this older version is also not covering the potential
>Execution-Prevention-issues in the right way.
>I posted a CallFunctionByPointer-approach ca. one year
>later, which is using the MemAllocation in the correct way:
><
>http://groups.google.de/group/microsoft.public.vb.winapi/browse_frm/t...
>(please look at ThreadEntry Nr. 8, which is the post
> where I got it "right" finally ;-)

>Nonetheless I'd recommend to use the small (StdAPI)-Dll,
>which I made for that purpose (DirectCOM.dll) - this Dll
>is known to work without any Exec-Prevention-issues
>on all systems from Win98 to Vista - and it is also safe to
>use in threaded scenarios, where the "direct VB5/6-based"
>approaches have shown some issues, and it also covers
>Lib-Handle-Caching etc.

>> (Sorry if I misspelled your last name, Olaf. I can never
>> seem to remember that spelling. :)
>It is Schmidt - but there are also a lot of 'Schmitts'
>"out there" (at least here in germany) <g>

>Olaf

Olaf, is DirectCOM.dll freeware?

MM



Wed, 17 Aug 2011 04:20:14 GMT  
 VB6 runtime is supported on Windows 7
http://groups.google.de/group/microsoft.public.vb.winapi/browse_frm/t...
e9859b326a3134d?q=vb+sss+asm#233d3b679215ba84

Quote:
> (please look at ThreadEntry Nr. 8, which is the post
>  where I got it "right" finally ;-)

> Nonetheless I'd recommend to use the small (StdAPI)-Dll,
> which I made for that purpose (DirectCOM.dll) - this Dll
> is known to work without any Exec-Prevention-issues
> on all systems from Win98 to Vista - and it is also safe to
> use in threaded scenarios, where the "direct VB5/6-based"
> approaches have shown some issues, and it also covers
> Lib-Handle-Caching etc.

  Thank you. I'd prefer to have code rather than an extra
library, but your DLL is nicely compact and frankly I only
partly understand your code and Matthew Curland's code.
So I'm really not in a position to judge whether writing my
own code is a good idea. I assume that the problem you're
talking about is when DEP is set for all processes? I'm only
vaguely familiar with that. I would have thought it was a
rare setting.

  With you DLL sample: There's not much explanation. You
don't have any documentation? Is the function GETINSTANCE
all that's needed to load an object? GETINSTANCE(Path, ClassName) ?
And the DLL reads the embedded type library to translate the
class name to CLSID? How is the object then released? You seem
to have a function UNLOADCOMDLL but I don't see any place
in your sample code where that's used.

Quote:

> > (Sorry if I misspelled your last name, Olaf. I can never
> > seem to remember that spelling. :)
> It is Schmidt - but there are also a lot of 'Schmitts'
> "out there" (at least here in germany) <g>

   Ah. I'll try to remember that. There's a quirky symptom
of aging I've noticed, whereby I seem to have the most
trouble remembering things I learned after my youth. For
instance, I'm more likely to remember someone's name if
I new a person by that name in childhood.  :)


Wed, 17 Aug 2011 04:10:28 GMT  
 VB6 runtime is supported on Windows 7



Quote:
> Olaf, is DirectCOM.dll freeware?

Yes, it is part of my small framework, which is in
the Public Domain and consists of three Dlls currently:

dhRichClient3.dll
sqlite36_engine.dll
DirectCOM.dll

Only the first one is an AX-Dll, so you would have
to put a reference to it in your project-settings, if
you want to use its Classes earlybound.

But DirectCOM.dll can load any AX-Dll regfree over
the GETINSTANCE(DllPath, ClassName) - Call,
not only the dhRichClient3.dll-Classes.

Included in the RichClient-AX is a Class, which makes
the instantiation of RichClient-internal (Public) Classes
even more easier, once you "bootstrapped" (meaning
the regfree loading) the appropriate cFactory-Class
(usually in a *.bas-module, so that the Factory is
 "visible" throughout your whole VB-Project).

Behind this "Factory" are currently a Constructor-Helper,
simply called 'c' and a class called 'regfree', which
offers the regfree loading (and also the new regfree
thread-instanciations) then behind a COM-Interface.

But DirectCOM.dll can also be used "standalone",
if you don't need the functionality of the RichClient-
Classes.

Olaf



Wed, 17 Aug 2011 06:10:52 GMT  
 VB6 runtime is supported on Windows 7



Quote:
>   Thank you. I'd prefer to have code rather than an extra
> library, but your DLL is nicely compact ...

Yep, it's a powerbasic-Compile - and so the calling
of Functions by Pointer was not requiring any Assembler-
"workarounds" as with the VB-Code, hence no DEP-
issues possible.

Quote:
> and frankly I only partly understand your code and
> Matthew Curland's code.
> So I'm really not in a position to judge whether writing my
> own code is a good idea. I assume that the problem you're
> talking about is when DEP is set for all processes?

Yep.

Quote:
> I'm only vaguely familiar with that. I would have thought it
> was a rare setting.

Yes, the default-setting is, that (at least XP) only
watches the "wellknown" Binaries.

Quote:
>   With you DLL sample: There's not much explanation.
> You don't have any documentation?

Yep, thought the examples were sufficient...<g>

Quote:
> Is the function GETINSTANCE all that's needed to load
> an object? GETINSTANCE(Path, ClassName) ?

Yes.
Simply look at it as a fully compatible working replacement
to CreateObject().
Instead of giving the (two-part) ProgID in one Parameter,
you will have to give a fully qualified path to your AX-Dll
in the first one - and the ClassName (the "right-part" of
the ProgID) in the second Param.

One thing should be mentioned though:
The only cases where the approach does not work
regfree is, when you want to instantiate a Public-Class
of your Dll, and this *Class* does contain the definition
of a Public Type - but Public Enums on the other hand
work fine.

Quote:
> And the DLL reads the embedded type library to translate the
> class name to CLSID?

Yes.

Quote:
> How is the object then released?

GetInstance returns with: 'As Object'
The instantiated and delivered Object-instance is released
in the usual way, when its last reference goes out of scope
(in the same way as with CreateObject-generated instances).
Or do you mean the Dll itself?

Quote:
> You seem to have a function UNLOADCOMDLL but I
> don't see any place in your sample code where that's used.

The loaded Library-Handle(s) of the AX-Dll(s) are cached
internally (and then reused) for the next instantiation-request.
After your Process (or the VB-IDE) terminates, all Lib-
Handles are freed automatically.

The UNLOADCOMDLL is there, if you want to unload
an already loaded COM-Dll and free its Lib-handle
*whilst* your process is yet running - e.g. to perform
an (online-) update or something in this regard (Dll-
replacement) without the need, to shut-down your
App completely.

In my projects I never used it so far - but it is there
and it works (but make sure, you have set all Obj-
instances which you got from this Dll to Nothing,
before you call it - there's a DllCanUnloadNow-
check included before the Unloading itself is allowed).

Olaf



Wed, 17 Aug 2011 06:43:45 GMT  
 VB6 runtime is supported on Windows 7

Quote:

> One thing should be mentioned though:
> The only cases where the approach does not work
> regfree is, when you want to instantiate a Public-Class
> of your Dll, and this *Class* does contain the definition
> of a Public Type - but Public Enums on the other hand
> work fine.

   Ugh. That's exactly what I want. I have a public
type that I want to pass a copy of to the caller,
which is compiled with a reference to the DLL. Is
there any way around that limitation?

Quote:
> The UNLOADCOMDLL is there, if you want to unload
> an already loaded COM-Dll and free its Lib-handle
> *whilst* your process is yet running - e.g. to perform
> an (online-) update or something in this regard (Dll-
> replacement) without the need, to shut-down your
> App completely.

> In my projects I never used it so far - but it is there
> and it works (but make sure, you have set all Obj-
> instances which you got from this Dll to Nothing,
> before you call it - there's a DllCanUnloadNow-
> check included before the Unloading itself is allowed).

   Thanks for the explanation. I'm in a situation where I
need to keep the object loaded only for a brief time, so
I have an event in the object that tells me I'm done with
it. But it sounds like that's no problem. If I understand you
correctly I can just do:

Set Obj = nothing
UNLOADCOMDLL

 No paramaters needed for that call? There's assumed to
be only 1 DLL loaded?



Wed, 17 Aug 2011 07:14:22 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. How to check, if a control supports READONLY property at Runtime in Windows Forms

2. Windows 7 and VB6 Runtime

3. VB6 Runtimes in Windows 7 ?

4. Access Runtime - Am I Missing Something?

5. Does mscomctl for vb6 need the vb6 runtimes?

6. URGENT MICROSOFT SUPPORT ISSUE - using ADO recordsets bound to Access .mbd Formsat runtime

7. Runtime 438 object dosenot support this property or method

8. Runtime error '3228': Selected collating sequence not supported by the operating system

9. ocx runtime support - missing files message

10. Determining, at runtime, if a object supports a method

11. Does VB have any support for runtime statements

12. Am I top Windows expert?

 

 
Powered by phpBB® Forum Software