[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] Bacula Windows Client 64bit build.
I thought 32bit client could use VSS features on 64 bit Windows machines
Thanks for the msdn link.
Yesterday 64bit client was tested on 64 bit windows server 2008, VSS was
found to be working fine.
I used visual studio for taking the 64 bit build. Bacula client
dependencies like zlib, openssl, pthread etc were also rebuilt for 64
Tried using 64 bit cross compiler mingw-w64 for building bacula client
for 64 bit windows. But dropped the plan since my linux machine broke
while forcing glibc. :-)
So again reverted to Visual Studio 2005 for taking the 64 bit build.
Bacula.def was modified to address the changed mangled names.
vssgeneric file was modified to address the new mangled name of function
in 64bit vssapi.dll
some preprocessors were modified for compilation.
Manifest file for 64 bit was added to pick up the correct CRT.
This native 64 bit client was tested on windows server 2008-64 and
windows vista-64 and was found to be working fine.
VSS feature was also tested.
64 bit build of bacula windows client should be looked into since 32 bit
bacula client on 64 bit windows wont be able to use the VSS feature.
[mailto:bacula-devel-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Kern
Sent: Friday, August 08, 2008 2:26 PM
To: Matthew Rhoten
Subject: Re: [Bacula-devel] Bacula Windows Client 64bit build.
On Friday 08 August 2008 08:49:02 Matthew Rhoten wrote:
> Hi folks,
> Apologies if I missed some of this thread; I just joined the list and
> don't see this mentioned in the archives prior to my joinin, so
> I thought I'd chime in.
> The reason a Windows 64-bit bacula-fd will be useful is that it would
> fix VSS support on x86-64 Windows clients. The VSS APIs don't work
> from within wow64, at least on Vista and later versions of the OS, as
> documented here:
Well, if I understand this correctly our Win32 Bacula FD (32bit) should
run on a 64 bit windows, or at least the VSS part will fail. Amazing
Microsoft seems incapable of making anything upward compatible! I'm
surprised that no one has filed a bug report on this. Riyas has
some problems, but I find your information above really pin points it
> It sounds like Riyas is making good progress on that front, at least
> using VS to build.
Sorry, but I don't know what VS is.
> Once all that's in the trunk I'm happy to help in
> getting it building with mingw.
Everything is already in the trunk, but it builds a 32 bit version of
> I should mention I have no mingw
> experience (but plenty of Windows experience).
Well mingw is not very complicated. Once you have the pre-requisites
and built, on Linux you type "make" in the correct directory and the
is a Win32 .exe installer for Bacula.
It will need some tweaking to convert it to a 64 bit build, which I
the cross compiler now supports.
> Incidentally, I noticed that the latest version of the VSS SDK (7.2)
We use a very old version of the VSS SDK, which I have modified to
Vista. The newer versions have a lot of changes and don't build out of
box with mingw, so I haven't taken the time to try to adapt to them. In
fact, I would like to find someone to write a GPLv2 version of the VSS
(we use only a very small part of it). That would simplify our license
allow us to distribute the full source code.
> doesn't use mixed-case filenames as the Bacula build environment and
> docs assume, so there's been some drift there. There's also been minor
> interface drift requiring a rebuild of bacula.def.
I assume you are meanding bacula.def won't work with the newer versions
VSS SDK, which I don't at all doubt. However, for building everything
are currently configured bacula.def is consistent. There may be a day
when it fails because we have added some new source subroutine and
needs an update, but that doesn't happen too often.
> I also read with interest the thread about service/GUI separation. I
> haven't been in the code to see how easy it would be to get this done
> with proper privilege separation, but that would be high on my list as
It is a rather straight forward project. One just needs to take the
monitor code and copy (probably not move) it into a separate standalone
program then add the TCP/IP config and communications files from
then modify the interface slightly to use TCP/IP to get the info.
> With VSS support enabled, many users could limp by by marking
> the FD executable manifest as requiring administrator credentials, but
> this would require a UAC check every invocation, wouldn't run unless
> the particular user was logged on, etc. If the 64-bit stuff is more or
> less taken care of, I could look at that next.
I am not sure what you mean by "if the 64-bit stuff is more or less
of", because to the best of my knowledge Bacula does run on 64 bit Win32
computers (barring any potential problems with VSS). Were you referring
the idea of getting the FD working with VSS on 64 bit Windows computers
Actually, I have an Win32 64 bit AMD laptop, so I probably should try
Some help with Windows programming would be an enormous help for the
In my opinion, the most important Win32 task at the moment is to get our
experimental Win32 bat, which is still a bit unstable, running smoothly
that it can be released in production. Bat has basically nearly all the
Win32 tray monitor features, plus all the features of bconsole and
This SF.Net email is sponsored by the Moblin Your Move Developer's
Build the coolest Linux based applications with Moblin SDK & win great
Grand prize is a trip for two to an Open Source event anywhere in the
Bacula-devel mailing list
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.