He may be "clearing talking about MacOS X", but he's equally clearly not talking about MacOS X in his second clause, as he speaks of MacOS X Server in his first clause, and contrasts it in his second clause with the other OS Apple is currenly selling, which is not MacOS X, unless they've started selling the non-server version while I wasn't looking.
As a matter of fact, Steve Walli said that they couldn't implement true Unix file hard links but only soft links because of using the NT file system.
According to Helen Custer's Inside the Windows NT(TM) File System, NTFS does support hard links, in order to support NT's native "contractual obligation" POSIX subsystem; I'm not sure why Softway couldn't do the same, unless they were worried about supporting OTFS^H^H^H^HVFAT, although there's other stuff required by POSIX that VFAT doesn't support, so I'd assume they'd just punt on stuff that the underlying file system said it couldn't support.
I suspect the point is that this might just as well help users make a transition from NT to Unix.
I suppose that's not inconceivable, but I have seen nothing to indicate that this is Microsoft's intent, and interpreting it as Microsoft's intent seems like wishful thinking at its worst.
If somebody's migrating from UNIX to NT, Interix lets them recompile their existing applications and run them on their NT boxes, until they rewrite them as Win32 applications (as per the press release).
If somebody's migrating from NT to UNIX, they presumably don't have UNIX applications to recompile; all this does is let them continue to run the applications on the NT boxes after rewriting them, without having to keep around source that can be turned into either Win32 or UNIX applications - helpful, but it doesn't seem as helpful to those folks as it does to folks migrating in the other direction.
Having the ability to process 32bit code on a 64bit chip if anything increases the speed because you can have two 32bit instructions run every cycle rather than a single 64bit instruction.
Not if, say, a 32-bit arithmetic instruction uses an entire ALU, as I think is the case on most 64-bit machines; I don't know if there are any that'd split a 64-bit ALU up into two 32-bit ALUs and run two 32-bit instructions through them (especially given that registers generally aren't split that way, either).
The SIMD "multimedia" instructions that most general-purpose instruction set architectures have picked up may process multiple less-than-full-word-size units in one ALU and in one instruction, but that's one instruction, not two.
Second of all Motorola already makes 64bit chips, these funny things called PowerPC chips. IBM and Apple use them, Apple runs 32bit code on the 64bit chip
What chips that implement the 64-bit version of the PowerPC instruction set does Apple use? (Chips that implement the 32-bit version of the instruction set, but that have a 64-bit bus interface, don't count as "64-bit chips" here.)
and now the 750 which is 128bit
No, it's 32-bit - it implements the 32-bit version of the PowerPC, without the AltiVec instructions, and according to this page at Motorola's Web site it has only a 64-bit bus interface for data.
Perhaps you're thinking of the 7400, which has the AltiVec instructions, but it also has only a 64-bit data bus, and only implements the 32-bit version of the core PowerPC architecture (note that the page for the 7400 links to the 32-bit version of the "Programming Environments Manual"), even if it also implements the AltiVec instructions that work on 128-bit registers.
If you expand the PPC family to include the POWER chipsets used in RS/6000s, then you can also include the POWER3 as a 64bit PPC...
I'd include in the PowerPC family any chip that implements the PowerPC instruction set architecture, and this press release says:
The POWER3 design is based on the highly scalable PowerPC architecture, IBM's strategic architecture used in its designs for embedded controllers to desktop-class processors to high-end processors. The PowerPC architecture provides the ability for thousands of POWER3 microprocessors to be combined into a single, unified computing unit.
(although it's not entirely clear how the instruction set "provides the ability for thousands of POWER3 microprocessors to be combined into a single, unified computing unit"). The RIOS chipset in the first RS/6000's implemented the POWER architecture, which had a few things PowerPC doesn't and didn't have somethings PowerPC does (but there is a common subset of the instruction set), as did the RSC (which I'm told stood for "RIOS Single-Chip", and which I've heard was modified to make the 601), and the POWER2 chipset implemented the POWER2 architecture (added a few things to POWER, but also lacked some stuff PowerPC had); I guess POWER3 finally picks up all of PowerPC.
However, it, like the RS64 in some other RS/6000 models, and the models used in the AS/400's (one of which is the RS64 III, as per this paper, presumably with "tags-active" mode turned on in the AS/400's and off in the RS/6000's), are proprietary to IBM, unlike the 4xx, 6xx, and 7xx chips, which IBM Microelectronics sells.
As I stated in another post, when people talk about 32- or 64-bit chips, they are usually talking about the length of the
instruction set.
And as others stated in replies to your post, that's not the case; the instructions are 32-bit in the 64-bit PowerPC architecture.
With 64-bit instructions you can create new operations, or more likely address more memory.
You can address more memory without 64-bit instructions; you might just have to do more work to synthesize addresses, and if the address is just a pointer you've been handed, or a pointer in a data structure, you don't have to synthesize the address.
The first PPCs had x86 instruction hardware support.
References, please? I've seen nothing to indicate that any PowerPC chip that actually made it out the door had x86 instruction support; all I've heard were claims that a 615 chip was being developed that would run x86 code, and, if I remember correctly, claims that Exponential's 704 would have x86 support.
The PPC is basically a RISCified mixture of m68k and x86
The PowerPC architecture is derived from IBM's POWER architecture (yeah, the same POWER architecture to which you referred with "IBM Power"), which first showed up in the RS/6000's, with assorted changes, e.g. single-precision floating-point and multiply and divide instructions that don't go through an MQ register. Please explain how a POWER derivative is "a RISCified mixture of m68k and x86, just a little cleaned up".
He indicated that it worked by basically replacing the WIN32 subsystems of NT by separate code that was built on the NT HAL (Hardware Abstraction Layer) not Win32.
Are you certain he said that it was built on the HAL? The impression I had is that it's built on the native NT system-call API, just as, say, subsystems such as the Win32 subsystem are, and just as the core API libraries (e.g., kernel32.dll) are, and just as some executable images that come with NT are. See, for example, Softway's "The INTERIX Solution" white paper, which has a diagram labeled "The Interix architecture" showing the Interix and Win32 subsystems running atop the NT kernel (although that diagram doesn't note that some Win32 APIs are apparently built directly atop the kernel, in the sense that some routines in, say, kernel32.dll directly make system calls; I think one of the editions of Inside Windows NT says that ReadFile() and WriteFile() don't pass through the Win32 subsystem process - perhaps some of the Interix library routines implementing the UNIX API do the same).
Building it purely atop the HAL would mean it couldn't access files on the file systems available to Win32 applications, say, as the file system and device driver code inside the kernel isn't part of the HAL.
If M$ wanted true *nix/Posix compliance they could have made or bought it years ago (I may be a Linux Zealot, but I recognize the skills that M$ has at its disposal) -- ergo they don't want it.
Or, at least, they didn't want it until now. Perhaps they've decided that they now do want it, to try to help customers move rapidly towards a Windows NT-based solution...
I've yet to see anything to indicate that Microsoft's motivation is anything other than what's described therein; they may plan to kill the product once it's served its purpose, which is to get UNIX sites migrated to NT.
They are smarter than to promote a *nix<->NT layer capable of allowing the WordPerfect's of the world to move easily to Linux
This isn't a "*nix<->NT layer", it's a *nix->NT layer - it doesn't "allow the WordPerfect's of the world to move easily to Linux", it's intended to let applications move to NT, and may be aimed primarily at in-house applications rather than shrink-wrapped applications.
I'm not a kernel hacker or anything so please correct me if I'm wrong. But I was under the impression that Win & NT can never really be stable OS's because they don't distinguish kernel and user spaces like unix does.
You're wrong, at least for NT - NT has stuff that runs in kernel mode, and runs other stuff (DLL code - think ".so code" if you're used to most UNIXes - application code, and code that runs in, say, the Win32 subsystem process) in user mode; user-mode code doesn't get access to the kernel-mode portion of the address space (unless the kernel decides to grant it that access, which I suspect it might do only for some privileged processes, and quite possibly not even for them).
Plus you still have to re-boot every time you install new software or change your configurations...
Not every time - I think current version of NT let you change some network settings without requiring a reboot (I'm curious whether any UNIX code does, say, a bunch of ioctls to find out the network configuration of the box, and can't be told "it's different now, re-fetch that data"), and I've installed at least some applications without the installer suggesting that I reboot.
Microsoft could be preparing for some sort of Unix virtual machine to run within the NT kernel, supporting Unix apps,
That's exactly what Interix is (except that at least some of it presumably runs in a user-mode subsystem process rather than in the kernel).
Note, though, that it doesn't "[support] Unix apps" in the sense of running binaries from some flavor of UNIX, as the Interix FAQ notes (see "Can I run any of my UNIX applications with INTERIX?").
And among the OSS community, there would be widespread derision over their apps being used on the NT platform.
I think Microsoft can live with that (and note that some OSS applications, e.g. the GIMP, have been ported).
For those unfamiliar with Interix, it is a UNIX95-certified platform, hence, a "real UNIX environment".
There's more to being "a real UNIX environment" than just implementing the stuff in POSIX.1, which is what the NT POSIX subsystem implements - POSIX.1 doesn't cover all the APIs that one might use in a UNIX application (e.g., it contains no networking APIs whatsoever). Interix also implements the POSIX.2 commands.
Yes, it "runs X" in the sense that you can build X applications to run in the Interix environment (although it appears its X11 environment is X11R5, not X11R6); "Interix Workstation", as opposed to "Interix Workstation Lite", comes with an X server and mwm, although the Interix FAQ says that Interix X applications should also work with other X servers on NT.
Allmost all of this windows developers release their material in a closed source fashion (you won't change this overnigth just because they are using Linux, is windows culture), then they have to pay Troll Tech money.
Then making Delphi not royalty free (thus changing their policy..., I doubt Borland want this)
There are no royalties, run-time licenses or other additional costs. You can distribute your Qt-based programs either statically or dynamically linked without any additional charges.
I.e., you have to pay Troll Tech money to get Qt Professional edition, which lets you sell closed-source software, but you do not have to pay them per copy of that software sold.
Just because it's POSIX compliant doesn't make it UNIX.
Linux is one hell of a lot more than just POSIX-compliant; it implements tons of stuff that isn't in POSIX but that's in other UNIX-compatible systems.
UNIX flavors are flavors of UNIX because they are derived from UNIX. GNU/Linux is not derived from UNIX, although the BSD derivatives are
Given the extent to which systems "derived from UNIX", in the sense that, at one point, the code in those systems started out with code from AT&T, have diverged from that code base, I'm not sure I consider being "derived from UNIX" to be all that interesting.
I consider the "feel" of the OS, even if none of the code ever looked like AT&T code, more important, and, given that Linux's native API looks as much like that of other "UNIX-flavored" OSes as the API of any of those other systems looks like that of its compatriots, and that its command-line interface looks as much like that of other "UNIX-flavored" OSes as the command-line interface of any of those other systems looks like that of its compatriots (no noise about color ls, please, Interactive Systems had a UNIX-flavored system whose ls had a significantly different set of flag options than others - adding color to ls is a relatively minor tweak), I consider it to be a member of the same family as those OSes that, at one point in their history, had AT&T code in them - and more of a member of that family than OSes that offer UNIX compatibility in addition to a native API (you administer a Linux system in ways that look pretty much like the ways you administer other UNIX-flavored OSes; you don't administer an OS/390 system, or an NT system with Interix, or an OpenVMS system).
Of course, he's still wrong since he left out Windows 2000.
...and Solaris (unless Sun does something like making the IA-64 version not 64-bit), and, presumably, Monterey (the AIX bits of which, at least, could be 64-bit).
IBM has too many servers with the format XX/XXXX. AS/400, RS/6000, S/390
They probably got in the habit from System/360, following it up with S/370 and, after not bumping the number in the '80's, S/390, as well as System/3, S/32, S/34, S/36, S/38, and so on.
So what did the magazines in question actually say?
VMS is not Unix.
I don't think the poster to whom you're replying was saying it was;
From the DEC/Digital side, their Unix was not well accepted. The OEM mags were quoting that for every 10 users leaving VMS, only 2 stayed with Digital.
reads to me as "...for every 10 users leaving VMS and switching to UNIX, only 2 stayed with Digital and switched to Digital^H^H^H^H^H^H^HTru64 UNIX from VMS."
So in a way, GNU/Linux could actually do just that, even though it's not a de facto member of UNIX.
You meant de jure, as in "it's not (yet?) been run through the UNIX 95 or UNIX 98 test suite, so it's not a 'UNIX' legally"; it's sure as heck a de facto "member of UNIX", given that it has an API that pretty much looks as much like that of any given UNIX as do the APIs of other "members of UNIX".
Having the ability to roll this optimized code into gcc/egcs
I suspect the internals of Digital/Compaq's GEM compiler are significantly different from those of EGCS, so I don't think their optimizations would necessarily just "roll in"; it might require significant internal changes to EGCS to implement them there.
No, it's more like IBM having AIX run on systems other than AS/400.
You presumably meant RS/6000 there; it might be that some AS/400 machines and some RS/6000 machines are the same (machines, not processors; the mere fact that two machines run the same chip, as might be the case if RS64 is actually one of the AS/400 extended PowerPC chips, with e.g. tagged mode not used, does not mean that the machines are identical - they may have different support chips, I/O buses, etc), but not all AS/400s run AIX (the ones with IMPI rather than PowerPC processors probably wouldn't), and not all AIX machines are AS/400's.
Besides, by supporting the merced with the only fully functional commercial 64 bit operating system, they would shout themselves in the Alpha foot.
In what way do you consider Solaris 7/SunOS 5.7, AIX 4.3, whatever the first 64-bit IRIX was, and HP-UX 11.0 not "fully functional commercial 64 bit operating systems"? (Throw in Red Hat, SuSE, etc. if you consider them "commercial".)
(I shall assume that "UNIX-compatible" was implicit; if that assumption is incorrect, throw OS/400 and OpenVMS in while you're at it.)
Slashdot Mirror
He may be "clearing talking about MacOS X", but he's equally clearly not talking about MacOS X in his second clause, as he speaks of MacOS X Server in his first clause, and contrasts it in his second clause with the other OS Apple is currenly selling, which is not MacOS X, unless they've started selling the non-server version while I wasn't looking.
According to Helen Custer's Inside the Windows NT(TM) File System, NTFS does support hard links, in order to support NT's native "contractual obligation" POSIX subsystem; I'm not sure why Softway couldn't do the same, unless they were worried about supporting OTFS^H^H^H^HVFAT, although there's other stuff required by POSIX that VFAT doesn't support, so I'd assume they'd just punt on stuff that the underlying file system said it couldn't support.
I suppose that's not inconceivable, but I have seen nothing to indicate that this is Microsoft's intent, and interpreting it as Microsoft's intent seems like wishful thinking at its worst.
If somebody's migrating from UNIX to NT, Interix lets them recompile their existing applications and run them on their NT boxes, until they rewrite them as Win32 applications (as per the press release).
If somebody's migrating from NT to UNIX, they presumably don't have UNIX applications to recompile; all this does is let them continue to run the applications on the NT boxes after rewriting them, without having to keep around source that can be turned into either Win32 or UNIX applications - helpful, but it doesn't seem as helpful to those folks as it does to folks migrating in the other direction.
Not if, say, a 32-bit arithmetic instruction uses an entire ALU, as I think is the case on most 64-bit machines; I don't know if there are any that'd split a 64-bit ALU up into two 32-bit ALUs and run two 32-bit instructions through them (especially given that registers generally aren't split that way, either).
The SIMD "multimedia" instructions that most general-purpose instruction set architectures have picked up may process multiple less-than-full-word-size units in one ALU and in one instruction, but that's one instruction, not two.
What chips that implement the 64-bit version of the PowerPC instruction set does Apple use? (Chips that implement the 32-bit version of the instruction set, but that have a 64-bit bus interface, don't count as "64-bit chips" here.)
No, it's 32-bit - it implements the 32-bit version of the PowerPC, without the AltiVec instructions, and according to this page at Motorola's Web site it has only a 64-bit bus interface for data.
Perhaps you're thinking of the 7400, which has the AltiVec instructions, but it also has only a 64-bit data bus, and only implements the 32-bit version of the core PowerPC architecture (note that the page for the 7400 links to the 32-bit version of the "Programming Environments Manual"), even if it also implements the AltiVec instructions that work on 128-bit registers.
I'd include in the PowerPC family any chip that implements the PowerPC instruction set architecture, and this press release says:
(although it's not entirely clear how the instruction set "provides the ability for thousands of POWER3 microprocessors to be combined into a single, unified computing unit"). The RIOS chipset in the first RS/6000's implemented the POWER architecture, which had a few things PowerPC doesn't and didn't have somethings PowerPC does (but there is a common subset of the instruction set), as did the RSC (which I'm told stood for "RIOS Single-Chip", and which I've heard was modified to make the 601), and the POWER2 chipset implemented the POWER2 architecture (added a few things to POWER, but also lacked some stuff PowerPC had); I guess POWER3 finally picks up all of PowerPC.
However, it, like the RS64 in some other RS/6000 models, and the models used in the AS/400's (one of which is the RS64 III, as per this paper, presumably with "tags-active" mode turned on in the AS/400's and off in the RS/6000's), are proprietary to IBM, unlike the 4xx, 6xx, and 7xx chips, which IBM Microelectronics sells.
And as others stated in replies to your post, that's not the case; the instructions are 32-bit in the 64-bit PowerPC architecture.
You can address more memory without 64-bit instructions; you might just have to do more work to synthesize addresses, and if the address is just a pointer you've been handed, or a pointer in a data structure, you don't have to synthesize the address.
No. Check out the PowerPC Programming Environments Manuals section of this page, and the (PDF) documents it links to. The instructions are 32 bits; the addresses and data they manipulate can be 64-bit in 64-bit PowerPC processors.
References, please? I've seen nothing to indicate that any PowerPC chip that actually made it out the door had x86 instruction support; all I've heard were claims that a 615 chip was being developed that would run x86 code, and, if I remember correctly, claims that Exponential's 704 would have x86 support.
The PowerPC architecture is derived from IBM's POWER architecture (yeah, the same POWER architecture to which you referred with "IBM Power"), which first showed up in the RS/6000's, with assorted changes, e.g. single-precision floating-point and multiply and divide instructions that don't go through an MQ register. Please explain how a POWER derivative is "a RISCified mixture of m68k and x86, just a little cleaned up".
Are you certain he said that it was built on the HAL? The impression I had is that it's built on the native NT system-call API, just as, say, subsystems such as the Win32 subsystem are, and just as the core API libraries (e.g., kernel32.dll) are, and just as some executable images that come with NT are. See, for example, Softway's "The INTERIX Solution" white paper, which has a diagram labeled "The Interix architecture" showing the Interix and Win32 subsystems running atop the NT kernel (although that diagram doesn't note that some Win32 APIs are apparently built directly atop the kernel, in the sense that some routines in, say, kernel32.dll directly make system calls; I think one of the editions of Inside Windows NT says that ReadFile() and WriteFile() don't pass through the Win32 subsystem process - perhaps some of the Interix library routines implementing the UNIX API do the same).
Building it purely atop the HAL would mean it couldn't access files on the file systems available to Win32 applications, say, as the file system and device driver code inside the kernel isn't part of the HAL.
...and not atop X.
Or, as stated in the press release for the acquisition, to smooth the transition from UNIX to NT for UNIX users.
Or, at least, they didn't want it until now. Perhaps they've decided that they now do want it, to try to help customers move rapidly towards a Windows NT-based solution...
...wait, it says precisely that in the press release announcing the acquisition.
I've yet to see anything to indicate that Microsoft's motivation is anything other than what's described therein; they may plan to kill the product once it's served its purpose, which is to get UNIX sites migrated to NT.
This isn't a "*nix<->NT layer", it's a *nix->NT layer - it doesn't "allow the WordPerfect's of the world to move easily to Linux", it's intended to let applications move to NT, and may be aimed primarily at in-house applications rather than shrink-wrapped applications.
You're wrong, at least for NT - NT has stuff that runs in kernel mode, and runs other stuff (DLL code - think ".so code" if you're used to most UNIXes - application code, and code that runs in, say, the Win32 subsystem process) in user mode; user-mode code doesn't get access to the kernel-mode portion of the address space (unless the kernel decides to grant it that access, which I suspect it might do only for some privileged processes, and quite possibly not even for them).
Not every time - I think current version of NT let you change some network settings without requiring a reboot (I'm curious whether any UNIX code does, say, a bunch of ioctls to find out the network configuration of the box, and can't be told "it's different now, re-fetch that data"), and I've installed at least some applications without the installer suggesting that I reboot.
That's exactly what Interix is (except that at least some of it presumably runs in a user-mode subsystem process rather than in the kernel).
Note, though, that it doesn't "[support] Unix apps" in the sense of running binaries from some flavor of UNIX, as the Interix FAQ notes (see "Can I run any of my UNIX applications with INTERIX?").
I think Microsoft can live with that (and note that some OSS applications, e.g. the GIMP, have been ported).
The person who submitted the article said
There's more to being "a real UNIX environment" than just implementing the stuff in POSIX.1, which is what the NT POSIX subsystem implements - POSIX.1 doesn't cover all the APIs that one might use in a UNIX application (e.g., it contains no networking APIs whatsoever). Interix also implements the POSIX.2 commands.
Yes, it "runs X" in the sense that you can build X applications to run in the Interix environment (although it appears its X11 environment is X11R5, not X11R6); "Interix Workstation", as opposed to "Interix Workstation Lite", comes with an X server and mwm, although the Interix FAQ says that Interix X applications should also work with other X servers on NT.
The guy who ported the GIMP to Win32 apparently wanted to do so....
"Not royalty-free" in what sense? The Pricing And Availability page for Qt says that
I.e., you have to pay Troll Tech money to get Qt Professional edition, which lets you sell closed-source software, but you do not have to pay them per copy of that software sold.
Would that be GNU "hello"?
Linux is one hell of a lot more than just POSIX-compliant; it implements tons of stuff that isn't in POSIX but that's in other UNIX-compatible systems.
Given the extent to which systems "derived from UNIX", in the sense that, at one point, the code in those systems started out with code from AT&T, have diverged from that code base, I'm not sure I consider being "derived from UNIX" to be all that interesting.
I consider the "feel" of the OS, even if none of the code ever looked like AT&T code, more important, and, given that Linux's native API looks as much like that of other "UNIX-flavored" OSes as the API of any of those other systems looks like that of its compatriots, and that its command-line interface looks as much like that of other "UNIX-flavored" OSes as the command-line interface of any of those other systems looks like that of its compatriots (no noise about color ls, please, Interactive Systems had a UNIX-flavored system whose ls had a significantly different set of flag options than others - adding color to ls is a relatively minor tweak), I consider it to be a member of the same family as those OSes that, at one point in their history, had AT&T code in them - and more of a member of that family than OSes that offer UNIX compatibility in addition to a native API (you administer a Linux system in ways that look pretty much like the ways you administer other UNIX-flavored OSes; you don't administer an OS/390 system, or an NT system with Interix, or an OpenVMS system).
...and Solaris (unless Sun does something like making the IA-64 version not 64-bit), and, presumably, Monterey (the AIX bits of which, at least, could be 64-bit).
They probably got in the habit from System/360, following it up with S/370 and, after not bumping the number in the '80's, S/390, as well as System/3, S/32, S/34, S/36, S/38, and so on.
So what did the magazines in question actually say?
I don't think the poster to whom you're replying was saying it was;
reads to me as "...for every 10 users leaving VMS and switching to UNIX, only 2 stayed with Digital and switched to Digital^H^H^H^H^H^H^HTru64 UNIX from VMS."
You meant de jure, as in "it's not (yet?) been run through the UNIX 95 or UNIX 98 test suite, so it's not a 'UNIX' legally"; it's sure as heck a de facto "member of UNIX", given that it has an API that pretty much looks as much like that of any given UNIX as do the APIs of other "members of UNIX".
I suspect the internals of Digital/Compaq's GEM compiler are significantly different from those of EGCS, so I don't think their optimizations would necessarily just "roll in"; it might require significant internal changes to EGCS to implement them there.
You presumably meant RS/6000 there; it might be that some AS/400 machines and some RS/6000 machines are the same (machines, not processors; the mere fact that two machines run the same chip, as might be the case if RS64 is actually one of the AS/400 extended PowerPC chips, with e.g. tagged mode not used, does not mean that the machines are identical - they may have different support chips, I/O buses, etc), but not all AS/400s run AIX (the ones with IMPI rather than PowerPC processors probably wouldn't), and not all AIX machines are AS/400's.
In what way do you consider Solaris 7/SunOS 5.7, AIX 4.3, whatever the first 64-bit IRIX was, and HP-UX 11.0 not "fully functional commercial 64 bit operating systems"? (Throw in Red Hat, SuSE, etc. if you consider them "commercial".)
(I shall assume that "UNIX-compatible" was implicit; if that assumption is incorrect, throw OS/400 and OpenVMS in while you're at it.)