VB Runtime NOT in next Windows

From

http://blogs.artinsoft.net/fzoufaly/...t-windows.aspx

VB Runtime NOT in next Windows

Here is an excerpt from an article that Greg DeMichillie wrote on Directions on Microsoft April Edition:

"The planned follow-on release to Windows Vista, code-named Windows 7, will not include the Visual Basic 6.0 (VB 6) runtime libraries, Microsoft has begun informing customers. This sets a timeframe for the final end of support for the runtime."

As we have informed on several occasion in this Blog, Microsoft is performing all the normal steps to retire a technology from market. Visual Basic 6 was/is a tremendously popular technology but never the less it will have to go away.

Jarvis Coffin once said: "All technologies fade away, but they don’t die." This is most probably what is going to happen to VB6 (hey.. we still have COBOL code written more than 30 years ago that is alive and kicking!!!) but the question I have for you is: will you embrace the new technology? Or will you fade away with it?

It is time to upgrade your skills as a developer and also to migrate your application to greener grounds.

So it looks like VB6 apps have their days numbered...

Moved to General Developer

This is hardly news (and, you can always install whatever dependency files your project requires using and installation and setup package. - in fact, you should never depend on the runtimes being there before hand...always include them.)

I welcome that news... although Windows 7 is years away from full adoption, it should give companies the needed motivation to start porting the apps over to this more 'unified' framework.

Quote:

---

Originally Posted by esposito

VB Runtime NOT in next Windows

"The planned follow-on release to Windows Vista, code-named Windows 7, will not include the Visual Basic 6.0 (VB 6) runtime libraries, Microsoft has begun informing customers. This sets a timeframe for the final end of support for the runtime."

---

This is bull, I've run full database apps on Vista and they have run perfectly without any add-ons, so the VB6 runtimes files are installed as standard on any WinNT machine. ;)

Keithuk - okay.... right... but what about AFTER VISTA? Vista is Windows 6 .... It's Windows 7 that's the target of that article. Yes, the VB6 runtimes were included in Vista... but that doesn't mean they will be on the next one.

-tg

Quote:

---

Originally Posted by mendhak

I welcome that news... although Windows 7 is years away from full adoption, it should give companies the needed motivation to start porting the apps over to this more 'unified' framework.

---

Heck, Vista is years away from full adoption.

Quote:

---

Originally Posted by mendhak

I welcome that news... although Windows 7 is years away from full adoption, it should give companies the needed motivation to start porting the apps over to this more 'unified' framework.

---

I have already started porting my applications over to Embarcadero Delphi, which allows me to produce standalone software in native code.

When the enormous .NET Framework 3.5 was released, I understood that if I wanted to make my apps get rid of huge runtimes or virtual machines all I had to do was abandon MS development tools and look elsewhere.

Quote:

---

Originally Posted by techgnome

Keithuk - okay.... right... but what about AFTER VISTA? Vista is Windows 6 .... It's Windows 7 that's the target of that article. Yes, the VB6 runtimes were included in Vista... but that doesn't mean they will be on the next one.

-tg

---

I've never heard Vista called Window 6. Actually Vista is still quite new in respect of other operating systems. Even with SP1 there are still a lot of bugs, we will have to wait and see what happens next.

Any installation package that you use for your app should always include the VB6 runtime files so there still isn't a problem. ;)

"Windows 7" is actually Windows 6.1 internally, and a fairly modest change from Vista. It is almost identical to Win 2008 Server in most respects (also versioned as 6.1) and VB6 is still supported there.

That guy writing the blog at the link above has a vested interest in selling VB to .Net migration tools. He speaks with ZERO authority and the guy he was quoting was ex-Microsoft even back when the blog post was written.

I've tried the thorny Delphi road several times over the years. Toxic user community, clunky component model, archaic module-decoration syntax (at least VB had the grace to hide the gingerbread), a joke of an IDE, doc/help system like a maze of funhouse mirrors, etc.

I wanted to like Delphi. I now realize its function is to steal just enough of the tools market to prevent anyone else from making money by developing a better product.

Quote:

---

Originally Posted by dilettante

"Windows 7" is actually Windows 6.1 internally, and a fairly modest change from Vista. It is almost identical to Win 2008 Server in most respects (also versioned as 6.1) and VB6 is still supported there.

That guy writing the blog at the link above has a vested interest in selling VB to .Net migration tools. He speaks with ZERO authority and the guy he was quoting was ex-Microsoft even back when the blog post was written.

---

