No point, I just didn't like the patronising reply from BC to my initial post.
ahh, I see. You didn't like your response to your troll post so you continued to troll, but couldn't even bothered to come up with another precious gem of a content-less post so you repeated the previous one. By the way, THIS post is patronizing. my previous one was informative. See the difference?
Visuals?? Check the ones you don't want off!! I think the biggest beef was "compatibility issues".... hardware like I said.... things don't mix, then get fouled up, people get pi@$#d off real fast! Trust me! ;-)
This is an issue with all Windows OS's; remember, Windows Vista introduced a new driver Architecture; Windows 7 is still using that same architecture, so this might contribute to any perceived increased compatibility.
Ill admit there are some real MS fans here,
I just thought of something... an interesting parallel.
People complain, OS wise, about how their older programs don't work in a newer OS; I've covered that this is usually because the program wasn't written right, etc. But I haven't said a whole lot about the development tools that MS themselves release.
Microsoft's First product was a BASIC interpreter. Every new release was almost always fully compatible with the previous one; you could load BASIC code you wrote for GW-BASIC into QBASIC or QuickBasic and run it just fine. This continued up until the first Visual Basic versions for windows, which needed some minor modifications due to the change from a text-based interface to a Graphical one.
With Each version of Visual Basic, you could almost be certain that you could load a project from a previous version with no issues. Visual Basic 2 Projects Loaded with VB3, VB3 project with VB4, VB4 projects with VB5 (with changes if your app was predominantly 16-bit) VB5 projects in VB6... this makes sense, considering, for example, you can always use all excel versions to open at least (and usually a lot more) previous versions documents. All versions of excel, and word, and powerpoint, etc work this way.
However, for some reason, when MS created .NET and added VB to it, they orphaned over 10 million Software developers who were using Visual Basic. There are more lines of code written in Visual Basic then there are in COBOL, and that's saying something. You can not open any non-trivial VB6 application with .NET and get it working without major changes.
Now this presents two problems: first off, why would they do this to the largest established development tool in the world? and Second, if they are going to do this once, for the first time, to a product that had been around for nearly 20 years, whose to say it won't get easier with time? "oh yeah, we threw everything away for .NET 2012, yep, your going to need to rewrite all your applications. we like this new organization that actually adds no functional value and instead makes things more confusing by grouping vaguely similar objects into namespaces with even more vague names, but hey, that's progress." Basically, it's hard to commit to a new MS tool when they've already swept a base of customers as large as those who used "classic" VB under the rug... whose to say they won't do it again.
And is Office still safe? will they release a Office.NET that completely breaks backward compatibility? No, probably not. s why with a development tool?