What if there was a NEW vb6

[Carlos Rocha]

As an additional comment, I would say that at present, the "killer feature" for C# is .NET native. The performance gains alone would convince me to switch any existing Vb.NET projects over (assuming the project were performance-sensitive, of course).

It's only for Windows Store?

[Tanner_H]

It's only for Windows Store?

For now. From the FAQ:

Desktop apps are a very important part of our strategy. Initially, we are focusing on Windows Store apps with .NET Native. In the longer term we will continue to improve native compilation for all .NET applications.

It's hard to overstate how cool this could be if it actually works as promised, e.g. from the FAQ:

Is this just about performance, or does this also allow for building C# code (say) that is natively compiled to Win32/64 and doesn’t require an install of the .NET Framework on the target machine?

That is correct: .NET Native is not just about performance, but also about productivity and a consistent device experience. .NET Native allows you to write code using managed languages and upload MSIL packages as always. However, apps will get deployed on end-user devices as fully self-contained natively compiled code (when .NET Native enters production), and will not have a dependency on the .NET Framework on the target device/machine.

[szlamany]

It's hard to overstate how cool this could be if it actually works as promised, e.g. from the FAQ:

Does using .Net native mean that people no longer have to worry about obfuscating their applications?

[Tanner_H]

I guess if I was ever going to write .Net desktop apps again that feature would matter.

As for it being a de facto cause to migrate...

.Net has other factors that slow it down - not just IL. Based on what you are doing, the GC might be evil to you.

Yeah, no disagreement here. But just like multiple languages in your programming toolbox, I'd say that understanding GC behavior is just part of being a modern developer. (Short of C/C++, most relevant languages - Java, Javascript, etc - are all GC.)

I was never trying to say that all VB.Net devs should migrate to C#, per se. Just that - in my experience - most VB.Net devs use VB.Net for the same reason a lot of VB6 guys use VB6: maintaining legacy codebases.

For new projects, I think it's difficult to make a case for any variation of VB, unless you just *really* love the syntax. (But obviously, if someone insists on writing new code in VB, .Net is going to be the right choice 99% of the time.)

[Tanner_H]

Does using .Net native mean that people no longer have to worry about obfuscating their applications?

*Turns on sarcasm detector*

*RESULT INCONCLUSIVE*

[FunkyDexter]

RESULT INCONCLUSIVE

That's odd. Mine gave a very definite result

I agree with most of what you've said (it's certainly been one of the more balanced contributions, for which I offer up a heartfelt "Thank You") but I'd take a slight issue with this: " most VB.Net devs use VB.Net for the same reason a lot of VB6 guys use VB6: maintaining legacy codebases".

I think many VB.Net users don't migrate to C# because there's no killer reason to (.Net native aside which I personally think serves a fairly niche set of use cases), whereas the killer reason for moving away from VB6 (with the exception of a few very niche cases) has been apparent for over a decade. I personally did make the choice to move from VB6 to .Net because I recognised I would have a very limited career if I didn't. A few years later I also made the choice to migrate from VB.Net to C# but mostly because I felt it was easy to do and it rounded out my CV which is pretty crucial as a contractor, not because I felt it was an imperative. If I was a permanent employee in a shop that was happy for me to carry on in VB.Net then I think the effort to learn C# would probably be better spent learning the various nooks and crannies of VB.Net - you can't know everything.

Migrating to C# is pretty trivial which is either an argument for just getting on and doing it or it's an argument that you don't really need to until you're good and ready.

[dilettante]

I got the idea that .Net Native also tries to extract whatever your Metro Store app needs from the Framework and compiles it in. But I'm less certain that you do not still need some subsetted CLR for core runtime fnctions. Even C++ Store apps need and use a runtime library.

See "So you want to sideload Windows fart apps... headache #783" C++ Runtime for Sideloaded Windows 8.1 apps.

[Tanner_H]

That's odd. Mine gave a very definite result