I really hope you are right and that the VB6 runtime files will be included in Windows 7. I am firmly convinced that the less you have to install on the user's machine, the better.

Quote:

---

I've tried the thorny Delphi road several times over the years. Toxic user community, clunky component model, archaic module-decoration syntax (at least VB had the grace to hide the gingerbread), a joke of an IDE, doc/help system like a maze of funhouse mirrors, etc.

I wanted to like Delphi. I now realize its function is to steal just enough of the tools market to prevent anyone else from making money by developing a better product.

---

I have to agree with you when you say that the Delphi user community is not as good and widespread as the VB one is. For example, you can't find any Delphi forums that are as professional as VBForums is. This is the only thing I have been missing so much since I switched from VB6 to Delphi.

I don't agree with your definition of the Delphi IDE as a joke. The standard Delphi toolbox contains more controls than the VB6 one and I don't find any particular difficulty using it. To be honest, in my humble opinion, Delphi is the only valid tool on the market that can compete with VB in terms of productivity and easiness of use. What does the VB6 IDE have more than Delphi?

Quote:

---

Originally Posted by Shaggy Hiker

Heck, Vista is years away from full adoption.

---

I'm afraid that will never happen and Windows 7 will have the same destiny...
It's not about products we like (or not for that matter) but rather investments (often significant) which is what (mostly) drives most major corps to stay with XP.
Also vendors - we have a major enterprise package written in VB6 by third party and that application is the only complete package adapted by the entire industry.
It's huge and there is no way they are able to migrate it some other technolgy (ms .net , java, etc...) in short period of time - it will take years.
And as far as I know nobody in the industry is willing to reinvest in the new version which is already "in the works".
Meantime all new in-house development is done in dot net.

Quote:

---

Originally Posted by esposito

I don't agree with your definition of the Delphi IDE as a joke. The standard Delphi toolbox contains more controls than the VB6 one and I don't find any particular difficulty using it. To be honest, in my humble opinion, Delphi is the only valid tool on the market that can compete with VB in terms of productivity and easiness of use. What does the VB6 IDE have more than Delphi?

---

My feelings about the Delphi IDE come from its crowded appearance, sloppy and slow performance, and tendency to crash. The Properties toolwindow (
"Object Inspector") and its inappropriate treeview are one example of the poor design. Though by Delphi 2005 things had improved a great deal, the best thing I can say about it is it works a lot better than the truly awful Lazarus IDE. At least the Delphi IDE's operation is a lot smoother and more rational than the one in REALBasic.

Even with all of my disappointment in Delphi I'll admit there is no other serious alternative out there to VB6.

Quote:

---

Originally Posted by Keithuk

Actually Vista is still quite new in respect of other operating systems.

---

Windows XP came out in 2001, an eternity ago.

Windows Vista has been in users' hands for almost two years now. Service Pack 2 is being readied right now.

Windows 7 developer pre-releases will be distributed next week at PDC 2008.


We heard this same nay-saying back when XP came out and people wouldn't give up Windows 95 and 98. Corporate deployment always lags home and small business deployment, so the slow adoption of Vista there has been no surprise.

Programs that were written according to Windows Guidelines that go back to Windows 2000 (and even to Windows 95 in some areas) have little problem on Vista, especially if they were written to conform to the old WinXP least-privileged user account (LUA) standards.

The only hard truths I see about Vista are that it requires more modern and powerful hardware and that programs non-compliant with LUA are harder to run and maintain because of the UAC features added to Vista to improve security. Very little of this will change in Windows 7.

Broader adoption will occur once the strangling dead weight of the "I.T. types" finally gets on board, and they stop downgrading new corporate machines back to Windows XP. I'm sure the economy will play a part here as well, slowing desktop PC replacement even more for a while. XP is basically dead at this date though, about where 95/98 was in 2004 and Windows 2000 was in 2006. I'm reminded of the Windows 3.1 holdouts back in 1997 too.


Change in itself isn't such a good thing. You can only hold back the tide in your mind though - the reality is you'll get very wet trying to do so. It is time to embrace the horror.

Well Windows 7 bits are not pre-release as its pre-beta and pre-ctp version that is going to be handed out to the PDC attendees on a drive for personal evaluations.

Windows 7 Beta will be out soon and RTM version expected within a year to 18 months from know as far as I have heard.

Windows 7 will hurt Vista's adoption even more but I think MS' rush to get it out is an attempt to spur more sales and adoption of its Vista platform with a rebranded name. Remember "the mojavie experiment"? ;)

