Re: Why 64bit Delphi compiler from Borland may be meaningless!

From: Abdullah Kauchali (non_at_non.com)
Date: 01/22/05


Date: Sat, 22 Jan 2005 16:21:55 +0200

gustavo wrote:

> Hi Abdullah, let me try to clarify things for you. One point is the
> possibility of running Delphi7 in a 64 bit windows. Yes it will --probably--
> be possible as it is possible to run Delphi1 (16 bit) in Windows2000 (32
> bit). There is a kind of emulation layer called WOW (Windows on Windows)
> that allows that. The other point is compiling --nativelly-- to 64 bits. In
> this way, the compiled app would run directly in 64 bits mode without any
> layer between it and the OS. To enable this Borland must build a brand new
> compiler and update the VCL (just a few things) to conform the new struct
> and pointer sizes. As it is done Borland will have a --new-- product that
> will be able to produce --native-- Win64 executables. You must notice that
> ALL MS apps are OS native, not .NET ones. As it is true, there is no reasons
> to think .NET API is the only way to go. Not in a minimum 5-6 years
> time-frame.

Hi Gustavo!

Finally, light-bulb! Thank you! (I *am* slow sometimes!) :)

LOL! I've just spent the last 45 minutes reading FAQ's and articles on
MSDN.

I can confirm the following:

1. There is *already* a Win64 compiler from Microsoft that takes your
*existing* win32 code in C++ (MFC? I'll confirm later) and compiles it
to win64 native with the beta version of win64 platform sdk. This, so
that you can take advantage of the new processor and avoid point 3
below.

2. .NET will continue to be a wrapper around win64 as it is a wrapper
around win32 currently! (Jezaas!)

3. For applications not recompiled with a 64bit-compliant compiler,
they will continue to run but under an emulation called WOW64. <g> This
will not affect .NET applications because there will be a *different*
.NET runtime for the 64 bit OS ensuring backward compatibility
*without* a recompile (JITter obviously assuming the necessary work for
you). (Another missing piece of the puzzle in my head.)

4. All enhancements to the core API on Windows 32 have stopped in
favour of the new 64bit API (that's what they meant by "win32 is dead").
Enhancements will however continue on the 64 bit platform *only*. Each
time a new api is introduced in the win64 platform sdk, .NET will
support it with its *own* wrapper and a new upgraded runtime.

5. Platform SDK for 64bit Windows will be finalised before Win64 hits
the shelves and so it *will* be publicly supported!!!

Boy, do I feel like a moron. :)

Where do I sign-up for the goddamn 64bit Delphi petition?!

ps. I think there are forces around us that are deliberately
misleading. Microsoft PDC is evil. I was convinced of the direct
relationship between the demise of win32 and the rise of .NET. Not
true! Not true at all!

I wonder how many are plagued with this mis-idea?



Relevant Pages

  • Re: Building Debug version of MIT kerberos for windows
    ... The only Platform SDK that is supported is the "Windows XP SP2 Platform ... The compiler that is used to build it is VS.NET 2003. ... > development environment as well as on Windows XP environment. ...
    (comp.protocols.kerberos)
  • Re: Calling all AppleWin Developers and Users!
    ... but I don't have a C compiler for Windows. ... You need the DirectX SDK and the platform SDK if you use 2005. ...
    (comp.emulators.apple2)
  • Re: Serious Treectrl 2.2.3 memory problem on Vista
    ... Studio 2005 Express plus the platform SDK ... Windows 2003 R2 seems to have cured the problem. ... are we talking about 32-bit builds running also on vista 32-bit? ... includes a 32-bit compiler. ...
    (comp.lang.tcl)
  • Re: Calling all AppleWin Developers and Users!
    ... but I don't have a C compiler for Windows. ... You need the DirectX SDK and the platform SDK if you use 2005. ...
    (comp.emulators.apple2)
  • Re: hmm..interesting
    ... you've got a discussion of ARM vs Intel architecture here: ... And ARM is rapidly running away from RISC. ... mainstream (many netbooks and smartphones run Linux instead of Windows ... And hardly any C compiler does. ...
    (comp.sys.acorn.hardware)