lol, you never know in this thread!

I think many VB.Net users don't migrate to C# because there's no killer reason to (.Net native aside which I personally think serves a fairly niche set of use cases), whereas the killer reason for moving away from VB6 (with the exception of a few very niche cases) has been apparent for over a decade. I personally did make the choice to move from VB6 to .Net because I recognised I would have a very limited career if I didn't. A few years later I also made the choice to migrate from VB.Net to C# but mostly because I felt it was easy to do and it rounded out my CV which is pretty crucial as a contractor, not because I felt it was an imperative. If I was a permanent employee in a shop that was happy for me to carry on in VB.Net then I think the effort to learn C# would probably be better spent learning the various nooks and crannies of VB.Net - you can't know everything.

Migrating to C# is pretty trivial which is either an argument for just getting on and doing it or it's an argument that you don't really need to until you're good and ready.

All fair points, and I'd be hard-pressed to disagree. If there's one point of contention I'd make, it's "the killer reason for moving away from VB6 (with the exception of a few very niche cases) has been apparent for over a decade."

I'd say this would depend a lot on the application and the developer. For hobbyist or non-professional developers, their choice to stay with VB6 has become oddly justified. I don't think any of us expected VB6 support to be so solid a full 15 years after it was deprecated. For people without the time or inclination to learn something new, they've gotten pretty good bang-for-their-buck with VB6.

For professional devs though, no argument that they should have moved on a long time ago for their own career viability.

I think there's also an argument to be made for companies, particularly SMBs, who have stuck with VB6 apps that are currently in "maintenance-only" mode. Getting 15 years of use out of an application is pretty remarkable, especially in an age where things like web apps have to be reworked every time a new browser releases. (That's a little hyperbolic, but you know what I mean.)

[Tanner_H]

I got the idea that .Net Native also tries to extract whatever your Metro Store app needs from the Framework and compiles it in. But I'm less certain that you do not still need some subsetted CLR for core runtime fnctions. Even C++ Store apps need and use a runtime library.

See "So you want to sideload Windows fart apps... headache #783" C++ Runtime for Sideloaded Windows 8.1 apps.

Yeah, I'm sure this will be a much more complicated problem to solve when the desktop version releases. I wouldn't be surprised if you're right about some subset of the CLR being required (although given how much of the CLR just calls into core WAPI functions, inlining just the CLR-specific parts may not be too terrible...? IDK).

As long as we're reading tea leaves, I expect this was much less about desktop development, and much more about improving mobile app performance, where the interpretation hit is a lot more meaningful for not just performance, but battery life too. iOS apps have been native-compiled since day one. Android has supported some form of native development since 2009 via the NDK.

Windows Phone already has a plethora of hurdles to deal with, but hopefully .NET Native can remove a few more.

[Niya]

I love the .Net Native idea for two main reasons. One, it provides natural obfuscation. .Net EXEs are far too easy to decompile. And two, it relieves you from the extra responsibility of checking for the and installing the correct version of the Framework. As I understand, it would perform some form of static linking during compilation.

However, there is one single major possible reason that I don't want to see .Net Native come to fruition, it may completely break reflection. For quite some time now, I've been quite reliant on the reflective capabilities of the .Net Framework. Reflection is quite possibly the single most useful ability to come with .Net. However, for it to work correctly, the EXEs and Dlls must have metadata and MSIL code itself sometimes acts as metadata. .Net Native is going to break reflection in some way. It is not worth it in my opinion. If this ever becomes standard and they do indeed break reflection, that would quite possibly be the beginning of the end of the love affair between me and .Net.

[FunkyDexter]

For people without the time or inclination to learn something new, they've gotten pretty good bang-for-their-buck

