[aramp]

Steve_S said:

>

Quote

Obviously. However, at any point and time, it could have been converted.

I am amazed how easy do you feel about converting something from one language to another AND at the same time from one API to another. Did you ever try to convert a small app from Carbon to Cocoa? I did and it took a whole lot of time. Both API's start with "C" but that's the only thing in common. In all the rest they are very different. And most importantly, the application architecture is very different. Of course, you might do tricks such as having a fundamentally Carbon app wrapped in a tiny Cocoa shell to look and feel like Cocoa application, but even that requires a deep architectural redesign and is not easily done. You may be lucky if the original application is written in plain C (which is a rear thing because for many years most of the development in the world is in C). Because then converting it into Cocoa is relatively easy. Objective C is an extension of C. But if the application is in C then the conversion is much harder because Objective C implies its own way of designing objects and their interaction. In most of the cases you can't just convert C into Objective C one to one. There are ways to merge C code with Objective C code in Cocoa application, but that makes the whole thing quite hard to support, involves type conversions back and forth and is actually not appreciated by Apple.

Quote

Huh? Are you suggesting it would have been technically unfeasible to write the Finder in Cocoa? If so, then what about products like Pathfinder?

Comparing Pathfinder with Finder is like comparing bicycle with SUV. Pathfinder is just a file manager. Finder does so many other things you will be amazed when you find out. Many API calls, including Carbon API calls end up in Finder code.

Quote

There is no technical reason any of Apple's Carbon based products couldn't or still can't be moved to Cocoa. The existence of a Cocoa based Finder product, Pathfinder has demonstrated this for years. Further, if Apple needed something on the API side, they could have easily done so very early on in the OS X development process. Apple seems to agree with you in that 8 years is long enough. Snow Leopard will have a Cocoa based Finder. That won't magically make the Finder a better product in and of itself though. But, it will drop the reliance on the legacy Carbon framework. I'd expect the remainder of Apple's Carbon apps to be migrated to Cocoa within the next release or so.

Of course there is no technical reason, also because any Cocoa application may call Carbon API and even BSD API without any restriction. The problem is the effort. I believe Apple was working on Cocoa version of Finder for many years. And it looks like they are almost there. I have to repeat what I said before and other people here stressed as well. Applications such as MS Word, Finder, iTunes contain millions of lines of code, are built to specific system architecture and are very hard to redesign. The redesign effort is comparable to the total rewrite.

As to what I expect from Cocoa Finder in Snow Leopard - it will become slower, will crash more often than the current version and will contain lots of annoying bugs that will eventually wiped out in some 10.6.5 update.

I would also like to quote one of your previous posts I did not have time to reply promptly to.

>AppleTV, even version 1 isn't exactly a terrible product. It's just not the product I'm looking for. There is a difference. Also, why are you comparing software products to hardware products? Has there been any "media extender" product to take the market by storm? No. Likewise, your point is moot.

AppleTV is a hardware product to the same extent as Mac is a hardware product. It contains hardware and software and the fault of Apple was in software. Most of users of AppleTV were unhappy about the product and Apple admitted the product was not good. I want to remind you that after the "take 2" was released, it was made available to users of the version 1 product and actually made it functionally almost equivalent to the version 2, which also makes it clear that the issue was not with hardware at all.

There were other major faults of Apple, I just picked one. Recall MobileMe rollout this summer, for instance. Apple has brilliant engineers, but they are not magicians. The same applies to Microsoft Mac unit. They are very good at what they are doing, but there is no reason to expect magic from them. The whole argument here is about MS Office for Mac not being functional equivalent to MS Office for Windows. First of all, I would hate it being functional equivalent (do you want that ribbon thing all over?). That will kill the product. Secondly, it is impossible. I don't want to make my long post even longer by elaborating on why it is impossible. Just take the word of the person with more than 15 years of programming experience who is leading the development of the product that has as much code as Microsoft Excel has.

[Steve_S]

robco said:

It's good that Apple uses open source code instead of always reinventing the wheel. That's the path MS is heading down and it sucks.

Well, that's just the thing. Nobody really knows what MS is doing since it's basically a closed system entirely, unlike OS X's open source foundation. For example, a few years back, Microsoft had the embarrassment of people finding traces of BSD networking code in their OS. So, in the end, we don't really know what MS has "re-invented" or what they have simply just taken without giving the proper credit. In any case, we agree that using open source where it makes sense is the way to go. Where we disagree is that you seem to trivialize that amount of OS X which was done and needs to be maintained by Apple.