I am really glad if they dont ship the VB6 runtimes in Windows 7. Like mentioned you should never rely upon them being present. Always create a proper installer etc. This is not waying that the VB6 runtimes will not work on Windows 7, only that they are not shipping pre-installed. Big deal :rolleyes: Now lets just wait to see if its also not going to run on Windows 7, then everyone can cry and complaign.

I should be able to answer this Tuesday monring as Monday night I am attending the MS/MVP dinner at the PDC. If its not anything NDA like I can post something up. :)

Quote:

---

Originally Posted by Shaggy Hiker

Heck, Vista is years away from full adoption.

---

I doubt MS themselves are even adopting Vista in their primary dev offices.

Thats a good question to ask them. Surely that would be a yes even if it may not be 100% accurate. I'll ask

Quote:

---

Originally Posted by dilettante

Though by Delphi 2005 things had improved a great deal, the best thing I can say about it is it works a lot better than the truly awful Lazarus IDE. At least the Delphi IDE's operation is a lot smoother and more rational than the one in REALBasic.

Even with all of my disappointment in Delphi I'll admit there is no other serious alternative out there to VB6.

---

Since MS discontinued VB6, I have been searching for a valid alternative to develop native software. Initially, REALbasic had attracted my attention but the user community was so poor that I immediately thought I'd better look for something better supported.

As fas as Delphi's user communities are concerned, there are three or four of them that could be considered reliable enough but I feel Embarcadero still has a long way to go to spread the Delphi Gospel in the world.

At the moment, I can see no alternative to VB6 better than Delphi and I have to say I have already got quite familiar with the Delphi code. I have already produced at least ten commercial applications in Delphi and so far my customers have not complained about their stability. There have been some minor problems, but I have always been able to sort them out and in all cases the bugs were caused by my lack of experience with this new programming environment, never by Delphi.

Unfortunately, the .NET languages are not suitable for my needs and for this reason I am gradually abandoning VB6 and trying to find the best replacement. So far Delphi has not disappointed me.

VB6 didn't create native language either. If you really want native language, why don't you write in C++? They you get the better IDE that comes with .NET, and you can create a fully native app that requires no runtime. You won't have the question of whether the VB6 runtimes will be supported, and your well known objections to .NET won't impact you either.

Quote:

---

Originally Posted by RobDog888

Like mentioned you should never rely upon them being present.

---

This is obsolete advice. Every supported version of Windows (from Windows 2000 SP4 onward) has a version of the VB6 runtimes that is later than VB6 SP4. Once you get to XP SP3 you have a version of the runtimes that is later than VB6 SP6.

If you want to deploy to the older supported Windows versions (like Win2K SP4, XP Gold) you need to test against those versions of the runtimes or deploy newer VB6 runtimes. If you want to deploy to an unsupported OS (like Win98) you'll really want to deploy newer VB6 runtimes.

As long as you're deploying to XP SP2 or later there is no need for a "proper installer" at all if you create an XCopy deployment package. This requires isolation manifests of course in order to use reg-free COM. It is safer still to limit XCopy deployment to XP SP3, because SP2 does not include the VB6 SP6 runtimes and there was a change in VB6 SP6 to provide better reg-free COM support that might impact your application. XP SP2 is usually good enough, and even XP SP1 will almost always work - but you really should test your application on those levels of Windows before attempting XCopy deployment.

However...

Most of the time you'll want a "proper installer" even if you use reg-free COM. That is because you usually want to create Start Menu shortcuts and create application directories and add data files under CommonAppData.

Creating a proper per-user MSI package even allows a formal install of a VB6 program to be done by users without requiring elevation under Vista or Windows 2008 Server with UAC active. It also works under XP as well of course.

The sweet spot for XCopy-deployable applications is the portable application market: programs "installed" onto a USB drive of some sort with or without an application manager like the U3 system, or a CD-ROM.


I fully expect there to be no change in status once Windows 7 is released. What I do expect is that the VB6 Support Statement will be updated regarding VB6 at runtime to include Windows 7 (though not the VB6 IDE). I also suspect the IDE will run on Windows 7 just fine, it just will never be claimed to be supported.


VC++ requires a runtime just as much as VB6 does. I have no idea where people get these notions.

Microsoft Visual C++ 2008 Redistributable Package (x86)


Only time will tell what Windows 7 will bring. At least in a week or less we should know more than we do today.

Quote:

---

Originally Posted by Shaggy Hiker

VB6 didn't create native language either. If you really want native language, why don't you write in C++? They you get the better IDE that comes with .NET, and you can create a fully native app that requires no runtime. You won't have the question of whether the VB6 runtimes will be supported, and your well known objections to .NET won't impact you either.