Given that .Net has had free express versions while 6 cost hundreds of pounds or had to be... ahem... independently acquired... I reckon they'd have had more bang for less bucks from .Net but I do know what you mean. I don't think MS ever envisaged that they'd still be supporting it after all this time. I know I certainly didn't when I decided to switch. I personally reckon that's mainly due to the fact that VBA never got replaced as the language behind office but there's a variety of reasons if you choose to go looking.

SMBs and maintenance only apps are an interesting case. I've always argued that migrating an app purely because you want it to be in a new language is insanity - you re-engineer when you need to, not because you saw something shiny and wanted to chase it. My experience was that I had a few clients with VB6 (or in one case VB3) apps that they wanted maintained beyond the early millennium and I was able to make a bob or two supporting them for a whole but they inevitably found that their own worlds moved and at some point they all changed direction, either by paying for a rewrite or just buying in a completely different product. I can honestly say that I am no longer aware of anyone still using it - which is not to say they don't exist, just that they've dwindled to a largely irrelevant market that's no longer worth me targeting.

I'm really talking about bespoke apps there though, and I do have some sympathy for folks that developed an off the shelf app in VB6 and then saw active support removed. Such sympathy as I have, though, is tempered by the fact they've probably had the best post deprecation support the IT industry has ever seen. If 15 years wasn't enough time to viably migrate your application then the application wasn't financially viable to begin with. So if I see someone say "I've never migrated my app and now I'm doomed and it's all Microsoft's fault" then I don't really have any sympathy. If, on the other hand, I see them say "I never bothered migrating because I guessed right that MS would never quite drop support and I've saved myself a mint on migration costs, Suckaz", then I'm inclined to pat them on the back and respond "good call, dude, good call".

[SJWhiteley]

The implication is that VB.NET developers will be in the same boat as VB6 developers. As already noted, the transition to C# is actually quite trivial step from VB. If the .NET platform goes away, there are a whole host of other technologies - web development which has a fairly strong market share is not reliant on .NET in any way shape or form. I believe most .NET developers have more than a passing familiarity with web-based technologies (e.g. JavaScript and associated libraries).

VB6 does not give 'hobby developers' any bang for their buck, and has not for well over a decade. It was easy to learn, but at a dollar cost. VB6 allowed someone with no programming skills to create applications; the similarities between VB6 and VBScript demonstrate this, and why VBA has not gone away, as atrocious a programming language that it is (it served a purpose).

the .NET (Express) opened up 'real' programming practices to the non-programmers. Those without programming training, education or skills would find .NET very daunting and overly complex. Much like any other skill, just because you have the tools, doesn't make one a craftsman in that field. This is where VB6 was lauded as an amateur language; it didn't have the rite of passage that the real programming languages demanded.

[Niya]

the .NET (Express) opened up 'real' programming practices to the non-programmers. Those without programming training, education or skills would find .NET very daunting and overly complex. Much like any other skill, just because you have the tools, doesn't make one a craftsman in that field. This is where VB6 was lauded as an amateur language; it didn't have the rite of passage that the real programming languages demanded.

This is so true. This is half the reason that VB is so despised by programmers with a non-BASIC background. It is considered a toy language and one only has to look at languages like C, C++, ASM, hell even Pascal to understand why. However, this is not a bad thing, the language is called BASIC for a reason, its meant to be basic. And while back in the day I used to scoff at the elitist attitudes of C/C++ programmers towards VB, it wasn't until I started writing C++ code myself that I understood just how justified they were. VB.Net tries to correct this and while it succeeds, its far too late. QuickBasic and earlier incarnations of VB have already cemented the status of any thing based on BASIC to be amateur.

[FunkyDexter]

Isn't that the point though? VB6 did enable non-programmers to produce functional apps and I think that's a good thing. Us "trained professionals" can sit in our ivory towers and pour scorn if we wish but those non-programmers produce ALOT of working functionality for the companies they work for, whether that's excel macros, python scripts, batch files or any other medium that enabled them to get the job done.

