The research work from ILX was folded into.NET 2.0 and is part of ECMA 4th edition.
All of the instructions that you listed are deprecated, they never really made it into.NET, their much improved, polished and battle field tested versions did. And they are the foundation for C#'s generics support and Don Syme's F# compiler, both which run just fine in Mono today.
The current Silverlight 3 preview release supports in addition to the proprietary codecs a pluggable framework for developers that wish to do so to use their own codecs.
As part of the Moonlight effort we now have implemented Vorbis, Theora and ADPCM and have a partial implementation of Dirac almost ready to use.
Our codecs work in both Silverlight 3 and our open source Moonlight implementation.
This means that the specifications can now be used to implement third party implementation and can be used by open source efforts to recreate Flash.
In the Silverlight world that was already possible as Microsoft publishes pretty much all of the specs necessary to implement Silverlight.
Both the Flash plugin from Adobe and the Silverlight plugin from Microsoft are proprietary products. Gnash, Sfwdec and Moonlight are open source implementations of these technology.
Luckily the code that you produce with Visual Studio will run on Mono (no recompilations necessary) including code that uses ASP.NET MVC. And with the new support for ASP.NET precompiled sites in Mono (available in Mono 2.4) you do not even need to copy the source code to your target server.
Click "Publish" in visual studio, enter the location for your shared directory, and you have a fully working ASP.NET MVC app running on Linux, without leaving Windows.
We are working on various integration points for Visual Studio that will give developers even more: debugging from Visual Studio remote applications deployed on Linux systems and producing packages ready-for-distribution on Linux.
Not only does it run, but you can now install a MonoDevelop plugin that will provide all the tooling to get the Linux developer experience to match the Visual Studio experience for MVC development.
Silverlight supports Firefox as well as it supports IE on both Windows and MacOS.
I do not remember the last time I even used IE on Windows to browse the web, and there have been *no* sites that use Silverlight that fail under firefox (we try a lot of them when looking for the "next sample to get working on Moonlight" from http://silverlight.net/Showcase).
If what you were implying though was that Moonlight 2.0 was not ready to run Silverlight 2.0 content, you are right. Moonlight, the open source version of Silverlight is not yet ready to render all of the 2.0 content, but it is very close to it.
Perhaps the Portugal government would like to fund the accelerated development of Moonlight by hiring a few developers to assist the project. That seems like a win-win for everyone involved. Faster Moonlight 2.0 and 3.0 and the warm cozy feeling that they made the world a better place.
Moonlight only exists because MS have disclosed most of the implementation details to them, it still lags a long way behind the MS implementation and isn't 100% compatible anyway.
Microsoft has since helped us by providing licensed codecs that can be used by Linux users; Providing us with Silverlight specs for a full open source impleentation (Although 100% of it is available on the web at msdn.microsoft.com) and they provided us with test suites to ensure that Moonlight passes every single Silverlight test suite that Microsoft uses internally.
No two implementations will be 100% compatible. In fact even fixing a bug means that version a and version a.0.0.0.1 with the bug fixed are not "100% compatible", so there is not much point in arguing about 100% compatibility in the first case, it is easy to prove that this will never be the case. But in that regard, no piece of software will ever be (not the kernel, not the browsers, not anything that ever gets bug fixed as a platform).
But we can get very close to the indented behavior as articulated in the test suites "This is what it is supposed to do as far as -we- humans could guarantee". There will certainly be bugs, but we do not have a problem fixing those, and the Microsoft engineers have been very helpful in answering any questions we might have.
It is worth pointing out that the real problem is not really the democrats or the republicans but with the system that has allowed anyone with deep enough pockets to make government do whatever they want.
The NAFTA agreement was not really aimed at helping any of the people in the three participating countries, NAFTA was always designed to help the big corporations reduce their cost of operations. At the same time, NAFTA contained enough provisions that it undid a number of constitutional guarantees and local laws (at least for Mexico it did) and new trade courts ended up having more power than national courts for any trade dispute.
(c) Repositories like Packman have RPMs that you can install for various distributions that you can install today.
We will be using Microsoft's Media Pack for Linux, which is a licensed version of the media codecs, binary drivers provided by Microsoft. This has the advantage that the media companies that own the patents on codecs have been paid for (MPEG-LA consortium and others).
For those of you that live in a country where software/machine patents are not enforced (media patents are enforced in Europe, contrary to popular lore) or those that just want to stick it to the man, you can build Moonlight with the open source FFMPEG media codecs.
Support for Silverlight 2.0 will ship in preview form in December.
The Iron* family of languages are re-implementations from scratch of a language to run on top of.NET. This approach requires a large time investment to get it working as reimplementing a language and then tuning it to run fast is not a weekend hack.
There is another option, to build bridges from a language to.NET. This is possible because.NET can be used as a library, Perl can host.NET and then create objects and send messages to objects living in the.NET world.
For a language in continuous evolution like Perl, following the Iron* route is more difficult, and the second approach might be better.
I believe there used to be a set of.NET bindings for Perl.
Apart from Migue De Icaza. He'd probably love it if Gnome were to be rewritten in Mono.
I am actually not a fan of rewriting software that works. Rewriting is not a decision that must be taken lightly, you introduce regressions, you might drop features, a lot of knowledge embedded in the small details is lost and so on.
But there are certain cases where rewriting is worth doing. I would like to see a few applications rewritten. I do not really want to "rewrite" the panel, but instead come up with new interaction metaphors for the main application launcher. Gnome-Do for example (already written in Mono) is a great tool, but it is a tool for power-users, not a tool for most people.
I would like to see new research, and new ideas for new panels rewritten, and I do not particularly care about what language or platform is used, as long as it produces some nice new ideas, and new metaphors. Gimme is such an attempt by Alex Graveley, written in Python.
I believe that the engine in Moonlight is worth reusing for many new kinds of applications, and it opens the doors for some new creative UIs. And you get to choose if you want to use it or not. If it offends your sensibilities that its written with Mono and C#, then do not use it. It really is that simple, nobody is forcing anyone to use the software I work on. If your religion prohibits prevents you from using software based on Mono, that is fine, nobody is asking you to change your religion.
That is the entire binding: you do not need to have any C++ glue compiled, compile the above and run, and it will call your glDrawBuffer method.
If you are happy with Java, by all means, continue using Java. I was merely explaining why Microsoft had to create.NET (they were bared from using it by a judge).
The only reasons.Net exists are because Microsoft needed an up-to-date language for developers who use Visual Studio, because Java was old and someone needed to give it a clean start, because Java takes a slightly different approach to C++ in some places (so C# can get migrating C++ developers) and because they wanted a real "write lots of languages to a single base and port anywhere" language.
Actually, the reason.NET exists is because Microsoft was prohibited after the Sun/MS lawsuit in 1997 from making changes that they needed to Java.
The changes that Microsoft did to Java included J/Direct and delegates.
Although Java does have a mechanism for calling into native APIs using JNI, it is cumbersome to use. JNI is a technology that requires developers to write a chunk of code in C++ and a chunk in Java to bind the C++ code. Microsoft's alternative, J/Direct allows all the code to be written in the native language. It now exists in.NET as P/Invoke, and it makes calling native APIs easy, and does not require any native code to go with it (this is the reason that using the SWT library for Java requires you to ship architecture-specific glue code).
Some Java developers did notice that the lack of something like J/Direct was a pain, and eventually came up with a system built on top of JNI that does what J/Direct used to do, the Java Native Access APIs.
The other bit were delegates. Delegates are merely the object oriented version of function pointers, but in addition to capturing the address of a function, they also capture the instance that is associated with the object. At the time Sun published a paper describing why they did not like delegates (http://java.sun.com/docs/white/delegates.html). It is an interesting read considering that pretty much everything on their case against delegates turned out to be wrong. Java would me a much better language and a simpler language to develop for had they allowed delegates to go into it.
The 1997 Java lawsuit prevented them from using it, but that does not mean that Java did not add a lot of value and was not a great idea to begin with. So Microsoft had to write their own, from scratch. In the process they would add the features that they needed (and in Mono, we use those extensively) and with the hindsight of knowing what was good and bad about Java, they could build a better Java, and that is what they did.
Although you can handle stuff to ISO, that does not mean there is a staff that can just work on it, which is why ECMA has approached ISO to work out a way in which ECMA can continue to contribute to the effort.
So, ODF was adopted as an ISO standard about a year ago, and since then there has already been a new version of ODF (1.1) released by OASIS, and they are supposedly close on version 1.2. I believe 1.2 is supposed to be significant as they've promised it will include a formula definition for spreadsheets (although the working group hasn't seen much activity lately if you look at the mailing list archives: http://lists.oasis-open.org/archives/office-formula/). So, the maintenance of ODF right now is being handled solely by OASIS, and I'm not sure what their plans are for bringing new drafts to the ISO.
Now, one of the Chairs of the ODF committee (IBM and Sun are now co-chairs of the ODF committee) has a blog post saying that Microsoft is somehow pulling a "bait and switch" because Ecma has proposed to ISO that a joint maintenance agreement be set up once DIS 29500 is approved. We're still months away from approval, but TC45 has already reached out and tried to start a discussion around maintenance.
So it's been a year since Rob's committee had its ISO approval and has since then maintained sole control; and TC45's DIS 29500 still has a few months before approval and they are already trying to establish a maintenance agreement. And this is now called a "bait and switch"?
Some other folks at 4 or 5 already have commented on the fact that this is not a C# bug or a.NET bug, but a programmer mistakes, so I will not elaborate.
But the article linked to was authored by "RedGate Software" for the Code Project, so it is basically an advertisement for their product. Their product did help the team fix their bug, so maybe that is good.
So what happened is that probably Red Gate wanted to score some PR points over at the Code Project and they digged up a story from their existing customers, decided to sponsor the guys in exchange for a few quotes that they could put on the article to promote their product.
It would probably not gone too far, except the guy that submitted the story thought he had found the smoking gun against C#.
It is not just an integrity check; Had it been an integrity check, it would have merely used the SHA1 checksum over its contents. Instead it initializes the SHA1 state with a key, and then computes SHA1.
Miguel says crap like, "We never made a promise to avoid patents.
BULLSHIT.
That is not what I said. What I said was quite different, but selectively quoting will remove all the context and of course you will come to the wrong conclusions.
You might have posted this on my blog a minute ago, I replied to you there, the post "Talk to your lawyers".
Well, sort of. For instance, any changes made in JTC1/SC34 aren't necessarily covered.
More to the point, only the features required to implement the spec are covered -- and the spec only requires syntax. If you actually implement any of the semantics, you're exposed.
Well, I can see why, because you can dump in the spec something that you want access to (Sun did the same with Oasis). Imagine that you standardize Windows Media inside the JTC1/SC34, and then claim "gotcha!".
As for the other stuff, I agree it is not nice of them, but am not sure how you could twist their arm to go beyond that.
Anyways, my fellow freedom fighters as a "Colbert Nation Hero", I have a duty to fulfill tonight by watching the Colbert Report and I must recuse myself for the night.
I can explain the date situation to you if you want. It is a bit complicated and most people have no idea of why this is decision is important.
The issue has to do with the way spreadsheets have historically represented dates. They do not represent dates in a special format, but instead as a floating point which can be interpreted by a special format. So "N.M" becomes day N hour M (where M is some fraction of the day, I cant remember now exactly the mapping).
The problem is that people do date computations and math computations based on the floating point values in the cells (the way you find the difference between two dates is very simple: substract the floating point numbers).
So cells would contain values like "10312" and an external format that says "render the value as a date with this format". Formats are combined with a region-based mechanism which I wont go into.
Now if you have ever debugged spreadsheets or worked with finance people that use spreadsheets extensively you will know that these people did not read "Design Patterns" and Knuth before writing their stuff. They are not exactly PhDs in computer science.
The date mistake comes from Lotus 1-2-3 (and possibly earlier, but at least the problem was present here) and has been with us ever since. Now, the reality is that there is a gap of four years (or something like that, again, I do not remember the details) in 1900 where the values are incorrect because of this mistake in Lotus 1-2-3. The problem is that all dates have been stored as numbers. So you certainly could decide to "fix" the problem to be correct, but then you would have to upgrade *and* debug all spreadsheets out there that do date computations. Now most date computations might be fine (because most people would do date-to-date computations) but the cases where people mixed date computations with *other* data would be affected. How badly? Well, there is no easy way of telling.
Now, if you have debugged a spreadsheet (I have, I debugged a lot of spreadsheets in my Gnumeric days) nasty spreadsheets are not easy to debug. They are fairly complicated beasts and am not sure that *anyone* that has existing models would have to debug these problems (the amount of people using Excel as a financial planning tool are way larger than you can imagine).
Now, you might say "ODF deals with this". It does, and it does so on an interesting way, a way that requires you to enter the data again. It basically keeps track of the stored value *and* the value actually entered by the user. This works as long as the user enters the data again, but if the user did not enter the data and you just imported, you are in trouble. I tried this some time ago and importing an XLS file into OpenOffice did in fact break the date computation during import and later export.
Now, if I had millions of users using my software, I would not want to impose on them a new semantic on the numbers on the spreadsheets. Imagine the consequences of fixing something like that say in a CPU: changing the semantics of something that even if broken was known and worked around already (yes, you could say, "fix the software", but that is easier said than done).
I for one, would prefer to keep compatibility that introduce bugs that will be incredibly hard to spot.
As for SVG, I do understand the frustration around it, but for the longest time those "in the known" were pretty unhappy with the direction that SVG took. It was a pretty good standard (although it avoided solving fundamental problems, I believe partially related to who was on the committee regarding fonts, you might want to google "Raph Levien fonts svg standard") until it became very bloated.
Part of the story involved Adobe trying to add a lot of features to SVG to turn it into something that could compete with Flash, turning SVG into a rather complicated standard to implement. Eventually Adobe would buy Macromedia and they lost interest in extending SVG (an
Miguel, the entire ECMA-376 spec is "optional," in the sense that a compliant application only needs to accept the syntax -- the semantics aren't required (and, therefore, are not covered by any of Microsoft's IP "pledges.")
Well, you ignored the part where I mentioned that this was being taken care of.
Now you argue about optional, so let me clarify, I meant OOXML "optional" which has a very precise term in the spec. Since we are talking about OOXML I expected you to be familiar with it, I guess you were not familiar with it, but only with the handful of bullet points circulating the intertubes.
OH MY GOD THEY USE A BITFIELD THAT IS JUST SO-NOT-XML
Oh my God, they used a bitfield to encapsulate Microsoft-proprietary extensions like VBA rather than standardizing them as well. (Proper capitalization used to represent more somber tone of retort.)
Got a reference for that? This is the first time I hear that the bit field was for encapsulating VBA and I do not see that referenced.
You seem to have answered a lot of questions that nobody thinks are the main questions, while not answering the important ones. The main issue is that the spec says implementations have to document the behavior of particular versions of MS products, but it doesn't spell out what that behavior is.
Am aware of those, they are minor issues. I feel they are worthless, but whatever.
The issue has been raised with ISO, it has reached ECMA and they are going to get you the docs.
If I were triaging this as a bug report, I would say its irrelevant, but it seems that through ISO it became a big deal, so you going to get this documented. Happier now?
Yaz, you wrote an essay and ignored the part where I said that ECMA was going to document that for the next batch of issues to resolve in the spec.
So they know about the issue, they will write the docs for it, and integrate it into the doc.
So basically "Your bug is being going to be fixed". Next issue.
In addition to the above I predict it does not matter, because its a legacy setting and they are themselves trying to not drag documents that contain that.
Slashdot Mirror
That was a research paper on ILX from 2001.
The research work from ILX was folded into .NET 2.0 and is part of ECMA 4th edition.
All of the instructions that you listed are deprecated, they never really made it into .NET, their much improved, polished and battle field tested versions did. And they are the foundation for C#'s generics support and Don Syme's F# compiler, both which run just fine in Mono today.
The current Silverlight 3 preview release supports in addition to the proprietary codecs a pluggable framework for developers that wish to do so to use their own codecs.
As part of the Moonlight effort we now have implemented Vorbis, Theora and ADPCM and have a partial implementation of Dirac almost ready to use.
Our codecs work in both Silverlight 3 and our open source Moonlight implementation.
This means that the specifications can now be used to implement third party implementation and can be used by open source efforts to recreate Flash.
In the Silverlight world that was already possible as Microsoft publishes pretty much all of the specs necessary to implement Silverlight.
Both the Flash plugin from Adobe and the Silverlight plugin from Microsoft are proprietary products. Gnash, Sfwdec and Moonlight are open source implementations of these technology.
I agree that Visual Studio is a very nice tool.
Luckily the code that you produce with Visual Studio will run on Mono (no recompilations necessary) including code that uses ASP.NET MVC. And with the new support for ASP.NET precompiled sites in Mono (available in Mono 2.4) you do not even need to copy the source code to your target server.
Click "Publish" in visual studio, enter the location for your shared directory, and you have a fully working ASP.NET MVC app running on Linux, without leaving Windows.
We are working on various integration points for Visual Studio that will give developers even more: debugging from Visual Studio remote applications deployed on Linux systems and producing packages ready-for-distribution on Linux.
ASP.NET MVC runs on Mono 2.4 out of the box.
Not only does it run, but you can now install a MonoDevelop plugin that will provide all the tooling to get the Linux developer experience to match the Visual Studio experience for MVC development.
It is quite sweet.
Silverlight supports Firefox as well as it supports IE on both Windows and MacOS.
I do not remember the last time I even used IE on Windows to browse the web, and there have been *no* sites that use Silverlight that fail under firefox (we try a lot of them when looking for the "next sample to get working on Moonlight" from http://silverlight.net/Showcase).
If what you were implying though was that Moonlight 2.0 was not ready to run Silverlight 2.0 content, you are right. Moonlight, the open source version of Silverlight is not yet ready to render all of the 2.0 content, but it is very close to it.
Perhaps the Portugal government would like to fund the accelerated development of Moonlight by hiring a few developers to assist the project. That seems like a win-win for everyone involved. Faster Moonlight 2.0 and 3.0 and the warm cozy feeling that they made the world a better place.
Moonlight only exists because MS have disclosed most of the implementation details to them, it still lags a long way behind the MS implementation and isn't 100% compatible anyway.
Moonlight exists because we were able to put a prototype together in 21 days (you can read about our hack-a-thon here: http://tirania.org/blog/archive/2007/Jun-21.html).
Microsoft has since helped us by providing licensed codecs that can be used by Linux users; Providing us with Silverlight specs for a full open source impleentation (Although 100% of it is available on the web at msdn.microsoft.com) and they provided us with test suites to ensure that Moonlight passes every single Silverlight test suite that Microsoft uses internally.
No two implementations will be 100% compatible. In fact even fixing a bug means that version a and version a.0.0.0.1 with the bug fixed are not "100% compatible", so there is not much point in arguing about 100% compatibility in the first case, it is easy to prove that this will never be the case. But in that regard, no piece of software will ever be (not the kernel, not the browsers, not anything that ever gets bug fixed as a platform).
But we can get very close to the indented behavior as articulated in the test suites "This is what it is supposed to do as far as -we- humans could guarantee". There will certainly be bugs, but we do not have a problem fixing those, and the Microsoft engineers have been very helpful in answering any questions we might have.
It is worth pointing out that the real problem is not really the democrats or the republicans but with the system that has allowed anyone with deep enough pockets to make government do whatever they want.
The NAFTA agreement was not really aimed at helping any of the people in the three participating countries, NAFTA was always designed to help the big corporations reduce their cost of operations. At the same time, NAFTA contained enough provisions that it undid a number of constitutional guarantees and local laws (at least for Mexico it did) and new trade courts ended up having more power than national courts for any trade dispute.
We are getting ready for our first beta of Moonlight 1.0, which will map to Silverlight 1.0, you have a few options to get it running:
(a) Wait until our official Beta launch, and it will contain an easy-to-install plugin. Click install, restart browser, you are done.
(b) You can use it today if you build from our source code, it is published here: http://www.mono-project.com/Moonlight
(c) Repositories like Packman have RPMs that you can install for various distributions that you can install today.
We will be using Microsoft's Media Pack for Linux, which is a licensed version of the media codecs, binary drivers provided by Microsoft. This has the advantage that the media companies that own the patents on codecs have been paid for (MPEG-LA consortium and others).
For those of you that live in a country where software/machine patents are not enforced (media patents are enforced in Europe, contrary to popular lore) or those that just want to stick it to the man, you can build Moonlight with the open source FFMPEG media codecs.
Support for Silverlight 2.0 will ship in preview form in December.
The Iron* family of languages are re-implementations from scratch of a language to run on top of .NET. This approach requires a large time investment to get it working as reimplementing a language and then tuning it to run fast is not a weekend hack.
There is another option, to build bridges from a language to .NET. This is possible because .NET can be used as a library, Perl can host .NET and then create objects and send messages to objects living in the .NET world.
For a language in continuous evolution like Perl, following the Iron* route is more difficult, and the second approach might be better.
I believe there used to be a set of .NET bindings for Perl.
I am actually not a fan of rewriting software that works. Rewriting is not a decision that must be taken lightly, you introduce regressions, you might drop features, a lot of knowledge embedded in the small details is lost and so on.
But there are certain cases where rewriting is worth doing. I would like to see a few applications rewritten. I do not really want to "rewrite" the panel, but instead come up with new interaction metaphors for the main application launcher. Gnome-Do for example (already written in Mono) is a great tool, but it is a tool for power-users, not a tool for most people.
I would like to see new research, and new ideas for new panels rewritten, and I do not particularly care about what language or platform is used, as long as it produces some nice new ideas, and new metaphors. Gimme is such an attempt by Alex Graveley, written in Python.
I believe that the engine in Moonlight is worth reusing for many new kinds of applications, and it opens the doors for some new creative UIs. And you get to choose if you want to use it or not. If it offends your sensibilities that its written with Mono and C#, then do not use it. It really is that simple, nobody is forcing anyone to use the software I work on. If your religion prohibits prevents you from using software based on Mono, that is fine, nobody is asking you to change your religion.
Miguel.
Hello,
The equivalent in .NET and Mono is called P/Invoke and in Microsoft modified Java it was called J/Direct.
The scenario that you describe: Java calling native code, and native code calling back is also supported by P/Invoke.
With P/Invoke the way you call into a native method is simple, for example if you wanted to call glDrawBuffer, you would do:
using System.Runtime.InteropServices;
class Sample {
[DllImport ("GL")]
extern static void glDrawBuffer (int mode);
static void Main ()
{
glDrawBuffer (10);
}
}
That is the entire binding: you do not need to have any C++ glue compiled, compile the above and run, and it will call your glDrawBuffer method.
If you are happy with Java, by all means, continue using Java. I was merely explaining why Microsoft had to create .NET (they were bared from using it by a judge).
Miguel.
Actually, the reason .NET exists is because Microsoft was prohibited after the Sun/MS lawsuit in 1997 from making changes that they needed to Java.
The changes that Microsoft did to Java included J/Direct and delegates.
Although Java does have a mechanism for calling into native APIs using JNI, it is cumbersome to use. JNI is a technology that requires developers to write a chunk of code in C++ and a chunk in Java to bind the C++ code. Microsoft's alternative, J/Direct allows all the code to be written in the native language. It now exists in .NET as P/Invoke, and it makes calling native APIs easy, and does not require any native code to go with it (this is the reason that using the SWT library for Java requires you to ship architecture-specific glue code).
Some Java developers did notice that the lack of something like J/Direct was a pain, and eventually came up with a system built on top of JNI that does what J/Direct used to do, the Java Native Access APIs.
The other bit were delegates. Delegates are merely the object oriented version of function pointers, but in addition to capturing the address of a function, they also capture the instance that is associated with the object. At the time Sun published a paper describing why they did not like delegates (http://java.sun.com/docs/white/delegates.html). It is an interesting read considering that pretty much everything on their case against delegates turned out to be wrong. Java would me a much better language and a simpler language to develop for had they allowed delegates to go into it.
The 1997 Java lawsuit prevented them from using it, but that does not mean that Java did not add a lot of value and was not a great idea to begin with. So Microsoft had to write their own, from scratch. In the process they would add the features that they needed (and in Mono, we use those extensively) and with the hindsight of knowing what was good and bad about Java, they could build a better Java, and that is what they did.
Miguel.
Brian Jones blogged a response to this which puts things in perspective here: http://blogs.msdn.com/brian_jones/
Miguel.
Some other folks at 4 or 5 already have commented on the fact that this is not a C# bug or a .NET bug, but a programmer mistakes, so I will not elaborate.
But the article linked to was authored by "RedGate Software" for the Code Project, so it is basically an advertisement for their product. Their product did help the team fix their bug, so maybe that is good.
But the bug was discovered and fixed in 2005:
http://pave.princeton.edu/main/archives/114
So what happened is that probably Red Gate wanted to score some PR points over at the Code Project and they digged up a story from their existing customers, decided to sponsor the guys in exchange for a few quotes that they could put on the article to promote their product.
It would probably not gone too far, except the guy that submitted the story thought he had found the smoking gun against C#.
Miguel.
It is not just an integrity check; Had it been an integrity check, it would have merely used the SHA1 checksum over its contents. Instead it initializes the SHA1 state with a key, and then computes SHA1.
Miguel.
That is not what I said. What I said was quite different, but selectively quoting will remove all the context and of course you will come to the wrong conclusions.
You might have posted this on my blog a minute ago, I replied to you there, the post "Talk to your lawyers".
Miguel.
You might want to get down from your high horse.
The ECMA group will be in charge of sorting through most of the issues as they work closely with ISO.
Well, I can see why, because you can dump in the spec something that you want access to (Sun did the same with Oasis). Imagine that you standardize Windows Media inside the JTC1/SC34, and then claim "gotcha!".
As for the other stuff, I agree it is not nice of them, but am not sure how you could twist their arm to go beyond that.
Miguel.
I was really going to watch the Colbert Report, but a quick post:
You got the history of ODF and microsoft pulling out of Oasis wrong, they were developing their own for a while:
http://blogs.msdn.com/brian_jones/archive/2007/01/25/office-xml-formats-1998-2006.aspx
Anyways, my fellow freedom fighters as a "Colbert Nation Hero", I have a duty to fulfill tonight by watching the Colbert Report and I must recuse myself for the night.
Miguel
Hello,
I can explain the date situation to you if you want. It is a bit complicated and most people have no idea of why this is decision is important.
The issue has to do with the way spreadsheets have historically represented dates. They do not represent dates in a special format, but instead as a floating point which can be interpreted by a special format. So "N.M" becomes day N hour M (where M is some fraction of the day, I cant remember now exactly the mapping).
The problem is that people do date computations and math computations based on the floating point values in the cells (the way you find the difference between two dates is very simple: substract the floating point numbers).
So cells would contain values like "10312" and an external format that says "render the value as a date with this format". Formats are combined with a region-based mechanism which I wont go into.
Now if you have ever debugged spreadsheets or worked with finance people that use spreadsheets extensively you will know that these people did not read "Design Patterns" and Knuth before writing their stuff. They are not exactly PhDs in computer science.
The date mistake comes from Lotus 1-2-3 (and possibly earlier, but at least the problem was present here) and has been with us ever since. Now, the reality is that there is a gap of four years (or something like that, again, I do not remember the details) in 1900 where the values are incorrect because of this mistake in Lotus 1-2-3. The problem is that all dates have been stored as numbers. So you certainly could decide to "fix" the problem to be correct, but then you would have to upgrade *and* debug all spreadsheets out there that do date computations. Now most date computations might be fine (because most people would do date-to-date computations) but the cases where people mixed date computations with *other* data would be affected. How badly? Well, there is no easy way of telling.
Now, if you have debugged a spreadsheet (I have, I debugged a lot of spreadsheets in my Gnumeric days) nasty spreadsheets are not easy to debug. They are fairly complicated beasts and am not sure that *anyone* that has existing models would have to debug these problems (the amount of people using Excel as a financial planning tool are way larger than you can imagine).
Now, you might say "ODF deals with this". It does, and it does so on an interesting way, a way that requires you to enter the data again. It basically keeps track of the stored value *and* the value actually entered by the user. This works as long as the user enters the data again, but if the user did not enter the data and you just imported, you are in trouble. I tried this some time ago and importing an XLS file into OpenOffice did in fact break the date computation during import and later export.
Now, if I had millions of users using my software, I would not want to impose on them a new semantic on the numbers on the spreadsheets. Imagine the consequences of fixing something like that say in a CPU: changing the semantics of something that even if broken was known and worked around already (yes, you could say, "fix the software", but that is easier said than done).
I for one, would prefer to keep compatibility that introduce bugs that will be incredibly hard to spot.
As for SVG, I do understand the frustration around it, but for the longest time those "in the known" were pretty unhappy with the direction that SVG took. It was a pretty good standard (although it avoided solving fundamental problems, I believe partially related to who was on the committee regarding fonts, you might want to google "Raph Levien fonts svg standard") until it became very bloated.
Part of the story involved Adobe trying to add a lot of features to SVG to turn it into something that could compete with Flash, turning SVG into a rather complicated standard to implement. Eventually Adobe would buy Macromedia and they lost interest in extending SVG (an
Well, you ignored the part where I mentioned that this was being taken care of.
Now you argue about optional, so let me clarify, I meant OOXML "optional" which has a very precise term in the spec. Since we are talking about OOXML I expected you to be familiar with it, I guess you were not familiar with it, but only with the handful of bullet points circulating the intertubes.
Miguel.
Miguel.
Got a reference for that? This is the first time I hear that the bit field was for encapsulating VBA and I do not see that referenced.
Miguel
Am aware of those, they are minor issues. I feel they are worthless, but whatever.
The issue has been raised with ISO, it has reached ECMA and they are going to get you the docs.
If I were triaging this as a bug report, I would say its irrelevant, but it seems that through ISO it became a big deal, so you going to get this documented. Happier now?
Yaz, you wrote an essay and ignored the part where I said that ECMA was going to document that for the next batch of issues to resolve in the spec.
So they know about the issue, they will write the docs for it, and integrate it into the doc.
So basically "Your bug is being going to be fixed". Next issue.
In addition to the above I predict it does not matter, because its a legacy setting and they are themselves trying to not drag documents that contain that.
Miguel