---

C++ is not as easy as Delphi is. Correct me if I am mistaken but I think that C++ does not even have a VB-like form designer, so you would have to spend a lot of time to code your app's interface.

What is the reason why I don't want to depend on huge frameworks or runtimes? The answer is, more and more often people share applications in LAN's and Delphi (but even VB6) is just perfect for this purpose. All you have to do is place your exe in a shared folder on the server computer and create a link to it from the workstations connected to the server.

All of my software does not make use of any OCX's or any other libraries that would oblige the user to install it on each workstation. Nothing compares to the advantage of being able to use an application on a USB pendrive.

To tell the truth, my old software is not even developed in VB6 but in VB5 and the reason for it is quite obvious: VB5 applications work on all versions of Windows as of Windows 98. All you have to do is put your exe and MSVBVM50.DLL in the same folder and it will run just fine on Windows 98, Me, 2000, XP, Server 2003 and Vista. As you know, MSVBVM50.DLL does not require any registration in the Windows Registry, so your app will work even on an overprotected computer.

I don't care whether what VB6 creates can be defined as native code or not. All I care is that my app must work without installation. Anyway, I do provide the final user with a setup package created with Inno but I also inform him or her that, if they want to use my app in a LAN or on a pendrive without installation, they will be able to do so.

When MS announced their intention to discontinue VB6 and invest all their time and effort in .NET, they broke my heart. I immediately realized that it was time for me to kiss them goodbye and look around for the real successor to VB6.

The real successor to VB6 is .NET for 99% of the world, but you have made your objections abundantly clear.

I believe your objection to C++ is at least partially correct. I have never used Delphi, but I doubt it is the code itself that would be the problem, but rather, as you noted, the lack of a form designer for unmanaged C++. To the best of my knowledge, which is very out of date in this case, you are correct about C++. However, I AM out of date about that, and I would be amazed if there isn't a Windows form designer front-end built for unmanaged C++.

The advantages of C++, in your case, are too significant to dismiss lightly. You have already tied yourself to one language that died on your watch, do you really believe that a small niche filler like Delphi is going to keep you happy for long? Perhaps it will prove to be like Apple and survive for decades despite never holding any significant market share and being left behind by technology in the main market, but I certainly wouldn't bet that way. On the other hand, ANSI C++ is likely to still be viable long after you have retired from the job market, and it is likely to be unchanged. The fact that it meets your needs for a small footprint, while being superior to Delphi in chance of surviving even the next five years, is such that you should seriously consider it. If the only real objection is that you don't know of anybody who has put an easy to use front-end for WinForm design onto it, you should take the time to determine that you are correct before abandoning the language most likely to meet your current and future needs.

Quote:

---

Originally Posted by Shaggy Hiker

ANSI C++ is likely to still be viable long after you have retired from the job market, and it is likely to be unchanged. The fact that it meets your needs for a small footprint, while being superior to Delphi in chance of surviving even the next five years, is such that you should seriously consider it. If the only real objection is that you don't know of anybody who has put an easy to use front-end for WinForm design onto it, you should take the time to determine that you are correct before abandoning the language most likely to meet your current and future needs.

---

I have done some research into the existence of WinForm designers for C++. There are some that look pretty nice but they are produced by amateur programmers and not by reliable software houses. The risk is that, by the time I get accustomed to using one of those form designers, its creator may just decide to stop updating it.

To be quite honest, I think you are underestimating Delphi. This programming language has been around for years and years and now its future looks brighter than ever as a big and reliable software house has decided to invest in it. The latest version of Delphi works perfectly on Vista and also supports Unicode. For the first time in its history, its user community is beginning to grow. Add to that the fact that the exacutables you create with Delphi are (and have always been) standalone and you have more than one reason to switch to it. Last but not least, it took me a very short time to convert all of my VB5 key code to Delphi and now I am fully operative in terms of productivity as I was before.

I may well be underestimating Delphi...but I doubt it.

Quote:

---

Originally Posted by dilettante

This is obsolete advice. Every supported version of Windows (from Windows 2000 SP4 onward) has a version of the VB6 runtimes that is later than VB6 SP4. Once you get to XP SP3 you have a version of the runtimes that is later than VB6 SP6.

---

You're wrong as you have versioning to consider too even as you also mention. Creating a proper installation package is the only best advice to take to insure your program runs without error. If you use a feature that is not supported in one of the OS' you are targetting then you will run into issues.

