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

Dan Johnson wrote:
"GreyCloud" <cumulus@xxxxxxxx> wrote in message news:rfCdnbZR0Kdw4Z3XnZ2dnUVZ_q2dnZ2d@xxxxxxxxxxxxxx
Dan Johnson wrote:
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.

Yeah, just names. < laugh > These are tags for the compiler to determine how storage for variables
is to be allocated. No problem eh? Guffaw!!!
Go read some of chomskys works.

The famous linguist? I am not seeing the relevance.

http://en.wikipedia.org/wiki/Noam_Chomsky

He taught at MIT. His basis in linguistics seems to have affected the means of parsing expressions for computers.
Lexical analyzers rely on this technique.


[snip]
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.

< laughing harder > The defines are based on what the compiler will be helped to understand.

The defines are alternate names that can be controlled outside the compiler, in a header file. You don't have to use the built-in type names in C; if you don't, you don't need to depend upon the whole '64-bit model' thing.

For an 'int' the compiler can handle that directly. But if you use 'MYINT' without a definition for the compiler,
it will err out.
So somewhere the 'int' for LP64 has to be defined in a header so that the C or C++ compiler can handle it correctly
in regards to memory allocation needs.


The 'int' is still the base for which you would define another moniker for to help the programmer.

You don't have to use it. The latest C standard provides explicitly sized types for you to use, as well: you can use int32_t, for instance, to get a signed 32-bit int.


Of course and are defined in a header that reduces down to the more common 'int',
or whatever basic storeage allocation requirement you are looking for.

However, the Windows headers are used with many compilers, including really old ones that don't have this. So you get stuff like DWORD and friends. Same idea, but self-contained.


Yes, I'm aware of that and I think we are in agreement on this point.

[snip]
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.

Of course and without them you are dead in the water.

You don't need Visual Studio to have these libraries. You need Windows.


But without Visual Studio you can't develop programs for windows. Both go hand in hand.

[snip]
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'.

Which backs up my earlier comment. It seems you are flip-flopping around now.

It does no such thing.


Don't care about C#. OS X doesn't have it so I'm not concerned with it.
OS X has Java instead.

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

But it does make a difference to the compiler that you are using. The compiler generates the code.
And then the linker needs to link this code to any lib calls. And if the code generated doesn't match the format in the lib, then an
error message is generated and you don't get a working program.

The linker does not care what you *call* the types. If you must pass a signed 32-bit integer, you can call it 'int', 'long', 'DWORD', 'int32_t', or whatever you like.


Oh, it will care. If the storeage allocation for a variable isn't set right and you make
a call to one the lib routines that receives something different than what it expects, your program
is going to bomb on you.

Microsoft feels it is easiest if they do not *change* the meanings of these names unnecessarily, which is what your LP64 model does: it changes 'long' so it means a 64-bit integer instead.


I think we can agree on this point easily. That was what I was trying make my point on.

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

In both vendor docs, in 64-bit mode the use of legacy code can be executed, such as the old 8080 code.

No, this isn't what I read in there. In 64-bit mode there are two sub-modes, one for 32-bit compatibility and one for 64-bit stuff. 8080 compatibility is not provided. Nor, more importantly, is 8086 or 80286 compatibility.


As I understand it as I read in Intels docs, you can.
For some reason AMDs docs aren't easy to find.


[snip]
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.

Yes, you can. You are still pushing disinformation here.
As long as the os is 64-bit, you can execute 32-bit code generated for the older archs.
Why M$ didn't get this right is a big question only M$ knows about.

MS did get this right; you can run 32-bit code on 64-bit Vista. But not 16-bit, without 'XP Mode'.


Then that is an os issue. It can be done but probably no one would use it.

Which is why XP Mode is more than useless.


A gamer might disagree with you there. He may want the Aero look on a 64-bit os, but would like
to run his XP version of his favorite game. Not that it is important to me, it is just that I have perused
the gamers sites to see what was really going on with Vista for them.

[snip]
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

Oh sure you have. not.

I'm really, really good at memory leaks! :D

[snip]
Guffaw!!! Doubt all you want, but you'd have to provide a link to this.
Apple is still keeping Carbon up to date due to the OpenGL requirements.

If you insist. Here's a early news article:
[http://arstechnica.com/apple/news/2007/06/64-bit-support-in-leopard-no-carbon-love.ars]


From page 47 of "OpenGL Programming on Mac OS X":

AGL is the Carbon interface to OpenGL on the Mac. Carbon is a set of C-level APIs to most Mac systems, and
is the foundation of many an older Macintosh application. Carbon is by no means a deprecated API set;
in fact, quite the opposite is true. Carbon-layer APIs tend to be the first place you see lots of new functionality
for the Mac. You can also create full-featured, modern, Mac OS X applications written entirely in Carbon.


Of course the book also covers the AGL and the Cocoa aspects as well. Of course AGL isn't 64-bit capable.
I don't put much in a web article that isn't researched or considered well as I do in a well researched book that is
for sale. In this case using the examples from the book is the 'proof-in-the-pudding'.


Here's the Apple docs:
[http://developer.apple.com/documentation/Carbon/Conceptual/Carbon64BitGuide/Introduction/Introduction.html]


Your problem is that you think Core Foundation is Carbon. Not everything that is C is Carbon.


And of course another passage in the above forementioned book is that Cocoa for OpenGL is layered over Carbon.
And you know that Cocoa can be used to create 64-bit OpenGL programs. Going deeper it also shows how one can
improve performance by using the 64-bit aspect of the Intel processor. So one has to be careful in saying which is
64-bit and which isn't. What isn't is AGL.



--
"It is impossible to defeat an ignorant man in argument."
William G. McAdoo.
American Government official (1863-1941).
.

Relevant Pages

  • Re: Parameter Name Warning?
    ... there is more to those names than just what the compiler does with them. ... You know only what you get in the header. ... correct for me in the watch window. ... >> int main ...
    (microsoft.public.vc.language)
  • Re: Parameter Name Warning?
    ... the names on the declarations do not matter, it should perhaps give a warning regarding different names being used. ... > there is more to those names than just what the compiler does with them. ... > You know only what you get in the header. ... >>> int main ...
    (microsoft.public.vc.language)
  • Re: Error in compliling AODB _ConnectionPtr
    ... The compiler ignores ALL input ... because it may affect the definitions in that header. ... >> int main ... I had it wrong at first anf the complier never complained. ...
    (microsoft.public.vc.atl)
  • Re: Tool to determine which headers are needed/not_needed?
    ... Surely that's too simplistic - consider a header containing: ... #undef FOO ... int a=1; ... Then with the default options on a lot of compilers the compiler will *not* complain, it will just silently compiler the code with what is now undefined behaviour which may or may not work. ...
    (comp.lang.c)
  • 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)