[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] Bacula Windows Client 64bit build.
In the 64 bit VSSAPI.dll in 64 bit windows OS, the decorated name
Hence using Volume Shadow service in 64 bit machines using 64 bit client
Using 32 bit client on 64 bit windows machine won't create any
problem... since it uses 32 bit VSSAPI.dll
So we may need to change bacula\src\win32\filed\vss_generic.cpp, like
From: Kern Sibbald [mailto:kern@xxxxxxxxxxx]
Sent: Wednesday, July 30, 2008 8:54 PM
To: Josh Fisher
Cc: bacula-devel@xxxxxxxxxxxxxxxxxxxxx; Riyas Y.
Subject: Re: [Bacula-devel] Bacula Windows Client 64bit build.
On Wednesday 30 July 2008 17:18:29 Josh Fisher wrote:
> Kern Sibbald wrote:
> > On Wednesday 30 July 2008 12:30:42 Riyas Y. wrote:
> > ...
> >> We could successfully backup and restore using the ported 64 bit
> >> bacula client.
> >> We are still unsure whether these warnings will cause some serious
> >> problems later.
> > I cannot tell you because I have not seen the warnings.
> >> Similarly we removed the _USE_32BIT_TIME_T preprocessor for 64 bit
> >> windows architecture.
> >> We are also unsure whether this will cause any problems.
> > I have never seen the _USE_32BIT_TIME_T preprocessor define, so I
> > comment. In general (maybe not 100%) Bacula can accept time_t
> > greater than 32 bits. However, removing the #define is for the
> > rather useless because we have many years to go before time
> Windows normally uses a 64-bit time_t, so I believe the intent of that
> define is to force the use of 32-bit time_t, which may be useful if
> compiling older source that assigned time_t values to int variables,
> etc. I doubt it is relevant, since Bacula almost certainly always uses
> time_t for time values.
> > Since you are using Microsoft C++, which we do not support, there
> > well could be some 32/64 bit problems depending on how they define
> > things. Using a different C compiler requires porting and needs
> > careful testing. I personally would not run such a program in
> > without careful examination of a lot of things and testing for at
> > month.
> I think porting would be required anyway, in a sense. AFAIK, only
> versions have been tested. The mingw-w64 compiler
> (http://sourceforge.net/projects/mingw-w64/) might be an easier port
> than MS VC++.
Interesting, I didn't know there was a mingw-w64, and I agree with you
probably would be a much easier port than MS VC++ ...
> > Regards,
> > Kern
> >> Regards,
> >> Riyas
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Bacula-devel mailing list
This mailing list archive is a service of Copilotco.