Excel 2010 (Microsoft Office 2010 CTP TO-do list (01)

by jlundstocholm 3. November 2009 18:11

I have been looking at how Excel 2010 has implemented various features using ISO/IEC 29500-4:2008 - also known as "OOXML Transitional".

Background:

ISO/IEC comes in two variants, a "transitional" (T) and a "strict (S). Transitional is the one containing all the legacy stuff such as VML, legacy digest algorithms, leap year bug etc. S does not contain these things and is therefore considered "more pure". T is practically identical to the document format submitted to ISO/IEC by ECMA - also known as "ECMA-376". A document conforming to ECMA-376 will therefore also conform to T, since the schemas are practically identical.

T is currently a superset of S, which means that "T includes everything in S". This has the effect that within a T document, a vendor can take advantage of new features in S while still being in "the comfort zone of T". T is therefore considered by some as providing a “graceful migration path to S”, meaning that vendors can change their existing T-compliant code, on a case-by-case basis, to gradually support the features of S instead of those of T.

Update 2009-11-17: By reading in the spec today, I realised that I was wrong in saying that the leap-year bug was not in S - indeed it is. I appologize for the confusion. Thank you, Jens Hørlück for pointing this out to me.

As you know, Microsoft is claiming "IS29500 compliance" for their latest incarnation of Microsoft Office. OOXML is a big and complex document format, and even though OOXML was not published until waaaay after "feature freeze" of Office 2010, I thought it'd be interesting to take a look at how Excel has reached compliance.

When looking at the markup generated by Excel 2010, it is important to remember the background information above, since you'd expect to find traces of this "graceful migration" in the markup already.

Conformance class

The DIS-process added a new attribute to the root elements of the documents. This element would specify the conformance level of the document. As to not invalidate existing documents, the default value for this attribute was “transitional”. The other possible value is "strict".

So when creating a new spreadsheet using Excel 2010, which markup does it create?


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<workbook>
  <sheets>
    <sheet name="Sheet1" sheetId="1" r:id="rId1>
  </sheets>
</workbook>

(condensed for easier reading)

The above is the markup for the root element of a SpreadsheetML spreadsheet.

So the conformance class attribute is omitted – making the document a T-document. I know that it is basically nonsense to add an attribute with the default value to implement support for this behavior, but for those of us that like looking at markup in text editors, I’d recommend Microsoft to include the conformanceClass-attribute with the appropriate value. As it is a no-brainer to implement for a consumer – it should be a no-brainer to implement for a producer.

Also – the existence of the conformanceClass-attribute is the only (or, best, anyway) indicator that a T document was created according to the schemas of ISO/IEC 29500 and not those of ECMA-376.

(and yes, I know that they are practically identical, but adding the attribute would be a clear indication that Microsoft wishes to produce markup according to ISO/IEC 29500 and not ECMA-376 1st Ed.)

Microsoft, please fix!

ISO-dates

Support for ISO-dates in SpreadsheetML just might be the biggest issue we faced in the DIS-process. It was hugely controversial and as such, a large amount of time was used at the BRM to figure out a solution.

Excel 2010 allows a user to manually chose the option to persist dates in ISO-8601 format. This is done through the "Settings-dialogue" as

So let us see what Excel 2010 does with dates. I opened the application and in a cell I wrote the date 28-02-1900. I then unzipped the XLSX-file and found this markup in the Worksheet-part:


<sheetData>
  <row r="1" >
    <c r="A1" t="d">
      <v>1900-02-28</v>
    </c>
  </row>
</sheetData>

So the date is actually persisted in the file using ISO-8601 notation and the cell is correctly typed with a t=”d”-declaration.

Now, depending on your point of view, this is a good thing, because it takes us further from the hell-hole I have previously written about with respect to “date-typing-of-numbers” in ECMA-376.

Thank you, Microsoft – good for you!

Smile

Leap-year bug

So … with the “Save-as-ISO- 8601-dates”-setting to “yes, please” as previously described, I added a formula to the spreadsheet above in cell B1. The formula simply was “=A1+1”.

Anyone up for guessing the result?

Well, the result was this:

That is funny because of two things:

  1. I set the “Save-as-ISO Dates”-setting to “yes”, so I was not expecting the leap-year-bug to still be used.
  2. I am pretty sure that the date-representation “1900-02-29” is not a valid ISO-date.

So I looked at bit at the markup generated for this spreadsheet.

The result was:


<sheetData>
  <row r="1" >
    <c r="A1" t="d">
      <v>1900-02-28</v>
    </c>
    <c r="B1">
      <f>A1+1</f>
      <v>60</v>
    </c>
  </row>
</sheetData>

Ahem … dear Microsoft … WTF?

So you have persisted the first date as an ISO-date,

but the result of calculating a value based on it – you persist the result as a serial date? In which universe would this make sense?

(I should note that whenever doing calculations resulting in dates not being invalid, the date is correctly persisted by Excel 2010 as an ISO-8601 date)

But – as I was writing this I thought “wasn’t there something about an at-BRM-added attribute called “dateCompatibility”? This was the attribute used to determine if the date-system used should support the leap-year-bug or not. And truth be told, the attribute is not used – making the dateCompatibility default to “true” – hence honoring the leap-year-bug.

But – this could simply be a glitch of Excel2010, so I added the attribute myself to force Excel2010 to discard date compatibility. I’d then suspect the result of adding 1 to the date of 1900-02-28 would be 1900-03-01.

The markup was this:


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<workbook dateCompatibility="false">
  <sheets>
    <sheet name="Sheet1" sheetId="1" r:id="rId1>
  </sheets>
</workbook>

Result: still 1900-02-29

I this calls for a few conclusive words before I move on:

Microsoft, I think you should stop using ISO-8601 dates in SpreadsheetML in T because of the arguments provided by my fellow WG4-expert Gareth Horton. But if you insist on using ISO-8601-dates in SpreadsheetML-T, you should do it right,. If you ask me, a user manually choosing to have Excel2010 use ISO-8601 dates, is a clear indication that the user does not want to deal with the leap-year-bug. The user has even decided to continue despite your warning that he or she might lose precision. So when a user performs this specific action, set the damn dateCompatibility-attribute to “false” and persist ALL dates as ISO-8601 dates.

You have a golden opportunity here to ditch the leap-year-bug for all new documents. If you act wisely and add the conformance attribute (so consuming applications can distinguish the files from ECMA-files) and setting the dateCompatibility-attribute to “false” when persisting dates as ISO-8601 dates, you’d have done really, really good. You have the by far biggest implementation of OOXML – so the vendors will follow your lead. Any application adding support for ISO-8601 dates in transitional documents in their existing ECMA-376-compliant code, will be able to kno

w what to do - and they'll do it the way you do it.

Now, I know you would like to demonstrate to all of us that you want to go towards “the S way”, but you need to do it right. Mixing ISO-8601 dates with serial dates simply to be able to maintain the leap-year-bug is not the right thing to do.

I have absolutely no idea of how the internals

of either the calculation instructions in Excel works – or even the Excel-team itself, but the way you have “added” ISO-8601 dates indicates to me, that you have changed barely anything except for the persistance-mechanism for dates.

I’m sure you’d argue that there is no longer time to change the inner workings of Excel2010, and you might very well be right about that. If that is indeed the case, I suggest you remove the option of saving dates as ISO-8601-dates from Excel2010 as soon as possible to avoid doing any more harm to the ecosystem around OOXML that we both share deep concerns for.

VML

At the BRM the biggest pile of things added to OOXML was where a feature was previously only possible with the use of VML. Of these include adding comments to cells in spreadsheets. The comments themselves are stored in a “Comment part” of the OPC-package, but the display of the comment was done using VML. Luckily, at the BRM markup was added to allow DrawingML to be used instead.

So I used the spreadsheet from before and added a comment in cell B2 (the one with the crappy leap-year-bug result)

.

Anyone wanna guess if this comment is displayed using VML or DrawingML?

Yes, you guessed it … somewhere in the back of the document is a VML-fragment containing the “box” containing my comment.


<xml xmlns:v="urn:schemas-microsoft-com:vml"
 xmlns:o="urn:schemas-microsoft-com:office:office"
 xmlns:x="urn:schemas-microsoft-com:office:excel">
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1"/>
 </o:shapelayout><v:shapetype id="_x0000_t202" coordsize="21600,21600" o:spt="202"
  path="m,l,21600r21600,l21600,xe">
  <v:stroke joinstyle="miter"/>
  <v:path gradientshapeok="t" o:connecttype="rect"/>
 </v:shapetype><v:shape id="_x0000_s1025" type="#_x0000_t202" style='position:absolute;
  margin-left:120.75pt;margin-top:1.5pt;width:126pt;height:55.5pt;z-index:1;
  visibility:hidden;mso-wrap-style:tight'
fillcolor="#ffffe1" o:insetmode="auto">
  <v:fill color2="#ffffe1"/>
  <v:shadow on="t" color="black" obscured="t"/>
  <v:path o:connecttype="none"/>
  <v:textbox style='mso-direction-alt:auto'>
   <div style='text-align:left'></div>
  </v:textbox>
  <x:ClientData ObjectType="Note">
   <x:MoveWithCells/>
   <x:SizeWithCells/>
   <x:Anchor>
    2, 15, 0, 2, 4, 55, 3, 16</x:Anchor>
   <x:AutoFill>False</x:AutoFill>
   <x:Row>0</x:Row>
   <x:Column>1</x:Column>
  </x:ClientData>
 </v:shape></xml>

If this was a tweet on Twitter, I’d finish it off using the tag #fail.

Document protection

And finally – what about document protection? “Document protection” is the mechanism in OOXML to allow applications to open documents in “read-only-mode”, to protect worksheets from editing etc. These are not really protecting the document as such, because a hash of the password is simply saved – but everything is still in clear text. Document protection was one of the areas where OOXML was fundamentally changed, allowing more robust algorithms to be used – and not only the weak “legacy-algorithm” previously supported by Office 2007.

So in Excel2010 I chose to protect the active sheet and looked at the markup again. Again, I was hoping to find some of the new markup, but again I was let down. Excel2010 still uses the weak algorithm and it still uses the legacy markup to persist it.


<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<worksheet>
  <sheetData/>
  <sheetProtection password="8985" sheet="1" objects="1" scenarios="1" />
</worksheet>

This is not only an annoyance for those not working on the Windows-platform – it is also an annoyance for those of us working with e.g. .Net development. If Excel2010 used SHA1, SHA256 or one of the other modern algorithms supported directly by .Net framework, we’d be able to use it straight out of the box. Now all of us still need to add additional code/assemblies to our code – simply to protect a whorksheet.

At the end …

I must admit that I am a bit disappointed. I know that barely a year has gone since the publication of ISO/IEC 29500, but I had expected more of the things we discussed at the BRM to be implemented. At the very least I was expecting some of the more “easy ones” to have been implemented – like the conformanceClass-attribute, VML in comments and document protection. It would have been a nice token of “good faith”.

Now, we are basically left with nothing. Do note, however, that the observations above are by no means a comprehensive test. These represent simply a few of the thoughts on the top of my head while writing this.

Next time: WordpressingML

PS: I have been trying to find a list of the stuff from the BRM that was implemented in Office 2010 (like ISO-8601 dates), but I have been unsuccessful. So if anyone can point me towards such a list, I'd be happy to include those results above.

Comments

11/3/2009 11:08:01 PM #

Alex Brown

Jesper hi

The real killer here is "ISO 8601" style dates in T; they will silently corrupt when read by legacy applications, as Gareth pointed out on his blog (and as we saw with our own eyes in Prague).

There is real potential for serious data problems if that kind of crap gets out into the wild ...

- Alex.

Alex Brown United Kingdom |

11/4/2009 1:40:07 AM #

jlundstocholm

Hi Alex,

I completely agree. Let Microsoft Office 2010 Excel ISO date feature be a PoC that it can be done ... and now,take Them away

Smile

jlundstocholm Denmark |

11/4/2009 6:15:48 PM #

Mohamed ZERGAOUI

#fail ....DAMMIT !

Let's propose to Microsoft an ISO Service Pack for Office 2010 !!

Mohamed ZERGAOUI France |

11/4/2009 7:54:50 PM #

Alex Brown

@Mohamed

Why wait for MS? Maybe there is a market for vendors to produce add-ons for Office so as to tailor its output for various kinds of standards conformance ...

Alex Brown United Kingdom |

11/4/2009 8:20:21 PM #

jlundstocholm

Alex,

Why wait for MS? Maybe there is a market for vendors to produce add-ons for Office so as to tailor its output for various kinds of standards conformance ...

A bit like the Sun ODF Microsoft Office plugin?

jlundstocholm Denmark |

11/5/2009 1:01:15 AM #

Luc Bollen

@Jesper: "I must admit that I am a bit disappointed. I know that barely a year has gone since the publication of ISO/IEC 29500, but I had expected more of the things we discussed at the BRM to be implemented."

You are disappointed, but are you surprised?  I have claimed in the past (see the comments in ctrambler.wordpress.com/.../ ) that "Microsoft should only support ECMA-376 (1ed) for archiving in XML documents created before Office 14 is available, and ISO-29500 Strict for new documents created with Office 14."  Adding new BRM features in OOXML files produced by Office 14 (aka Office 2010) will result in incompatibilities with Office 2007, which will at best ignore these features, and at worse prevent the correct handling of the file.

So the only choice for Microsoft is to avoid adding new BRM features in their OOXML files.  Alex and you say the same thing when you recommend to remove the option of saving dates as ISO-8601-dates as soon as possible.  Same thing for DateCompatibilty and VML (if the comments are in DrawingML, they cannot be handled by Office 2007).  All the new features added by Office 2010 are added via MCE to preserve compatibility with Office 2007.

Looking back, it was a bad decision at the BRM to make Transitional being a superset of Strict. It would have been much cleaner to have Transitional being perfectly aligned with Office 2007 (that's what SC34/WG4 is busy doing now) and Strict being a "clean" version, where all the legacy is removed and the improvements/new features are added.

But we know that this was not possible for politic reasons: 1. it is not the purpose of an ISO standard to document the format of a proprietary product, and 2. Microsoft main argument for justifying OOXML (in addition to ODF) was that OOXML was "the format of the future with 100% compatibility with the binary formats" (I paraphrase).  So it was politically not good to have a clear split in a Transitional variant looking backward (which already existed in ECMA-376) and a Strict variant looking forward (which was basically a duplicate of ODF).

Your tests indicates that Microsoft knows all this: they will make sure that the Office 2010 files remain fully compatible with the Office 2007 files (i.e. ECMA-376 files).  Sometimes later (2012? 2014?) Microsoft will maybe start producing ISO-29500 Strict files.  But it appears that producing ISO-29500 Strict files is so complex that Microsoft will not be able to do it in Office 2010.

Another explanation would be that it is not complex to implement ISO-29500 Strict, but that Microsoft does not care about ISO-29500, and want to continue their own way...  Of course, this will be claimed only by cynical or ill-minded people Wink. As said by Rick Jelliffe: "The instruction of the BRM, that Transitional is not to be used for new documents, should be taken seriously [...]. An application that generates OOXML Transitional for new documents (by default) should not be acceptable, because it goes against the clear instructions of Part 4 of the Standard. [...] To put it bluntly, if Office 14 (or a future OpenOffice ) generates OOXML Transitional for new documents but not OOXML Strict, the documents may conform to the standard, however the application is non-conforming." ( broadcast.oreilly.com/.../...participation-pa.html ).

All this confirms my standpoint: OOXML as an ISO standard has always been a farce, and purely a marketing move from Microsoft.

Luc Bollen Belgium |

11/5/2009 1:47:42 AM #

pingback

Pingback from topsy.com

Twitter Trackbacks for
        
        Excel 2010 (Microsoft Office 2010 CTP TO-do list (01)
        [idippedut.dk]
        on Topsy.com

topsy.com |

11/5/2009 3:29:51 AM #

Cecil

May be Dough Mahugh from Microsoft could elaborate something about this issues in Office Excel 2010.

Dough , are you there?

Cecil United States |

11/5/2009 3:34:47 AM #

Alex Brown

@Luc

It would have been much cleaner to have Transitional being perfectly aligned with Office 2007 (that's what SC34/WG4 is busy doing now) and Strict being a "clean" version, where all the legacy is removed and the improvements/new features are added.

Bingo! we agree on that 100%

So let's do it (I don't perceive the 'political' problems you do as being blockers).

- Alex.

Alex Brown United Kingdom |

11/5/2009 9:29:15 AM #

Luc Bollen

@Alex: Announcing clearly in 2008 that ISO-29500 Transitional was *only* aimed at documenting the legacy Microsoft formats (binary and Office 2007), and that ISO-29500 Strict will not be available in any major implementation before 2012 or 2014 or never (while ODF implementations were readily available for producing new documents), would have quite automatically resulted in DIS29500 being rejected.  Politically, it was therefore not acceptable for Microsoft to say it. But it appears clearly now that it was their hidden agenda, as many have claimed at the time.

"So let's do it" ? Indeed, now that ISO-29500 exists and that JTC 1 and ISO have lost their credibility as independent providers of quality IT standards, there are no blockers left.  So let's continue in the same direction and help Microsoft to achieve the remaining part of their hidden agenda.  Let's align perfectly the ISO-29500 Transitional variant on the existing commercial product of a single provider (don't forget to drop the ISO-8601 date format and all the new features or changes added during the BRM - we should not allow that kind of crap gets out into the wild).  At the same time, drop the Strict variant, as it looks like it will never be implemented.  It will then be clear to the remaining sceptics that ISO has lost its soul and that ISO-29500 has no value outside the Microsoft ecosystem.

Luc Bollen Belgium |

11/5/2009 6:29:26 PM #

Alex Brown

@Luc

Actually, it's pretty clear that Transitional *was* only aimed at documenting the legacy Microsoft formats -- that's embodied in the scope of the Standard as amended by the BRM. Furthermore it is stated that new Transitional documents should not be created (which rather raises the question of why new features were added to it).

I think you're obsessing about Microsoft here. The benefit of T is to the vast user base of people working with MS Office 2007 documents: all mainstream text processors, most back-office enterprise systems, and thousands of bespoke pieces of document processing software. Having T accurately represent those documents is a benefit to them. How this benefits or disadvantages Microsoft is incidental to that.

As to Strict ... yes, if it remains unimplemented at the time of its review then that is a good argument for having it withdrawn ...

- Alex.

Alex Brown United Kingdom |

11/6/2009 9:37:49 PM #

Luc Bollen

@Alex

"it is stated that new Transitional documents should not be created" Indeed, this is stated in ISO-29500, but still MS Office 2007 produces only new Transitional documents, and MS Office 2010 will continue to produce only new Transitional documents.  So Microsoft does not care about what is stated in the standard if it goes against their own plans.

"The benefit of T is to the vast user base of people working with MS Office 2007 documents" OK, but is it really the purpose of ISO to claim in an international standard that 1900 is a leap year (this is one example), just because many people are working with MS Office 2007 ?  The French proposal to publish OOXML as a Technical Specification rather than an International Standard would make more sense for this purpose.

"As to Strict ... yes, if it remains unimplemented at the time of its review then that is a good argument for having it withdrawn ..."  Are you really saying that you don't care if Strict is never implemented by anybody ?  As far a I know, most of the results of the BRM are concentrated in the Strict variant.  So, if you remove from T the new features which were added to it (e.g. ISO_8601 dates) and you withdrawn S, you simply end up with an international standard documenting a commercial product, without taking into account any of the improvements to the format requested by the NBs as part of their review.  Is this really something that you find acceptable ?

Luc Bollen Belgium |

11/6/2009 10:24:23 PM #

Alex Brown

@Luc

> MS Office 2010 will continue to produce only new
> Transitional documents.  So Microsoft does not care
> about what is stated in the standard if it goes against
> their own plans.

What Microsoft do (or do not do) is up to them. The release cycle of MS Office meant is was unlikely Office 2010 could ever have been a Strict-conforming product. Nevertheless this leaves Office 2010 on distinctly questionable ground in regard to conformance to IS 29500.

Meanwhile NBs can be quietly pleased that have a Standard which matches (with increasing fidelity) the reality of Office 2007 documents, for the benefit of their users.

> is it really the purpose of ISO to claim in an
> international standard that 1900 is a leap year
> (this is one example), just because many people
> are working with MS Office 2007

Yes, for that particular purpose. Standards reflect consensus, which is not to be confused with reality.

> if you remove from T the new features which were added
> to it (e.g. ISO_8601 dates) and you withdrawn S, you
> simply end up with an international standard documenting
> a commercial product,

There you go again, obsessing about MS. What the Standard represents are *documents* which - yes - were mostly emitted by a particular product (MS Office) but which the whole world has to work with.

However, T is essentially a deprecated format. I'd not expect it to stick around for so very long ...

> without taking into account any of the improvements to the
> format requested by the NBs as part of their review.  Is
> this really something that you find acceptable ?

Well, sadly it's just life that better technologies very often lose out to inferior ones.

We can watch with interest ...

Alex Brown United Kingdom |

11/6/2009 11:20:37 PM #

Luc Bollen

@Alex: Interesting comment. If you consider ISO 29500 Transitional as a deprecated format, and you expect ISO 29500 Strict to loose against it, this does not look like a bright future for OOXML...

Luc Bollen Belgium |

11/7/2009 7:59:14 PM #

Alex Brown

@Luc

The Transitional format, even deprecated, is very useful right now and for some time to come, as the "legacy" is not going to vanish overnight.

I don't know if I expect the Strict format to "lose" -- but it's possible it may never enjoy traction/dominance.

You might want to think about HTML/XHTML as an interesting parallel ...

Alex Brown United Kingdom |

11/10/2009 10:23:47 AM #

Luc Bollen

@Alex: "What Microsoft do (or do not do) is up to them."

Sorry, I'm going for a little bit more of what you call "obsessing about MS", as I cannot help but think that MS is central to OOXML.  I wonder why Wink.  Indeed, you are right to remind (indirectly) that only Microsoft is controlling the *real* content of the OOXML standard (as the only relevant specification is what MS produces with Office 2007 and Office 2010).

What emerges now is that ISO-29500 will ultimately be perfectly aligned with what has always been produced by Office 2007 (and not the other way round), and that the whole saga of the review by the NBs and the BRM to produce the Strict variant was only time and effort lost by everybody (as nobody will ever implement Strict if it is not implemented by Microsoft).

Finally, Microsoft has everything it expected from the process: buy the time and the ISO stamp they needed to keep MS Office relevant for a few more years, and at the same time tarnish the ISO image.  They could indeed not afford to have the ISO brand highly regarded, the rival format stamped by ISO and their own format left in the dust.

Fortunately, the long term result of all this is a Microsoft image even more tarnished than the one of ISO, and users worldwide more educated about the cost of lock-in, so that the Microsoft dominance on the office document formats will be extended for a few years, but will ultimately vanish.  Amen.

Luc Bollen Belgium |

11/10/2009 8:58:42 PM #

Alex Brown

@Luc

With the Transitional variant, NBs effectively took a decision to standardize the MS Office formats through 2007 (or 2008 for the Mac); they have taken no such decision wrt future versions of MS Office. For the Transitional format there is no "other way round", because the billions of documents are already out there. What would be the point of a legacy format which didn't accurately document the actual legacy?

NBs cannot force MS (or anybody else) to adopt Strict - again I say we will just have to wait and see what happens. I suspect things are going to be a bit more twisty and turny than you are predicting though!

Alex Brown United Kingdom |

12/9/2009 10:22:14 PM #

trackback

SC 34 WG meetings in Paris last week

SC 34 WG meetings in Paris last week

Where is there an end of it? |

2/6/2010 6:35:37 PM #

Conference Call System Companies

Haha... Owned. Great job, Jesper.
Forward this to Microsoft and let them have updates built. =D
Don't get disappointed so fast, Office 14 is now just Beta right? ;)

Conference Call System Companies United States |

7/5/2010 11:38:26 PM #

steve

I actually support both the ODF and the OOXML technologies being written up as international standards. An international standard for IT is like a book in a library, it can be selected and evaluated by users where appropriate. But then Im not sure my opinion has much sway!

steve United Kingdom |

7/23/2010 4:52:39 PM #

Woo

I don't think I'll be giving up my Excel 2007 just yet. Why must we feel the need to update constantly? Heheh. I guess more features in Microsoft Excel is just something we all want.

(Link removed
/Jesper)

Woo Canada |

7/27/2010 3:44:08 AM #

Mobile Phone Recycling

I didn't like the use of MS Office 2007 to be honest. It was very buggy on my laptop. MS 2010 however works extremely fast. If there are people creating add-ons for bugs found in MS then it is great. I don't think anyone should rush into upgrading, but should if they are having speed issues.

Regards
Son Best

(Link Removed
/Jesper)

Mobile Phone Recycling United Kingdom |

9/14/2010 10:26:37 AM #

Martin Hall

#fail ....DAMMIT !

Let's propose to Microsoft an ISO Service Pack for Office 2010 !!

Martin Hall United Kingdom |

Comments are closed