Quote

If you don't like the Quartz example, how about Bonjour - Apple's implementation of zeroconf. Not all born and bred Apple. Apple does do nice implementations of many ideas.

Again, no Apple didn't create the zeroconf standard, but they did develop and need to maintain their implementation of it. When you look at zeroconf, it's essentially everything Apple did previously invent with Appletalk but using standard conventions instead. Likewise, where do you think the concept from zeroconf came from? Further, Apple actually did contribute by creating the multicast DNS portion of zeroconf. So again, I'd say... bad example. ;)

Quote

They've pulled off a great feat of taking BSD and making it user-friendly. My only point being however that not all the underlying tech is all Apple's.

Again, I agree with you point that not ALL the underlying tech is Apple's. That said, just the way you phrase that "making BSD user-friendly" sort of implies OS X is nothing more than BSD with a pretty shell on top. That's not even close to what OS X is. Just look at any breakdown of the OS X technology layers and you'll see the BSD component is just a very small piece of the overall pie. You've completely trivialized what OS X is. OS X doesn't use BSD's kernel, it doesn't have any of the higher level layers which contribute to OS X's user experience, etc. Rather, OS X does use some of BSD's services such as networking, etc. BSD's contribution to OS X isn't insignificant, but it's just one piece (of many) in OS X's design.

Quote

Unfortunately Apple's whims change. Java was one of the original programming languages for Cocoa. Now that's been deprecated and the current implementation of Java on the Mac is behind every other platform.

Apple is changing with the times. Years ago, Java was all the rage. From an object oriented developers platfrom, it's a nice language. But, Java hasn't lived up to it's promise of write once run anywhere. Java is still popular on server platforms, etc. But, in terms of GUI based development, it's not the best choice. Yes, Apple could have maintained their Cocoa bridge for Java, but in the end, it has no real advantage to Objective C. The latest incarnation of Objective C even does garbage collection, etc. Objective C based code will also perform better than Java. If you're going to be a Mac developer, you're going to have to learn the Cocoa APIs anyway.

>iSync has pretty much been an orphan since the iPhone debuted.

It hasn't really gone anywhere. It used to be a separate program, now it's part of the .Mac sync services. It's the same thing.

Quote

The point being that Apple is fickle and trying to keep up with all the new features and constant releases is tiring.

Okay, I agree with that. But, the alternative to what you're suggesting is for Apple to remain stagnant. Is that what you suggest for Apple?

If it were so easy, where are the 64-bit versions of Aperture, Logic, Shake and FCP? Apple should have rewritten them all from scratch by now. I'm not saying that Adobe and MS shouldn't adopt new technologies like .NET and Cocoa when they become available, but it's not something easily done. Everytime the code is touched, there is the chance of introducing new bugs.

I agree. But, this is just stating the obvious. Any significant modification you make to a program introduces the opportunity for new bugs. As for the apps, Shake is being completely re-written and when it's done, it won't even be called Shake anymore. It's being redesigned for both features and technology. As for the others, 64bit really wasn't ready in Tiger. Only since Leopard has been completed has this even been an option. Let's see how the next round of upgrades go.

The Mac is a nice platform for many reasons, but it does have its drawbacks. Apple is a nice company that has some talented engineers, but their products aren't perfect. Some of the decisions make it very difficult for developers who want to support the platform. Microsoft is committed to the Mac - but they also want to maintain cross-compatibilty. Likewise Adobe wants to maintain feature parity between both platforms - that means not implementing Mac-only or Windows-only features. You or I may not agree with that decision.

Agreed.

