The "profile" feature is both annoying and useful. If you sign in you can save/change your "profile"; then if you login on another system, your profile settings will be applied for the session. it's annoying because logging in on another machine invalidates every other system, so if I start it on my laptop, the copy on my desktop will freak out- basically it won't let me use both at once, which makes perfect sense. I worked around this by instead using Visual Studio 2015 on my laptop.

It's unlikely. Windows 3.1 was the codebase used and eventually upgraded to Windows ME. Windows 8 is based off of NT, which was completely separate product from the 9x line. It's possible there is some code-reuse at the Windows Application level (tools like notepad for example) but I would be surprised if there was anything from 9x like what you've mentioned; the Kernel's were entirely different; Even between 9x and Windows 3.1 Applications needed to take special care to work on both. Also, Windows No longer has a "MessageBox" Function. Windows NT uses Wide and ASCII versions for those functions, so we have MessageBoxA and MessageBoxW; consequently they both are almost certainly changed internally as a result.

As for VB6 being full of problems, perhaps I should qualify: For it's Era, it was a very good product. However, in the context of developing applications today, I'd say it's full of problems by virtue of being designed for the technologies of ~1998. So when I say "full of problems" I'm thinking more in terms of developing Applications that look and work like any Other win7 application. Off the top of my head I seem to recall having to hack in the resource manifest to get Visual Styles, Some whimsy and hacks to get Icons that support Alpha channels, and such. My most memorable experience was managing to actually get the Right-Click Explorer Menu in my own application, which involved crazy amounts of weak references, manual use of CoCreateInstance and QueryInterface, custom Typelibs for the shell interfaces, etc. However, I also rewrote that functionality in C# later, too, and I found it to be a lot cleaner and easier. I can't say this is entirely because of the language and platform, because I'd like to think I simply got better as a programmer in the meantime. Perhaps ironically, I think it was easier to do because I didn't need to learn more; with the VB6 version I had to learn MIDL and the MIDL compiler, enough about IDL to define Interfaces, etc. with C# I could do that with attributes and C# interface definitions.

VB6 didn't have implementation inheritance. This is a rather massive omission. I wouldn't say it required "minimal coding" since you had to manually write a new implementation that delegated to an instance of the inherited type. I recall there are some add-ins that can actually do this for you. It also lacks Generics, but I think we can give it a pass on that since generics wasn't in many languages for some time after VB6's release. (Even though the lack of generics is the thing I find most infuriating as I frequently re-implement type-safe collection classes...). the "interface" classes you see are the interfaces created by the VB compiler. Basically the interface was generated automatically and your actual concrete class would implement that interface. This get's even more interesting when you use Binary Compatibility and add new methods or Properties to a class- those methods and properties get added to a new interface (I forget the naming scheme) and your concrete class implements both that new interface as well as the old one. Pretty nifty, though sadly it didn't always work particularly well. Forms had similar magic; the Form was simply a class that actually inherited from the Form class, but when you create a Form, VB6 would also magically create a Global instance of that Form with the same name. I mean I have fond memories of VB6 but I also use my benefit of Hindsight to realize that it was full of problems.

I worked in VB6 for years. I was firmly entrenched that I didn't need any other languages, because I could use all the APIs and add functionality if needed. Using CreateThread() from VB6 was generally a very bad idea. You couldn't access anything from the VB runtime, since that was not re-entrant. The best you could get was an Out-Of-Process component as a "multiple thread" but I'm not sure if we can count that. Now that I can look back on VB6, I can say that Classes and Object-Oriented support in VB6 was barely workable. When I think back to the things that took the most effort in VB6, I realize that almost all of that effort is either a result of features the language didn't have (such as emulating implementation inheritance by delegating to an aggregate and using implementation inheritance), or working around it's myriad fiobles (have fun implementing IEnumVariant!). Compared to VB6, C# is (for me) like the difference between having to manually slaughter, gut, and butcher a Animal compared to simply having to cook a steak.

the as operator should only be used when the result being null is either checked, you already know that the cast will succeed (testing with is) or when having a null result will not unravel the application. If memory serves, 'as' will not call any defined cast operator routines, either, which can be desirable functionality in some cases. It should not be used as the preferred cast style, particularly where strong types or specific abstract base classes or interfaces need to be enforced. I'm a bit curious how changing a database type would cause as to return null. It rather brings up the question why you had to cast to begin with, since generally you ought to only require casts when dealing with a polymorphic system. Either way, if a person uses the as operator and does not have a reasonable basis to assume the cast will fail and does not code for the result being null- (for example, with sensitive transactions or database data, trying to preserve existing state and rollback, etc) Then I'm more inclined to say they misused the language, not that the feature shouldn't exist or is a problem itself. My personal rule of thumb is if I have a reasonable set of actions to perform if the cast fails, I use as and compare with null; otherwise, I use a direct cast and just let Exceptions occur, as well as showing any applicable compile-time errors. I also use as when I want to throw a custom exception for the case that the type fails, and don't want to cloud my code with an extra Try...Catch around the cast for an InvalidCastException. I also have to say I disagree with the sentiment that strong typing is important, too, though. I'd say that consistent typing is more important.

I don't think anybody gets paid for 'programming'. They get paid to solve problems, or create things. Programming just happens to be one of the means to an end. If a Language or technology makes a problem easier to solve, or certain things easier to create, there is no reason not to use it. The same argument could be used to say a C programmer should rewrite all the standard library routines, because using the standard library (or STL in C++) makes things "too easy" so somehow it's not "really programming".