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

"GreyCloud" <cumulus@xxxxxxxx> wrote in message news:FY6dndWn3qlI7GLUnZ2dnUVZ_jOdnZ2d@xxxxxxxxxxxxxx
Dan Johnson wrote:
[snip]
LP64 for all other vendors except M$.

That's what I remembered.

That's completely trivial; it's not even Windows, it's what MS's C++ compiler does. If you want LP64 or ILP64, you can use gcc on Windows, or Intel's compiler. If you aren't using C or C++, it's _completely_ irrelevant to you.

Well, it isn't irrelavant.

If you aren't using a C-compatible language, it is.

Heck, you might not have *any* type named "int" or "long" or "pointer"; they are just *names*, Grey. The meanings are available under other names, and it's just not a problem.

You see, Apple uses gcc 4.2. So the memory model is LP64.
Then you have to address the fact that you have to match up with the libraries that are supplied.

On Unix this is so. On Windows, however, the Win32 libraries all use macros or typedefs for all types in the headers. You would need to edit a few header files so they no longer use 'int' for the basic definitions.

Nobody does this because there is no benefit to doing it.

A much different case with windows. With windows you really need to use Visual Studio along with
their libraries if you want an application.

The libraries you really need are the .DLLs that ship with Windows.

Cygwin... ?? I don't know how extensive their libs are.

Much, much less extensive than Win32, I believe. :D

C#, for instance, uses LP64 these days.

I wouldn't know about that part, but then it'd have to have LP64 libs completely.

Not at all. It just means you can't use the Win32 header files directly, since when they say 'long' they mean 'signed 32-bit integer'. When you translate them to C#, you replace replace 'long' with 'int'.

It makes *exactly* no difference to the binaries produced at any level.

[snip]
http://en.wikipedia.org/wiki/64-bit

Because device drivers in operating systems with monolithic kernels, and in many operating systems with hybrid kernels, execute within the operating system kernel, it is possible to run the kernel as a 32-bit process while still supporting 64-bit user processes.

x86-64 doesn't support this officially, but Apple has hacked it.


Of course it does. Ever check out the Intel and AMD architecture manuals?

Yeah, the Intel ones anyway. Didn't bump into a 32-bit kernel/64-bit user-space mode though.

[snip]
Yeah; they should have done it properly. But it'll be no big deal if they go to a 64-bit kernel in Snow Leopard, as I have read. I anticipate no serious problems for Apple because of this.

Hardly. I can run both 32-bit drivers as well as 64-bit drivers under Leopard with no trouble.

No, you can't. There are no 64-bit OS X drivers yet. When Snow Leopard comes out, there then will be- and they won't work in Leopard.

I remember HPs website early in 2008 having users to wait for 64-bit drivers for Vista until HP got around to writing them.
Now that is stupid.

You'll get to do the same thing with Snow Leopard.

[snip]
Why would any editor need to be 64-bit if the os can execute the 32-bit editor in a 64-bit environment?

Well, they might need more RAM than a 32-bit kernel can handle, I suppose.


I doubt that seriously. Have you ever written anything that would take up more than 4Gb of ram?

Yes. But then they made fix it. :D

However, Apple's 32-bit kernels can use more RAM than that. There's a limit due to the size of the page tables that can fit in a 4 GB kernel, which is why Snow Leopard is going to have a higher max RAM than Leopard did.

But Apple's larger issue is not the kernel; it's 64-bit Carbon, or rather not having 64-bit Carbon when the apps that want all that memory use Carbon.

I do believe that Carbon is 64-bit.

I doubt this. It was all over the Mac news when Apple cancelled 64-bit Carbon. You must have seen it, surely.

Otherwise, how would you be able to compile using the -m64 switch using gcc?

By not using Carbon. Think Cocoa!

And also being able to use Cocoa in an OpenGL situation?

OpenGL has nothing to do with it. But I have read that some bits of 64-bit Carbon were kept, even though they were officially 'cancelled', just so Cocoa could use them. They are not exported for the user of 3rd party apps, though, so they are quite unhelpful in practice.

I have read that the Carbon menu manager is like this.

[snip]


.

Relevant Pages

  • Re: Micro$haft desperate! Buy Windoze 7, get (virtual) XP free!
    ... it's not even Windows, it's what MS's C++ compiler does. ... Because device drivers in operating systems with monolithic kernels, and in many operating systems with hybrid kernels, execute within the operating system kernel, it is possible to run the kernel as a 32-bit process while still supporting 64-bit user processes. ... Leopard with no trouble. ... rather not having 64-bit Carbon when the apps that want all that memory use Carbon. ...
    (comp.sys.mac.advocacy)
  • Re: New Patch Fixes 43 Flaws In OS X, Many Serious
    ... A product being a "Unix" has no security implications ... Mac OS X would then become higher ... So it is with any kernel, ...
    (comp.sys.mac.advocacy)
  • Re: computers review
    ... He's arguing it's not Leopard. ... the battery must be out of power and the battery ... Is Snit arguing that Leopard is involved, ...
    (comp.sys.mac.advocacy)
  • Re: Story Time
    ... In this case, the General Public License says that "you" can freely use "his" code, but that if you distribute the subsequent binaries to anyone else, you must share your changes with "them". ... the GPL encourages you to charge money for shipping your code to your distributees. ... difference ins the kernel between the two versions. ...
    (comp.os.vms)
  • Re: computers review
    ... Leopard as the causation. ... I still don't understand how the battery ... Snit is lying again... ...
    (comp.sys.mac.advocacy)