OS X does enough odd stuff with processes that I'd not be shocked in fork() had a bunch of extra process-related overhead that pthread() does not.
Heck, it'd not be shocked if fork() on Linux had extra overhead that pthread_create() didn't. It might, for example, be duplicating the address space; fork() is copy-on-write (on most if not all UN*Xes, including OS X and Linux) so that the data in the address space doesn't get copied, but the address space data structures might have to be duplicated, and resident writeable pages would have to get marked non-writeable in the MMU so that an attempt by parent or child to store into them would provoke a copy.
And bugs aren't unusual. It is the cost you pay when you use microkernel.
As opposed to monolithic kernels, where bugs are unusual?
BTW, there's not much "microkernelish" about OS X; it's not as if the kernel's spending lots of time sending messages to random server processes to implement every system call - that code path is a Boring Old Monolithic Kernel code path.
Also things fails like Kernel Panic which both the different OSX BSD and Linux kernels technologies are prone to do.
Yes, but neither of those systems are prone to blue screen halts. (Well, I don't think Linux's panic screen is blue.)
(I.e., the terminology might be different in NT, but the concept exists. Statistics on how often particular Linux kernel releases, OS X releases, and NT (including NT 5.x) releases die in the kernel might be interesting.)
The first release had a layered microkernel organization. However, this version delivered low performance compared with that of Windows 95. Windows NT 4.0 partially redressed the performance problem by moving layers from user space to kernel space and more closely integrating them.
The main movement I know of was moving the low-level graphics code from the Win32 subsystem server to a kernel-mode driver. File systems, network stacks up to the transport layer, and storage and network drivers were already in kernel-mode code.
It's perhaps a bit more microkernel than, say, OS X (I think some amount of process creation and image launching, and opening files, are done by the Win32 subsystem, although I think file and network I/O map directly to NT system calls), but it's still not a full-blown microkernel.
I find it to be very consistent. The default X11 behavior is not necessarily intuitive to windows/mac users.
I'm not sure what the "default" X11 copy/paste behavior is, but I suspect the most common one is Ctrl+C copies, Ctrl+V pastes.
(Note: that button in the middle of your mouse - or, if you have a two-button mouse and have configured it in the typical fashion, clicking both at once - implements "paste current selection", not "copy/paste". They're two different things.
Both can be useful, although on OSes with desktop environments that don't use Ctrl as the command modifier, one of the main uses of a purely mouse-based paste-current-selection, i.e. pasting in a terminal window where Ctrl+C is typically the "interrupt program" key and Ctrl+V is typically the "quote the next character" key, isn't quite as necessary as it is on other desktop environments.)
A lot of the problem with consistent copy/paste on X11-based desktop environments is a result of toolkits or applications not following the X clipboard explanation; it has nothing to do with...
But there are a wealth of desktop environments which supply a clipboard manager (and a wealth of other clipboard managers you can use instead).
Just because Apple support GCC (and will continue doing so unless ICC for OSX suddenly becomes free or they start charging for XCode) doesn't mean they shouldn't compile their entire O/S with ICC to take advantage of the speed.
If, however, the article is correct when it says that "The Intel tools... will not provide a compiler for Objective C", that means that they couldn't compile the entire OS with ICC.
Add to that, we are going to be supporting both PPC and X86 on the Mac for many years to come.
ICC won't prevent you from building universal binaries
Correct - it probably won't hunt down all copies of GCC installed on your machine and remove them.
Whether it will itself build universal binaries is another question. I would be extremely suprised to hear that it does (even with that stuff about Altivec in the article; I suspect either the author, or some Intel spokesperson whom they asked
about Altivec, was confused).
Perhaps you can build the PPC version with GCC or XL C/XL C++, the x86 version with ICC, and then lipo them together.
/.> Will the promise of the same feature set and the same tools (for Windows, Mac and Linux) mean the future of cross-platform development is here?
No.
Ask AMD.
User-mode code generated for x86 (and EM64T, if Intel's tools support it) should work on AMD processors (I think for user-mode code EM64T is just x86-64), although you probably won't be able to optimize for particular AMD processors.
However, the answer "No" is still correct, as a lot of "cross-platform development" between Windows, OS X, and UN*X+X11 (of which many Linux distributions are instances) can involve supporting different GUI toolkit APIs on those platforms, so this isn't "the future of cross-platform development" unless Intel provides tools to make the same app run on different toolkits.
Combining it with, for example, Qt (or GTK+, if you're willing to live with an X11-based app on the Mac) might provide a platform for cross-platform development of GUI apps.
But for their own builds of OSX, I would expect Apple to move towards Intels' tools.
For at least some components of OS X, they can't do that; the article says "The Intel tools will support C, C++ and FORTRAN, but will not provide a compiler for Objective C". The compilers "will be interoperable with Objective C", which presumably means "will generate C and C++ code that can be called from Objective-C code generated by Apple's GCC".
However the comment that "...Intel has also not considered whether it will support Altivec instructions, a 128-bit vector execution unit in PowerPC G4 and G5 processors. Such support won't be in the early betas..." would suggest that they will be creating universal binaries and supporting PPC
...or that the author of the article didn't know what the hell he was talking about. I would be greatly surprised to hear that Intel would devote any effort whatsoever to add support for a competitor's instruction set architecture to their compilers; I would not be surprised to hear either that Intel wasn't even asked whether they'd support Altivec, or that the question was asked of some Intel spokesperson who had no clue what "Altivec" was and who gave a canned PR-department "we haven't yet considered that" answer.
Batch programs (i.e. no GUI) that use standard C and C++ libraries, and the more vanilla Posix calls, are very portable among Win, *nix, Mac, etc.
The more vanilla POSIX calls should work among *nixes (Mac OS X is a *nix). Some more work would be needed to make them work on Windows. (MSVC++'s libraries have versions of at least some of those calls, but I think their names begin with an extra "_".)
You would have to compile your simple program twice, once on Windows and once on Linux to create two binaries.
And the Windows binary would be in PE (Portable Executable) format (we're presuming Win32 or Win64 here), the Microsoft executable file/dynamically-loaded code file format, while the Linux binary would be in ELF (Executable and Linking Format), the executable file/dynamically-loaded code file/object file/core dump file format, originally developed by AT&T, used on Linux, most BSDs, Solaris, and at least some other UN*Xes these days.
The program would probably compile on most if not all other UN*Xes, including OS X, and be in the native binary file formats for those OSes (ELF, as per the above, on many other UN*Xes; Mach-O in OS X; various mutant flavors of COFF (Common Object File Format, also developed by AT&T, and mutated by various UN*X vendors into ECOFF, XCOFF, etc.) on some other UN*Xes.
ELF binaries for one OS might, or might not, work on another OS. Binaries for Windows would only work on UN*Xes with the aid of software to run Windows binaries, such as Wine; binaries for various UN*Xes probably wouldn't work on Windows at all (I know of, for example, no "inverse Wine" to let you, for example, run Linux binaries on Windows). Binaries in one format might, or might not, work on an OS using a differenrt format.
Re:But they didn't deliver; they provided a stop-g
on
Windows 95 Turns 10
·
· Score: 1
Check out Andrew Schulman's "Inside Windows 95" some time.
I am all about how things work and learning about new and interesting things but would that book be of any value 10 years after the fact considering that OS and anything like it is already dead?
OK, perhaps the person to whom you're responding should have said
Check out Andrew Schulman's "Inside Windows 95" some time
if you're curious how Windows 95 actually worked, e.g. how it kicked DOS out of the way and took control of devices, file systems, etc..
I.e., he was responding to somebody who make an incorrect statement about the way W95 worked, and suggested a book that more accurately described how it worked, as a reference to support his statements about how it worked. It wasn't, as far as I know, a broad suggestion that everybody reading his posting go out and get the book.
Intel could design cores that are common to all their CPUs
(Presumably you mean "all their x86 CPUs", i.e. this doesn't include their IA-64 or ARM CPUs, for example.)
It sounds as if that's what they're going to be doing with the new line of x86 chips (as opposed to now, where they have both the Pentium M and the Pentium 4 cores).
There is no ``unified architecture between server / laptop / desktop''. All of these markets may be served by CPUs that implement tha x86 instruction set, but that doesn't mean they have the same architecture. The Pentium M you would find in a laptop is a completely different beast from the P4 you would find in a desktop machine.
Yes, but I have the impression that the laptop and desktop versions of the new Intel processors aren't "completely different beasts" from each other; I suspect the person to whom you're responding meant, when they referred to a "unified architecture", that the chips in the family were very similar in their internal architecture.
Now for CPUs: There is no reason you can't have one unified architecture across all CPUs and still specialize them for niches and form factors. Just having the same architecture has not stopped IBM and Motorola from having 5 different 'niche' implementations:
When the person to whom you're replying used the word "architecture", were they referring to instruction set architecture, or to internal chip architecture? If the latter, then the handtop/mobile/desktop/server versions of {fill in Intel name for the new chip internal design if, as, and when they give it one} are "one unified architecture" in both senses, while the various POWER-family processors you mention implement (more or less) the same two instruction set architectures (modulo, e.g., Altivec) - 32-bit POWER-family and 64-bit POWER-family (the latter including the 32-bit version) with what I think are significantly different internal chip architectures.
...somehow renders the replies to Mr. "go AMD!" invalid
Make that "Mr. 'Go Advanced Micro'"; "Go AMD!" was what the deliverer of the aforementioned foot up the ass said when he pointed out that AMD and IBM are, just like Intel, members of the Trusted Computing(TM)(R)(LSMFT) group (whether it's the TCPA or the TCG).
Really? "The Trusted Computer Alliance" doesn't exist anymore. They disbanded.
Fine. Replace "TCPA" ("Trusted Computing Platform Alliance", not "Trusted Computer Alliance") with "TCG", for "Trusted Computing Group".
Then go look at the TCG's member list. Note the appearance of "AMD" and "IBM" on the list. Then please explain to the audience how saying ""The Trusted Computer Alliance" doesn't exist anymore. They disbanded." somehow renders the replies to Mr. "go AMD!" invalid. (Perhaps AMD won't have any chips that support DRM, and perhaps IBM wouldn't have added DRM to chips for Apple, but it's not as if AMD and IBM are brave members of the Rebel Alliance against Trusted Computing.)
The Intel EM64T is a horrible kludge compared to x86-64 (Athlon64).
"EM64T" and "x86-64" are, as far as I know, just instruction sets, with, I have the impression, slight differences in some kernel-mode stuff, but no differences that applications would see. What makes one "a horrible kludge" compared to the other?
Now, perhaps Intel's implementation sucks relative to AMD's, but that's another matter.
Slashdot Mirror
Heck, it'd not be shocked if fork() on Linux had extra overhead that pthread_create() didn't. It might, for example, be duplicating the address space; fork() is copy-on-write (on most if not all UN*Xes, including OS X and Linux) so that the data in the address space doesn't get copied, but the address space data structures might have to be duplicated, and resident writeable pages would have to get marked non-writeable in the MMU so that an attempt by parent or child to store into them would provoke a copy.
As opposed to monolithic kernels, where bugs are unusual?
BTW, there's not much "microkernelish" about OS X; it's not as if the kernel's spending lots of time sending messages to random server processes to implement every system call - that code path is a Boring Old Monolithic Kernel code path.
...if any of that whiz-bang cross-machine Mach messaging stuff were supported and used, but it's not.
Only if the threads are UN*X processes rather than pthreads.
...except when they talk directly to the NT kernel.
Yes, but neither of those systems are prone to blue screen halts. (Well, I don't think Linux's panic screen is blue.)
(I.e., the terminology might be different in NT, but the concept exists. Statistics on how often particular Linux kernel releases, OS X releases, and NT (including NT 5.x) releases die in the kernel might be interesting.)
The main movement I know of was moving the low-level graphics code from the Win32 subsystem server to a kernel-mode driver. File systems, network stacks up to the transport layer, and storage and network drivers were already in kernel-mode code.
It's perhaps a bit more microkernel than, say, OS X (I think some amount of process creation and image launching, and opening files, are done by the Win32 subsystem, although I think file and network I/O map directly to NT system calls), but it's still not a full-blown microkernel.
I'm not sure what the "default" X11 copy/paste behavior is, but I suspect the most common one is Ctrl+C copies, Ctrl+V pastes.
(Note: that button in the middle of your mouse - or, if you have a two-button mouse and have configured it in the typical fashion, clicking both at once - implements "paste current selection", not "copy/paste". They're two different things.
Both can be useful, although on OSes with desktop environments that don't use Ctrl as the command modifier, one of the main uses of a purely mouse-based paste-current-selection, i.e. pasting in a terminal window where Ctrl+C is typically the "interrupt program" key and Ctrl+V is typically the "quote the next character" key, isn't quite as necessary as it is on other desktop environments.)
A lot of the problem with consistent copy/paste on X11-based desktop environments is a result of toolkits or applications not following the X clipboard explanation; it has nothing to do with...
...the absence of a clipboard manager.
If, however, the article is correct when it says that "The Intel tools ... will not provide a compiler for Objective C", that means that they couldn't compile the entire OS with ICC.
Correct - it probably won't hunt down all copies of GCC installed on your machine and remove them.
Whether it will itself build universal binaries is another question. I would be extremely suprised to hear that it does (even with that stuff about Altivec in the article; I suspect either the author, or some Intel spokesperson whom they asked about Altivec, was confused).
Perhaps you can build the PPC version with GCC or XL C/XL C++, the x86 version with ICC, and then lipo them together.
The Mac OS X compilers and libraries will probably require some special software, called "Mac OS X", to be running on the machine.
Apple's compiler is GCC (or, at least, GCC-based). Did you mean "IBM's compiler" (XL C/C++)?
User-mode code generated for x86 (and EM64T, if Intel's tools support it) should work on AMD processors (I think for user-mode code EM64T is just x86-64), although you probably won't be able to optimize for particular AMD processors.
However, the answer "No" is still correct, as a lot of "cross-platform development" between Windows, OS X, and UN*X+X11 (of which many Linux distributions are instances) can involve supporting different GUI toolkit APIs on those platforms, so this isn't "the future of cross-platform development" unless Intel provides tools to make the same app run on different toolkits.
Combining it with, for example, Qt (or GTK+, if you're willing to live with an X11-based app on the Mac) might provide a platform for cross-platform development of GUI apps.
For at least some components of OS X, they can't do that; the article says "The Intel tools will support C, C++ and FORTRAN, but will not provide a compiler for Objective C". The compilers "will be interoperable with Objective C", which presumably means "will generate C and C++ code that can be called from Objective-C code generated by Apple's GCC".
...or that the author of the article didn't know what the hell he was talking about. I would be greatly surprised to hear that Intel would devote any effort whatsoever to add support for a competitor's instruction set architecture to their compilers; I would not be surprised to hear either that Intel wasn't even asked whether they'd support Altivec, or that the question was asked of some Intel spokesperson who had no clue what "Altivec" was and who gave a canned PR-department "we haven't yet considered that" answer.
The more vanilla POSIX calls should work among *nixes (Mac OS X is a *nix). Some more work would be needed to make them work on Windows. (MSVC++'s libraries have versions of at least some of those calls, but I think their names begin with an extra "_".)
And the Windows binary would be in PE (Portable Executable) format (we're presuming Win32 or Win64 here), the Microsoft executable file/dynamically-loaded code file format, while the Linux binary would be in ELF (Executable and Linking Format), the executable file/dynamically-loaded code file/object file/core dump file format, originally developed by AT&T, used on Linux, most BSDs, Solaris, and at least some other UN*Xes these days.
The program would probably compile on most if not all other UN*Xes, including OS X, and be in the native binary file formats for those OSes (ELF, as per the above, on many other UN*Xes; Mach-O in OS X; various mutant flavors of COFF (Common Object File Format, also developed by AT&T, and mutated by various UN*X vendors into ECOFF, XCOFF, etc.) on some other UN*Xes.
ELF binaries for one OS might, or might not, work on another OS. Binaries for Windows would only work on UN*Xes with the aid of software to run Windows binaries, such as Wine; binaries for various UN*Xes probably wouldn't work on Windows at all (I know of, for example, no "inverse Wine" to let you, for example, run Linux binaries on Windows). Binaries in one format might, or might not, work on an OS using a differenrt format.
OK, perhaps the person to whom you're responding should have said
I.e., he was responding to somebody who make an incorrect statement about the way W95 worked, and suggested a book that more accurately described how it worked, as a reference to support his statements about how it worked. It wasn't, as far as I know, a broad suggestion that everybody reading his posting go out and get the book.
If he leaves again, will he become a (rack-mountable?) XCEO?
(Presumably you mean "all their x86 CPUs", i.e. this doesn't include their IA-64 or ARM CPUs, for example.)
It sounds as if that's what they're going to be doing with the new line of x86 chips (as opposed to now, where they have both the Pentium M and the Pentium 4 cores).
Yes, but I have the impression that the laptop and desktop versions of the new Intel processors aren't "completely different beasts" from each other; I suspect the person to whom you're responding meant, when they referred to a "unified architecture", that the chips in the family were very similar in their internal architecture.
When the person to whom you're replying used the word "architecture", were they referring to instruction set architecture, or to internal chip architecture? If the latter, then the handtop/mobile/desktop/server versions of {fill in Intel name for the new chip internal design if, as, and when they give it one} are "one unified architecture" in both senses, while the various POWER-family processors you mention implement (more or less) the same two instruction set architectures (modulo, e.g., Altivec) - 32-bit POWER-family and 64-bit POWER-family (the latter including the 32-bit version) with what I think are significantly different internal chip architectures.
Make that "Mr. 'Go Advanced Micro'"; "Go AMD!" was what the deliverer of the aforementioned foot up the ass said when he pointed out that AMD and IBM are, just like Intel, members of the Trusted Computing(TM)(R)(LSMFT) group (whether it's the TCPA or the TCG).
Fine. Replace "TCPA" ("Trusted Computing Platform Alliance", not "Trusted Computer Alliance") with "TCG", for "Trusted Computing Group".
Then go look at the TCG's member list. Note the appearance of "AMD" and "IBM" on the list. Then please explain to the audience how saying ""The Trusted Computer Alliance" doesn't exist anymore. They disbanded." somehow renders the replies to Mr. "go AMD!" invalid. (Perhaps AMD won't have any chips that support DRM, and perhaps IBM wouldn't have added DRM to chips for Apple, but it's not as if AMD and IBM are brave members of the Rebel Alliance against Trusted Computing.)
Surely you mean "I'm using Windows, you insensitive clod!"
"EM64T" and "x86-64" are, as far as I know, just instruction sets, with, I have the impression, slight differences in some kernel-mode stuff, but no differences that applications would see. What makes one "a horrible kludge" compared to the other?
Now, perhaps Intel's implementation sucks relative to AMD's, but that's another matter.
You're looking at it.