I hate to say it, but apparently you believe everything you read.
The statistic you're talking about is misleading because it only takes into account the length of time from the vulnerability being publicly disclosed and the time of the patch. Typically bug details are embargoed for weeks to months before a patch is made public and the vulnerability is publicly reported.
Don't believe me? Go ahead and look at the bugzilla database for when the vulnerabilities were created, not when the security alert was issued.
I'm curious, but can you explain exactly what makes 'integral to the OS' inherantly insecure? Do you even know what that phrase means in regards to IE? Do you know HOW it's "integral"?
It's not running in the kernel. It doesn't run with privileges that are above the current users. In fact, there's nothing about IE's "integration" that Mozilla isn't just as vulnerable to (in effect, anything IE can do, so can Mozilla, because IE just uses userland API's the same as Mozilla does).
Actually, that's not really true. Mono has kept up pretty well with the standard, and as far as I know already has a full C# 2.0 implementation, and is working on C# 3 already.
The deal is, Microsoft has to publish their spects YEARS in advance. C# 2 was first published in 2003 with public working committee drafts. This standard process has allowed Mono to follow the progress and implement the features as well.
C# 3 is likely to be the same thing, by the time Microsoft ships a commercial compiler, Mono will likely be right there with them.
The purpose of "fast tracking" is that there is very little to be gained by two seperate standards bodies doing a full standards process (and in fact, it can be detrimental). If it's been done by one body, then ISO need only review the work and decide on whether it should be accepted or not.
Fast tracking requires a 2/3 majority vote of all ISO members to aprove. So this isn't a "under the radar" kind of thing.
As for the length of time, I don't think that applies to fast tracked standards. It typically applies to ISO developed standards as far as I know.
You might want to look again, especially at the copyright dates. Then compare them to the first open source release of BSD (Networking Release 1, 1989).
You'll note that the copyrights pre-date the NR1 (which had all the copyrights updated on it), by at least 6 years, which means the code is older than the first open source release, which likely means that the code was licensed from Berkeley directly under a non-open source license.
And what happens when you start a project in the "baby" language, and then discover you need "the advanced language" to implement a given feature. Now you have to rewrite you code to the new language, just because your current language isn't powerful enough.
In fact Microsoft is still distributing their incompatable 1.1.4 JVM as part of Windows XP SP1
Umm.. no. They're not. XP SP1 is no longer being distributed by MS (and hasn't for a few years), instead they ship XP SP1a, which doesn't include their JVM.
Further, as part of their settlement with Sun, they had to remove all MS JVM support from a ton of other products as well. See:
You're going to have be more specific. I gave examples of how the IDE no longer interferes with you doing things the way you want to.
The original message was very vague about what specifically he had problems with, and I commented on a few things off the top of my head.
If you mean "How is it more productive", then just watch any of the demos over at Channel 9 for examples. Things like context sensitive intellisense in the HTML editor (ie, it will only show you valid items within a given block), the amazingly cool visualization capable debugger with datatips (yeah, I know that sounds like marketing bullshit, but they really are cool). See http://www.code-magazine.com/Article.aspx?quickid= 0503061 for an example
Honestly, if you just *USE* it for a few hours, you'll be amazed. And you can download it for free too.
You apparently haven't used VS 2005 yet. It really does address nearly all of those issues. Things like tool palettes now work in both code and design modes. The design mode no longer rewrites your code. For ASP projects, you no longer have "project" files, and it no longer compiles to a big dll.
The productivity improvements in 2005 are monstrous, and it's damn good IDE even if you tend to spend all your time in code view now.
Umm.. No. First, LINQ is database independant. It uses a provider model that 3rd party vendors can plug into to generate the code in question. Microsoft provides providers for MS SQL, Jet, and a few others, but there's nothing stopping MySQL or Postgre, or Oracle or anyone else crom providing their own.
Second, Vista won't REQUIRE the hardware you mention, that will simply be the "Optimum". Vista will degrade various features that require more hardware than you have (such as 3D Compositing).
If you've got a 1Ghz PC with 256MB RAM and integrated video, it will still work fine, you just won't see as many advanced featuers.
Actually, VB6 was not anywhere near as deterministic as you think it was.
VB6 was based on the COM model (which is one reason it was so easy to interface with COM). While COM does usually release objects when the reference count reaches 0, it's not required to, and can do so when it makes sense.
VB is basically just as garbage collected as VB.NET is. The only difference is that VB.NET is a little more lackadaisical about finalizing, which is why features like the using keyword in C# are so nice (I wish VB had it).
I realize that a conversion is still a lot of work, but it's nowhere near the work that a rewrite is, though of course the real cost is retesting everything.
There *ARE* lots of business reasons to rewrite as well. There are a ton of productivity enhancements coming down the pipe, and a ton of new windows foundation features you can take advantage of (for example, the Windows Workflow Foundation, which an amazing number of VB/database sytle apps could make very good use of).
No doubt, it's hard to stay on top of technology. That's the inherant cost of it. Even Java deprecates features and makes changes.
The problem here is that VB -> VB.NET was a major jump. But, in my mind, it was a necessary one, and the right choice. I think MS could have made extra effort to improve the conversion process, but that's a different argument.
You might also consider the cost of a commerical migration tool, such as ArtinSoft's http://www.artinsoft.com/
I'm not sure you understand the process. Standards don't update themselves, someone has to do the work, then recommend it.
In this case, the 2.0 changes to C# have already been accepted by the ECMA (as of July) and ratified as an ECMA standard. It has then been forwarded on to ISO for fast tracking (just like the first version was).
C# 3 will also be recommended to the ECMA, who will analyze it, possibly recommend changes (though they will have likely worked with the ECMA to develop the spec in the first place, so that may not happen much). And again, be ratified by the ECMA and sent on to ISO for fast tracking.
Microsoft isn't doing anything wrong here. Lots of standards work this way.
I think the part you misunderstand is that C# is effectively the "Reference language" for the CLR. Therefore, anything the CLR does, C# must do as well, because it's the "reference implementation".
That means, adding features to the CLR for a Scheme.NET or Eiffel.NET necessarily means adding those features to the reference language as well. It's all part of the standardization process.
It would be silly to have the CLR do things that C# didn't support. You wouldn't have a reference implementation for the standards body to accept and approve.
You can make any thing you want so long as you don't use the Java trademark.
Tell that to Microsoft, who lost the ability to use THEIR OWN IMPLEMENTATION of Java, trademarked or not.
While, I could implement my own version of Java from scratch, if you've used *ANY* sun IP in your code, you're under Sun's iron fist, and as far as I know, even gjc uses Sun IP. For example, the class libraries all have the name "java.*" in them, which means it would be a trademark violation just to include any of the java libraries, even if they were entirely open source.
You could rename them, of course, but then you break all the existing code, making it effectively a new language.
This is one advantage to the CLR, while there are some Microsoft.* and Vb.* class libraries, the standardized CLR uses class libraries free of trademarks (aka System.*)
I think you greatly misunderstand the history and licensing of Java.
I think you greatly underestimate the extent to which Sun has burrowed their IP into the entire platform.
Well, just like the more esoteric features of C++, you don't have to use them if you don't want to. If you want to stick to a subset, you're more than welcome to.
BUT, for those people that DO want to use them, they provide powerful features that would require either a lot more work, or couldn't be done at all. Or, the features make the language safer, and less error prone for certain tasks.
Lots of people still write C++ code as "more strongly type C" or "C with classes". They don't use templates, or overloaded operators, or placement operators, or anything else. And that's fine. That doesn't mean those features are useless.
And, C# *IS* an ISO standard. Version 1 was ratified by the ECMA and was then "fast tracked" and accepted by ISO. Version 2 has (as of July) been accepted by the ECMA and is now on the fast track to ISO. Version 3, which won't even have an impelmentation by Microsoft or anyone else for at least a year or more to come will likely be standardized as well.
Standardization doesn't mean the lanugage becomes static and never changes. It means that 3rd party vendors have a specification to follow for interoperability, and that you can rely on 3 vendors implementing the same standard to be relatively interoperable.
Jezus. Microsoft has been telling the world that VB was going away since 1999. You had plenty of warning. VB.NET has been out since 2002. Conversion from VB to VB.NET is *NOT* that big of a task, no matter how large your project is. 80+% will convert without problems, 10-15% will convert with minor problems. 5% may need to be rewritten, but that's the price of progress. You will gain MUCH more than you lose by converting.
Bite the bullet. hire a temporary contractor to help with the job for a few weeks. The cost of NOT converting will be FAR more than the cost of converting, unless your app truly is dead and won't be maintained.
However, it may be better to convert to C# if you're worried about this ever happening again. It's an ISO standard langauge, and there are multiple implementors. If Microsoft decides to abandon it, there will certainly be people to step up to the plate and fill their shoes.
Plus, there are some very nice VB to C# converter programs to make the conversion job easier, though they won't help you with learning a new language (that you'll have to do on your own).
Frankly, it's suicide to stay with VB6. Even if you move to Java, it will be better than staying with VB6.
Actually, Java is effectively sole source. You are confusing multi-platform with sole source.
Sun makes the only Java platform on many OS's, and they control it's destiny and licenses. So, even if you have your own implementation, you're limited by what Sun says you can do.
If sun decides to drop Java, you can't just take their source and continue working on it, unless they release it open source.
Well, both languages are more or less functionally equivelent. The C# is basically modeled after the CLR (or is it vice versa? I don't know), and most closely reflects the core CLR architecture. This makes it *slightly* more efficient than VB in some cases.
My experience is that VB is a little easier to learn, and provides some nice syntactical sugar (such as the Left/Mid/Right stuff) that C# doesn't (the functionality is still there, it's just not a nice keyword). C# has some nice things like the using keyword to help with resource management.
I find that people that come from VB are most comfortable with VB.NET, and those coming from C++ and Java are most comfortable with C#. The years gone stigma of VB is still there for these people, and many of them can't bring themselves to give VB.NET much respect (even though it's a fully first class language now).
Another thing to keep in mind is availability of talent. There are more VB programmers out there than C++ and Java programmers combined. If your code needs to be maintainable by any monkey they hire down the road, VB may be a better choice.
C# is more "efficient" to program in. It uses fewer words, is more compact, and doesn't waste the programmers time. VB.NET is easier to read, helpful, hand holding (not really, but to some degree), and warm and fuzzy.
It's all about style, attitude, experience, and familiarity.
Re:How can you vouche for the security of this?
on
Flash, Meet Sparkle
·
· Score: 1
It's true that i'm arguing a US-Centric point, it's because I live in the US, and wasn't aware that you don't.
There is a difference between protesting about things you disagree with, and ignoring the law because you disagree with it, though. The US has a long history of civil disobedience, but typically this is misdemeanor level stuff. If you're willing to sacrifice your rights (many countries, including the US, forfeit many rights as a citizen if you are convicted of a felony) as a form of protest, that's up to you.
I think the part you seem to be missing is that OEM licenses are a tradeoff. You get the license for far less than buying it retail in exchange for certain restrictions, among them being non-transferability to other hardware. If OEM licenses could no longer be enforced, the result would not be everyone having a retail license for the cost of an OEM license, it would result in everyone paying for a retail license.
In other words, you're actually begging to pay more for your license by refusing to honor the OEM license.
So, regardless of whether or not such licenses are legal in your jurisdiction, you're essentially trying to "ruin it for everyone" by removing the incentive for the vendor to sell you a license at a reduced cost. And, considering that an OEM license is less than 1/4 the cost of a retail license, you could buy 3 new PC's with 3 new copies of Windows and still come out ahead. Why would you even WANT to poison the well?
Re:How can you vouche for the security of this?
on
Flash, Meet Sparkle
·
· Score: 1
You seem to totally miss the point. FF 1.5 is in beta NOW, but when it ships, it will still likely be before CSS3 is finalized. Also, Automatic update in FF 1.0x seems to work randomly or not at all, and when it does simply puts a little icon in the upper right corner that means almost nothing to most people (None of whom I've talked to even noticed it was there).
Again, most of these people were told that FF was immune to security problems (or at best, that's the impression they got from whoever turned them on to it). They have no reason to update if they don't see a reason to. If FF 1.5 ships with CSS3 support prior to the standard being finalized (and the standard changes), then you have millions of clueless people out there that don't know that their browser isn't compatible with the standard. Then, these people complain when the web sites they view (that support the final standard) don't look or act right.
That, in turn, creates the situation where web developers have to hack their CSS to deal with incompatible CSS3 support in FF 1.5. Get my point now? And why it's irresponsible to put draft standard features into a final product before the standard is finalized?
And, while I can disable the extensions in MY browser (but wait, they're not 'extensions' at all, are they?), I can't disable them in the browsers of the 2 million people that might be using my web site with FF 1.5.
It's a Collossally stupid idea. The only features that should be going into any final version of a browser are those that are either 100% standard, or those that namespaced to prvent collisions with the final standard.
Re:How can you vouche for the security of this?
on
Flash, Meet Sparkle
·
· Score: 1
Yes, I am trying to have a real discussion here (I know, stupid expectation, but sometimes it works out).
I understand what you're getting at, and I believe I stated quite clearly that the ProCD case didn't mean that ALL Eula's were legal. I was using it as case law to support that Eula's CAN be legal. Of course the terms must also be legal, just like any contract.
I mentioned ProCD because you claimed that Eula's weren't valid because you didn't have the right to examine the terms before purchase. ProCD clearly addresses this issue, and that's all I intended it for, not the various other issues of the case.
Fair Use and First sale are exceptions to the copyright law, and while Fair Use has been pretty coherantly defined by case law, First sale has not, and has been ruled on in several different (often contradictory) ways. You can't rely on First sale to cover anything more than redistribution because different circuits have ruled differently on the "licensed versus purchased" debate.
I never said, nor implied that EULA's trump first sale or fair use, but rather that first sale isn't a clearly defined law when it comes to software, and in fact the very code that defines it is contradicted by other parts of the UCC (namely section 117)
The issue comes down to whether or not licensing is trumped by first sale or not. Some courts have yes, but other courts have ruled otherwise. First sale doctrine does not apply to rented or leased works, and there is some judicial disagreement about whether software licenses are "sales" or "leases".
At least 2 circuit courts have ruled that software is licensed, and thus first sale doesn't apply. That specific issue has not yet been ruled on by a higher court because all the cases have had other extenuating circumstances that have not brought first sale into play, as in the ProCD case.
What ProCD *DOES* say, however, is that Eula's are not unenforceable for a number of reasons. Even though other factors involved may make them unenforceable.
So, the short of it is that shrink wrap licenses are enforceable (though that doesn't mean the terms necessarily are, they must be evalued individually), and that as of yet, no court has ruled that OEM licensing (ie, restricting transfer to other hardware) by itself is unenforceable (though several OEM licenses have been found unenforceable for other reasons).
Maybe it's not enforceable. But as of yet, there is no case law to support that position.
Re:How can you vouche for the security of this?
on
Flash, Meet Sparkle
·
· Score: 1
Why do you keep changing your argument? You said that EULA's weren't valid because the customer didn't have the right to read the terms of the license prior to purchase. ProCD v. Zeidenberg states clearly that this is not true.
Yes, there are other factors involved in ProCD v. Zeidenberg (and indeed, pretty much every license case law), but the decisions do clearly spell out what is and isn't legal, and your arguments so far have been clearly countered by existing case law that says differently. Just because the case involves copyright infringement doesn't mean its decisions about other matters involving the case aren't applicable.
And, again, first purchase doesn't apply to what we're arguing about. First purchase *ONLY* comes into play if you are trying to resell your copy of the software, not if you are trying to transfer it to another computer you own. (apart from the fact that First purchase isn't very strong because it's contradicted by other articles in the UCC)
Further, the license and the sale are two seperate entities, since you can buy something that you aren't legally allowed to use (think of automatic firing pins in assualt weapons and the like).
The license gives you the right to USE the software, persuant to your agreement of the terms within, in addition to how you may resell or transfer it's ownership. If the license doesn't permit you to use it on other hardware, then no matter what your first sale rights may be, you AGREED to the license, and you are bound by it.
That's the part you keep overlooking (deliberately or not, i can't tell). You agreed to the license by using it. You are bound by them. *IF* you had never agreed to the terms, you might be able to argue several other avenues, but that's not the case in this argument. You used the software on one PC, then are trying to transfer it to another to continue using it.
So far you've argued that shrink wrap licenses aren't legal, I've shown how several courts have upheld them. You've argued that the terms don't apply because you can't read them prior to sale, and i've shown how the courst have ruled differently as well. You've argued that first sale doctrine applies, but first sale doctrine has been ruled by different courts in different ways. Some supporting licensed versus sale, and some supporting the other way. There is no legal consensus, and it's a crap shoot.
Simply put, you're on shaky ground to claim that first sale trumps EULA. You might be right, but that depends entirely on what state you live in, and what circuit court you fall under, and there's no guarantee that an even higher court won't hold differently than your local circuit.
You must be a gambling man.
Re:EULAs and Returnability of opened software.
on
Flash, Meet Sparkle
·
· Score: 1
First, we're talking about OEM software and the OEM EULA that comes installed on a PC, not store bought software.
Second, many companies, including MS will allow you to return opened retail software to them within their return period if the store in question will not honor it.
Slashdot Mirror
I hate to say it, but apparently you believe everything you read.
The statistic you're talking about is misleading because it only takes into account the length of time from the vulnerability being publicly disclosed and the time of the patch. Typically bug details are embargoed for weeks to months before a patch is made public and the vulnerability is publicly reported.
Don't believe me? Go ahead and look at the bugzilla database for when the vulnerabilities were created, not when the security alert was issued.
I'm curious, but can you explain exactly what makes 'integral to the OS' inherantly insecure? Do you even know what that phrase means in regards to IE? Do you know HOW it's "integral"?
It's not running in the kernel. It doesn't run with privileges that are above the current users. In fact, there's nothing about IE's "integration" that Mozilla isn't just as vulnerable to (in effect, anything IE can do, so can Mozilla, because IE just uses userland API's the same as Mozilla does).
Actually, that's not really true. Mono has kept up pretty well with the standard, and as far as I know already has a full C# 2.0 implementation, and is working on C# 3 already.
The deal is, Microsoft has to publish their spects YEARS in advance. C# 2 was first published in 2003 with public working committee drafts. This standard process has allowed Mono to follow the progress and implement the features as well.
C# 3 is likely to be the same thing, by the time Microsoft ships a commercial compiler, Mono will likely be right there with them.
The purpose of "fast tracking" is that there is very little to be gained by two seperate standards bodies doing a full standards process (and in fact, it can be detrimental). If it's been done by one body, then ISO need only review the work and decide on whether it should be accepted or not.
Fast tracking requires a 2/3 majority vote of all ISO members to aprove. So this isn't a "under the radar" kind of thing.
As for the length of time, I don't think that applies to fast tracked standards. It typically applies to ISO developed standards as far as I know.
BTW: my OP linked to a download for the C# 3.0 compiler. It works just fine and the IL it generates runs on the 2.0 CLR.
That's true, but I was referring more towards a commercial implementation, not a research one. Sorry for the confusion.
Indeed, but not Open Source BSD. The first open source release of BSD was Networking Release 1, released in 1989 (and had the 1989 copyright on it).
So what does a 1983 copyright tell you?
You might want to look again, especially at the copyright dates. Then compare them to the first open source release of BSD (Networking Release 1, 1989).
You'll note that the copyrights pre-date the NR1 (which had all the copyrights updated on it), by at least 6 years, which means the code is older than the first open source release, which likely means that the code was licensed from Berkeley directly under a non-open source license.
And what happens when you start a project in the "baby" language, and then discover you need "the advanced language" to implement a given feature. Now you have to rewrite you code to the new language, just because your current language isn't powerful enough.
That's silly.
In fact Microsoft is still distributing their incompatable 1.1.4 JVM as part of Windows XP SP1
s p
Umm.. no. They're not. XP SP1 is no longer being distributed by MS (and hasn't for a few years), instead they ship XP SP1a, which doesn't include their JVM.
Further, as part of their settlement with Sun, they had to remove all MS JVM support from a ton of other products as well. See:
http://www.eweek.com/article2/0,1895,1405300,00.a
And, btw, all of those third party products have agreements with Sun, and are using their IP.
You're going to have be more specific. I gave examples of how the IDE no longer interferes with you doing things the way you want to.
= 0503061 for an example
The original message was very vague about what specifically he had problems with, and I commented on a few things off the top of my head.
If you mean "How is it more productive", then just watch any of the demos over at Channel 9 for examples. Things like context sensitive intellisense in the HTML editor (ie, it will only show you valid items within a given block), the amazingly cool visualization capable debugger with datatips (yeah, I know that sounds like marketing bullshit, but they really are cool). See http://www.code-magazine.com/Article.aspx?quickid
Honestly, if you just *USE* it for a few hours, you'll be amazed. And you can download it for free too.
You apparently haven't used VS 2005 yet. It really does address nearly all of those issues. Things like tool palettes now work in both code and design modes. The design mode no longer rewrites your code. For ASP projects, you no longer have "project" files, and it no longer compiles to a big dll.
The productivity improvements in 2005 are monstrous, and it's damn good IDE even if you tend to spend all your time in code view now.
Umm.. No. First, LINQ is database independant. It uses a provider model that 3rd party vendors can plug into to generate the code in question. Microsoft provides providers for MS SQL, Jet, and a few others, but there's nothing stopping MySQL or Postgre, or Oracle or anyone else crom providing their own.
Second, Vista won't REQUIRE the hardware you mention, that will simply be the "Optimum". Vista will degrade various features that require more hardware than you have (such as 3D Compositing).
If you've got a 1Ghz PC with 256MB RAM and integrated video, it will still work fine, you just won't see as many advanced featuers.
Actually, VB6 was not anywhere near as deterministic as you think it was.
r /
VB6 was based on the COM model (which is one reason it was so easy to interface with COM). While COM does usually release objects when the reference count reaches 0, it's not required to, and can do so when it makes sense.
VB is basically just as garbage collected as VB.NET is. The only difference is that VB.NET is a little more lackadaisical about finalizing, which is why features like the using keyword in C# are so nice (I wish VB had it).
I realize that a conversion is still a lot of work, but it's nowhere near the work that a rewrite is, though of course the real cost is retesting everything.
There *ARE* lots of business reasons to rewrite as well. There are a ton of productivity enhancements coming down the pipe, and a ton of new windows foundation features you can take advantage of (for example, the Windows Workflow Foundation, which an amazing number of VB/database sytle apps could make very good use of).
No doubt, it's hard to stay on top of technology. That's the inherant cost of it. Even Java deprecates features and makes changes.
The problem here is that VB -> VB.NET was a major jump. But, in my mind, it was a necessary one, and the right choice. I think MS could have made extra effort to improve the conversion process, but that's a different argument.
You might also consider the cost of a commerical migration tool, such as ArtinSoft's http://www.artinsoft.com/
You might also want to read this article:
http://www.ftponline.com/vsm/2003_06/online/meade
In the end, you can't sit still. Plus ca Change.
I'm not sure you understand the process. Standards don't update themselves, someone has to do the work, then recommend it.
In this case, the 2.0 changes to C# have already been accepted by the ECMA (as of July) and ratified as an ECMA standard. It has then been forwarded on to ISO for fast tracking (just like the first version was).
C# 3 will also be recommended to the ECMA, who will analyze it, possibly recommend changes (though they will have likely worked with the ECMA to develop the spec in the first place, so that may not happen much). And again, be ratified by the ECMA and sent on to ISO for fast tracking.
Microsoft isn't doing anything wrong here. Lots of standards work this way.
I think the part you misunderstand is that C# is effectively the "Reference language" for the CLR. Therefore, anything the CLR does, C# must do as well, because it's the "reference implementation".
That means, adding features to the CLR for a Scheme.NET or Eiffel.NET necessarily means adding those features to the reference language as well. It's all part of the standardization process.
It would be silly to have the CLR do things that C# didn't support. You wouldn't have a reference implementation for the standards body to accept and approve.
You can make any thing you want so long as you don't use the Java trademark.
Tell that to Microsoft, who lost the ability to use THEIR OWN IMPLEMENTATION of Java, trademarked or not.
While, I could implement my own version of Java from scratch, if you've used *ANY* sun IP in your code, you're under Sun's iron fist, and as far as I know, even gjc uses Sun IP. For example, the class libraries all have the name "java.*" in them, which means it would be a trademark violation just to include any of the java libraries, even if they were entirely open source.
You could rename them, of course, but then you break all the existing code, making it effectively a new language.
This is one advantage to the CLR, while there are some Microsoft.* and Vb.* class libraries, the standardized CLR uses class libraries free of trademarks (aka System.*)
I think you greatly misunderstand the history and licensing of Java.
I think you greatly underestimate the extent to which Sun has burrowed their IP into the entire platform.
Well, just like the more esoteric features of C++, you don't have to use them if you don't want to. If you want to stick to a subset, you're more than welcome to.
BUT, for those people that DO want to use them, they provide powerful features that would require either a lot more work, or couldn't be done at all. Or, the features make the language safer, and less error prone for certain tasks.
Lots of people still write C++ code as "more strongly type C" or "C with classes". They don't use templates, or overloaded operators, or placement operators, or anything else. And that's fine. That doesn't mean those features are useless.
And, C# *IS* an ISO standard. Version 1 was ratified by the ECMA and was then "fast tracked" and accepted by ISO. Version 2 has (as of July) been accepted by the ECMA and is now on the fast track to ISO. Version 3, which won't even have an impelmentation by Microsoft or anyone else for at least a year or more to come will likely be standardized as well.
Standardization doesn't mean the lanugage becomes static and never changes. It means that 3rd party vendors have a specification to follow for interoperability, and that you can rely on 3 vendors implementing the same standard to be relatively interoperable.
Jezus. Microsoft has been telling the world that VB was going away since 1999. You had plenty of warning. VB.NET has been out since 2002. Conversion from VB to VB.NET is *NOT* that big of a task, no matter how large your project is. 80+% will convert without problems, 10-15% will convert with minor problems. 5% may need to be rewritten, but that's the price of progress. You will gain MUCH more than you lose by converting.
Bite the bullet. hire a temporary contractor to help with the job for a few weeks. The cost of NOT converting will be FAR more than the cost of converting, unless your app truly is dead and won't be maintained.
However, it may be better to convert to C# if you're worried about this ever happening again. It's an ISO standard langauge, and there are multiple implementors. If Microsoft decides to abandon it, there will certainly be people to step up to the plate and fill their shoes.
Plus, there are some very nice VB to C# converter programs to make the conversion job easier, though they won't help you with learning a new language (that you'll have to do on your own).
Frankly, it's suicide to stay with VB6. Even if you move to Java, it will be better than staying with VB6.
Actually, Java is effectively sole source. You are confusing multi-platform with sole source.
Sun makes the only Java platform on many OS's, and they control it's destiny and licenses. So, even if you have your own implementation, you're limited by what Sun says you can do.
If sun decides to drop Java, you can't just take their source and continue working on it, unless they release it open source.
Well, both languages are more or less functionally equivelent. The C# is basically modeled after the CLR (or is it vice versa? I don't know), and most closely reflects the core CLR architecture. This makes it *slightly* more efficient than VB in some cases.
My experience is that VB is a little easier to learn, and provides some nice syntactical sugar (such as the Left/Mid/Right stuff) that C# doesn't (the functionality is still there, it's just not a nice keyword). C# has some nice things like the using keyword to help with resource management.
I find that people that come from VB are most comfortable with VB.NET, and those coming from C++ and Java are most comfortable with C#. The years gone stigma of VB is still there for these people, and many of them can't bring themselves to give VB.NET much respect (even though it's a fully first class language now).
Another thing to keep in mind is availability of talent. There are more VB programmers out there than C++ and Java programmers combined. If your code needs to be maintainable by any monkey they hire down the road, VB may be a better choice.
C# is more "efficient" to program in. It uses fewer words, is more compact, and doesn't waste the programmers time. VB.NET is easier to read, helpful, hand holding (not really, but to some degree), and warm and fuzzy.
It's all about style, attitude, experience, and familiarity.
It's true that i'm arguing a US-Centric point, it's because I live in the US, and wasn't aware that you don't.
There is a difference between protesting about things you disagree with, and ignoring the law because you disagree with it, though. The US has a long history of civil disobedience, but typically this is misdemeanor level stuff. If you're willing to sacrifice your rights (many countries, including the US, forfeit many rights as a citizen if you are convicted of a felony) as a form of protest, that's up to you.
I think the part you seem to be missing is that OEM licenses are a tradeoff. You get the license for far less than buying it retail in exchange for certain restrictions, among them being non-transferability to other hardware. If OEM licenses could no longer be enforced, the result would not be everyone having a retail license for the cost of an OEM license, it would result in everyone paying for a retail license.
In other words, you're actually begging to pay more for your license by refusing to honor the OEM license.
So, regardless of whether or not such licenses are legal in your jurisdiction, you're essentially trying to "ruin it for everyone" by removing the incentive for the vendor to sell you a license at a reduced cost. And, considering that an OEM license is less than 1/4 the cost of a retail license, you could buy 3 new PC's with 3 new copies of Windows and still come out ahead. Why would you even WANT to poison the well?
You seem to totally miss the point. FF 1.5 is in beta NOW, but when it ships, it will still likely be before CSS3 is finalized. Also, Automatic update in FF 1.0x seems to work randomly or not at all, and when it does simply puts a little icon in the upper right corner that means almost nothing to most people (None of whom I've talked to even noticed it was there).
Again, most of these people were told that FF was immune to security problems (or at best, that's the impression they got from whoever turned them on to it). They have no reason to update if they don't see a reason to. If FF 1.5 ships with CSS3 support prior to the standard being finalized (and the standard changes), then you have millions of clueless people out there that don't know that their browser isn't compatible with the standard. Then, these people complain when the web sites they view (that support the final standard) don't look or act right.
That, in turn, creates the situation where web developers have to hack their CSS to deal with incompatible CSS3 support in FF 1.5. Get my point now? And why it's irresponsible to put draft standard features into a final product before the standard is finalized?
And, while I can disable the extensions in MY browser (but wait, they're not 'extensions' at all, are they?), I can't disable them in the browsers of the 2 million people that might be using my web site with FF 1.5.
It's a Collossally stupid idea. The only features that should be going into any final version of a browser are those that are either 100% standard, or those that namespaced to prvent collisions with the final standard.
Yes, I am trying to have a real discussion here (I know, stupid expectation, but sometimes it works out).
I understand what you're getting at, and I believe I stated quite clearly that the ProCD case didn't mean that ALL Eula's were legal. I was using it as case law to support that Eula's CAN be legal. Of course the terms must also be legal, just like any contract.
I mentioned ProCD because you claimed that Eula's weren't valid because you didn't have the right to examine the terms before purchase. ProCD clearly addresses this issue, and that's all I intended it for, not the various other issues of the case.
Fair Use and First sale are exceptions to the copyright law, and while Fair Use has been pretty coherantly defined by case law, First sale has not, and has been ruled on in several different (often contradictory) ways. You can't rely on First sale to cover anything more than redistribution because different circuits have ruled differently on the "licensed versus purchased" debate.
I never said, nor implied that EULA's trump first sale or fair use, but rather that first sale isn't a clearly defined law when it comes to software, and in fact the very code that defines it is contradicted by other parts of the UCC (namely section 117)
The issue comes down to whether or not licensing is trumped by first sale or not. Some courts have yes, but other courts have ruled otherwise. First sale doctrine does not apply to rented or leased works, and there is some judicial disagreement about whether software licenses are "sales" or "leases".
At least 2 circuit courts have ruled that software is licensed, and thus first sale doesn't apply. That specific issue has not yet been ruled on by a higher court because all the cases have had other extenuating circumstances that have not brought first sale into play, as in the ProCD case.
What ProCD *DOES* say, however, is that Eula's are not unenforceable for a number of reasons. Even though other factors involved may make them unenforceable.
So, the short of it is that shrink wrap licenses are enforceable (though that doesn't mean the terms necessarily are, they must be evalued individually), and that as of yet, no court has ruled that OEM licensing (ie, restricting transfer to other hardware) by itself is unenforceable (though several OEM licenses have been found unenforceable for other reasons).
Maybe it's not enforceable. But as of yet, there is no case law to support that position.
Why do you keep changing your argument? You said that EULA's weren't valid because the customer didn't have the right to read the terms of the license prior to purchase. ProCD v. Zeidenberg states clearly that this is not true.
Yes, there are other factors involved in ProCD v. Zeidenberg (and indeed, pretty much every license case law), but the decisions do clearly spell out what is and isn't legal, and your arguments so far have been clearly countered by existing case law that says differently. Just because the case involves copyright infringement doesn't mean its decisions about other matters involving the case aren't applicable.
And, again, first purchase doesn't apply to what we're arguing about. First purchase *ONLY* comes into play if you are trying to resell your copy of the software, not if you are trying to transfer it to another computer you own. (apart from the fact that First purchase isn't very strong because it's contradicted by other articles in the UCC)
Further, the license and the sale are two seperate entities, since you can buy something that you aren't legally allowed to use (think of automatic firing pins in assualt weapons and the like).
The license gives you the right to USE the software, persuant to your agreement of the terms within, in addition to how you may resell or transfer it's ownership. If the license doesn't permit you to use it on other hardware, then no matter what your first sale rights may be, you AGREED to the license, and you are bound by it.
That's the part you keep overlooking (deliberately or not, i can't tell). You agreed to the license by using it. You are bound by them. *IF* you had never agreed to the terms, you might be able to argue several other avenues, but that's not the case in this argument. You used the software on one PC, then are trying to transfer it to another to continue using it.
So far you've argued that shrink wrap licenses aren't legal, I've shown how several courts have upheld them. You've argued that the terms don't apply because you can't read them prior to sale, and i've shown how the courst have ruled differently as well. You've argued that first sale doctrine applies, but first sale doctrine has been ruled by different courts in different ways. Some supporting licensed versus sale, and some supporting the other way. There is no legal consensus, and it's a crap shoot.
Simply put, you're on shaky ground to claim that first sale trumps EULA. You might be right, but that depends entirely on what state you live in, and what circuit court you fall under, and there's no guarantee that an even higher court won't hold differently than your local circuit.
You must be a gambling man.
First, we're talking about OEM software and the OEM EULA that comes installed on a PC, not store bought software.
Second, many companies, including MS will allow you to return opened retail software to them within their return period if the store in question will not honor it.
http://www.microsoft.com/info/nareturns.htm