10.3 Server 64bit? 10.3 Consumer 32bit?

zozo
Posted:
in macOS edited January 2014
I have a feeling the new PPC 970 chip will debut in the Xserve and we will see OS X 10.3 Server 64bit and normal 10.3 still 32bit.



Then when PowerMacs get the GPUL chip, we will see 10.4 64bit accross the board.



Or does this not make sense in the development of an OS?

Comments

  • Reply 1 of 11
    jlljll Posts: 2,713member
    [quote]Originally posted by ZO:

    <strong>I have a feeling the new PPC 970 chip will debut in the Xserve and we will see OS X 10.3 Server 64bit and normal 10.3 still 32bit.</strong><hr></blockquote>





    Apple won't maintain two separate code bases of Mac OS X.
  • Reply 2 of 11
    kickahakickaha Posts: 8,760member
    64/32 bittedness doesn't require two code bases, just two compiles.



    Same code, just a compiler switch... rather like they already have MacOS X Server and MacOS X both being based on the same code base, but with different compiler options and initial default settings.
  • Reply 3 of 11
    kecksykecksy Posts: 1,002member
    I think you're wrong. The PPC970 will debut in both the XServe and PowerMac. Why? Both these machines will need the speed. PowerMac sales are important, so I doubt Apple would continue to use the G4 if a faster chip is available, especially since Intel is aiming to hit 4GHz and AMD's Hammer will be out next year.



    I imagine the fact that PowerMacs come with a 64-bit Workstation CPU and a 900MHz system bus would help sales. I don't see any reason to hold the PowerMac back. People will still buy XServes because of their form factor and better IO.



    As for a 64-bit Server OS and a 32-bit consumer OS? I don't think that's likely either. OS X and OS X Server are basically the same operating system. OS X Server has some server specific features Apple has chosen not to include in its consumer OS. Other than that, they are the same. If one gets a 64-bit support, the other will since they are developed as a single OS.



    Apple will likely sell a 64-bit version of OS 10.3 for new hardware, and a 32-bit version for old hardware. They'll share the same code, but will be different compiles.



    [ 10-14-2002: Message edited by: Kecksy ]</p>
  • Reply 4 of 11
    [quote]

    Apple won't maintain two separate code bases of Mac OS X.

    <hr></blockquote>



    Well, technically they wouldn't need to; Solaris, for example, ships as 32- or 64-bit capable. In fact, I would expect MOSX to ship in that fashion for a while, because there will still be a vast number of 32-bit systems out there. Of course, Apple has proven itself perfectly capable of shutting slightly older Macs out of newer OS builds, but this would be a bit extreme even for them.



    ZO, the problem is that, once you move to a 64-bit environment, applications compiled for that environment aren't backwards-compatible. If Apple were to ship both 32- and 64-bit systems at the same time, developers wouldn't bother coding for 64 bits, since they'd lose that part of the computing market; therefore, there's no advantage to Apple doing so except during a transition period. Plus, the server market's negligible for Apple, so why bother?



    You could, I suppose, also package both 32- and 64-bit aware versions of an application in a MAB (or "fat" binary) ... but that way, methinks, lies madness. (Madness may be in our future nonetheless.)
  • Reply 5 of 11
    [quote]Originally posted by Kickaha:

    <strong>64/32 bittedness doesn't require two code bases, just two compiles.</strong><hr></blockquote>



    To get needlessly technical, this isn't necessarily true, since you're moving from an ILP32 to an I32/LP64 model; assumptions about the width of particular types, including type equivalence (e.g., sizeof(int) == sizeof(long)) and address arithmetic, can break existing code. I would imagine, however, that Apple has a concerted effort underway to clean out any cruft in the old NeXT code and use derived types.



    [ 10-14-2002: Message edited by: The Watchful Babbler ]</p>
  • Reply 6 of 11
    [quote]Originally posted by The Watchful Babbler:

    <strong>You could, I suppose, also package both 32- and 64-bit aware versions of an application in a MAB (or "fat" binary) ... but that way, methinks, lies madness. (Madness may be in our future nonetheless.)</strong><hr></blockquote>Madness, perhaps. But why else do you think Apple structured the .app package the way it is?



    There could easily be fat apps that share the same resources but use different binaries in the platform folders. Specifically, note the Contents/MacOS/ directory in any app -- Apple could add one called MacOS64 or GPUL, etc.



    This directory first caught my attention in DP2 when it was actually named like this:



    /Support Files/Executables/Mac OS X



    So, Apple has clearly been planning on making fat apps an option for the future.
  • Reply 7 of 11
    zozo Posts: 3,117member
    well, if Apple keeps dev cycles as they have been going on, sometime in Feb/March we should be seeing OSX 10.3DP with 64bit support so that by around MWNY or Seybold 10.3 64bit can actually be released.



    In other words, we should be seeing a Developer Release in 4-5months, no? Then again... what developers (except maybe the highest tiers) would get access to PowerMac 970s?



    That would be pretty sweet... get OSX 10.3 64bit DP and get a developer preview of hardware as well.



    On the other hand, (this may seem a stupid question, but lets get it out of the way at least), COULD Apple release a 64bit Proc and yet still only run the current 32bit OSX on it seeing that the 970 is fully 32bit backward compatible?



    That way, release the GPUL hardware, and slowly adjust everything to 64bit?
  • Reply 8 of 11
    [quote]Originally posted by ZO:

    <strong>

    On the other hand, (this may seem a stupid question, but lets get it out of the way at least), COULD Apple release a 64bit Proc and yet still only run the current 32bit OSX on it seeing that the 970 is fully 32bit backward compatible?



    That way, release the GPUL hardware, and slowly adjust everything to 64bit?</strong><hr></blockquote>



    Sure; the 64-bit Power series has a 32-bit compatibility mode, so you can fall back with no problems.



    [quote]

    <strong>

    There could easily be fat apps that share the same resources but use different binaries in the platform folders. Specifically, note the Contents/MacOS/ directory in any app -- Apple could add one called MacOS64 or GPUL, etc.

    </strong>

    <hr></blockquote>



    MACHO has fat binary capability, so you wouldn't need to have different binaries as long as you build correctly ... but you bring up an interesting point regarding the .app structure -- I didn't think of it on that level as well.



    [ 10-14-2002: Message edited by: The Watchful Babbler ]</p>
  • Reply 9 of 11
    kickahakickaha Posts: 8,760member
    Oh heck, NeXT had fat binaries for x86, 680x0, Sparc... basically for any platform it ran on.



    Single app package, same files, runs on several CPU-incompatible machines and OSs.



    Old news.
  • Reply 10 of 11
    [quote]Originally posted by The Watchful Babbler:

    <strong>



    Sure; the 64-bit Power series has a 32-bit compatibility mode, so you can fall back with no problems. </strong><hr></blockquote>



    I thought there were "minor" code changes required for 32 bit code to work on the 970.
  • Reply 11 of 11
    kickahakickaha Posts: 8,760member
    Nope, there are 'minor' code changes needed for a 32-bit **OS** to run on the 970. Apps need no changes.
Sign In or Register to comment.