See my post/thread on my dinner with Microsoft last night :)

http://www.vbforums.com/showthread.php?t=544835

Quote:

---

Originally Posted by dilettante

VC++ requires a runtime just as much as VB6 does. I have no idea where people get these notions.

Microsoft Visual C++ 2008 Redistributable Package (x86)

---

We get these notions because we weren't born yesterday. I went to that link, and it was fairly bizarre. What is that, managed C++? Perhaps the world has changed since last I used C++ (well, it HAS changed, I just don't know how much), but C++ is not MS. If I write in GC++ or some other C++ compiler, I certainly don't need to load some kind of MS runtime for programs to run. That would be pretty stupid of the compiler creator. Yet the link clearly expects that you do need to install some things. I assume that's for managed C++, but it doesn't specifically say so, and some of the items they are identifying predate .NET by many years. So what are they really saying? Is it just that if you use certain dlls you need to include them, and this package does that automatically? I didn't dig far enough to find out. Still, you definitely don't need any runtime for C++ in general, even if you do for some particular flavor of C++. This can be determined by simple thought: Since you can program straight ASM in C++, what has to be required for this to run? The only possible requirement is the CPU itself, and nothing more CAN be required.

Most C++ compilers produce code that will use a runtime. VC++, Sun C++, HP C++, and many others.

Some C++ compiler systems may allow static linking as an option, some don't give you the option. Just like various Basic, etc. compilers do. But lots of basic services of the language are implemented in these libraries.

With some contortions you can avoid using a CRT library in some programs. Avoiding the Visual C++ Runtime Library is an old article on doing this.

Hunh! I never thought of dlls as being considered a runtime the way the VB VM and .NET framewords were. I guess you could see them that way, though I never have. You don't NEED any of those, unless you want the items added in the link libraries. Your alternative would be to write every function that would otherwise be included from the dlls. That's not the same level of dependency that you have with either VB6 or .NET. In both of those situations, there is no code that you can run without the VM or frameworks.

However, the result is the same. As long as you are going to use the items supplied in the link libraries, you are just as much dependent on them as VB is dependent on their inclusions, and if you aren't going to use any of the items supplied in the link libraries....then you are either doing something peculiar, or you're crazy.

It's certainly a valid way of viewing things, and not one that I had considered.

When it comes right down to it almost everyone who isn't writing bootstrapper code relies on some kind of "runtime" I suppose. As long as they're versioned and have bug fixes coming out there is always the issue of deploying dependencies too.

Some of them are deployed and updated as OS components: kernel32.dll, msvbvm60.dll, and everything in between. For example XP SP3 included a new msvbvm60.dll, and in Vista and later they're protected so you can't overwrite them with older versions.

I am still vb6 and not moved to .net yet. i have a doubt.
when we keep upgrading to .net programing, do we really taken away from the knowledge of basic windows architect?

for example, if you take transparency in vb6, we use getWindowLong, SetWindow api's and we ad and extra style bit to the window to make the transparency. inaddition to This the declaration of the api tells, in which windows dll the function resides ans what it expects etc. so we go and learn about the basics of window architect to use this functions.

in .net, you just pic the transparency key (color) and run, wow transparent window.

so i like to raise this question.

Do some one new to programming world and who started with .net and became a good .net programmer will he know about all this api and dll stuffs that makes this effects :confused:

:sick:

Probably not but its more of an area of expertise that you would consider separate. Win32 API programming is still possible and used in .NET, just the example you stated is alot simplier to set a property then to code it via API. Ther are still many things that you need to use APIs for in .NET so its not like its a lost technology. Just dependes on what you are needing/wanting to do.

Quote:

---

Ther are still many things that you need to use APIs for in .NET so its not like its a lost technology

---

Thanks Rob :thumb:

Think of it like VB6 and Win32 as compared to .NET and Win32. You can even subclass in .NET. All your Win32 experience is almost 100% transferable to .NET. Just need to learn the new syntax for declaring APIs and what data types map to which and viola your Win32 programming in .NET

I would say that your understanding of windows forms will be greater under .NET. One of the objections I always had about vb6 was that you were highly insulated from what was actually happening. Having come to the language from ASM and C/C++, I was always thinking about how the VB6 code was actually being implemented under the hood, yet it was so opaque to the user that I was really just guessing. I find that .NET is much more transparent, which is better for some and worse for others.

shaggy hiker, thank you, better if you can provide me a simple example on your comment. perhaps you can take my window transparent think or somthing like that to give an small example.

Perhaps a separate thread too ;) :)