Dear all, In the 64 bit VSSAPI.dll in 64 bit windows OS, the decorated name "?CreateVssBackupComponents@@YGJPAPAVIVssBackupComponents@@@Z" changes..
Hence using Volume Shadow service in 64 bit machines using 64 bit client fails.. 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 #ifdef _WIN64 #define VSSVBACK_ENTRY "?CreateVssBackupComponents@@YAJPEAPEAVIVssBackupComponents@@@Z" #else #define VSSVBACK_ENTRY "?CreateVssBackupComponents@@YGJPAPAVIVssBackupComponents@@@Z" #endif Regards, Riyas -----Original Message----- From: Kern Sibbald [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2008 8:54 PM To: Josh Fisher Cc: [email protected]; 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 windows > >> 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 cannot > > comment. In general (maybe not 100%) Bacula can accept time_t values > > greater than 32 bits. However, removing the #define is for the moment > > rather useless because we have many years to go before time overflows. > > 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 very > > well could be some 32/64 bit problems depending on how they define > > things. Using a different C compiler requires porting and needs very > > careful testing. I personally would not run such a program in production > > without careful examination of a lot of things and testing for at least a > > month. > > I think porting would be required anyway, in a sense. AFAIK, only 32-bit > 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 it probably would be a much easier port than MS VC++ ... Thanks. Kern > > > 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 http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