Where I think I really differ is in the belief that .Net is daunting - or rather that it has to be daunting. The actual act of throwing together a simple single form app that does some simple work is really no different in .Net than it was in VB6. I think the problem non-programmers face is that .Net framework and the ide has loads of features they don't care or need to know about at first and that, I can see, can be intimidating. Then they go on line to look up how to find an item in an array and they're presented with Linq and Lambdas before they've really had a chance to just loop it and do a comparison. They get information overload.

IMO, if MS want to make .Net accessible to the masses in the way that VB6 was all they really need to do is provide a beginners version (or a beginners "mode" in the full version) with a cut down framework and some tutorials right there in the IDE so the user doesn't have to go to google the first time they get stuck.

[szlamany]

This is so true. This is half the reason that VB is so despised by programmers with a non-BASIC background. It is considered a toy language and one only has to look at languages like C, C++, ASM, hell even Pascal to understand why. However, this is not a bad thing, the language is called BASIC for a reason, its meant to be basic. And while back in the day I used to scoff at the elitist attitudes of C/C++ programmers towards VB, it wasn't until I started writing C++ code myself that I understood just how justified they were. VB.Net tries to correct this and while it succeeds, its far too late. QuickBasic and earlier incarnations of VB have already cemented the status of any thing based on BASIC to be amateur.

It goes so much further back then that.

When I used PDP/11 machines (back in HS - 1979) you sat at a READY prompt - on screen or paper terminals.

You typed things like NEW "FILENAME.BAS" - SAVE, RUN - and code lines as well.

Ready

10 PRINT 'HELLO WORLD'
20 END
Run

HELLO WORLD

Ready

PDP/11's where BUSINESS machines - most schools had them and ran student admin packages like attendance on them. Colleges used them for billing.

TRS/80's from Radio Shack behaved the same way.

Primitive file statements are unlike regular language constructs for many of these reasons (like NAME AS)

[szlamany]

From a wiki link

In 2006, 59% of developers for the .NET Framework used Visual Basic .NET as their only programming language

[Tanner_H]

Given that .Net has had free express versions while 6 cost hundreds of pounds or had to be... ahem... independently acquired... I reckon they'd have had more bang for less bucks from .Net but I do know what you mean. I don't think MS ever envisaged that they'd still be supporting it after all this time. I know I certainly didn't when I decided to switch. I personally reckon that's mainly due to the fact that VBA never got replaced as the language behind office but there's a variety of reasons if you choose to go looking.

VB6 Control Creation Edition was free for anyone. The primary limitation was no compiling to native code, but for beginners, that wasn't a deal-breaker.

SMBs and maintenance only apps are an interesting case. I've always argued that migrating an app purely because you want it to be in a new language is insanity - you re-engineer when you need to, not because you saw something shiny and wanted to chase it. My experience was that I had a few clients with VB6 (or in one case VB3) apps that they wanted maintained beyond the early millennium and I was able to make a bob or two supporting them for a whole but they inevitably found that their own worlds moved and at some point they all changed direction, either by paying for a rewrite or just buying in a completely different product. I can honestly say that I am no longer aware of anyone still using it - which is not to say they don't exist, just that they've dwindled to a largely irrelevant market that's no longer worth me targeting.

I'm really talking about bespoke apps there though, and I do have some sympathy for folks that developed an off the shelf app in VB6 and then saw active support removed. Such sympathy as I have, though, is tempered by the fact they've probably had the best post deprecation support the IT industry has ever seen. If 15 years wasn't enough time to viably migrate your application then the application wasn't financially viable to begin with. So if I see someone say "I've never migrated my app and now I'm doomed and it's all Microsoft's fault" then I don't really have any sympathy. If, on the other hand, I see them say "I never bothered migrating because I guessed right that MS would never quite drop support and I've saved myself a mint on migration costs, Suckaz", then I'm inclined to pat them on the back and respond "good call, dude, good call".

So true. I always go back to the seminal article on code rewrites: Joel on Software - Things You Should Never Do, Part I.

