Re: Micro$haft desperate! Buy Windoze 7, get (virtual) XP free!

"GreyCloud" <cumulus@xxxxxxxx> wrote in message news:0bSdnS3xTeJ8s2LUnZ2dnUVZ_tydnZ2d@xxxxxxxxxxxxxx
Dan Johnson wrote:
And when you port UNIX programs over to another certified UNIX os is a fairly straightforward process. Stating that it is hard is dishonest.

Good thing I didn't say that, then! :D

It is. Because XCode docs show that much isn't needed to be done.

XCode docs? So the Unix certification Apple got is useless, we can tell it's compatible by looking it up in the XCode online help?

It all rests between BSD and SYSV.

"Between" BSD and System V? What does that mean?

And the differences will require one to have a good book on his desk top to show those minor differences
such as "Advanced Programming in the UNIX Environment".

Oh, not *that* again!

[snip]
Carbon is the base in which NS APIs are built from in regards to graphics.

No, this is wrong too. Cocoa uses CoreGraphics, and that's not the same thing. Carbon does have its own graphics layer, but it is QuickDraw and it's deprecated.

No, I'm actually getting this information from "OpenGL Programming on Mac OS X".
Since Tiger, this is now what is happening with Carbon. And CoreGraphics is layered on top of Carbon.

You are confusing Core Foundation with Carbon again.

Of course Quickdraw is deprecated, but it is still there for those that have a personal interest in it.

A "personal" interest? Do we need to move this conversion to the alt.* hierarchy?

[snip]
One has choices in which to use, but all of them are based on Carbon.

This isn't true.

Guffaw!!! Again you are wrong. Go read the above mentioned book first and then you'll see how things work.

I very much doubt that "Advanced Programming in the UNIX Environment" is going to tell me a whole lot about Carbon.

[snip]
I realize I'll get nothing but blank denials from you, but I think this point is telling. Nobody else uses UTF-8 like this. It's all UTF-16, really, except a few oddballs who prefer UTF-32. But never UTF-8 by choice. It's something you do because you have to deal with Unix's limitations.

Guffaw!!! Yet I'm posting from Solaris 10 that does use UTF-8 and very extensively.

Because it is Just Another Unix. But consider that in spite of this very fact- Java uses 16-bit Unicode. It was a new API, and there was no reason that they couldn't do it right. So they did it right.

It's especially telling in this case, since doing it this way favored Microsoft Windows: Java on Solaris has to translate to UTF-8, but on Windows it doesn't need to do that.

[snip]
It's not that Sun couldn't add 'widened' APIs; it's just that nobody would use them, because those would be Solaris specific. Unix is so fragmented that being non-portable like that is usually unacceptable.

No, nothing of the sort. You are making up more disinformation.

OK, simple example. I've got a UTF-16 string that contains a filename, and I want to open the file. On Windows, I might call 'wfopen', Microsoft's widened version of fopen. What do I do on Solaris?

The best answer is "use Java", of course. But suppose I have to use C...

[snip]
Apple is *not* using the Unix approach of 'utf-8 locales'; the old Carbon APIs still take Mac OS Roman or whatever.

Which is unicode btw. You're still making up imaginary problems here.

Mac OS Roman is most certainly not Unicode. But Carbon does have first-class support for Unicode through its upgraded APIs.

And yet it works well.

It does, because Apple did this properly. Upgraded APIs in Carbon, for one thing.

The same on Solaris, AIX, SCO, etc.
It is just the windows developers that have problems with unicode porting from UNIX.

It's Unix developers who don't quite 'get' Windows that have trouble doing that. They often assume they have to use the POSIX APIs, and work around their limitations. In fact, you should target Windows using Windows own APIs, and not have to work around.

And that also applies to OS X. You should target the native APIs. It is just better so.


.

Relevant Pages

  • Re: Snow Leopard: A 64-bit Observation
    ... I admit to not knowing how Mach is different from other Unix ... have to turn to Carbon here and there. ... but on 32 bit Windows each bit has to watch *two* squares! ... for example (but not Photoshop). ...
    (comp.sys.mac.advocacy)
  • Re: Micro$haft desperate! Buy Windoze 7, get (virtual) XP free!
    ... Because XCode docs show that much isn't needed to be done. ... So the Unix certification Apple got is useless, we can tell it's compatible by looking it up in the XCode online help? ... Carbon does have its own graphics layer, but it is QuickDraw and it's deprecated. ... Microsoft Windows: Java on Solaris has to translate to UTF-8, but on Windows it doesn't need to do that. ...
    (comp.sys.mac.advocacy)
  • Re: Micro$haft desperate! Buy Windoze 7, get (virtual) XP free!
    ... Yeah, but the Mac ecosystem is not based on Unix ports, but on original Mac software. ... Carbon is the base in which NS APIs are built from in regards to graphics. ... Carbon does have its own graphics layer, but it is QuickDraw and it's deprecated. ... They introduced a new set of parallel Carbon APIs that take CFStrings instead of 'char *'; these new APIs accept Unicode text. ...
    (comp.sys.mac.advocacy)
  • Re: Connecting to the Internet
    ... > APIs was a lot easier than learning Registry APIs.) ... be installed in all versions of Windows that you choose to support. ... I hope you don't mind me saying you have "missed the boat". ... Vague questions such as that are often ignored in Microsoft newsgroups ...
    (microsoft.public.vb.winapi)
  • Re: I really do like OS X but . . .
    ... >features and APIs included in 2000 and XP. ... >still lots of code on Windows that was originally written for Windows ... >> support perspective too. ... which G5s do fairly well at despite the poor optimizations. ...
    (comp.sys.mac.advocacy)