Re: D8 may be 32 bit only
From: Joshua Williams (willij3_at_mac.com)
Date: 03/18/04
- Next message: Joshua Williams: "Re: D8 may be 32 bit only"
- Previous message: Eric Grange: "Re: "Faster, More Powerful . 64 Bits!""
- In reply to: Nick Hodges (TeamB): "Re: D8 may be 32 bit only"
- Next in thread: Craig Stuntz [TeamB]: "Re: D8 may be 32 bit only"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 18 Mar 2004 09:11:50 -0800
"Nick Hodges (TeamB)" <nickhodges@yahoo.com> wrote in message news:<40590307$1@newsgroups.borland.com>...
> Will DeWitt Jr. wrote:
>
> > will very likely
>
> You overstate the case again, Will. I think he said "leaning towards".
> In addition, he's polling for thoughts. Carrying on a conversation as
> if the decision has been made seems a bit over the top to me.
Hey guys, I wish that I could have been involved in this thread
earlier. I just wanted to add a few points to my earlier blog entry
re: this thread.
1) Leaning twoards does mean still making the decision. We have a
solution coded up, but we're not sure if it is the right solution. I
am really enjoying the debate that this topic has started in the
community, and I have been bringing the debate back to the people
making the decision because I believe they can make a much more
informed decision with the help of all these extra data points.
2) MS is betting on managed code big time, for both 32bit and 64bit
worlds. SQLCLR is going to be a big step forward for SQL in Yukon,
Longhorn will be highly managed code (shell, WinFS, etc...) and much
of our internal development is moving in that direction.
3) When I made the Win64 vs. CLR64 comparison it was to make the point
that without Win64 CLR64 is kind of a moot point right? CLR64 doesn't
run on a 32bit version of WinXP, so if we bit the hand that feeds us
by having some apps randomly crash and make it look like Win64 is
buggy then we don't get as many people buying into managed code.
4) As for future Delphi releases supporting running in 64bit, all that
needs to needs to happen from the compiler side is to move to the CLR
2.0 PE headers which include some concept of bitness. Then if Delphi
generates code that is MSIL (processor agnostic, this is as denoted by
the compiler, not by the code, you can write code that will blow up
and call it MSIL, that is a bug in the code) it will run natively on
whichever platform you put it on. It is my understanding that we've
distributed that spec to other compiler creators who are interested in
targeting v2.0 (I will check on that, maybe we won't be handing it out
until the beta??).
5) Windows API of the future... This is a hot and debateable topic. I
think we're moving to a managed WinFX world, but that's just an
opinion and in no way represents a proven fact. A lot of it will
depend on developer adoption...
Josh Williams [MS]
p.s. yes, I'm writing this from my .mac account, last time i posted to
newsgroups with my MS account the amount of spam in my inbox increased
exponentially.
- Next message: Joshua Williams: "Re: D8 may be 32 bit only"
- Previous message: Eric Grange: "Re: "Faster, More Powerful . 64 Bits!""
- In reply to: Nick Hodges (TeamB): "Re: D8 may be 32 bit only"
- Next in thread: Craig Stuntz [TeamB]: "Re: D8 may be 32 bit only"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
