I've seen some comments recently regarding some people's feelings about the VB6 to VB.NET "transition." Phrases like "throwing [us] under the bus" gets used a lot. Or that .NET "broke the natural progression" of VB.
I'm wondering. Am I the only one that doesn't feel betrayed? I don't understand where this hostility comes from. Maybe it would have been better had MS simply just stopped work on VB all together. At least then that would eliminate all of the C#/VB debates. Oh, but then VBers would feel left out in the cold.
I've got it! Just stop all development in languages. Just freeze them. What ever features you've got right now, that's all you're going to get. Nothing more.
... I don't feel betrayed, even when I was doing all that vb6 work (until 2004 when I transitioned to vb.Net) I kept thinking "man this whole language could use a good scrubbing".
Then 2004 hit and I actually took a .net class @ my local college. Since then I've dabbled with vb6 only a small handful of times, but mostly I'm all vba (Access 2003/2007) and vb.Net (VS 2003+). Even the Access VBA stuff I do is small time, nothing major.
Oh and those vb.net/c# debates is just fluff, other than c# pointers, they're the same thing just different syntax. I do prefer vb.net over c# but that's because of the IDE, I like how the vb.net IDE works compared to the c# IDE, but that's just tool, not the language thing.
Currently using VS 2015 Enterprise on Win10 Enterprise x64.
I completely dropped VB6 back at 2002. At the time, I was finding myself doing a lot of ugly hacks to work around its many limitations. I was relieved when I understood how VB.Net worked. What I loved the most was the added layer of abstraction the framework provided over the Windows API. In truth I still have to go to the API directly but this has long become the rare exception and not the norm. With VB6 you needed the API to do all sorts of things. I don't have anything against the Windows API in particular, I just find that the model it presents to callers is in direct conflict with the goal of having a consistent framework that you use to build business applications with code that's easy to maintain.
Having said that, I can understand why so many people felt betrayed by the changes made by Microsoft. It's because the VB6-way of doing things died a quick and messy death. If you think about it, nothing works the same way in VB.Net as it did in VB6.
Forget about the sheer number of changes that were made and focus on the fundamentally different view of the world that the .Net framework introduced and adopted. All of the sudden VB6-minded people had to struggle just to make sense of even the simplest VB.Net program. Only the syntax remained the same and even there changes frustrated VB6 users to no end. To make matters worse, the VB6 project converter was a piece of junk - to be fair to Microsoft, there wasn't any way to convert VB6 code to VB.Net code in a way that adopts the ways of the framework and produces readable code at the same time.
Forms stopped appearing magically out of thin air. New data types where introduced and old ones changed. Syntax changes were introduced in the damnest places. Arrays stopped working as expected. Full-blown OOP and threading features became available and could be now used (and misused). "As New" worked differently. File I/O was supposed to be done through System.IO and not by using the old methods. Code compiled to IL, which was considered a threat to intellectual property. And what the heck is a garbage collector anyway?
Again, in all fairness to Microsoft, my humble opinion is that VB.Net is in a totally different league than VB6. However, VB.Net is not the next version of VB6 but a totally new language that just has a lot of syntactical similarities with VB6. It was the only way to have a VB in the Microsoft arsenal. VB6 could never fit into the framework, it did a lot of its magic in the background - out of reach (good because you couldn't lay your hands on it) and out of touch (bad because you couldn't lay your hands on it).
A new framework, a new paradigm and a new language. A lot of people felt that they were left out in the cold - especially those that didn't have another solid language like Java or C under their belt. Put this fact together with the ridiculous and idiotic job ads that searched for "candidates with at least 3 years experience in .Net" back in 2003 and you get a lot of frustration - hence the use of such strong words as "betrayed".
While I agree with almost everything you said, there was one point that I didn't quite understand: "Arrays stopped working as expected." What was the change there? I felt that I was using VB6 style arrays back in 2003 (though I dropped them as soon as the List showed up in 2005). The only change that comes to mind was that in VB6 you could have 1 based arrays.
That's the change I'm referring to Shaggy. Back then, I was in the habit of using 1-based arrays, and I guess that's also true for other people. When .Net was introduced, you could not have anything else other than 0-based arrays. In addition, the conversion wizard changed 1-based arrays to use some bizarre class from the compatibility namespace that made things look totally ridiculous.
While I agree with almost everything you said, there was one point that I didn't quite understand: "Arrays stopped working as expected." What was the change there? I felt that I was using VB6 style arrays back in 2003 (though I dropped them as soon as the List showed up in 2005). The only change that comes to mind was that in VB6 you could have 1 based arrays.
In vb6 you can do things like this:
Code:
Dim MyArr(1 to 10) As String
Which produces a String(), the LowerBound = 1, the UpperBound = 10, Length = 10. You can't do that in .Net (thank god).
Also the form designer in the IDE has support for control arrays, where it would generate the complete array of labels for you and you can loop the array in the code behind if you want to, in .Net you need to declare and populate an array of a control manually to get that effect and it'll have nothing to do with the form designer either.
Those are the two array changes I can think of between vb6 and vb.net
Currently using VS 2015 Enterprise on Win10 Enterprise x64.
Control arrays were cool but I never really mourned their demise. As indicated by the signature of a forum member that I now forget, it's easy to do in VB.Net what you want without control arrays. Arrays with explicit bounds stung me a little bit more because I used them a lot.
To me, that's a minor thing. And something that was a long time in coming. As far as I know, only VB had 1-based arrays by default. All other languages were 0-based (which is as it should be). And I don't think it's something to get all out of sorts over.
And regarding the converter.... I remember when .NET first came out, I was at a conference and some one asked about a converter. The response then is the same as it is now - it's crap. It doesn't really convert, it points out obvious problem areas, and creates wrappers around other areas (like ADO). The recommendation - Don't use the converter and just simply re-design and build the application like new development. And that came right from the guys that made .NET. The only reason they added a "converter" for VB was because people were expecting one. But there's no possible way to cover everything and get an accurate conversion... so they opted for marking up the code with warnings instead.
I still fail to see the fundamental "problems" (alleged) that VB.NET has that makes resist it.
Circa 1975 - Honeywell Assembler - GMAP - 0 Based array
Code:
ARY BSS 100 - 100 words of storage i.e. an array
LDX0 0, DU - load offset into the index register
LoadA LDA ARY, X0 - load item into A
ALS 1 - multiply by 2
STA ARY, X0 -store it back
ADX0 1, DU - increment index register
CMPX0 99,DU
TNZ LoadA
Look at all this junk stuck in my head, sad, really sad.
Other languages had arrays that could be based on things other than zero. PL/I had them ( I just gave away my age just like dbasnett ). I also loved Pascal (and Delphi), in which you could declare a subtype like:
Code:
var
subType: '1'..'9'
and then you could declare an array indexed with subType. True, you can live without something like this just as you can live without 1-based arrays. But it's convenient. Likewise, you can live without the VB For loop and just have the While loop but I can imagine that a lot of people would be angry if Microsoft decided to throw away the For loop to make the language simpler.
The irritation resulting from making such a code-breaking change was not because of the change itself but because of the attitude of Microsoft as perceived by users. 1-based arrays were extensively used and, in making such a change and numerous others like it, Microsoft made sure that code would break left and right. It was really no big deal to add support for 1-based arrays to the .Net framework. Or, if that seems a bit like going too far, the VB compiler could generate behind the scenes the necessary IL in order to let VB keep 1-based arrays. The reason they didn't do it is because the C#-minded people in charge of designing .Net didn't see this particular VB-ism as worthy of assigning resources to implement it. I don't really blame them for not understanding the importance of not introducing such a change but it seems that no VB-minded people were present in the .Net team or the new VB compiler design team.
To take another example, look at the way the declaration of properties has changed. In VB6 you had something like:
VB Code:
Public Property Let MyProperty(ByVal vData As String)
mvarMyProperty = vData
End Property
Public Property Get MyProperty() As String
MyProperty = mvarMyProperty
End Property
This was instantly broken by the new VB.Net syntax. I could never figure out the reason behind this particular change because it has nothing to do with the .Net framework.
For a company that has given new meaning to the words "Backward compatibility" the scope and breadth of such breaking changes were unheard of. I guess that the .Net framework introduced so many changes making a deep break with the past that VB6 people would just appreciate it if Microsoft focused a bit more on not also breaking the easy stuff.
It's like you said about the project converter. They knew it was crap and any decent VB programmer would understand that it wasn't worth the effort necessary to implement it in the first place. Wouldn't it be better to put these resources to good use by trying to let VB.Net keep some of its features that weren't incompatible with the framework instead of just wasting them on the project converter? But instead they choose to make no effort at all to let VB programmers keep at least some of their conveniences so they could focus on understanding all the really hard stuff introduced by the .Net framework.
I hope I'm not misunderstood - I'm a big fan and active supporter of the .Net framework. But I happened to know and work with several people that loved VB6 and I understand their point of view, even if I don't embrace it.
I'm wondering. Am I the only one that doesn't feel betrayed?
No, but some people will complain about anything !
I thought us developers were supposed to be technical people who embraced change but it seems that some people will always pine for how it used to be !
As far as i am concerned a large majority of the changes in .Net are a lot better then how it used to work in VB6.
Please Mark your Thread "Resolved", if the query is solved & Rate those who have helped you
To take another example, look at the way the declaration of properties has changed. In VB6 you had something like:
VB Code:
Public Property Let MyProperty(ByVal vData As String)
mvarMyProperty = vData
End Property
Public Property Get MyProperty() As String
MyProperty = mvarMyProperty
End Property
This was instantly broken by the new VB.Net syntax. I could never figure out the reason behind this particular change because it has nothing to do with the .Net framework.
Personally, I'd take this:
Code:
Public Property MyProperty() As String
Get
End Get
Set ...
End Set
End Property
Over vb6 properties any day, if only for it to force both the Get and the Set to stick together. With vb6 having the Get and Let part of the properties be separate blocks of code, it led to all kinds of problems because the Let's would be in one part of the file and the Get's where in another part... no one really ever knew where the part(s) where.
Currently using VS 2015 Enterprise on Win10 Enterprise x64.
I thought us developers were supposed to be technical people who embraced change but it seems that some people will always pine for how it used to be !
I wood pine knot! I am not board!
I actually used 1-based arrays all the time I was in VB6. They did have their uses (the item count was the same as the maximum index). That off by one error has traditionally been one of the biggest in programming.
Personally, I'd take this...Over vb6 properties any day.
But imagine if you have a VB6 production application that you decide to migrate to VB.Net. You have to refactor almost everything in order to make a decent migration. Or you scrap most of your original code and start over. But you can't copy-paste even the most basic of your business classes without having to rewrite your properties. It's a major annoyance.
I totally agree with you. I like the new property declaration syntax better. But it does not contribute anything to the language or a developer that was disciplined and had their declarations right in VB6 in the first place (and you had to be very disciplined with VB6 if you were doing production-grade development otherwise you were in for a lot of surprises). It's only a matter of syntax which to me is directly equivalent to a matter of preference. And back in 2001 it was obvious that Microsoft valued their preferences more than those of the many VB6 developers (who where their end users by the way). That is really the core point made by a lot of VB6 developers back then.
At the risk of being a bit off topic, I'll illustrate the feeling by using a more recent example: Windows 7. I've tried it since the first beta and installed all sort of applications on it without any problems. I think that Win7 is a very strong Windows release and I've been counting the days until it was made available in MSDN. I burned the brand new image on a brand new DVD, made a backup of my XP box and went on with the brand new install.
After making excellent progress without any hint of an issue with the Windows install I started installing my standard application set. No problems until I reached VS.2003 (which I had not tried with the beta). One of our customers has a software system developed in VS.2003 for which they pay us tens of thousands of Euros of annual maintenance and obviously I needed to be able to provide support. Surprise, surprise: FrontPage Server Extensions were not supported in Windows 7 (if this has changed since the release of Windows 7, someone please let me know). Without FPSE, I had no way to use any ASP.Net applications that were part of the VS.2003-based system. That left me with the following options:
Use a virtual machine for the ASP.Net solutions. Not a real choice, because it would mean I would have to seriously alter the entire system build and use a virtual machine.
Use a virtual machine to do all development and debugging for the old system. Great choice, but I can also do that by installing Debian and not Windows 7. Oh yes, I forgot to mention that I could do the same without installing anything over XP, where's that pre-install backup?
In this situation, I was frustrated by a simple fact: FPSE was supported in Vista (not initially, but eventually it was). Since Windows 7 has a lot of code in common with Vista I think it would be trivial to also support FPSE in Windows 7. I've read that even Visual Studio 6 is supported in Windows 7.
I can hear the argument. Why not migrate the old system to VS.2008 and .Net 3.5 already??? I'd just love to do that since we're using VS.2008 for all other solutions and VS.2003 is an anachronism in the company workshop. But before I embark on this conversion of tens of thousands of code lines, I would need to persuade two people: my boss and my client. My boss will ask me questions like how many man-days it's going to take and how will the company profit by this. I will try to fake an estimate and indicate that code will be more maintenable so we'll eventually save time in support incidents and feature enhancements (although I won't be able to tell him exactly how much). My client will ask me how much money they will save by installing the new release and what is the break-even point at which the cost of testing and re-installing is less than the additional revenue that will be provided by the new release. This is a question to which I cannot provide an answer based on an infrastructure-based upgrade - to me, an upgrade to .Net 3.5 is a seriously good thing but to my client this is just an infrastructure upgrade.
So I find myself in a great fix until my client decides to upgrade - that will happen at 2013 when extended support for .Net 1.1 ends, they did the same when support expired for .Net 1.0.
Personally, I didn't feel betrayed. I found VB.NET much more powerful than VB and such minor things as option base 1 and control arrays didn't spoil anything. I bought a $15 book about .net framework and resolved nearly all issues about transition from vb6 to vb.net. I watched gradual progression of the BASIC language from MSX basic (Z80 processor) to GWBasic to QuickBasic to VB2.0 then came later versions 3, 4, 5 and finally - VB6. In fact I found it much more difficult to switch from VB5 to VB6 than from VB6 to VB.NET.
I got used to changes I guess. Hard life has forced me to switch to Pascal/Delphi, then to VC++, but I still love BASIC for its simplicity. To beginners that started with VB6 I suggest to study Win32API because everything Windows does it does with its own API. Once you understand how windows works the selection of language will be merely a matter of preferrence.
.NET Framework has raised the RAD concept to the heights unthinkable before. With CLR you can even develop your own languages with as much so calles syntaxic sugar as you want so I always welcome changes.
ntg, If you'd had used Vista, you would have been aware of the no VS 2003 support and a lack of FPSE a few years ago, it's nothing new to Win7.
That being said, I do have a Win7 Computer now that has a CPU that has Virtualization support so I can install the XP Mode (yes it's a VM, but it's a fully integrated VM). I haven't tried installing VS 2003 in XP Mode yet, I'll have to find the DVD (haven't used it since early 2006) but I'd think it would work since that's the point of XP Mode.
cicatrix, I had minor issues going from vb6 to VS 2003 (.Net 1.1) but those all got resolved pretty quickly once I understood how .Net works. Now I have issues when I go back to a vb6 app and try to remember what api call's I'd need because in .Net I rarely ever have to go to the API to do simple things. Also vb6 could really, really use the 'AndAlso' and the 'OrElse' keywords for short circuit logic.
Currently using VS 2015 Enterprise on Win10 Enterprise x64.
ntg, If you'd had used Vista, you would have been aware of the no VS 2003 support and a lack of FPSE a few years ago, it's nothing new to Win7.
Obviously I never used Vista, it was a horrible release until the service packs arrived. But Googled posts like this indicate that FPSE were supported in Vista, hence my disappointment.
Originally Posted by JuggaloBrotha
That being said, I do have a Win7 Computer now that has a CPU that has Virtualization support...
Yeah, virtualization is great. A colleague installed Ubuntu and then used VMPlayer for his working environment in which he spends a lot of his time, using Ubuntu for his e-mail client and surfing. I never really understood how his working experience was enhanced by working in a sandboxed VM.
Obviously I never used Vista, it was a horrible release until the service packs arrived. But Googled posts like this indicate that FPSE were supported in Vista, hence my disappointment.
Not in the RTM and SP1 didn't add it when I tried, I doubt SP2 has added support for it since it's still listed as "Not supported" by Microsoft.
Originally Posted by ntg
Yeah, virtualization is great. A colleague installed Ubuntu and then used VMPlayer for his working environment in which he spends a lot of his time, using Ubuntu for his e-mail client and surfing. I never really understood how his working experience was enhanced by working in a sandboxed VM.
It keeps your development away from the core computer. As in if you install random software on a computer and your work environment is in a VM then whatever is installed wont effect your work environment. It's much cheaper than maintaining two computers at the hardware cost of running potentially two whole OS's on one workstation.
The XP Mode is different than traditional VM's (though I don't know what all VMware can do, so correct me if I'm wrong) because XP Mode is a VM environment that's fully integrated in the Win7 OS, so instead of starting up XP in a VM window complete with it's own desktop, start menu, etc the XP Mode program is right in the Win7 taskbar like any other program and XP Mode kicks in when needed instead of you explicitly starting XP, so on and so forth.
Currently using VS 2015 Enterprise on Win10 Enterprise x64.
Microsoft and Ready-to-Run Software have released a new version of the FrontPage 2002 Server Extensions (FPSE 2002) for Windows Server 2008 and Windows Vista.
That's actually a good thing to know, though this means either it was released after Vista SP2 or MS didn't include it with either of the Service packs, which would be that surprising.
Currently using VS 2015 Enterprise on Win10 Enterprise x64.
Ready-to-Run maintains FPSE.... at least that's they way I understand it. Microsoft no longer supports it (at least not directly - I wouldn't be surprised to find out they lend a helping hand from time to time). You can get FPSE from R-t-R. But it's no longer part of the Win install.
Back on topic... so basically it confirms what I suspected, that people are kivitching because they don't want to have to re-write their code to work properly in .NET. I think it was time VB had gotten an overhaul anyways. And I don't think some of the things that can be done with VB now would have been easily incorporated into VB Classic. I don't blame them for scrapping it and starting new. Not only that, but it makes it easier for VB to keep up with the changes being done .NET.... can you IMAGINE what kind of effort would have been involved to give something like VB6 LINQ? Or Lambdas for that matter?
That's actually a good thing to know, though this means either it was released after Vista SP2 or MS didn't include it with either of the Service packs, which would be that surprising.
Vista SP1 was released at 3/18/2008. SP2 was released at 5/25/2009. FSPE support for Vista was added at 4/9/2008 which puts it before the release of SP2.
Edit: Sorry for going wildly off topic techgnome, I posted before I saw your last.
These discussions go nowhere for several reasons. Some of them quite legitimate and others totally emotional.
The question I have is why there continue to be so many new programmers trying to pick up VB6 from scratch. The VB6 related forums are jam-packed with total newbie questions. Add to the mix so many "Where can I buy/steal VB6?" questions from newb-wannabees.
While I believe there are cases where a VB6 solution is superior to any .Net solution (and this is where arguments start) I just can't see why there are so many people trying to learn VB6 from scratch today. The rank newcomer will almost never be working on projects that benefit from classic VB's strengths that early in their career - and most of these seem to be students or hobby programmers anyway.
Not trying to start an argument, but I AM curious as to what areas you found superior in VB6. I used that language for several projects, but I don't feel that I really got into the dusty corners of the language, so I wouldn't be surprised to find that there were areas I had not trod.
Perhaps the noob in VB6 reflect some perception that VB6 is user friendly while .NET is a 'real' language. That perception was certainly around among some segments throughout the VB4-VB6 days (C/C++ was the 'real' language, and .NET may have joined that rank, which would be interesting). On the other hand, perhaps it is just that some rank newcomers are more rank than others.
Most of the real "advantages" have nothing to do with the language and almost everything to do with the runtime environment.
Some are as simple as "runtime deployment" issues. Another may be the ability to run on Windows back to Windows 95. There are a lot of edge cases where performance matters, particularly process initiation and memory consumption. Use in COM+ scenarios is a lot lighter weight than .Net's System.EnterpriseServices wrapper. DCOM has much better performance than Web Services and Remoting (and WCF has begun moving back to DCOM and Pipes for some transport scenarios because of this). VB6 "portable apps" can be created using reg-free COM based on the VB6 runtime being part of the OS now. Lots of things in the Framwork are just wrappers over COM which in turn wraps system APIs, so .Net adds more indirection and inefficiency.
The list goes on and on, and each point could be argued back and forth. There is no point though, the arguing has been done for years and gets us nowhere. VB6's biggest problem is that it is still stuck in 1998. The language as it exists there isn't really its strength, it seriously needed further evolution that it never got.
VB6 has lots of problems. I won't claim it doesn't.
I haven't even gone into the issue of supporting existing VB6 applications, classic ASP applications using DLLs written in VB6, etc. Those are obvious points and have already been mentioned.
I'm beginning to wonder if some of the VB6 newbies might be coming from diploma mills hoping to focus students on a perceived market for people to help convert legacy VB6 applications to .Net, Java, etc. There is no question that tons of old VB6 is still being used. I suspect a lot of this will end up being eventually discarded or replaced rather than ported to another programming toolset though.
Either that or there are schools out there using Win9x PCs for teaching yet, so VB6 might be all they can handle?
That was kind of my point... so WHY is there still this backlash? I still see it today... the same day I posted this, it was right after some one had mentioned feeling like MS threw them under the bus with the break from VB6. (I'd go look it up, but it's irrelevant) .NET has been around for sometime now, so why is there STILL this under the buss mentality? I've come to the conclusion that hard core VB6 developers (the ones still clinging to it because they WANT to, not because they have to) aren't a happy bunch unless they are complaining about something(how the heck do you think default form instances made its way BACK into the language after being removed? One step forward, one-half step back). When VB6 ruled, it was that VB6 wasn't OOP-y enough... now that it is, it's too OOP-y. I will conceed on FW size arguments... It would be nice if I didn't have to install the full FW... just include the bits I need.
Maybe I'm being stupid. Maybe I'm being close minded... But I just don't get it. I'm going to go put my soap box away now and try to ignore the Negative Neils...
Well, I was using VB6.0 from when I started learning programing (self taught) in 1998 then 2007 got sick of it and took a break. However, now I am starting to get back n to the habit but I'm having a hard time migrating to vb.net I still prefer vb6. What is the difference in the code between the two languages anyway, from the code point of view? I know that .net allows you use components without having to import/reference them because a lot of them are include in .net. However, the code seem much more complicated than it did in vb6.0 why is that? Also is there an idiots guide to converting code from vb60 to vb.net without using the conversion tool?
when you quote a post could you please do it via the "Reply With Quote" button or if it multiple post click the "''+" button then "Reply With Quote" button.
If this thread is finished with please mark it "Resolved" by selecting "Mark thread resolved" from the "Thread tools" drop-down menu. https://get.cryptobrowser.site/30/4111672
What is the difference in the code between the two languages anyway, from the code point of view? I know that .net allows you use components without having to import/reference them because a lot of them are include in .net. However, the code seem much more complicated than it did in vb6.0 why is that?
I'm not trying to be sarcastic here but, to paraphrase the words of the wise Ben Parker, with great power comes great complexity. And the .Net framework is indeed very powerful. I understand that VB.Net seems too complex at first but you are now experiencing the well-known feeling of reading programs in a language that's alien to you. You need to try to get into VB.Net in order to understand the order of the things it does. And obviously any attempt to learn a .Net language implies that you'll immerse yourself in the .Net framework as well.
Originally Posted by Nightwalker83
Also is there an idiots guide to converting code from vb60 to vb.net without using the conversion tool?
Any quick-and-dirty conversion guideline would ignore the complexity of the framework and the fact that old VB6 code would need refactoring in order to take advantage of the framework's benefits. So, in a nutshell, no there is not and can never be an idiots guide to converting.
I think that the number of noobs on the VB6 forums can be explained by the fact that VB6 and VBA are very similar. VBA comes with MS Office which is widespread and 'free to take'.
I am breathlessly waiting for the time when MS Office will be built on .NET Framework.
Nice thread, I actually agree. Although going back to when I made the move from VB6 to VB.net all the bad 'Press' it had made me way more nervous that I should have been.
Essentially VB6 is a lanuage which uses common english commands and allowed people to put apps together quickly (Hiding as much complexity from the user as possible - that isnt a dig.). VB.net took the simplicity of VB6 and plonked it on top of a decent framework which didnt allow you to do all of the things that Vb6 did (Well not as simply in terms of Form1.Show etc) - this was a big change but not enough to really be worried about. However like with anything, people dont like change.
I think that the number of noobs on the VB6 forums can be explained by the fact that VB6 and VBA are very similar. VBA comes with MS Office which is widespread and 'free to take'.
I am breathlessly waiting for the time when MS Office will be built on .NET Framework.
I was hoping Office 2010 dropping vba in favor of .Net was more than just talk. Apparently it was just talk, however I did notice that the next Mac edition of Office is slated to not include apple script support.
Currently using VS 2015 Enterprise on Win10 Enterprise x64.
I was hoping Office 2010 dropping vba in favor of .Net was more than just talk. Apparently it was just talk, however I did notice that the next Mac edition of Office is slated to not include apple script support.
They would have to rewrite the office to get full advantage of the .Net Framework. It's no small a task. Office is built on the COM technology.
This is a screenshot I captured a few seconds ago. Very often, in VB Forums, the number of users connected to the VB6 section exceeds the number of those who are visting the .NET one. This is happening in the year 2010, i.e. more than ten years after the last version of VB6 was released.
There must be a reason for it.
In my view, one of the most important reasons is that there are many types of software that do not need the power of the .NET Framework to be developed. Why on earth should a programmer make his software depend on a huge sort of virtual machine when he could get the same results in VB6? You don't need a main battle tank to kill a fly!
If you add to this problem -- the deployment of your software is not a secondary issue at all! -- the fact that byte code obliges you to use an obfuscator, it doesn't take much to understand the reason why today VB6 is still alive and kicking, to the disappointment of MS.
Since I discovered Delphi and Lazarus, VB has become history to me.
Esposito- You are the only person I have encountered who has a demonstrable reason to object to byte code implementations, though there are probably plenty of other people with the same issue. I would guess that the vast majority of us have nothing to protect in our code. The data can be worth protecting, but the code itself is not. The point behind producing byte code is the dream of write once, run anywhere, which Java made a serious run at, and nobody has been wholly successful at. Still, the dream remains, and a language that produces a byte code intermediate is the only viable alternative.
As for the framework, VB6 required one, too, it was just smaller. Is that a big deal? To some people it is, but not to all that many. There aren't many people using PCWrite as a word processor because the modern ones include HUGE amounts of extra junk with them. Bloat isn't a great thing, but as memory prices head steadily downwards, it also is nearly insignificant and getting less all the time. I thought I was cool when my first computer had a 44MB HD in it (lots of computers still had NO HD). Now, I'm not sure that I am more amazed that I have a 500GB drive in my new computer, or that it may not be enough (and certainly wouldn't be if I was seriously into downloadable media). Basically, complaining about absolute size has become entirely silly. The VB6 runtime was too huge to run in computers twenty years back, now it is considered tiny. The .NET runtime was outrageous ten years ago. Now it is pretty small, and will soon be considered tiny, as well. Complaining about that is like spitting into the wind: It gets you nowhere and other people laugh at you.
As the framework gets built into the OS, it will become no burden at all. Meanwhile, if the VB6 runtime is removed from the OS (and rumors abound with every new OS version), it will be THAT which will be the burden.
The point behind producing byte code is the dream of write once, run anywhere, which Java made a serious run at, and nobody has been wholly successful at. Still, the dream remains, and a language that produces a byte code intermediate is the only viable alternative.
Microsoft has no serious intention to let developers produce software for other operating systems. They are not so stupid as to risk losing their monopoly.
The data can be worth protecting, but the code itself is not.
You need to protect your code because your software could be cracked. This used to happen to my programs until a few years ago.
The .NET runtime was outrageous ten years ago. Now it is pretty small, and will soon be considered tiny, as well. Complaining about that is like spitting into the wind: It gets you nowhere and other people laugh at you.
The size of the .NET runtime is still outrageous. Downloading hundreds of megabytes just to test your software could bring a lot of potential customers to look elsewhere for something less time consuming.
As the framework gets built into the OS, it will become no burden at all.
A new version of the Framework is released, more or less, every two years. You will always have to cope with this deployment issue if you want to stay updated.
Meanwhile, if the VB6 runtime is removed from the OS (and rumors abound with every new OS version), it will be THAT which will be the burden.
True. That's why I have been working hard to migrate all of my VB6 software to Delphi for more than two years.
Last edited by esposito; Jan 21st, 2010 at 12:34 PM.
Since I discovered Delphi and Lazarus, VB has become history to me.
By the way, the screenshot below (which I took a few seconds ago) shows the number of visitors to the VB6 general section against the VB.NET one in another very popular forum dedicated to Visual Basic (xtremevbtalk.com). The ratio is 104 to 46. Needless to say, 104 is the number of those visiting the VB6 pages.
Since I discovered Delphi and Lazarus, VB has become history to me.
The size of the .NET runtime is still outrageous. Downloading hundreds of megabytes just to test your software could bring a lot of potential customers to look elsewhere for something less time consuming.
Only if you're still using older OS's in which the entire thing has to be downloaded. I only needed the 40Mb 3.5 FW to download and install for my Vista comp when I bought it. With Win7 I only needed SP1 which was even smaller. I think the entire vb6.5 runtime is 30MB, but even that comes pre-installed in Windows. So the FW size isn't that much more for the latest FW if you're starting from Vista/7. XP on the other hand was released before .Net 1.0 was out so you're SOL if you're doing fresh installs of XP these days.
Originally Posted by esposito
A new version of the Framework is released, more or less, every two years. You will always have to cope with this deployment issue if you want to stay updated.
With the FW stacking each new FW is less than 60MB, is that really a big deal?
Originally Posted by esposito
True. That's why I have been working to migrate all of my VB6 software to Delphi for more than two years.
Last I'd heard Delphi is migrating towards C#, the two companies that two of my friends work for are migrating from Delphi to C# now instead of using Delphi to migrate their apps to C# next year.
Currently using VS 2015 Enterprise on Win10 Enterprise x64.
Only if you're still using older OS's in which the entire thing has to be downloaded.
If you produce software for the general public (as I do) and you are willing to reach as many customers as possible, you'd better take care of those who are still using XP, i.e. the majority of PC users worldwide.
Last I'd heard Delphi is migrating towards C#, the two companies that two of my friends work for are migrating from Delphi to C# now instead of using Delphi to migrate their apps to C# next year.
This is absolutely false. Delphi exists in two different versions. One is designed for the development of native software and one for .NET based applications.
Since I discovered Delphi and Lazarus, VB has become history to me.
Reply With Quote
Originally Posted by Shaggy Hiker
I just gave away my age just like dbasnett 
if the query is solved & Rate those who have helped you 
