If the US was not run by corrupt scumbags MS... Wow. Let's assume for a second that I'm not going to respond to your anti-US sentiments, nor your claims that I'm being paid by MS to spread FUD -- or even that it is FUD.
I have no problem with the EU Commission fining MS for failing to comply; that is their legal responsibility. Without looking at the documentation, which I'm sure you haven't either, I can't say one way or the other whether the documentation is sufficient or insufficient. Neither can you. MS has published a set of documentation, which their representatives say is complete -- with the caveat that it would take a great deal of experience to implement based off of it -- while the EU Commission's representatives say is insufficient. They're probably both right. It doesn't matter.
Microsoft is in the business of making money. It's hurting their stock price to have this still hanging over their heads. It's hurting their productivity to have spend money to pay people to document all these protocols. Whether it's five people over 10 months or one person over fifty months probably means very little -- aside from the fact that Microsoft, trying to make money, would rather have this over and done with.
I'll reiterate my original point: an 8 day deadline is absurd. I can't imagine anyway that MS could complete the task in that time. If the Commissioner just wants to fine them, okay. However, providing an unreachable goal helps no one. Whether or not MS inflated the time they thought it would take to get the documentation up to snuff is almost insignificant. I sincerely doubt MS has the documentation being requested already written -- the 3 million euro daily fine would be a great reason to get it out there if they did.
If the Commission honestly wanted the documentation done in a faster manner, the proper response would be to disagree on the date of completion, and ask MS to complete it faster. I, unfortunately, could not find when MS announced it would be done next July, but even if it was six months ago, telling Microsoft NOW that they want the information in 8 days is simply absurd. Based on the complaints of Neil Barrett, the most recent version of the documentation is still massively insufficient. If MS had scheduled the work to be done by next July, for whatever reason -- real need or delaying tactic -- shifting the schedule may have been a possibility; say by January, or even maybe December. Some deadline that was actually attainable is a very different creature than an arbitrary 8 day deadline that is certainly unreachable.
SO: an 8 day deadline that is impossible to reach is absurd. Microsoft is too smart of a company, no matter how evil and monopolistic, to want to carry this out any longer than necessary; it's too expensive, and Microsoft is in the business of making money. The EU Commission is not evincing a desire here for the documentation to be completed; their demanding their money.
As far as I can recall, MS did endeavor to document a bunch of their interfaces. The response was that it was insufficient. MS tried to find out how it was insufficient, and was told that it was MS's responsibility to figure that out.
MS does produce technical documentation for a whole slew of its products. Look at the API-level documentation that is on http://msdn.microsoft.com/library/. It's just not the most obvious documentation. Is it usable? For the most part. Does it cover every single idiosyncracy? No.
MS did make a good faith effort previously, and the only response they got was a thumbs down with no guidance on what to do differently. I don't really think such a risky prospect as actually having SECRET APIs would have been permitted by the company's legal department after the antitrust mess. Rather, I just don't think the documentation is that good. An uncommented header file would be documentation; it just wouldn't meet the needs of the EU regulators.
Providing MS with an EIGHT DAY deadline is just absurd. Even if everyone qualified as a technical writer was thrown at the problem, there still needs to an information flow, probably from some people who are on vacation for a month now that Vista has shipped. There's only so much that can be written at a time, and only so much that can be documented in any period of time. Add in the time for editing, and legal review, and to verify completion... eight days? It's just an excuse to charge Microsoft with more money. Even a month would be more of an indication that they expected Microsoft to be able to comply. Given that up until this point Microsoft was working at having it done next July, the scheduling cannot be compressed by 8 months.
Had the commissioner provided a more reasonable deadline, Microsoft could be cast into a harsh light by this ruling, as the request already existed, and the Commissioner just disagreed with the amount of time they were claiming to need. Microsoft has tried to provide documentation before, and was told it was insufficient -- doubtless this time they wanted to avoid this charge.
Anyone who has ever written technical API documentation will probably be inclined to agree that trying to compress even a three month timeline into 8 days will be well nigh impossible. The commissioner's demand is effectively a demand for money, not for documentation; I can't see any way ANY company, no matter their motives, would be able to meet the deadline.
Regionalized dialects that for the present at least share words will be completely lost, and communication will fall apart as the written English language devolves into localized written dialects that are effectively indecipherable to anyone who doesn't "hear" with that intonation pattern.
It's like an Evil Genius plan for world domination -- "Well, I'm heavily invested in China, and the effectively English-dominated markets really have too much sway. I know, I'll make it so that no written communication can take place between different area of the United States! All of a sudden, Rhode Island will be a separate market than Connecticut! London will be separate from Surrey! Wales will be a complete write-off!"
First company I worked for produced a series of ActiveX controls written in VB, shipped and sold with the source. It supported 3 full time devs, 2 support/sales people, one HR person, and an intern (me).
They vanished after they tried to compete in the.COM world and got absorbed by ZDNet, but their components are still for sale on Programmer's Paradise, last I checked.
I got an internship with Microsoft after spending most of my interview defending VB as a language choice -- this was pre-C#/.Net.
Some "facts" from above annoyed me, so I'm responding: 1) VB is only interpreted. VB6 can be compiled to P-code, and will run interpreted. However, by default it's compiled to executable code. The only "penalty" for using VB6 when it comes to speed is really the memory footprint of the VB6 runtime DLLs.
2) VB6 is not suited to large products. I'm aware of at least one company that based an entire website off VB6 apps. I'm sure they would be ASP.Net now, but at the time (VB4), that wasn't yet an option. So the web engine was actually a series of VB apps that were invoked to process the web request as ReadLine and Print commands.
3) VB6 -> VB.Net (The person in question did only propose this as an idea.) I would argue against this. There are certain elements only possible in VB6, and the switch to managed code is unfortunately not as seamless as MS would have liked. Hence the uproar when MS EOL'd VB6. VB.Net is great for managed code, and even has some features that C# lacks. I personally prefer C#, but I come from enough of a mixed background that I can handle what VB.Net code comes my way. While rewriting the application in VB.Net may be the proper thing to do, it certainly does not provide much in the line of benefits above and beyond rewriting the application in C#.
VB does have certain benefits to use. As a RAD environment, it is (or was:) ) without peer. As to the inavailability of new APIs: a) Pretty much anything in COM can be used -- although some trickery may be necessary for custom structures. b) Anything done in a "straight" Win32 API can be directly invoked -- akin to P/Invoke in the managed world. For database work, VB was unparalleled. The ease of data connections has now come in some degree to the managed code word, but in unmanaged code only VBA comes close. C++ just can't compete. VB is no longer entirely late-bound -- if a dual interface is available, and the code is written to expect that type rather than just Object, VB6 operates as an early bound client. VB6 is also capable of being used in a late-bound fashion with almost identical code to the early bound scenarios.
While I can't know why your manager wants to use VB, it's not such a terrible order.
If your manager only wants to preserve the look-and-feel of previous versions, the previous proposal of writing COM components in C++ for the high-performance portions and using VB for the front-end is certainly a very viable option, and one that I've used previously. In this manner, the weaknesses of VB6 can be circumvented while still leveraging existing components and possibly even code. At the far end of the advancement spectrum, even managed components can be exposed to COM clients -- Adam Nathan's wonderful ".Net and COM: The Complete Interoperability Guide" is probably the most complete book on the subject. If appropriate, you can write new code in C#, and expose it back to VB6.
If your manager wants to preserve the code base in VB6, you might want to determine why he wants to rewrite the application -- it's possible a better solution is just to rewrite portions of the code, depending on the scope of the changes he desires. The right tool for the right job -- VB is the right tool for some jobs, but shouldn't be presupposed to be the right tool for every job.
That being said, there are few things you can't do in VB -- although some of the solutions are probably not as simple as they may be in other languages. Keep in mind, however, that it is even possible to get assembly code linked into a VB6 application, if necessary. It just takes a little bit of creativity.
Slashdot Mirror
If the US was not run by corrupt scumbags MS...
Wow. Let's assume for a second that I'm not going to respond to your anti-US sentiments, nor your claims that I'm being paid by MS to spread FUD -- or even that it is FUD.
I have no problem with the EU Commission fining MS for failing to comply; that is their legal responsibility. Without looking at the documentation, which I'm sure you haven't either, I can't say one way or the other whether the documentation is sufficient or insufficient. Neither can you. MS has published a set of documentation, which their representatives say is complete -- with the caveat that it would take a great deal of experience to implement based off of it -- while the EU Commission's representatives say is insufficient. They're probably both right. It doesn't matter.
Microsoft is in the business of making money. It's hurting their stock price to have this still hanging over their heads. It's hurting their productivity to have spend money to pay people to document all these protocols. Whether it's five people over 10 months or one person over fifty months probably means very little -- aside from the fact that Microsoft, trying to make money, would rather have this over and done with.
I'll reiterate my original point: an 8 day deadline is absurd. I can't imagine anyway that MS could complete the task in that time. If the Commissioner just wants to fine them, okay. However, providing an unreachable goal helps no one. Whether or not MS inflated the time they thought it would take to get the documentation up to snuff is almost insignificant. I sincerely doubt MS has the documentation being requested already written -- the 3 million euro daily fine would be a great reason to get it out there if they did.
If the Commission honestly wanted the documentation done in a faster manner, the proper response would be to disagree on the date of completion, and ask MS to complete it faster. I, unfortunately, could not find when MS announced it would be done next July, but even if it was six months ago, telling Microsoft NOW that they want the information in 8 days is simply absurd. Based on the complaints of Neil Barrett, the most recent version of the documentation is still massively insufficient. If MS had scheduled the work to be done by next July, for whatever reason -- real need or delaying tactic -- shifting the schedule may have been a possibility; say by January, or even maybe December. Some deadline that was actually attainable is a very different creature than an arbitrary 8 day deadline that is certainly unreachable.
SO: an 8 day deadline that is impossible to reach is absurd. Microsoft is too smart of a company, no matter how evil and monopolistic, to want to carry this out any longer than necessary; it's too expensive, and Microsoft is in the business of making money. The EU Commission is not evincing a desire here for the documentation to be completed; their demanding their money.
As far as I can recall, MS did endeavor to document a bunch of their interfaces. The response was that it was insufficient. MS tried to find out how it was insufficient, and was told that it was MS's responsibility to figure that out.
MS does produce technical documentation for a whole slew of its products. Look at the API-level documentation that is on http://msdn.microsoft.com/library/. It's just not the most obvious documentation. Is it usable? For the most part. Does it cover every single idiosyncracy? No.
MS did make a good faith effort previously, and the only response they got was a thumbs down with no guidance on what to do differently. I don't really think such a risky prospect as actually having SECRET APIs would have been permitted by the company's legal department after the antitrust mess. Rather, I just don't think the documentation is that good. An uncommented header file would be documentation; it just wouldn't meet the needs of the EU regulators.
Providing MS with an EIGHT DAY deadline is just absurd. Even if everyone qualified as a technical writer was thrown at the problem, there still needs to an information flow, probably from some people who are on vacation for a month now that Vista has shipped. There's only so much that can be written at a time, and only so much that can be documented in any period of time. Add in the time for editing, and legal review, and to verify completion... eight days? It's just an excuse to charge Microsoft with more money. Even a month would be more of an indication that they expected Microsoft to be able to comply. Given that up until this point Microsoft was working at having it done next July, the scheduling cannot be compressed by 8 months.
Had the commissioner provided a more reasonable deadline, Microsoft could be cast into a harsh light by this ruling, as the request already existed, and the Commissioner just disagreed with the amount of time they were claiming to need. Microsoft has tried to provide documentation before, and was told it was insufficient -- doubtless this time they wanted to avoid this charge.
Anyone who has ever written technical API documentation will probably be inclined to agree that trying to compress even a three month timeline into 8 days will be well nigh impossible. The commissioner's demand is effectively a demand for money, not for documentation; I can't see any way ANY company, no matter their motives, would be able to meet the deadline.
U se tometo, I se tomato.
Regionalized dialects that for the present at least share words will be completely lost, and communication will fall apart as the written English language devolves into localized written dialects that are effectively indecipherable to anyone who doesn't "hear" with that intonation pattern.
It's like an Evil Genius plan for world domination -- "Well, I'm heavily invested in China, and the effectively English-dominated markets really have too much sway. I know, I'll make it so that no written communication can take place between different area of the United States! All of a sudden, Rhode Island will be a separate market than Connecticut! London will be separate from Surrey! Wales will be a complete write-off!"
First company I worked for produced a series of ActiveX controls written in VB, shipped and sold with the source. It supported 3 full time devs, 2 support/sales people, one HR person, and an intern (me).
.COM world and got absorbed by ZDNet, but their components are still for sale on Programmer's Paradise, last I checked.
:) ) without peer. As to the inavailability of new APIs: a) Pretty much anything in COM can be used -- although some trickery may be necessary for custom structures. b) Anything done in a "straight" Win32 API can be directly invoked -- akin to P/Invoke in the managed world. For database work, VB was unparalleled. The ease of data connections has now come in some degree to the managed code word, but in unmanaged code only VBA comes close. C++ just can't compete. VB is no longer entirely late-bound -- if a dual interface is available, and the code is written to expect that type rather than just Object, VB6 operates as an early bound client. VB6 is also capable of being used in a late-bound fashion with almost identical code to the early bound scenarios.
They vanished after they tried to compete in the
I got an internship with Microsoft after spending most of my interview defending VB as a language choice -- this was pre-C#/.Net.
Some "facts" from above annoyed me, so I'm responding:
1) VB is only interpreted.
VB6 can be compiled to P-code, and will run interpreted. However, by default it's compiled to executable code. The only "penalty" for using VB6 when it comes to speed is really the memory footprint of the VB6 runtime DLLs.
2) VB6 is not suited to large products.
I'm aware of at least one company that based an entire website off VB6 apps. I'm sure they would be ASP.Net now, but at the time (VB4), that wasn't yet an option. So the web engine was actually a series of VB apps that were invoked to process the web request as ReadLine and Print commands.
3) VB6 -> VB.Net
(The person in question did only propose this as an idea.)
I would argue against this. There are certain elements only possible in VB6, and the switch to managed code is unfortunately not as seamless as MS would have liked. Hence the uproar when MS EOL'd VB6. VB.Net is great for managed code, and even has some features that C# lacks. I personally prefer C#, but I come from enough of a mixed background that I can handle what VB.Net code comes my way. While rewriting the application in VB.Net may be the proper thing to do, it certainly does not provide much in the line of benefits above and beyond rewriting the application in C#.
VB does have certain benefits to use. As a RAD environment, it is (or was
While I can't know why your manager wants to use VB, it's not such a terrible order.
If your manager only wants to preserve the look-and-feel of previous versions, the previous proposal of writing COM components in C++ for the high-performance portions and using VB for the front-end is certainly a very viable option, and one that I've used previously. In this manner, the weaknesses of VB6 can be circumvented while still leveraging existing components and possibly even code. At the far end of the advancement spectrum, even managed components can be exposed to COM clients -- Adam Nathan's wonderful ".Net and COM: The Complete Interoperability Guide" is probably the most complete book on the subject. If appropriate, you can write new code in C#, and expose it back to VB6.
If your manager wants to preserve the code base in VB6, you might want to determine why he wants to rewrite the application -- it's possible a better solution is just to rewrite portions of the code, depending on the scope of the changes he desires. The right tool for the right job -- VB is the right tool for some jobs, but shouldn't be presupposed to be the right tool for every job.
That being said, there are few things you can't do in VB -- although some of the solutions are probably not as simple as they may be in other languages. Keep in mind, however, that it is even possible to get assembly code linked into a VB6 application, if necessary. It just takes a little bit of creativity.