it'll also put the OK and Cancel buttons the right way around.
Well,it'll allow toolkits to put them the right way around for the desktop you're on - version 1.6 of the API doc has a ButtonOrder() API to let a toolkit determine the appropriate button order for the desktop on which it's running.
If that's not what you consider the right way around, either switch to a desktop that puts them in the order you want, try to get your preferred desktop to put them in the order you want, or try to get them to offer an option to control the button order. Portland doesn't exist to standardize the look and feel of desktops, it exists to allow applications written for one desktop to work better on other desktops.
...it'll be a matter of which widget set you prefer. The api's, however, will be identical for both!
By "widget set" are you referring to the way the widgets you see on the screen appear and behave, or to the actual toolkit (GTK+/Qt/etc.) and higher-level (GNOME/KDE/etc.) APIs?
If the latter, the APIs definitely will notbe identical. If the former, they still won't be identical; GTK+ and Qt and... will still exist, it's just that certain desktop environment operations that involve data outside the application itself (e.g., your desktop, your Start^W{foot,K} menu, your preferred applications for particular file types, etc.) can be performed in a way that works with all desktop environments that support Portland. Those will be the only APIs that will be "identical" - and it might be that there will be, in some cases, different KDE/GNOME/etc. APIs that use the Portland APIs, if, for example, there already exist KDE/GNOME/etc. APIs to perform those functions (in what would presumably be a way that only works on the desktop in question).
No, not unless CDE adopts it, which is probably pretty unlikely at this point (I'm not sure anybody's actively developing it).
However, the press release nonwithstanding, this is not intended solely to be used by KDE and GNOME; the FAQ lists XFCE as another probable supported desktop environment.
Mine is Dont have selection boxes with just yes no and canel on them, make them more informative such as is in linux, ie Save File and Discard, Don't Close and Save.
...which was, I think, recommended by Apple before being popular on other systems. (See "Buttons for addressing the alert".)
Then again, even one of Microsoft's HIGs suggests that, albeit not as strongly (look for "Dialog Box Commands"). For that matter, so does the Vista HIG (look for "Use positive commit buttons").
The x86 takes a virtual address and translates with with the paging unit to a linear address, then the segmentation unit (theoretically) does another translation on that to give a physical address.
Other way around. The segmentation unit takes a 16-bit segment number and 32-bit segment offset and translates it to a 32-bit linear address, then the paging unit translates it to a physical address.
I mean, all of the vastness of the cosmos, and yet we're the best it has to offer?
That's just a theory, not a fact. We've seen very little of the "vastness of the cosmos", so we're in no position to claim that we either are or aren't "the best it has to offer".
And he wasn't just talking about a generic being "greater than man",he was specifically talking about the God of the Bible, for whose existence I've seen no good evidence.
Between 20 - 40% of your compiled code is spent moving data in and out of the accumulator register, since most instructions depend on specific data being in that register - to the point that they introduced zero-cycle add/mov functionality in the P4 line
Got any numbers to back up that "most" claim? Or by "the accumulator register" and "that register" do you really mean "any of the 8 GPRs"?
their chosen supplier, Intel, didn't have any notebook-oriented processors until now
Oops, I meant "notebook-oriented 64-bit processors".
And one point I didn't think of until just now:
Even if either Intel had notebook-oriented 64-bit processors available in January 2006 or Apple decided they didn't need to go Intel in the ntoebooks, and they had all the libraries and frameworks 64-bit clean in Tiger, going 64-bit-only for the Intel machines would have required developers doing Universal apps not only to ensure that their code is byte-order clean but also to ensure that it's 64-bit clean even if it doesn't need to be 64-bit - and, again, for apps that are truly "universal", as in "will run on all machines that support Tiger", there will have to be a 32-bit PPC version, so it's not as if they'd get to abandon 32-bit code.
Re:Apple opted for poor quality when they chose In
on
Apple's Growing Pains
·
· Score: 1
I haven't measured the heat out the fans from the machines with a thermometer, but it is a *substantial* difference. The Xeons are definitely hotter.
And those are 51xx-series Xeons? (If they're not, those aren't the same processors as the ones Apple's using; they're probably NetBurst Xeons, and much of the reason for the switch to the Intel Core Microarchitecture(TM)(R)(LSMFT) was to cut power consumption and heat output.)
The biggest problem I have with the apple transition was that they had a 32-bit intel architecture that now must be supported for years to come. I honestly am not quite sure why they did that, as there will undoubtably be some support headaches for apple developers for the next few years.
Probably because
their chosen supplier, Intel, didn't have any notebook-oriented processors until now, and they wanted an Intel speed kick for the pro notebook;
they already had a 32-bit architecture (32-bit PPC) that'll have to be supported for a while, so developers would have to support 32-bit code anyway unless they want to support only Power Mac G5's and Xserve G5's;
the OS X available at the time, Tiger, only had a small number of "fat" libraries, so GUI code, or any other code using Apple frameworks, couldn't be 64-bit (so developers who don't want to support 32-bit code don't have much in the way of capabilities their apps could make use of), and making all the frameworks 64-bit clean is probably a non-trivial effort (note that it's not happening until Leopard).
The reason people are stuck with in 32-bit mode is lack of software support, and 64-bit intel macs from the start would have changed that..
From your use of "would have", I presume you mean "64-bit Intel Macs running Tiger" rather than "64-bit Intel Macs running Leopard". Are there a lot of 64-bit apps for the PowerMac G5 and Xserve G5? (Tiger doesn't support 64-bit apps using much more than libSystem; no 64-bit GUI code, for example.)
That would either mean that they'd be running Tiger, in which case you'd have the same limitations as on the G5 machines (no GUI in 64-bit code, so you'd have to split the app between a 32-bit front end and a 64-bit back end), or Leopard, in which case "the start" would have been Spring 2007.
As it is, I'm sure they're stuck running in 32 bit mode for 'compatibility' reasons.
If you're "sure", presumably you just got your Mac Pro and tried building a 64-bit app and checking whether it had a >4G address space and 8 more registers to play with, and found the answer was "no", right? (Otherwise, you can't be "sure" - you're just guessing.)
Are there any other improvements in 64 bit CPUs other than the larger memory ceiling?
In the case of 64-bit x86 CPUs, there are 8 more registers for the compiler to use. (That's not true of any other 32->64 architectural changes I know of; those were either RISC architectures that already had 31 or 32 registers, or System/3x0 which already had 16 registers.)
The Intel® Core(TM) 2 Duo processor for desktop PCs began shipping during the quarter ahead of its formal launch July 27 and has already set performance records
across dozens of industry-standard PC performance tests. The mobile PC version of the Intel Core 2 Duo processor is also shipping now, one month ahead of schedule.
It was a yawn-fest for developers too, you know. Apple would have been better served by just keeping their mouth shut until they could actually talk about their "super-secret" features.
From a developer's point of view, that's what the WWDC sessions are for.
Slashdot Mirror
Well,it'll allow toolkits to put them the right way around for the desktop you're on - version 1.6 of the API doc has a ButtonOrder() API to let a toolkit determine the appropriate button order for the desktop on which it's running.
If that's not what you consider the right way around, either switch to a desktop that puts them in the order you want, try to get your preferred desktop to put them in the order you want, or try to get them to offer an option to control the button order. Portland doesn't exist to standardize the look and feel of desktops, it exists to allow applications written for one desktop to work better on other desktops.
By "widget set" are you referring to the way the widgets you see on the screen appear and behave, or to the actual toolkit (GTK+/Qt/etc.) and higher-level (GNOME/KDE/etc.) APIs?
If the latter, the APIs definitely will notbe identical. If the former, they still won't be identical; GTK+ and Qt and... will still exist, it's just that certain desktop environment operations that involve data outside the application itself (e.g., your desktop, your Start^W{foot,K} menu, your preferred applications for particular file types, etc.) can be performed in a way that works with all desktop environments that support Portland. Those will be the only APIs that will be "identical" - and it might be that there will be, in some cases, different KDE/GNOME/etc. APIs that use the Portland APIs, if, for example, there already exist KDE/GNOME/etc. APIs to perform those functions (in what would presumably be a way that only works on the desktop in question).
No, not unless CDE adopts it, which is probably pretty unlikely at this point (I'm not sure anybody's actively developing it).
However, the press release nonwithstanding, this is not intended solely to be used by KDE and GNOME; the FAQ lists XFCE as another probable supported desktop environment.
Perhaps, but a third popular desktop platform has two of them - Carbon and Cocoa. (I assume Windows is one of the two; what's the other one?)
No, because that's just a window manager, not a full desktop environment. Perhaps you meant to say "You mean, like, CDE?"
...which was, I think, recommended by Apple before being popular on other systems. (See "Buttons for addressing the alert".)
Of course, "on Linux" in this context really means "in GNOME" or "in KDE" or ..... The GNOME Human Interface Guidelines make the same suggestion about button labels, which I think they took from the OS X HIG. The KDE HIG also suggests buttons with verbs. I don't know what other DEs or toolkits recommend (if anything) or support.
Then again, even one of Microsoft's HIGs suggests that, albeit not as strongly (look for "Dialog Box Commands"). For that matter, so does the Vista HIG (look for "Use positive commit buttons").
Paragraph breaks? From the dude who wrote Molly Bloom's soliloquy? Surely you jest.
Other way around. The segmentation unit takes a 16-bit segment number and 32-bit segment offset and translates it to a 32-bit linear address, then the paging unit translates it to a physical address.
Not by themselves, they didn't.
That's just a theory, not a fact. We've seen very little of the "vastness of the cosmos", so we're in no position to claim that we either are or aren't "the best it has to offer".
And he wasn't just talking about a generic being "greater than man",he was specifically talking about the God of the Bible, for whose existence I've seen no good evidence.
Because it's not a fact, it's just a theory, and one for which I haven't seen any good evidence.
...but imul doesn't - one of the remaining irregularities.
Got any numbers to back up that "most" claim? Or by "the accumulator register" and "that register" do you really mean "any of the 8 GPRs"?
Oops, I meant "notebook-oriented 64-bit processors".
And one point I didn't think of until just now:
Even if either Intel had notebook-oriented 64-bit processors available in January 2006 or Apple decided they didn't need to go Intel in the ntoebooks, and they had all the libraries and frameworks 64-bit clean in Tiger, going 64-bit-only for the Intel machines would have required developers doing Universal apps not only to ensure that their code is byte-order clean but also to ensure that it's 64-bit clean even if it doesn't need to be 64-bit - and, again, for apps that are truly "universal", as in "will run on all machines that support Tiger", there will have to be a 32-bit PPC version, so it's not as if they'd get to abandon 32-bit code.
And those are 51xx-series Xeons? (If they're not, those aren't the same processors as the ones Apple's using; they're probably NetBurst Xeons, and much of the reason for the switch to the Intel Core Microarchitecture(TM)(R)(LSMFT) was to cut power consumption and heat output.)
Probably because
...and ran them as 32-bit systems. Tiger was the first Mac OS X release to support 64-bit code.
MIPS IV has 64 GPRs? MIPSco disagrees with you:
(No, MIPS I through III didn't have 16 GPRs.)
From your use of "would have", I presume you mean "64-bit Intel Macs running Tiger" rather than "64-bit Intel Macs running Leopard". Are there a lot of 64-bit apps for the PowerMac G5 and Xserve G5? (Tiger doesn't support 64-bit apps using much more than libSystem; no 64-bit GUI code, for example.)
That would either mean that they'd be running Tiger, in which case you'd have the same limitations as on the G5 machines (no GUI in 64-bit code, so you'd have to split the app between a 32-bit front end and a 64-bit back end), or Leopard, in which case "the start" would have been Spring 2007.
If you're "sure", presumably you just got your Mac Pro and tried building a 64-bit app and checking whether it had a >4G address space and 8 more registers to play with, and found the answer was "no", right? (Otherwise, you can't be "sure" - you're just guessing.)
In the case of 64-bit x86 CPUs, there are 8 more registers for the compiler to use. (That's not true of any other 32->64 architectural changes I know of; those were either RISC architectures that already had 31 or 32 registers, or System/3x0 which already had 16 registers.)
Wouldn't that be more like
mov edx, [arg_d]
mov eax, [arg_c]
sub edx, [arg_e]
add eax,[arg_b]
imul eax, edx
(one instruction fewer)given that x86 supports memory-to-register arithmetic ops?
Intel announced both desktop (Conroe) and laptop (Merom) processors on July 27, 2006,and said in their recent earnings release that
From a developer's point of view, that's what the WWDC sessions are for.
He probably meant x86, but that's not exactly "new" as in "it just happened" - XCode has supported x86 for a while now.
"Currently", yes, but the XCode 3.0 page says "Many such Xray instruments leverage the open source DTrace, now built into Mac OS X Leopard."