As for "If 15 years wasn't enough time to viably migrate your application then the application wasn't financially viable to begin with," we must work in different fields. This is no different from companies who built some horrible web app in ActiveX and are now tethered to IE6 forever. (Yep, I steal deal with this WAY more often than I'd like.)

Maybe it's an American business thing, but I have worked for far too many places where the approach to code maintenance was "do not migrate until the end of the world." Hacks, VMs, dedicated boxes running insanely old OSes - whatever it takes to keep working code working.

I used to think businesses like this were crazy, but honestly, the older I get, the more I subscribe to "if it ain't broke, don't fix it." I'm sure there are exceptions, or maybe some nice formula you can use to estimate the costs of maintenance vs rewrites, but idk... there are so many new problems that need solving, that I can't blame companies for wanting to rewrite or migrate until the last possible instant.

(Of course, when I'm the guy stuck deciphering ancient FORTRAN code and trying to figure out how to rewrite it as a modern web app, I'm a little more furious about this...)

[Tanner_H]

The implication is that VB.NET developers will be in the same boat as VB6 developers. As already noted, the transition to C# is actually quite trivial step from VB. If the .NET platform goes away, there are a whole host of other technologies - web development which has a fairly strong market share is not reliant on .NET in any way shape or form. I believe most .NET developers have more than a passing familiarity with web-based technologies (e.g. JavaScript and associated libraries).

VB6 does not give 'hobby developers' any bang for their buck, and has not for well over a decade. It was easy to learn, but at a dollar cost. VB6 allowed someone with no programming skills to create applications; the similarities between VB6 and VBScript demonstrate this, and why VBA has not gone away, as atrocious a programming language that it is (it served a purpose).

the .NET (Express) opened up 'real' programming practices to the non-programmers. Those without programming training, education or skills would find .NET very daunting and overly complex. Much like any other skill, just because you have the tools, doesn't make one a craftsman in that field. This is where VB6 was lauded as an amateur language; it didn't have the rite of passage that the real programming languages demanded.

Oh please - not this tired argument again.

There is no magical demarcation between "real programming" and "fake programming". If you are typing out instructions for a computer to follow, guess what? You're doing programming.

.NET did not magically make programming "real" for hobbyists, any more than BASIC or HTML or Javascript any other language did. Languages like LOGO were helping the masses understand programming long before VB even existed!

"Those without programming training, education or skills would find .NET very daunting and overly complex."

Sorry, but this is just silly. Why do you think many universities and community colleges use .NET as part of their intro to programming course? .NET development is cake compared to C/C++, so I have no idea why people think it's some kind of mythical terrifying thing. (VB6 guys might make this argument, and if they do, they should be called on it, because it's idiotic.)

Please stop parroting the ridiculous argument that some kind of "rite of passage" is required for True Programmers (tm). There are hobbyists who write better code than guys with Ph.D.'s and thirty years experience. Good code is good code, regardless of the source, and regardless of the language.

[dilettante]

