[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] Bacula Windows Client 64bit build.

Hello Matthew,

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:
> http://msdn.microsoft.com/en-us/library/bb968832(VS.85).aspx

Well, if I understand this correctly our Win32 Bacula FD (32bit) should not 
run on a 64 bit windows, or at least the VSS part will fail.  Amazing how 
Microsoft seems incapable of making anything upward compatible!  I'm 
surprised that no one has filed a bug report on this.  Riyas has mentioned 
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 the FD.

> 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 loaded 
and built, on Linux you type "make" in the correct directory and the result 
is a Win32 .exe installer for Bacula.

It will need some tweaking to convert it to a 64 bit build, which I understand 
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 support 
Vista.  The newer versions have a lot of changes and don't build out of the 
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 SDK 
(we use only a very small part of it).  That would simplify our license and 
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 of the 
VSS SDK, which I don't at all doubt.  However, for building everything as we 
are currently configured bacula.def is consistent.  There may be a day or two 
when it fails because we have added some new source subroutine and bacula.def 
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
> well. 

It is a rather straight forward project.  One just needs to take the tray 
monitor code and copy (probably not move) it into a separate standalone 
program then add the TCP/IP config and communications files from bconsole, 
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 taken care 
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 to 
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 it.

Some help with Windows programming would be an enormous help for the project.  
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 so 
that it can be released in production.  Bat has basically nearly all the 
Win32 tray monitor features, plus all the features of bconsole and 

Best regards,


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.