64 bit Vista

[Frank M. Cook]

I'm not sure whether this is the right newsgroup in which to ask this
question, but I need to start somewhere. Can someone give me the
ultra-short course in 64 bit operating systems. Our current product is
built in CB3 but we're moving to CB2007. Every once in a while we get a
call from a customer who has bought a 64 bit computer not really knowing
what they are getting and our current product won't even install. I
certainly remember the old days when 16 and 32 bit was a library option but
I don't have a clue about 64 bit. Can I make a 64 bit application with
CB2007 assuming I dump the BDE and use an appropriate database? If so, will
it be easy to maintain both 32 and 64 bit versions from the same source code
or are these just two different worlds that will need entirely different
components?

--
Frank M. Cook
www.acsplus.com

[Remy Lebeau (TeamB)]

"Frank M. Cook" <fc...@acsplus.com> wrote in message
news:48499254$1...@newsgroups.borland.com...

> Can I make a 64 bit application with CB2007

No. None of CodeGear's products are 64bit-enabled yet. That is not
scheduled to be released for another year or so.

> will it be easy to maintain both 32 and 64 bit versions
> from the same source code

There are ways to do that. Microsoft has already made updates to many of
its macros and pointer types in recent Platform SDKs to handle 32bit->64bit
migration. You would have to make changes to your code to use the new
types, but once you do that you would be a step closer, at least.

> are these just two different worlds that will need entirely
> different components?

Existing components would have to be recompiled for 64bit, since pointer
sizes are different and such.

Gambit

[Jonathan Benedicto]

Frank M. Cook wrote:
> Every once in a while we get a call from a customer who has bought a 64
> bit
> computer not really knowing what they are getting and our current product
> won't even install.

If they are using Windows XP 64-bit or Windows Vista 64-bit, your
application should work just fine. Both those operating systems have
complete 32-bit backwards compatibility.

You don't need to make your application 64-bit for it to be able to run on a
Windows 64-bit OS.

Jon

[Darko Miletic]

Jonathan Benedicto wrote:
> If they are using Windows XP 64-bit or Windows Vista 64-bit, your
> application should work just fine. Both those operating systems have
> complete 32-bit backwards compatibility.
>
> You don't need to make your application 64-bit for it to be able to run on a
> Windows 64-bit OS.

However just to be sure get yourself a trial copy of AQtime 5
(http://www.automatedqa.com/products/aqtime/index.asp) and run your BCB3
executable with Platform Compliance static analysis. It will show you if
your executable is supported under 64 bit OS'es.

[Frank M. Cook]

<<If they are using Windows XP 64-bit or Windows Vista 64-bit, your
application should work just fine.>>

won't even install. is this just an issue with the InstallShield version
that was included in the old CBuilder? if I use the install from CB2007
with my CB3 application, will I get by that hurdle?

[Frank M. Cook]

<Also, provide exact error messages. In theory, there should be no problem
running 32 bit apps on 64 bit OS.>

the installation program generates an error saying that this program is
incompatible with the operating system. we don't even get our application
installed.

[Alex Bakaev [TeamB]]

Frank M. Cook wrote:
> I'm not sure whether this is the right newsgroup in which to ask this
> question, but I need to start somewhere. Can someone give me the

You may post this in the .cpp.non-technical. Also, provide exact error

[Jonathan Benedicto]

Frank M. Cook wrote:
> won't even install. is this just an issue with the InstallShield version
> that was included in the old CBuilder? if I use the install from CB2007
> with my CB3 application, will I get by that hurdle?

Ok, that makes sense - AFAIK, the old InstallShield was a 16-bit
application, which does not run on a 64-bit OS. You'll have to get a better
installer.

Either InstallAware (bundled with CB2007) or InnoSetup should work for you.

HTH

Jon

[Alex Bakaev [TeamB]]

Frank M. Cook wrote:

> the installation program generates an error saying that this program is
> incompatible with the operating system. we don't even get our application
> installed.

Well, in this case it's not your program's fault. You need to use a new
installer.

[Frank M. Cook]

<<Ok, that makes sense - AFAIK, the old InstallShield was a 16-bit
application, which does not run on a 64-bit OS. You'll have to get a better
installer.>>

ah, light goes on. I knew there was a problem with InstallShield but it
never connected that it might be 16 bit. we'll build a new installation
with InstallAware and send it to the user who called today with the problem.
if we can get it installed and still have errors, I'll post a new question.
thanks all.

[Darko MIletic]

Frank M. Cook wrote:
> <Also, provide exact error messages. In theory, there should be no problem
> running 32 bit apps on 64 bit OS.>
>
> the installation program generates an error saying that this program is
> incompatible with the operating system. we don't even get our application
> installed.

Probably that old version of installshield does not handle a case where
OS is 64bit Vista. Try to get updated version of installshield or use
some open source version like nullsoft installer (NSIS)
http://nsis.sourceforge.net/Main_Page.

[Colin B Maharaj]

1. 64 bit means the pointers that allow memory access is much larger
and thus your 64 bit programs can access many scores of gigabytes of memory.
In the 32 bit world, there is a maximum of 3.5 Gigs of RAM accessible
to all applications but shared among them and the operating system.

Thus, this brings up certain fundamental philosophical questions.
a) Is your application (or customers using your app) going to be using
more than 3.5 gigs RAM?
b) Will my 64 bit hardware going to accommodate more than 4 Gigs RAM,
and how much more?
c) Most modern workstation platforms can take 8 Gigs RAM. Am I going to
be using that 8 Gigs of RAM effectively?
If your answers to a and c are no then you have nothing to worry about.

2. 64 bit also means larger registers and faster math when it comes to
64 bit numbers. However just because we run our 32 bit application in a
64 bit os/hardware - does not mean we will gain this benefit.

3. With U.A.C. turned on in Vista, you could have problems with your
application accessing the registry and others parts of the operating
system (32 and 64 bit)

4. Right click content menus are not compatible between 32 bit windows
and 64 bit windows. E.g. Winzip8 will not work properly in the 64 bit O/S.

5. Current versions of BCB may (or may not) work in 64 bit O/S but
definitely will not create 64 bit applications.

6. Microsoft has 64 bit compilers so if you want to do 64 bit coding
go there first. Codegear has this carded for next year. no telling what
the component architecture will be like. I think most vendors may have
to rewrite their components to get the benefit.

7. Certain third party installers will probably not work in Vista 64
even though your (32 bit) application can.

8. The real winners in the 64 bit game, firstly are the database people.
They can probably hold their whole multi gigabit database in RAM so they
will be smiling ear to ear.
2ndly, gamers - more RAM more speed.
3rdly, us the programmers. Now this is just a theory of mine, in that
even though we still work in 32bit, we have more access to RAM
collectively. E.g. If I have 8 gigs RAM and use bsd2007 and it takes say
1.5 gigs for the IDE and debugging, our application still will have 3.5
gigs to work with (4 gigs if you patch it). In the 32 bit world, the 1.5
gigs would have been taken away from the 4 gig max pool.

9. bds2007 will not make 64 bit apps and we do not know the state of
the new 64 versions of bds/delphi/c++builder until codegear comes out
with it. And what I mean by state has to do mostly with moving your 32
bit code to 64 bit.

hope this helps