While I'm certain there was a VB5 Control Creation Edition (I have a copy here) I'm not sure there was ever a VB6 Control Creation Edition (and if there was I don't think it was free but possibly part of VFP 6 or possibly the same as the VB6 Learning Edition only legally distributed on books with CDs).


As far as "newbyism" goes, I'd think if anything VB.Net is a far better choice than VB6. I say that because Microsoft has updated to tools to make it easier for the novice to create working programs on current versions of Windows. You also get easy use of ClickOnce.

Producing and deploying VB6 programs that work properly can be a far tougher thing since the VB6 community was long ago abandoned to live or die on its own. This means you can't rely on intro books or stuff downloaded from POS Code any more, you need to know a bit more about Windows and be a lot better at reading Microsoft documentation and making use of the Windows SDK. Windows has changed substantially since 1998.

We see a lot of this in the question threads on VB6. A good number of them deal with UAC, deployment, Unicode, and other issues VB6 didn't have to "worry about" at release. Anyone can cope with these given some effort, experience, familiarity with the documentation, and good reading comprehension. The "pro" is more likely to have these but it doesn't preclude dedicated hobbyists from getting there as well.


There are people who stumble as novices with a first programming language. They reject it, blaming the tool, and move to a second. Once they make progress with the second language they acquire a confirmation bias and their rejection of the first one becomes more extreme.

[dilettante]

This reminds me of back when I had a regular full-time job before I retired.

Back around 2004 there was a push to migrate several major mainframe application suites to "another platform" and Windows was chosen. This was put under the direction of a 3rd party consulting company, and "fire one" was "Let's do all of this in C#!"

The full-time programmers were sent to 3rd party training, teaching Microsoft's official curriculum. These were 4 and 5 day intensive courses with labs using Microsoft's training materials. The idea was for the staff to work with the vendor during the "porting" process and take over maintenance once conversion was complete.

The progress was amusing.

The full-time ASP.Net guys came in cocky, but they failed to complete the first 4-day course!

The VB.Net "desktop" guys made it through the first course, struggled with the second, and failed to complete the third course.

The old-timer Cobol guys struggled with the first course, then aced the second and third. A couple of former systems programmers with multilanguage background being retreaded as application developers were able to sleepwalk right through all three courses.

Then the conversion project smashed right into a wall after two years of effort. It got about 1/10th of the way along in that time and the users and testers got totally fed up with the poor performance of this system, front-ended with Ajaxy ASP.Net, middle in C#, and SQL Server as the database.

It just couldn't cut it... at all. Even with a load of 10 users!

Back to the drawing board, and a year later the vendor came back. Now they proposed a fatter-client approach using VB.Net, discarding ASP.Net for anything but a few minor public-facing interactions.

No training this time. The vendor would do 90% of the conversion with a new team, and the local guys were told to just keep up.

The ASP.Net guys were worthless, and the VB.Net guys were removed from the project and sent back to maintain their existing code. Only some of the Cobol and formerly-systems folks were involved in the programming, and everyone else was forced to do little but unit testing.

The last I heard... even this many years later only a small fraction of the job was done, working as a parasite on the existing mainframe suite. This vast waste of money, effort, and time has made the newspapers a number of times.


What does this show?

The language doesn't make the man, the man makes the language. It is far less about the tools than the workman.

[FunkyDexter]

The language doesn't make the man, the man makes the language. It is far less about the tools than the workman.

Now there I'm with you 100%.

[techgnome]

I had a similar experience on a project. in a prevois life they brought a bunch of us on board to build a new entrprise system that would replace some 20+ applications based on dos, access, excel, and who knows what, as well as replacing a number of home-grown stuff from each regional office.

Overall, it worked, however, it was based on a hugely flawed architecture that didn't scale well. some of us in the trenches saw it coming. but we were "too far down the road to try and change it now"... we rolled 3 offices and about 12 projects (it was a construction copany) before someone saw fit to pull the plug, and do usability/load testing. Needless to say it failed big time. Again, echoing dil's post, it wasn';t the tool, but the carpenter that was the problem. We all built qualiuty stuff on top of a really bad foundation and it caused it crumble in a spectacular way.

Ironically, at the time of this failure one of their newly aquired companies said "Hey, we can do this in SAP< we're SAP 'Masters' we'll set it all up." -- last i heard that failed just as well, it turned out they weren't the SAP Masters they thought they were.

Not sure what they are doing there now. nearly everyone i knew from there has moved on to newer and better things.

-tg

[SJWhiteley]

...
What does this show?

The language doesn't make the man, the man makes the language. It is far less about the tools than the workman.

That is true, but here's my story.

I had a guy who agreed to mow my lawn. He turned up. No mower. He used my mower. He needed gloves to pick up branches and leaves. I gave him some gloves. He needed bags to bag the leaves. I supplied them. Half way through - a 1/3 acre lot - he said he was tired and would finish later. He wanted the money for the job, then. I told him he'd get paid when he finished. I never saw him again.

So, yes, it's less about the tools than the workman, but if the workman shows a bad choice of tool, that is the workman.

[Niya]

Yea, there are guys that would use a hammer to turn a screw.

[SJWhiteley]

At some point, this may turn into 'What if there was a NEW VB.NET'.

[FunkyDexter]

We'd all refuse to use it and start petitions to get the old VB.Net brought back.

[szlamany]

I'm curious - these questions go out to the "New VB6" proponents (or I guess anyone who wants to speak up).

1) What are the top 5 features or aspects of VB6 that are the most important to you - that you really require?