All I'm saying is cut MS and Adobe a little slack. Just because they haven't optimized every single line of code or implemented every new feature Apple has come out with (indeed, even Apple hasn't) doesn't mean they're purposely trying to screw over Mac users.

I hear what you're saying. I don't think I've given either Microsoft or Adobe a particularly hard time. I have given a hard time to those that have taken the Apple is mean / arrogant for evolving the platform and poor Adobe and Microsoft are being blind-sided by Apple's steady evolution of the platform. In particular, you tried to trivialize the effort Apple has to do in order to keep up with it's own change in direction. Similarly, while I agree each change (going to Intel, moving to 64bit) takes considerable work, both Microsoft and Adobe have made it harder on themselves by deferring the move to Cocoa until the last minute. I tried to make the point that they knew the move to Cocoa was inevitable and they've had ample opportunity to minimize the work involved, but chose not to. In the end, I don't really even hear Microsoft and Adobe complaining that loud. At best, Adobe just says sorry we missed 64bit Photoshop for CS4, we'll get there next time. It's not that big of a deal, but it is their choice to make.

[Steve_S]

aramp, in terms of effort involved, I don't think we are in disagreement. Further, part of your discussion is just going on to speculation for how we think things might be in Snow Leopard (i.e. Cocoa Finder, etc.). While it may be fascinating to speculate, it's really not helping either one of us make a point.

>AppleTV is a hardware product to the same extent as Mac is a hardware product. It contains hardware and software and the fault of Apple was in software. Most of users of AppleTV were unhappy about the product and Apple admitted the product was not good. I want to remind you that after the "take 2" was released, it was made available to users of the version 1 product and actually made it functionally almost equivalent to the version 2, which also makes it clear that the issue was not with hardware at all.

My claim was that AppleTV 1.0 wasn't a terrible product. I stand by that claim. Take 2 was more a change in direction to movie rental services than it was to "fix" anything with 1.0. I think you've missed the point of what Take 2 was all about. Is it perfect? No. Should it be terribly surprising that a 1.0 product isn't / wasn't perfect? My biggest issues are with the product's hardware limitations rather than specific software issues. That doesn't mean some people didn't have some issues with the software. However, again, is there another media extender device that really hit a home run and is perfect? I haven't seen one.

Quote

There were other major faults of Apple, I just picked one. Recall MobileMe rollout this summer, for instance.

Yes, Apple really dropped the ball with the MobileMe launch. Nobody ever said Apple was perfect or incapable of making mistakes. I've simply challenged specific examples people have chosen where it wasn't justified.

>The whole argument here is about MS Office for Mac not being functional equivalent to MS Office for Windows. First of all, I would hate it being functional equivalent (do you want that ribbon thing all over?). That will kill the product. Secondly, it is impossible. I don't want to make my long post even longer by elaborating on why it is impossible.

Functionally equivalent does not mean "exactly the same". It means that I should be able to open a document in either the Windows or the Mac version and see the same output. It also means that I should be able to apply the same general functions to the document (be it spreadsheet functions, or transitions in PowerPoint) and expect the same output for both platforms. I think you're reading too much into the meaning of functionally equivalent.

Quote

Just take the word of the person with more than 15 years of programming experience who is leading the development of the product that has as much code as Microsoft Excel has.

I can't help but find your comments somewhat condescending. While I've only done a relatively small amount of Mac development (more or less hobby type stuff), if we're comparing resumes, I have 20 years of professional IT experience. 15 years has been in development. I manage a large team of developers and analysts and am currently also working on the upgrade of an ERP system which is easily larger than Microsoft Office. So, if you're concerned that I might not follow or relate to a concept you're talking about, try me. ;)

[aramp]

Steve_S,

Let me start from the last remark of yours:

Steve_S said:

>I can't help but find your comments somewhat condescending. While I've only done a relatively small amount of Mac development (more or less hobby type stuff), if we're comparing resumes, I have 20 years of professional IT experience. 15 years has been in development. I manage a large team of developers and analysts and am currently also working on the upgrade of an ERP system which is easily larger than Microsoft Office. So, if you're concerned that I might not follow or relate to a concept you're talking about, try me. ;)

That is more than I could have hoped for. This means I don't have to prove basics that you probably know better than me. It is however pretty hard for me to figure out what we are arguing about because you stepped in the middle mainly to beat some of my points without expressing yours. :) Anyway, let me again just give my opinion on issues you touched in your last post.

>aramp, in terms of effort involved, I don't think we are in disagreement. Further, part of your discussion is just going on to speculation for how we think things might be in Snow Leopard (i.e. Cocoa Finder, etc.). While it may be fascinating to speculate, it's really not helping either one of us make a point.

Well, neither you nor me are working for neither Apple nor Microsoft (while there are some few very close friends of mine working for Microsoft, so I know more or less about matters there), so half of what we talk about here are all speculations. The value of speculations provided by experienced people is in their experience. If you and me agree that a product which has a size of MS Word, for instance, can't have its development circle less than a couple of years, that is not a speculation in general, but something learned and proved.

Quote

My claim was that AppleTV 1.0 wasn't a terrible product. I stand by that claim. Take 2 was more a change in direction to movie rental services than it was to "fix" anything with 1.0. I think you've missed the point of what Take 2 was all about. Is it perfect? No. Should it be terribly surprising that a 1.0 product isn't / wasn't perfect? My biggest issues are with the product's hardware limitations rather than specific software issues. That doesn't mean some people didn't have some issues with the software. However, again, is there another media extender device that really hit a home run and is perfect? I haven't seen one.

It was not a terrible product. Neither Vista is a terrible product. The problem is: customers don't like it. For some or other reason. Which from the company standpoint is a failure. Steve Jobs publicly admitted it was a failure. So this time it's not my speculation. I agree media extender devices are not successful but not because there is no need for such a device. But that has nothing to do with my initial point. I may have a product that only few people use, and from the marketing point of view it does not seems successful. But if these few people like the product, it is a good product anyway.

Quote

Functionally equivalent does not mean "exactly the same". It means that I should be able to open a document in either the Windows or the Mac version and see the same output. It also means that I should be able to apply the same general functions to the document (be it spreadsheet functions, or transitions in PowerPoint) and expect the same output for both platforms. I think you're reading too much into the meaning of functionally equivalent.

Agree here. However, the as you might see the extent of the equivalence is something people speculate about all the time.

One side note. There is a major difference between the way Adobe and Microsoft approach the development of their products for Mac that you most probably is aware about. Adobe has one single team developing both products (PC and Mac). In the past Mac version would come out earlier than the PC version. Later with expansion of PCs among designers they changed their mind. But still, from the very beginning Adobe Photoshop and Illustrator were actually Mac products ported to PC. Both markets are equally important for Adobe.

Microsoft tried the same approach with Word 6. They failed terribly, that's a very well known story. That's why they have established MacBU and have organized their support for Mac very differently. Now they have Windows Office team developing another version for Windows, and then Mac team porting selected changes to Mac plus doing Mac-specific development. Because starting from Word 98 Mac version was intentionally made different from PC version, these are now different products carrying the same name and sharing some source code. Further comes my another speculation, but to my understanding of matters and from what I have learned reading blogs of different MacBU people, code-wise Mac and PC versions stand apart more than, say Office 2007 compared to Office 2003.

My point here is that because Mac and PC versions of Office are so far away, from the functional requirement point of view they should at least be considered as different versions of the same product. Do we require Office 2007 to open, interpret and print all documents exactly the same way as Office 2003 did? No. That is impossible, because we all know the code has been changed, and while the team had focused on providing compatibility, 100% compatibility is impossible by the very nature of progress. If we get back to Adobe, then it is well known that while their Mac and PC products share most of the source code and are being developed by the same team, there are still compatibility issues between two products.

[Steve_S]

aramp said:

My point here is that because Mac and PC versions of Office are so far away, from the functional requirement point of view they should at least be considered as different versions of the same product. Do we require Office 2007 to open, interpret and print all documents exactly the same way as Office 2003 did? No. That is impossible, because we all know the code has been changed, and while the team had focused on providing compatibility, 100% compatibility is impossible by the very nature of progress. If we get back to Adobe, then it is well known that while their Mac and PC products share most of the source code and are being developed by the same team, there are still compatibility issues between two products.

First, I think we are in general agreement at a high level. I simply challenged some of the specific points used to make an argument in this thread. In the end, I believe it led to a healthy discussion on the topic for both of us.

With that said, I do challenge the issue you make in this last paragraph. A pet peeve I have with Office is the lack of compatibility with documents between platforms, particularly PowerPoint. I believe this is due to a design flaw with regards to the Mac BU's approach to ports. For starters, Adobe doesn't have the same problem, nor do most companies that offer multi-platform products. On one hand, I agree with your point about the Word 6 approach not working. Yes, I remember that. But, are we blaming the execution or the concept here? I blame the execution. Allow me to explain...

Mac users do want products that feel like a Mac product. I agree with you that Office 98 was a great product. It was probably Microsoft's best effort of making a Mac-like product to date. I certainly agree that a Mac product shouldn't adopt Windows conventions. Windows users don't like Mac conventions (i.e. iTunes, Safari on Windows) just as Mac users don't like Windows conventions on a Mac product. However, without seeing Microsoft's code, I would have to guess that Microsoft does not do a good job of separating the layout engine from the rest of the code. If that's not the case, then the Mac BU is really dropping the ball in terms of execution as they must be introducing new discrepancies somewhere in the presentation layer. Anyway, back to the point, I see no reason that the layout engine (that which parses the document, makes rule based decisions on how to lay the document out, etc.) shouldn't be exactly the same across platforms. The rest of the product should be different in order to keep the "native" feel of the product. If I open a Photoshop or Illustrator or (Safari for that matter) on one platform, I'm very confident it will open the same on the other platform. Microsoft wasn't able to pull this off with IE when they made it for the Mac and they can't do it with PowerPoint. Word and Excel are in somewhat better shape, but not perfect replications either (from my experience).

In summary, while I do agree with much of what you're saying, there are specific examples such as the one above where I disagree with you and I struggle to see how you can defend this position. If you have contacts with the Mac BU, I would be interested in hearing their perspective with regard to why the layout engine is apparently different. I know that IE used a different engine (by name at least) between the two platforms. Again, why? Clearly, that was not and is not a good idea. Using a common layout engine does not preclude a unique platform specific look and feel.

[Grapho]

Let me butt my head in here only to make one point.
Power Point on the Mac, when it opens a Windows PP file, it will immediately attempt to translate the graphics from WMF to PICT. The problems that I see are two serious ones. First WMF can contain vector information while PICT is an strict raster image format and this translation is not always accurate. It eliminates the advantage of a vector format being resolution independent. Why not simply implement the WMF with in Office as the a stander. Adobe Illustrator has full support for this format on both platforms, so I don't see what the problem might be.

[aramp]

Steve_S,

I agree with you that the underlying technology layer should have the same code shared between platforms, the same way, as, for instance, Firefox is built. However, to my understanding of matters, that will not guarantee the compatibility. Especially for Office. Let me share my thougths on that and see if you agree or not.

Text rendering might either be done by the application itself or might involve the underlying OS services. It is well known that Adobe Illustrator does not use the OS font rendering. That makes it easy to provide compatibility but also has its drawbacks. As far as I know, MS Office products do use Mac OS font rendering, but then they do some twicks. So basically even on the font level there is already compatibility gap that is hard to close. Further on there is another issue. Mac and PC versions of Office went different ways after Office 98 for Mac. As a result the development team has an obvious problem to choose which one of compatibilities is the most important. Should they care about the user who have just upgraded from Office 2004 to Office 2008 and provide compatibility between two Mac versions, or they should focus on making Office 2008 compatible with Office 2007 for Windows. That's a tough question not easily answered. Both approaches have their pros and cons.

Another issue I believe is that Office for Windows is too much integrated into Windows itself. That is a drawback of being a company that does both applications and OS. Microsoft is constantly blamed for that, but how can you help using the knowledge that is just one e-mail away? I think that as Office 98 was separated in Mac BU, the main office team felt itself free from any obligations to care of Window-independece of their code. We are now experiencing results of that approach.

[aramp]

Grapho said:

Let me butt my head in here only to make one point.
Power Point on the Mac, when it opens a Windows PP file, it will immediately attempt to translate the graphics from WMF to PICT. The problems that I see are two serious ones. First WMF can contain vector information while PICT is an strict raster image format and this translation is not always accurate. It eliminates the advantage of a vector format being resolution independent. Why not simply implement the WMF with in Office as the a stander. Adobe Illustrator has full support for this format on both platforms, so I don't see what the problem might be.

I hope the new GM of Microsoft will have a look at the comments on his first public interview. And who knows, it might happen that he or other person in Mac BU will reply to your question somewhere in one of their blogs.

[Steve_S]

aramp said:

I agree with you that the underlying technology layer should have the same code shared between platforms, the same way, as, for instance, Firefox is built. However, to my understanding of matters, that will not guarantee the compatibility. Especially for Office. Let me share my thougths on that and see if you agree or not.

This was a good discussion. I think we're basically on the same page now.

Quote

Text rendering might either be done by the application itself or might involve the underlying OS services. It is well known that Adobe Illustrator does not use the OS font rendering. That makes it easy to provide compatibility but also has its drawbacks.

It really depends on the application. You could argue that it's probably not a big deal for Excel if the layout is exactly the same. But, for Word and PowerPoint, it's probably a bigger deal. For something like InDesign, it's absolutely critical, which is why Adobe uses it's own display engine for both Windows and Macs. Apple's done the same with Safari. Google took a different approach. They use Webkit for the layout, but use Microsoft's Cleartype for text, etc. For a web browser, just using Webkit is probably enough in my opinion. Still, this stands in strong contrast to Microsoft's philosophy. When Microsoft did support a Mac browser, it had a distinctly different rendering engine from it's Windows counterpart (Tasman vs. Trident).

>As far as I know, MS Office products do use Mac OS font rendering, but then they do some twicks. So basically even on the font level there is already compatibility gap that is hard to close. Further on there is another issue. Mac and PC versions of Office went different ways after Office 98 for Mac. As a result the development team has an obvious problem to choose which one of compatibilities is the most important. Should they care about the user who have just upgraded from Office 2004 to Office 2008 and provide compatibility between two Mac versions, or they should focus on making Office 2008 compatible with Office 2007 for Windows. That's a tough question not easily answered. Both approaches have their pros and cons.

Yes, I agree they face challenges and decisions to make. However, I question whether the right choices were made. Microsoft acknowledged Office 6 was a blunder and made a distinctly Mac specific product for Office 98. That's all well and good, but I'm not sure that I buy that it has to be so far one way or the other. I would guess that layout engines in Office are not well separated (layered) from the rest of the code. Likewise, it may well be nearly impossible for the Mac BU to do both compatibility and still keep a Mac look and feel. However, I contend that it should be possible. Modularizing your code in such a way is a good programming practice. This makes for a better architecture that is more easily supported, more reliable and more easily ported to other platforms. If this is the case, I would hope the Mac BU would be able to influence future builds of Office on the Windows side.

Quote

Another issue I believe is that Office for Windows is too much integrated into Windows itself. That is a drawback of being a company that does both applications and OS.

Possibly. But, again, it comes down to whether or not you have a good overall architecture or not. If the Office product is that attached to Windows, then Microsoft has more problems on its hands that they know. By contrast, both Safari and iTunes make pretty good use of OS X specific features. Yet, Apple is able to port them to Windows. If that means that Quicktime has to come along for the ride, then perhaps Microsoft may have to do the same in order to maintain compatibility. Personally, I think Apple takes it to far by making the Windows application's skins look a little to Mac like, but that's a design choice by Apple, not a technical limitation in any way.

>Microsoft is constantly blamed for that, but how can you help using the knowledge that is just one e-mail away? I think that as Office 98 was separated in Mac BU, the main office team felt itself free from any obligations to care of Window-independece of their code. We are now experiencing results of that approach.

Agreed. Overall, Office is a good product on the Mac. But, not only do you have Mac users that realize they are missing features, but Ballmer himself has thumbed his nose and said that you're not getting the real Office on the Mac. He's very much aware that the Mac product isn't nearly as feature complete as the Windows product. Worse, is that he uses that as some sort of competitive advantage. I don't see Apple or other companies doing that (okay with the possible exception of Intuit, etc.).

My point is that I think Microsoft probably does have architecture issues to address with Office. To some degree, you touched on this as well by indicating how you believe Office is integrated into Windows to much. Of course, we're both speculating, but that's the only reasonable answer for the disparity of products that we have today. It's also obvious that Microsoft knowingly keeps the Mac product at a level lower than the Windows version for competitive reasons. Finally, where consistent output is important, a common layout engine needs to be used. Other vendors understand this (like Adobe and Apple, etc.). Yes, there may be some tradeoffs with this approach, but if layout matters, then compatibility is of great importance. I don't think Microsoft agrees with or possibly even understands this.

[Steve_S]

Grapho said:

Let me butt my head in here only to make one point.
Power Point on the Mac, when it opens a Windows PP file, it will immediately attempt to translate the graphics from WMF to PICT. The problems that I see are two serious ones. First WMF can contain vector information while PICT is an strict raster image format and this translation is not always accurate. It eliminates the advantage of a vector format being resolution independent. Why not simply implement the WMF with in Office as the a stander. Adobe Illustrator has full support for this format on both platforms, so I don't see what the problem might be.

I don't doubt this is true, but don't know for certain one way or the other. However, from my experience, the compatibility issues aren't just limited to graphics. Even with text/fonts, there are major display compatibility issues. The bottom line is that I should be able to create a PowerPoint presentation on a Mac, then display it on PC (or vice versa) without experiencing major layout issues. I've tried many times and this just isn't possible. I shouldn't have to consider PDF options, etc. in order to accomplish something like that. I believe it would be in Microsoft's best interest to keep their Office formats relevant. If Office formats become an intermediate format, then they're in trouble. We're not there yet, but it's not hard to imagine the day.

[Grapho]

I totally agree. My problem, and this is by no means exclusive to Power Point is that people use all the Office suite applications for the wrong purpose. I as a print service provider, I am forced to deal with what ever format my clients dish out to us. We can attempt to educate them but at the end we pretty much are left dealing with it. The only sure proof way I have found is to open all of MS Office documents with a Windows version of Office, from their we create a PDF that can be print ready, at least for a 4 color workflow. Spot color can be a lot more troublesome.

Now, even if the document was created on a Mac, Mac Office print engine does not posses the ability to accurately produce a postscript file that can be distilled in to a print friendly PDF format (It leaves the color space in RGB, which in printing can be a big problem specially black text). I find this very onerous and I can't help to think that this is totally done on purpose to simply undermine the Macintosh as far as dealing with Microsoft Office files in a print service provider setting.

Sure, we can argue that the applications where never designed for professional print output, but then, why does is work on Windows so well and it is so badly implemented on the Mac?

[aramp]

Steve_S said:

My point is that I think Microsoft probably does have architecture issues to address with Office. To some degree, you touched on this as well by indicating how you believe Office is integrated into Windows to much. Of course, we're both speculating, but that's the only reasonable answer for the disparity of products that we have today. It's also obvious that Microsoft knowingly keeps the Mac product at a level lower than the Windows version for competitive reasons. Finally, where consistent output is important, a common layout engine needs to be used. Other vendors understand this (like Adobe and Apple, etc.). Yes, there may be some tradeoffs with this approach, but if layout matters, then compatibility is of great importance. I don't think Microsoft agrees with or possibly even understands this.

I mostly agree with your points. Yes, it looks like Microsoft is managing a complex situation. On one hand, Office for Windows assures constant demand for Windows. On the other hand, there is a second real platform, Mac OS. It is a competing platform, but not to the extent that might seriously challenge Microsoft's domination. Still, there is a danger coming from that platform: it needs office productivity suit. If not from Microsoft, then from someone else. However, Macs are used wide enough to create enough income for that someone else, effectively providing a chance for a serious competition to arise. That's why it is strategically important to keep MS Office for Mac, and keep it competitive enough. That's a goal. Of course such a goal can't motivate a whole team, that's why Mac BU team works with best intentions in their minds, being assured that they are allowed to do anything. Many people, btw, believe that MS Office for Mac is actually better than its Windows counterpart. To a some extent I tend to agree with them: after using Mac version for some time I really hate to use Windows version. Probably because I don't need full compatibility actually. For my everyday business needs the compatibility level it provides is OK with me. Actually the only reason why I have to run Windows time to time is lack of macros and OLAP support in MS Excel for Mac.

[Steve_S]

aramp said:

>On the other hand, there is a second real platform, Mac OS. It is a competing platform, but not to the extent that might seriously challenge Microsoft's domination. Still, there is a danger coming from that platform: it needs office productivity suit. If not from Microsoft, then from someone else. However, Macs are used wide enough to create enough income for that someone else, effectively providing a chance for a serious competition to arise. That's why it is strategically important to keep MS Office for Mac, and keep it competitive enough.

Fortunately (for both Apple and Microsoft), Office has apparently been a profitable venture on the Mac platform. Office 2008 is apparently doing very well, despite it's obvious VB Script limitations. Ten years ago, having MS office available for your platform was almost a life or death situation. Without it, your platform didn't stand a chance of surviving. Ten years later, I think people are realizing that not much has changed in the Office productivity suite genre in years. Many are also realizing that they don't actually need the MS brand of Office. There have always been some alternatives (like Mariner Calc, Write, etc.), but iWork on the Mac is actually evolving quite well. Keynote is best in class. While Word still has a few advantages, it has actually been playing catchup to Pages' layout capabilities. Obviously Excel is quite a bit ahead of Numbers, for that should be expected for a 1.0 product. In another 2 or 3 iterations, Numbers may actually pose a real challenge for Excel. Combine that with the availability of OpenOffice across multiple platforms, including Linux. Also, consider the proliferation of newer web based content from Google Docs and others. Suddenly, MS Office becomes less relevant. One thing is for certain, MS can no longer command the same high prices for the product as it once did.

>That's a goal. Of course such a goal can't motivate a whole team, that's why Mac BU team works with best intentions in their minds, being assured that they are allowed to do anything. Many people, btw, believe that MS Office for Mac is actually better than its Windows counterpart. To a some extent I tend to agree with them: after using Mac version for some time I really hate to use Windows version. Probably because I don't need full compatibility actually. For my everyday business needs the compatibility level it provides is OK with me. Actually the only reason why I have to run Windows time to time is lack of macros and OLAP support in MS Excel for Mac.

Yeah, that makes sense. Like you, I prefer to do work in my Mac environment. By virtue of running as a native Mac application, it's not hard to see why many prefer it. In reality, that doesn't mean I believe it has feature parity with the Windows version of the product I use. I work in a Windows environment all day and I tend to use Office more at work than at home. In the end, this brings us back to the frustration we initially spoke of. When I conduct large team meetings, I often present with PowerPoint. I would love to be able to create that presentation at home and just bring it to work to be used on Windows. Unfortunately, I can't do that without significant manipulation. Ideally, it would be great if Apple would port Keynote to Windows, but that's another story. I don't have as much trouble with Word, but often, I do get spreadsheets that don't work properly on the Mac version, especially now that VB Script is gone.

While I think it's great that the MacBU team is creating a nice custom Mac application, I'm not sure I agree with their design goals. Who is the Mac target audience? Do they think Mac users are creating content for their own Macs only? I think the assumption should be that we Mac users need to also open and modify Windows versions of the same documents, apply the same functions and get consistent output. Anything less than that for a design goal is a failure in my opinion. We already have applications that give us 90% compatibility with Office. From a Microsoft Mac product, I expect 100% compatibility. Isn't that what we're paying for?

[aramp]

Stieve_S,

iWork is not a threat to Microsoft, because it is Mac only. It is made on Cocoa and Cocoa is Mac only by design. It is also hard to imagine the reason why Apple might want to port it to other platforms. OpenOffice is terrible. At some point I was considering to replace MS office in some scenarios with OpenOffice. That did not work. The word processor in OpenOffice is more or less usable,Calc is a nuisance compared to Excel, Impress is impossible to use, other apps in the package are toys.OpenOffice might be reasonably good at home, but in the office environment saving does not pay off. So I don't see any real factor that might change the status quo in the nearest 3-4 years. We'll see what comes after.

As to PowerPoint compatibility, I agree there are issues. What I have learned from my experience with presentations, most problems are related to fonts not available at another machine. In Windows it is easy to fix: Microsoft has developed a technology called "font embedding", so you may keep all the fonts you need with the presentation. There is no such technology on Mac. So Mac PowerPoint files do not carry any fonts. PowerPoint on Mac has to use Mac OS X font rendering engine, it works differently from Windows font rendering. That is not that visible with regular text, because in the regular text average paragraph allows for the text to extend or shorten a little bit. But when the text size is large, problems arise: most of the times there is no space to extend into. Because Mac OS X renders the same TrueType font differently, PowerPoint for Mac and PowerPoint for Windows display the same text differently. That is a major issue.

Microsoft tried to take care compatibility issues by introducing a special compatibility check. Any time you plan to use the file on Windows or previous versions of Office, it is advised to check the compatibility. It helps, but not always.

It is important to understand that Adobe's approach is not possible for Microsoft. Adobe does have its own font rendering engine. That it because they invented vector fonts, PostScript and PDF. If you remember, there was a long perioud of time when Adobe had a special application that provided PostScript font capabilities for both Macs and Windows. So all Adobe products share the same code that renders fonts on different platforms. However, you might notice that Adobe PDF viewer shows the text differently from the Preview. That might be OK for PDF. But for regular productivity applications that work with regular documents such approach does not work.Users are used to how fonts are rendered in Mac OS X, they are used to Mac-specific view of Arial, Times New Roman and other popular fonts. They would heavily object to see the same font totally differently in Word or Excel. As a matter of fact, that would create another anti-Microsoft storm. Besides, to render Adobe Postscript fonts Microsoft uses code licensed from Adobe for Windows only. So porting Windows font engine to Mac is not possible.

You have provided an example of Safari working the same way on Windows and Mac. Safari uses WebKit that is initially portable, so Apple has to actually port the shell only. However we all know there were initially many problems with Windows rendering of WebKit that were fixed on the way. And still, if you compare how the same HTML is displayed by the same WebKit on Windows and on Mac, you will find differences. That boils down to the same font rendering differences on Windows and Mac.

My point is: compatibility is important, no doubt. But 100% compatibility is not possible in this case. There will always be discrepancies due to different OSes. Personally I am happy that Microsoft has chosen to separate Mac and Windows office development. When comparing upsides and downsides of that, I think we come up with more upsides.Separate focused team is better than one team having primary and important platform and secondary and unimportant. Adobe, as I have noticed before, is in the different position. For pro design applications their Mac business is comparable to Windows business for historical reasons.