The link below goes to a visual studio customer feedback site. We can vote to save vb6... Everyone if you use vb6 Please vote, we need 12,000 votes, we are now at 400. Please Help!
http://visualstudio.uservoice.com/fo...improved-versi
Printable View
The link below goes to a visual studio customer feedback site. We can vote to save vb6... Everyone if you use vb6 Please vote, we need 12,000 votes, we are now at 400. Please Help!
http://visualstudio.uservoice.com/fo...improved-versi
I'm making this a sticky for awhile.
What can they do for a language that has no concept of modern operating systems? They CHOSE not to be able to upgrade VB6 after VS2008. I suppose they can rewrite .Net to use VB6? Not likely...
Seems to me, that a programming language would be sorta crippled if it was written for a specific OS. The more generic it is, the more flexible it can be, I'd think. Besides, VB6 can access the windows API, so it can take advantage of functions which might not have existed when it was first developed. Considering that C++ was developed quite a number of years ago as well, and it is still the language of choice for many developers, it stands to reason that VB6 can also live on. Let's not forget that windows itself is written using C++. The only real question regarding VB6 is whether the runtime DLLs might fail to work properly under some future flavor of windows, since Microsoft doesn't seem very willing to ensure operability.
Given that C++ apps rely heavily on the windows API, and that countless C++ apps exist, and continue to be developed, it seem to me that the API has to be maintained for that reason at the very least. So I wonder how VB6 could fail while C++ apps all still run, unless Microsoft intentionally did something to cripple it, which doesn't seem likely either. They just don't want to guarantee it.
However, it's more than just the language. It wouldn't do much good to duplicate the syntax of VB6 in .net, because .net can only produce managed code, which can be decompiled back to usable source code. Commercial developers have enough trouble from pirates already, even without essentially giving away their code.
They didn't re-write the controls for the new OS, which is where it started to fail. (FLEXGRID Apps?)
Yeah, I've read about a few bugs regarding the appearance of some controls, especially with "themes" turned on. But Flexgrid isn't an intrinsic VB control anyway, so any trouble specifically with that isn't the fault of the VB runtime. Incidentally, all the controls I developed continue to function perfectly :D
I completely disagree with that, respectfully. Any programming language as seen from the programmer's standpoint has nothing to do with the way it is written underneath. That is why QTforBasic can be syntactically identical to vb6, operate the same, yet be totally based on a completely different source and libraries, and it is completely comfortable on Windows, Linux and MAC. MS chose to foist .net on everyone because they lost touch with what 85% of their customers wanted...Simplicity with optional power. Net has the latter, but lacks the former. There is absolutely no way to write code in .net faster than vb6 when just the typing overhead alone is far greater than in vb6. There is a lot of sense in a programming language that has a dual personality...Simplicity for beginners but also for pros who just need to do something really quick and easy with no fuss like having to worry about passed parameters in every procedure..and yet a language that allows the user to tap into the very powerful GDI32 API.Quote:
What can they do for a language that has no concept of modern operating systems? They CHOSE not to be able to upgrade VB6 after VS2008. I suppose they can rewrite .Net to use VB6? Not likely...
Windows 8 can Suspend, Resume, ANY app with a common api. vb6 can't. What happens when Windows 8 kills your desktop app after 10 minutes? Most would have to re-start and initialize to zero...
That's simple...Create vb7 and add the functionality, while maintaining the basic vb6 framework.
Actually, that only applies to newer Metro style apps, not desktop apps.
I would have to completely disagree with that statement. I have used VBDos, 3,4,5,6 and still use VB6. But I have also used VB.Net 2003,2005,2008,2010 and it depends on what you are doing what it entails, at first there was a learning curve that slowed things down a bit but now I find that I can write many things faster in .Net, reuse more code and of course am able to do a lot of things that just can't be done in VB6
Consider that you want to get a list of files from a folder and all sub folders in a given location. In VB6 you can use Dir() and a loop and call that recursively and build your list. You can use the exact same code in VB.Net to do the exact same thing [which btw is the case for many many things] but in vb.net you can do the same thing with a single line of code by using the System.IO classes and if you don;t like the extra typing of adding the System.IO. in front of the statements you can use an Imports System.IO at the top of the class.
The point being that this is one example where you can do something that is fairly complex in VB6 the same way in VB.Net or you can do it a much easier way with less typing and less margin for coding errors and this is just one of hundreds of things this applies to.
Nothing against VB6, it is great and I will keep using it but To say that it is not possible to write code faster in VB.Net just means that you have not used VB.Net very much or have not learned how to use it properly yet.
Well, your arguments are well stated and in principal I cannot disagree with your opinions. However, there is also no reason why such "one-line" functionalities could not have been added to vb6 in later versions. It's analogous to the GDI32 situation where Bezier curves are supported but not cubic splines. Someone just needed to write the function, not change the "language".
It was.... It is called VB.Net of course it is not VB6 anymore because VB6 was a single version of Visual Basic namely "Visual Basic Version 6" the next was "Visual Basic Version 7" which adopted the .Net name and added tons of new stuff as well as keeping support for tons of existing stuff.
Yes there were lots of changes between 6 and 7 just like there were lots of changes between 3 and 4 and 5 not to mention the changes when it jumped from Dos to windows.
Yet the VB.Net versions still support most of the actual code that you could have written in VBDos
To add to DM's replies...
Even with VB.NET there has been a lot of changes as well. If you were to look at how VB.NET 2003 handled databases, and then look at VB.NET 2005, you would see a clear difference.
There are still tons of info add to the VB language ( yes, it is still the Visual Basic language ) and there is a lot of things being dropped off or changed - it is an ongoing process, and it will not change. It doesn't have to just stop.
Look at how Windows and Office has changed. Look at how the technology world is changing. It is obvious that languages should adapt too, isn't it?
I also love VB 6, and still use it quite often
One main difference between VB6 and .net is that .net code can be decompiled back to usable source code. This makes it unacceptable for commercial distribution. That is unless you don't care if your work is stolen. But then, there wouldn't be much point to trying to sell it.
That is an issue for sure. There are ways to make it harder to get the code but I have not tried to crack them to test how well they work. Most of the apps I work on are not for mass distribution so it is not an issue there but there are some main stream commercial applications which are written in .net and seem to be doing just fine.
But it is hard to claim that vb"7" (aka .Net) is an evolutionary change in the vb line. It really is a drastically different language. And clearly, there has been a huge backlash from customers who are frustrated with MS over moving away from the vb "structure". Again, I point to QT for Basic...It is syntactically identical to vb6 and although completely re-written on the inside, did not require changing any of vb6's style (commands, procedures, etc.). MS brain-****** by not appreciating what they had, and more seriously, not appreciating how much they gave the finger to their largest programming product, customer base. If this were not true, there would not be the backlash we still see today, FIFTEEN years later. I am not saying that .Net should not have been created...Just don't confuse it with vb6 and its popularity. Sell it as another programming product. But don't **** off the customer by essentially saying, "**** ***, you get what we give you and you'll buy it." And it is not as if MS doesn't have the money to keep developing both. For a company that insists on creating different versions of one operating system all at the same time, and even multiple OSs, I doubt they don't have the funds. Especially when you tell the people that give you money for your product to essentially take a hike.
Five years ago, I was developing a large app in vb6, only to get a third of the way through and being told that 6 was not going to be supported in Windows 7. So despite my frustration with MS, I ported everything over to .Net, only to find that GDI+ was dog slow compared to GDI32. I no longer had a program with great performance. Quite frankly, it sucked. So I found out that basically, "Oh, you don't want to use GDI+ anymore...That's obsolete. You want to use WPF". I see, so how many times is this going to happen? How many times is MS going to change something and constantly require me to learn something new, when they could have considered the CUSTOMER, and allow me to get a product done without constantly changing the rules?
Oh, and despite MS's claims, vb6 IS compatible with Win7 and Win8! I know there are some who claim that it is not COMPLETELY compatible anymore, but I have not experienced any of these issues on my systems.
So, not only did they change the rules, they lied to the customer to get them to make the switch.
I was so ***** off, I could not bring myself to work on the app for a good solid year. Guess what I am developing it in now? vb6. Guess where I'll go when MS decides to cut the head off of vb6? QT for Basic.
Ever try to run VB6 on an APPLE product? .Net can
I have VBDos Pro on one of my machines still. When I made the jump to VB3 it was a drastic difference. It was almost like a completely different language and I found that there was a learning curve to get even a simple application done. An app I could have done in an hour in VBDos would have taken a day in VB3, and then there were all of these support files, VBX, DLL. My VBDos could build a stand alone exe and there were no need for any of those vbxs or dlls nor even Windows. It could run fine under dos, windows or OS/2. It was a different world.Quote:
But it is hard to claim that vb"7" (aka .Net) is an evolutionary change in the vb line. It really is a drastically different language.
Sound familiar?
This really isn't anything new, the language has evolved over the years and VB6 now is even more ancient than my VBDos was when I started using VB6 and that program I could have written in an hour in VBDos would now take me 30 minutes in VB6 or VB.Net and probably a week in VBDos due to the 1000s of things that have been added since then.
True there are a bunch of people online complaining about .Net, I would wager most of them just haven't really gotten deep enough into to appreciate it. I personally have came in contact with lots of VB programers. There are those who write in VB6, hate VB.Net and complain yet it seems that they really have not given the .Net a fair shake and really do not see the advantages it offers. Then there are those who are new and have not really used VB6 so clearly they favor .Net but then there are those who like myself loved Vb6, used it for years and still use it if for no reason other than that they can quickly through together a simple app and are very confident in their VB6 knowledge. Then there are those who even though they used VB6 for years and thought it was great have taken the .Net plunge and will never go back, some of them could not imagine ever having to write in VB6 again and loose all of those 1000s of extra helper classes and code re usability they get in .Net.
Personally I find it harder all the time to write in VB6 just due to the fact that I am getting more used to the .Net environment and structure. One big point for me is that using VB.Net I can easily develop applications for Windows CE devices, Windows Mobile devices, Windows Phone, as well as Windows Services, Web Services, ASP.Net web sites, Xbox360 as well as the traditional Windows apps I had always used VB6 for. About 90% of the projects I get now require me to use .Net as they simply can't be done in VB6. and others are just easier to do in VB.Net
Oh anothe rbig advantage with vb.net is the multi threading support is great on modern multicore PCS. a properly built VB.Net program could run 2 to 6 times faster than one written in vb6 on the same machine depending on number of cpu cores
DOS is a bit different than the Windows style...
I totally agree about the multi-threading in .Net. I have used it myself and the performance increase was really cool (roughly 20%). But I was vastly annoyed at the awful performance of GDI+. That was definitely a step backwards in my opinion. For the life of me, I cannot understand why they just could not get that right, and instead, reinvented the wheel again with WPF. But you echo my opinion about the ease of use of vb6. THAT to me is the key point that MS missed when they moved to .Net. Again, the beauty of vb6 was simplicity, yet power via GDI32. REALLY great performance with that API.
I know we all think differently, and so our minds all have different requirements to work quickly and efficiently. For me, vb6 was it. It just needed to be taken further in that direction rather than jump the tracks and head off in an entirely different direction at the expense of vb6.
Yep. Like a new model of a car that looked great until they ruined it. :)
Or... improved it....
An improvement to VB6 would be to enable it to produce true, stand-alone executables. In other words; without the need for any runtime dll files. But .net takes it completely in the opposite (wrong) direction, with an entire "framework" monstrosity (runtime dependencies), managed code, and more overhead than in our wildest dreams. IMHO, .net is not much more than a competitor to Java. And like Java, .net finds a place within companies who need proprietary software, which is not for wide commercial distribution.
And many moved to Java for just those reasons.
If someone made a serious offer to BUY the program from MS, then they'd get the source code, and be free to add whatever they wanted. Kind of hard to implement the CLIPBOARD from Metro to Desktop. Until MS Research released CLIP in the Window Store. Now it works!
Ironically VBDos does have the ability to produce true stand alone exes as does Quick Basic this ability was removed with the introduction of the Windows environment.
There are many commercial programs done it .Net. I can't tell you which off the top of my head but I have had several that required a version of the dot net framework to run.
Nero ( used to burn CDs ) and CorelDraw are perfect examples. Since CorelDraw changed their versions to X4, X5 etc. the .NET Framework was needed. That sucks in my opinion and that is why I actually still use CorelDraw 10 ( although I am forced to use the newer versions when teaching those classes ). Since .Net framework was introduced into CorelDraw things started to become a bit more sloppy and sluggish.
I'm starting to agree with you folks.... That is scary :eek:
Not for a few years... http://www.thefullwiki.org/VBDOS_1.0
I wonder if perhaps a programmer creating something in C++ or other language might also utilize some part of .net as a shortcut, or if they don't know how to do it otherwise. Is it possible for a program not written in .net to use the framework for certain functions, thus the requirement?
C++ uses the framework. Even JAVA can use it.
Have a look here :
http://msdn.microsoft.com/en-us/libr...=vs.80%29.aspx
I programmed in Visual Basic 6 professionally over a tens ago, but I have not used it since. I am actually quite surprised to hear that people are still using it. Perhaps, it is still being used because Visual Basic 6 was the only version of Visual Basic that could be compiled into machine code and thus, easily distributed. Having a background in C++ and Windows API, I am not a fan of Visual Basic. I felt like I was forced to ride a bike with training wheels. The thing, I liked about Visual Basic the most, was the ability to easily call any function in any DLL by just supplying the interface. This allowed me to bypass some of the limitations of Visual Basic.
I lot of you are crying that Microsoft has abandoned Visual Basic 6. Do not feel so bad. In about fifteen or so years, people will be crying about Microsoft abandoning .NET! Microsoft keeps re-inventing the wheel with most of its products, because that is how Microsoft keeps making money. If you do not want someone else re-inventing your wheel, then re-invent it yourself.
Given that there are hundreds of millions of Windows users out there, I would hardly consider a programming language to be crippled if it can only be used to create applications that run on Windows. As far as I know, applications written for Windows NT 4.0 should still run on Windows 8 and all of the versions in between.
Actually, all applications running on Windows rely on the Windows API. The Windows API is how the applications and the operating system communicate. Once an application, that does not rely on any run-time DLLs, is compiled, the language the application was written may not even be able to be determined.Quote:
Given that C++ apps rely heavily on the windows API, and that countless C++ apps exist, and continue to be developed, it seem to me that the API has to be maintained for that reason at the very least.
Any executable file can be disassembled. Some are more tricky than others and converting that assembly code back into a higher level language may require a human to make sense of it. This can in some instances, however, be even more work than just writing something from scratch.Quote:
.net can only produce managed code, which can be decompiled back to usable source code. Commercial developers have enough trouble from pirates already, even without essentially giving away their code.
This statement would be true if it read "There is absolutely no way to write code in .net that runs faster than code written in vb6".
Apples can run Windows, so just about anything that runs on Windows can run on an Apple product. Since Apples and PCs now use the same processors, there is not even much of a performance drop.
.NET was Microsoft's response to being successfully sued by Sun Microsystems for J++. Java is used a lot to run web servers and thus, the Java applications are only accessible to the people who work on the web servers, not the web browser clients.
This should be expected since .NET applications are compiled into byte code that must then be emulated by the .NET run-time DLLs. Applications compiled into machine code need no such emulation. I agree with everyone who says this was a step backwards. I have been saying Java was a step backwards ever since the first time I heard about it.
I'll suggest rereading what I said, in context. What I meant was, if a language was designed to produce programs only for a specific version of an OS, be it windows or any other.
Indirectly, yes. With that I'd agree. But one can write an application in VB6, Java, .net, and many others, without directly accessing the windows API. It happens behind the scenes.Quote:
Actually, all applications running on Windows rely on the Windows API. The Windows API is how the applications and the operating system communicate. Once an application, that does not rely on any run-time DLLs, is compiled, the language the application was written may not even be able to be determined.
I actually suspect that Microsoft may hope to discontinue the windows API altogether, perhaps in part to put an end to the debacle of DLL mismatching. I mean, if enough programmers were to embrace the .net framework the way it is being promoted, they wouldn't directly access the windows API (I am under the impression that doing so is already "taboo"). Then, there wouldn't be so much a need to continue exporting the functions. That way, when they want to change something at that level, the programmer wouldn't even have to know, as the interface provided by the framework would continue to operate the same way. It would essentially make (to use your words) "training wheels" a necessary part of windows programming. There might possibly be a way around that, but it wouldn't be particularly easy. Thus most programmers, especially by that time, wouldn't likely even attempt it.
I tend to agree, but .net makes it comparatively easy. As I understand it, the reason is because .net code is managed, thus it only compiles to intermediate code. I've read the same goes for Java.Quote:
Any executable file can be disassembled. Some are more tricky than others and converting that assembly code back into a higher level language may require a human to make sense of it. This can in some instances, however, be even more work than just writing something from scratch.
But there again, this plays into Microsoft's stated goal, which would essentially make end user systems not much more than dummy terminals. How? Easy. With programs that are vulnerable to theft of source code, programmers would be practically forced to deploy their wares only on servers, to be accessed over the Internet. I see the push for "cloud" servers as yet another step in this direction.
Thank goodness there are other languages for producing windows programs out there besides .net. But they'd all stand to be seriously hindered if not destroyed if the API is evaporated.
Actually no, it would still be false. While it is true that in general VB6 can create code that runs faster than what is created in Vb.Net the fact that VB.Net can use all 6 cores on a 6 core processor at the same time means that you can write code that will run faster in Vb.Net than in VB6. There are also many things that you can do in .Net that are simply not possible in VB6 so it would be hard to find a way to write something faster when that something can not be written at all.
Click-once can deploy a NET app to a user desktop that just goes away immediately after it closes. Only opens from the web link. Hard to imagine in the VB6 days.
.Quote:
Actually no, it would still be false. While it is true that in general VB6 can create code that runs faster than what is created in Vb.Net the fact that VB.Net can use all 6 cores on a 6 core processor at the same time means that you can write code that will run faster in Vb.Net than in VB6. There are also many things that you can do in .Net that are simply not possible in VB6 so it would be hard to find a way to write something faster when that something can not be written at all.
Not so true since there are many mathematical processes and processes in general that do not lend themselves to parallelism, or where parallelism is very limited. So a "fast" language should not depend on multi-processing to get the speed it should be expected to have without MP. Case in point, some years ago, I had written a program that numerically solved for the position and velocity of a spacecraft moving through the solar system. The positions of the planets at each second were based on periodic coefficients such that out of the 8 planets involved (Mercury is too small as the 9th planet to have any bearing on the problem, unless you are very close to it), only 8 threads could be concurrent and no more. Although it ran roughly 20% faster than my vb6 version (which was cool by itself), the program still had to send data to the screen, and THAT was a huge performance loss in .Net due to the gawd-awful performance of GDI+. So gain here, lose there...That's no way to build a newer, "better" language.
In addition, the notion that vb6 does not support parallelism is not true. It's not easy, but it CAN be done.
By "behind the scenes" you mean within the run-time DLLs. The run-time DLLs, in turn, call the Windows API.
The DLL mismatching debacle ended with Windows NT 4.0. Every process gets its own copy of the Windows API DLLs in its process memory so DLLs that use global or static variables no longer affect other processes. Also, 16-bit DLLs used ordinal numbers to identify export functions. These numbers were assigned sequentially when the DLLs were compiled. If a DLL was later updated with a function inserted somewhere between existing functions, the functions after the inserted function would have their ordinal numbers shifted, causing all types of havoc. 32-bit DLLs generally use function names to identify the export functions. Open an executable file in Notepad and scroll down towards the end. You will see the statically linked function names amongst the other gobbledygook. (Incidentally, never try to modify an executable file in Notepad because Notepad automatically converts null characters to spaces, among other reasons.)Quote:
I actually suspect that Microsoft may hope to discontinue the windows API altogether, perhaps in part to put an end to the debacle of DLL mismatching.
As far as DLL versions goes, the Windows API DLLs (kernel32.dll, gdi32.dll, user32.dll, ...) are written to be backwards compatible. Newer versions of the DLLs may contain additional export functions, but the previous export functions should not change or disappear. Only official Windows updates should ever replace the Windows API files. Other software installations should never do that. Likewise, applications that use their own support DLLs, should install those DLL files in their own folders along side their executable files, not in the Windows directory! This may have been done in the pass to save on hard disk space, but there is absolutely no reason for it anymore. (Third party driver files that have to be installed in the Windows directory can still cause conflicts.)
The Windows Application Programming Interface will never be discontinued! As I wrote before, the Windows API is how every application communicates with the operating system, whether you see it or not.
The only people, who consider accessing the Windows API directly to be "taboo", are those who want you to only use .NET and those who fear what they do not know. .NET will never be fully embraced because it uses an intermediate code middle man which slows it down. Code written to call the Windows API directly will run faster with less memory overhead. I write all my applications to call the Windows API directly. Sure, it takes some time to learn the Windows API, but it is not any harder than learning the constantly changing frameworks. To make development quicker, code can be reused over and over.Quote:
I mean, if enough programmers were to embrace the .net framework the way it is being promoted, they wouldn't directly access the windows API (I am under the impression that doing so is already "taboo").
If the Window APIs or any libraries for that matter are carefully updated to be fully backwards compatible, the existing interfaces will not change.Quote:
That way, when they want to change something at that level, the programmer wouldn't even have to know, as the interface provided by the framework would continue to operate the same way.
Yes, Microsoft copied Java on this, but Java was not the first to do it either.Quote:
As I understand it, the reason is because .net code is managed, thus it only compiles to intermediate code. I've read the same goes for Java.
Mainframes are secretly making a comeback. :eek:Quote:
But there again, this plays into Microsoft's stated goal, which would essentially make end user systems not much more than dummy terminals. ... I see the push for "cloud" servers as yet another step in this direction.
Now, for those of you who want to continue to use Visual Basic 6, there really is nothing stopping you from doing so. As long as Microsoft continues to make the newer versions of Windows backwards compatible, your applications and Visual Basic Studio should still work fine. (I would hope all the bugs in Visual Basic Studio have been resolved by now.) You may not be able to access the newer features intrinsically through Visual Basic, but this can still be accomplished indirectly by calling the Windows API directly. I admit calling DLL functions from Visual Basic is somewhat awkward, but maybe somebody could encapsulate the necessary code in classes so you do not have to look at it. I do this with some of my code.
You'll note that i did not refer to any one specific code just the fact that VB.Net can generate faster code than VB6. This is not always going to be the case but it is at times. I was responding to the statement that there would be absolutely no way to write code in .Net that runs faster than code in VB6 which is a false statement. It is possible and in some cases very likely.
Also I pointed out that there are things that can't be coded in VB6 that can be coded in VB.Net so clearly those are going to run a lot faster since the VB6 version would not run at all ;)
You make good points, but I still say that the deficiencies in vb6 are only because they dumped it and didn't add more to that language. There is no reason why vb6 could not have gone with full parallelism and other goodies you find in .net. Again, it has nothing to do with what's on the inside to make it work...It has everything to do with how the user gets something done. That has more to do with evolution of a product, and I don't see .Net as an evolution of vb, but more a whole different gene pool.Quote:
Also I pointed out that there are things that can't be coded in VB6 that can be coded in VB.Net so clearly those are going to run a lot faster since the VB6 version would not run at all
Regardless. It is still VB it is just different than it was 15 years ago just like VB6 is completely different than the brand of basic that MS was offering 15 years before VB6.
Things change, that's just the way it is.
I also doubt that even with updates to it that VB6 would have been altered to be able to create XBox games, Windows Phone apps, Silverlight and such
Yes, that's what I mean. Although I suspect that in some future incarnation, .net may not use the exported functions. In fact, I don't know if it uses them currently. I've seen code examples of how to access DLL functions that aren't exported, so that's why it wouldn't surprise me if the windows API eventually goes away. Yes, gazillions of programs depend on it, but Microsoft seems to have a tendency to change the game anytime they want. And if they want as many programmers using .net as they can get, this would seem to be one way to do it. Besides, it could certainly put a big dent in the competition for desktop apps, if most applications have to be accessed over the Internet.
Sure, but the less competition there is, the less the possibility for conflicts. Still, while it may play a part, I don't think this factor is a major motivation for the push behind .net.Quote:
As far as DLL versions goes, the Windows API DLLs (kernel32.dll, gdi32.dll, user32.dll, ...) are written to be backwards compatible. Newer versions of the DLLs may contain additional export functions, but the previous export functions should not change or disappear. Only official Windows updates should ever replace the Windows API files. Other software installations should never do that. Likewise, applications that use their own support DLLs, should install those DLL files in their own folders along side their executable files, not in the Windows directory! This may have been done in the pass to save on hard disk space, but there is absolutely no reason for it anymore. (Third party driver files that have to be installed in the Windows directory can still cause conflicts.)
See above.Quote:
The Windows Application Programming Interface will never be discontinued! As I wrote before, the Windows API is how every application communicates with the operating system, whether you see it or not.
Yes, that's what I was getting at. Incidentally, I also use the API directly, whenever it'll make a positive difference, which is just about everywhere.Quote:
The only people, who consider accessing the Windows API directly to be "taboo", are those who want you to only use .NET and those who fear what they do not know. .NET will never be fully embraced because it uses an intermediate code middle man which slows it down. Code written to call the Windows API directly will run faster with less memory overhead. I write all my applications to call the Windows API directly. Sure, it takes some time to learn the Windows API, but it is not any harder than learning the constantly changing frameworks. To make development quicker, code can be reused over and over.
I mean the interface provided by .net. There are a bunch of deprecated functions which I'm sure they'd gladly strip from the windows core DLL files once they got enough programs to stop using them. I've also read that there are a number of popular programs which use techniques which Microsoft doesn't appreciate, so weeding those out would work in their favor as well. They apparently have to keep certain things unchanged just because of the wide use of such programs. The more programmers Microsoft can get on board .net, the more freedom it gives them to rework the core.Quote:
If the Window APIs or any libraries for that matter are carefully updated to be fully backwards compatible, the existing interfaces will not change.
Therein lies the key to the problem:Things have changed over the years.Quote:
It has everything to do with how the user gets something done
DLL mismatching is a no longer an issue, but by suggesting that it is, you are actually helping the push towards .NET.
In other words, the .NET run-time will be incorporated into the Windows operating system, if this has not already been done. Microsoft could then phase out executable files with byte code files taking their place. Microsoft would essentially become another Apple, forcing third party software vendors to use Microsoft's development tools and possibly taking a chunk of the software revenue as well. Apple already does this. They get 30% of anything sold through their App Store and their iOS development environment forces developers to use their App Store. Microsoft sees how much money Apple is making and they want that money too.
If Microsoft does this, I predict there would be a major migration to Linux or other operating systems, although Microsoft would surely still enjoy a hefty piece of the market. Some people simply would not upgrade to the so-called "latest and greatest" version of Windows, much like people stopped upgrading to Windows Vista. Unfortunately, this may prevent them from upgrading their hardware as well since the older versions of Windows will no longer be available and may not take advantage of new hardware features. Of course, hackers will find a way around this, but their actions will not be deemed legal by Microsoft. That will not help people like us who are trying to make an honest living.
Sorry for getting a little off topic here, but your fight to save Visual Basic 6 may ultimately be a fight to save Windows as we know it. There are a lot of other non-.NET languages out there, so I doubt Microsoft will ever be completely successful.
andQuote:
Things have changed over the years.
QT for Basic is a perfect example of how the vb6 style can survive just fine, regardless of platform. So regardless of OS and this dll and that dll, QT will be there as if nothing changed, AND will continue to grow alongside .Net.Quote:
...your fight to save Visual Basic 6 may ultimately be a fight to save Windows as we know it.
Personally, I think that MS has reached their peak in popularity and I think they may actually be on the down-slope...But you don't see it yet because they have only just started their downward curve where the slope of the curve is still near zero. Give them about 15 years to destroy their market share advantage.