2) What are the top 5 most unwanted features of VB.Net that you never, ever want to see?

[NeedSomeAnswers]

I'm curious - these questions go out to the "New VB6" proponents (or I guess anyone who wants to speak up).

1) What are the top 5 features or aspects of VB6 that are the most important to you - that you really require?

2) What are the top 5 most unwanted features of VB.Net that you never, ever want to see?

Stop trying to turn this into a Logical argument szlamany, otherwise whats the point of this thread !

Anyway we all know what the arguments are by now, the reasonable, the unreasonable and the downright crazy !!

But if you really really want a proper answer its because VB.Net is made of Jam and not marmalade!!

[dilettante]

There are limits to what could be done without breaking a lot of things people expect from VB6 now.

Anything that requires a new runtime will become a disaster for many. People have come to rely on a stable VB6 runtime being preinstalled as part of Windows. That precludes any changes to the set of instrinsic controls, native I/O, and other built in classes and functions.

What could be done includes things like an updated IDE, a new C2.EXE aware of newer CPUs to generate more optimal code, more OCXs containing Unicode as well as ANSI controls, and new OCXs and DLLs that follow the shift from 1998 to now. In many cases all that is needed for the latter are some wrapper-OCXs or even just some typelibs for things already implemented in Windows... and then some more VB-friendly documentation. The main "shifts" I'm referring to include less need for ANSI support, more need for Unicode including UTF-8, prevalence of HTTP and web services, and things like that.

Most of that could be done piecemeal, i.e. they might leave the IDE alone except to add a few compiler options to be passed through to C2 - if even that. Or they might just ship a "libraries add-on pack" with those new OCXs, DLLs, and typelibs.

Any or all of that could be part of a new Service Pack.


More radical changes that actually resulted in a real VB7 (not VFred7) would mean the runtime deployment requirement returns. I don't really care for that unless it made things that I need possible, and most of what I want or need could be accomplished through that "service pack" approach I already described.

In a UAC/least-privilege world being able to package VB6 programs as "portable apps" using reg-free COM has been important. With a "new VB6" we would lose that because of the new runtime requirement... unless they found a way to make the runtime libraries portable as well.

[dilettante]

Hmm...

I might have to take some of that back.

With a new IDE/compiler and C2.EXE pass 2 I suppose they could add to native I/O syntax and even add new Unicode pseudo-intrinsic controls by compiling them as calls into a statically-linked extender library. Then the existing Earth Standard VB6 runtime that is preinstalled in Windows could still be used.

This would bloat compiled programs, but how much depends on how many things they put into the extender library. I suppose that could be an optional DLL though instead.

Edit:

But that's still a minor update, not a "new VB6" at all. Call it "VB6.1" maybe?

[SJWhiteley]

We'd all refuse to use it and start petitions to get the old VB.Net brought back.

From what I can see in this thread, VB.NET is, apparently, already on life support. Should we start the petition now?

[dilettante]

You could say all of Windows is on life support, aside from the WinRT part Microsoft is focusing on.

If Windows 10 fails to see high rates of adoption I'm not sure what might be next. Maybe that would be enough pain to get them to drop WinRT and go back to a desktop focus and a normal version and service pack life cycle.

[Gruff]

Regarding Windows 10 adoption.

I've been running the Windows 10 Evaluation for some time now.
I think in general it will be accepted for desktop as it looks and feels very much like Window 7.

Where they could go wrong is if they try to strong arm Microsoft products over the competition.
Essentially they want you to buy into the Microsoft cloud world.
All your content and apps (eMail, files, pictures, video, music, games, etc) will have direct control from the OS.

So far it looks like you will be able to use third party apps, but they will not be integrated with the OS.

[Niya]

Regarding Windows 10 adoption.

I've been running the Windows 10 Evaluation for some time now.
I think in general it will be accepted for desktop as it looks and feels very much like Window 7.

Did they bring back Aero glass ?

So far it looks like you will be able to use third party apps, but they will not be integrated with the OS.

Could you explain this in more detail ? If you're saying what I think you're saying, then that's a deal breaker for me.

[Gruff]

Ah. No Aero. (so far.)

What I meant for instance there is a search bar built into the taskbar at the bottom of the screen.
It is available all the time. It only searches with MS IE or the new reduced size MS Browser.
Cortana (MS speech recognition tool) also is built into the search bar.

I see no way to replace them with third party tools. Say Chrome and Chrome Speech Recognition.
Of course nothing is stopping you from launching Chrome and using speech recognition from within Chrome.
It is just not immediately available as Cortana.

Microsoft Skydrive. Now called OneDrive is just another Drive/folder in Windows Explorer making it that much easier to get to.

XBox
Exchange
Etc...

Are all offered the same way.

My gut feeling is that Microsoft can give Windows 10 away for free to Windows 7 and 8 users because they will make money back on all the services they will be charging you for.

[FunkyDexter]

You could say all of Windows is on life support

You could say that but you'd obviously be wrong.

[dilettante]

PC Market Continues Decline Despite Growth in Mobile PC Segment

"The first quarter results are not a sign doom for the U.S. market," Kitagawa said in a news release. "The biggest reason for the decline of PC shipments in the U.S. was attributed to the desktop market, which experienced a double-digit decline. This was primarily due to the end of the Windows XP replacement cycle. In contrast, mobile PC shipments in the U.S. continued to show year-over-year growth, and early results show this segment could have grown approximately 10 percent in the first quarter of 2015."

Ok, so "mobile PCs?"

3 Reasons Chromebooks Are Shining in Education

While some observers might refer to this changing of the guard as a "return of the laptop" or the "tailing off of the tablet," to those doing the buying, that’s not quite the case. Valerie Truesdale, chief of technology, personalization and engagement for North Carolina's Charlotte-Mecklenburg Schools, said of the HP device in use at her district, "It's the size of a tablet; it's portable [like a laptop], but this Chromebook is another animal in between.”

I.e., not Windows laptops either. Windows is in a steep decline.

[szlamany]

How about a more open consideration of the state of Windows PC sales?

http://www.zdnet.com/article/the-rea...ugh-computing/

It is a complicated situation - many different ways to serve the same need with users cherry picking where to get x or y from.

[techgnome]

Ok, so "mobile PCs?"

W/o reading it, I'd venture that "mobile PCs" referrs to things like the Surface Pro line... too big to be a tablet, too small to be a laptop... sort of the "tween" of computing platforms.

It doesn't surprise me that traditional PC sales are slowing or even declining. people want their stuff on the go. Even in the business world, I'm seeing more and more people whipping out their iPad, or Surface, or what ever tablet at meetings. The only people I still see using a laptop or desktop are Techy types, or hard-core business users who are still running old (but tried and true) system that work on older systems.

-tg

[FunkyDexter]

I'm seeing more and more people whipping out their iPad, or Surface, or what ever tablet at meetings

Sure they do. And then they all go back to their desks and fire up a traditional desktop. Walk around any office and it looks just like it did 5 years ago. Windows is far from "on life support".