You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by "Dennis E. Hamilton" <de...@acm.org> on 2011/11/20 07:06:37 UTC
Microsoft Tools for Windows Builds
Another conversation came up (on [libre-office]) on how to find the installed
VC++ software from within cygwin. The attempted approach involved
mucking-about in the Windows Registry in order to track down the tools. That
struck me as the long way around. The Windows Developer Tools themselves are
able to bootstrap command-line environments using a few environment variables
and some batch scripts as levers.
I also confirmed that when cygwin starts up, it absorbs the path and
environment variables that exist at the time.
This preconditioning seems much healthier than attempting to reach out from
cygwin into the Windows environment.
Here's how I demonstrated it working.
1. I have batch scripts that I use to launch console windows with the Visual
C++ environment all set up. One is the attached MyVC++.bat.txt (with the .txt
removed). It creates the correct path, environment variables, etc., for a
VC++ command-line build.
2. The second batch script, VCygwin.bat.txt (without the .txt) is placed in
my C:\cygwin folder where I can run it whenever I want a cygwin environment
that is already set up to use VC++. (A copy of MyVC++.bat is placed in the
same folder with the original cygwin.bat script and the modified VCygwin.bat.)
3. What I get when the cygwin is started using VCygwin.bat is shown in the
attached PNG file. (In the illustrated case, I am using a MyVC++.bat that
sets up VC++ 2010 Express Edition, what I have installed on the same machine I
just added cygwin to.)
4. This same principle can be used to create a setup that uses additional
included files and libraries of the Windows SDK and the ATL include files and
libraries of the Windows DDK. It is setup before cygwin is started and the
settings and tools are then available for the entire session.
That's how I would do it. (I need to test the same idea to see if it works
with the bash shell in the Windows Posix SUA subsystem.)
There's more too it of course because of the way the Windows file system is
mapped for access under cygwin and how commands to the VC++ command-line
compiler are created. But that must be done somehow either way.
- Dennis
-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
Sent: Sunday, November 06, 2011 20:49
To: ooo-dev@incubator.apache.org
Cc: 'Regina Henschel'
Subject: RE: Need a current build for WinXP 32bit
Thanks Mathias,
I found the ATL headers in the WinDDK/.../inc/atl71/, and libraries too.
There is also the ATL Reference Guide and other materials available at MSDN
on-line, along with some books in a very dusty corner of my office shelves.
That is one heck of a dependency. I wonder how much of it actually adds to
OO.o to do a static binding [;<).
It would be interesting to see how much could be replaced by plain-vanilla COM
dependencies. Not something I will be in any hurry to dig into though. Just
something to nag my mind while I concentrate on simpler things first.
- Dennis
-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
Sent: Sunday, November 06, 2011 11:44
To: ooo-dev@incubator.apache.org
Cc: 'Regina Henschel'
Subject: RE: Need a current build for WinXP 32bit
Thanks Mathias,
I missed your earlier response.
I just checked to see whether the DLLs are on my system already and they are
of course. 7.1, 8.0, 9.0, and 10.0 plus related patches.
I will look into the WDK.
This seems a good place to start:
<http://msdn.microsoft.com/en-us/windows/hardware/gg487463>.
The release notes are interesting. Hmm, 619.77 MB ISO Image. OK, time to go
do other chores while the download happens.
- Dennis
-----Original Message-----
From: Mathias Bauer [mailto:Mathias_Bauer@gmx.net]
Sent: Thursday, November 03, 2011 01:13
To: ooo-dev@incubator.apache.org
Subject: Re: Need a current build for WinXP 32bit
On 31.10.2011 20:18, Dennis E. Hamilton wrote:
> Regina,
>
> I would like to find an already built Win32 WinXP version too. I
> despair of ever succeeding in building one myself without extensive
> practice with the tools that I am expected to operate to accomplish
> that.
>
> I don't know how to deal with the ATL dependencies. I thought that it
> was going to be made available independently, but it is apparently
> still tied to VC++ 200xy non-express editions.
As I already wrote on this list some weeks ago, you can get ATL headers
by installing the Windows driver SDK. It might require to add paths to
your build environment, but basically it should work with VS Express.
It might be an idea to install the driver SDK, get the necessary stuff,
move it into a suitable location, adapt include path and library path of
your build env and then deinstall the otherwise useless SDK again.
Regards,
Mathias
RE: Microsoft Tools for Windows Builds
Posted by "Dennis E. Hamilton" <de...@acm.org>.
It looks like the Windows 7 slave should work, depending on what version is installed.
That would be a place to use one of the MSDN subscriptions (assuming the license allows it as a server function). One nice feature of the more-recents sets of tools is the ability to have side-by-side installs of different development-tool versions. (The different command-line setup scripts establish the ones used in a given situation.)
- Dennis
-----Original Message-----
From: Ross Gardler [mailto:rgardler@opendirective.com]
Sent: Sunday, November 20, 2011 11:05
To: ooo-dev@incubator.apache.org; pfg@apache.org
Subject: RE: Microsoft Tools for Windows Builds
Sent from my mobile device, please forgive errors and brevity.
On Nov 20, 2011 7:00 PM, "Pedro Giffuni" <pf...@apache.org> wrote:
>
> FWIW;
>
> It would be really nice to have a Windows buildbot.
>
> http://ci.apache.org/buildbot.html
Feel free to make such a request of infra. They work hard to support such
requests. If it is viable they will make it happen.
Ross
>
> cheers,
>
> Pedro.
[ ... ]
RE: Microsoft Tools for Windows Builds
Posted by Ross Gardler <rg...@opendirective.com>.
Sent from my mobile device, please forgive errors and brevity.
On Nov 20, 2011 7:00 PM, "Pedro Giffuni" <pf...@apache.org> wrote:
>
> FWIW;
>
> It would be really nice to have a Windows buildbot.
>
> http://ci.apache.org/buildbot.html
Feel free to make such a request of infra. They work hard to support such
requests. If it is viable they will make it happen.
Ross
>
> cheers,
>
> Pedro.
>
> --- On Sun, 11/20/11, Dennis E. Hamilton <de...@acm.org> wrote:
> ...
> > Hi Ross,
> >
> > The goal is to be able to do the Windows Build with the
> > free tools that Microsoft has available. That includes
> > the free-to-download Microsoft Visual Studio Express
> > software (specifically the Visual C++ Express Edition), the
> > Microsoft SDK, and the Windows DDK. This assures that
> > anyone can do a build for Windows without having to have an
> > MSDN Subscription or a commercially-sold version of Visual
> > Studio, so long as they can meet the configuration
> > requirements for building on a Windows PC.
> >
> > A secondary problem, independent of how one acquires the
> > Microsoft developer tools, is that the toolset and build
> > structure for OO.o looks, walks, and talks like a Unix/Linux
> > build. To have the build process work on Windows,
> > cygwin (which provides a bash work-alike and a large set of
> > Unix-style utilities) has to have access to the Microsoft
> > tools as if they were installed on a Unix system that has
> > provisions for executing Windows software.
> >
> > The experiment I did yesterday was a proof-of-concept
> > demonstration that finding the Microsoft tools from cygwin
> > is easier than digging around in the Windows registry, since
> > (1) firing up cygwin preserves the environment variables and
> > path that are set in Windows at the time and (2) all of the
> > Windows developer tool sets that run from the command-line
> > have scripts that setup environment variables and path for
> > their command-line operation. I just connected those
> > dots. There is more to do to make an easily
> > customizable bridge script, especially for running on a
> > localized version of Windows. But the concept
> > works. It also puts the Windows-configuration binding
> > outside of the build itself, so it can be performed and
> > customized prior to starting cygwin and then initiating a
> > build. It's also easy to build checks into the scripts
> > (as I did just for locating the VC++ compiler) so that an
> > user knows the configuration is located properly before even
> > attempting the build.
> >
> > This may get us over some of the gnarlies that seem to be
> > in the way of easily setting up a Windows build. But
> > it is just a proof-of-concept at this point.
> >
> > - Dennis
> >
> > -----Original Message-----
> > From: Ross Gardler [mailto:rgardler@opendirective.com]
> >
> > Sent: Sunday, November 20, 2011 02:05
> > To: dennis.hamilton@acm.org;
> > ooo-dev@incubator.apache.org
> > Cc: Regina Henschel
> > Subject: Re:Microsoft Tools for Windows Builds
> >
> > We used to have free MSDN licenses for Apache projects. I
> > can't remember
> > the details and I'm not sure if the donation is still
> > valid. Would this
> > provide what is needed in a convenient way? If so I'll find
> > or what the
> > status is.
> >
> > Ross
> >
> > Sent from my mobile device, please forgive errors and
> > brevity.
> > On Nov 20, 2011 6:07 AM, "Dennis E. Hamilton" <de...@acm.org>
> > wrote:
> >
> > > Another conversation came up (on [libre-office]) on
> > how to find the
> > > installed
> > > VC++ software from within cygwin. The attempted
> > approach involved
> > > mucking-about in the Windows Registry in order to
> > track down the tools.
> > > That
> > > struck me as the long way around. The Windows
> > Developer Tools themselves
> > > are
> > > able to bootstrap command-line environments using a
> > few environment
> > > variables
> > > and some batch scripts as levers.
> > >
> > > I also confirmed that when cygwin starts up, it
> > absorbs the path and
> > > environment variables that exist at the time.
> > >
> > > This preconditioning seems much healthier than
> > attempting to reach out from
> > > cygwin into the Windows environment.
> > >
> > > Here's how I demonstrated it working.
> > >
> > > 1. I have batch scripts that I use to
> > launch console windows with the
> > > Visual
> > > C++ environment all set up. One is the attached
> > MyVC++.bat.txt (with the
> > > .txt
> > > removed). It creates the correct path,
> > environment variables, etc., for a
> > > VC++ command-line build.
> > >
> > > 2. The second batch script, VCygwin.bat.txt
> > (without the .txt) is placed
> > > in
> > > my C:\cygwin folder where I can run it whenever I want
> > a cygwin environment
> > > that is already set up to use VC++. (A copy of
> > MyVC++.bat is placed in the
> > > same folder with the original cygwin.bat script and
> > the modified
> > > VCygwin.bat.)
> > >
> > > 3. What I get when the cygwin is started using
> > VCygwin.bat is shown in the
> > > attached PNG file. (In the illustrated case, I
> > am using a MyVC++.bat that
> > > sets up VC++ 2010 Express Edition, what I have
> > installed on the same
> > > machine I
> > > just added cygwin to.)
> > >
> > > 4. This same principle can be used to create a
> > setup that uses additional
> > > included files and libraries of the Windows SDK and
> > the ATL include files
> > > and
> > > libraries of the Windows DDK. It is setup before
> > cygwin is started and the
> > > settings and tools are then available for the entire
> > session.
> > >
> > > That's how I would do it. (I need to test the same
> > idea to see if it works
> > > with the bash shell in the Windows Posix SUA
> > subsystem.)
> > >
> > > There's more too it of course because of the way the
> > Windows file system is
> > > mapped for access under cygwin and how commands to the
> > VC++ command-line
> > > compiler are created. But that must be done
> > somehow either way.
> > >
> > > - Dennis
> > >
> > > -----Original Message-----
> > > From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> > > Sent: Sunday, November 06, 2011 20:49
> > > To: ooo-dev@incubator.apache.org
> > > Cc: 'Regina Henschel'
> > > Subject: RE: Need a current build for WinXP 32bit
> > >
> > > Thanks Mathias,
> > >
> > > I found the ATL headers in the WinDDK/.../inc/atl71/,
> > and libraries too.
> > > There is also the ATL Reference Guide and other
> > materials available at MSDN
> > > on-line, along with some books in a very dusty corner
> > of my office shelves.
> > > That is one heck of a dependency. I wonder how
> > much of it actually adds to
> > > OO.o to do a static binding [;<).
> > >
> > > It would be interesting to see how much could be
> > replaced by plain-vanilla
> > > COM
> > > dependencies. Not something I will be in any
> > hurry to dig into though.
> > > Just
> > > something to nag my mind while I concentrate on
> > simpler things first.
> > >
> > > - Dennis
> > >
> > > -----Original Message-----
> > > From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> > > Sent: Sunday, November 06, 2011 11:44
> > > To: ooo-dev@incubator.apache.org
> > > Cc: 'Regina Henschel'
> > > Subject: RE: Need a current build for WinXP 32bit
> > >
> > > Thanks Mathias,
> > >
> > > I missed your earlier response.
> > >
> > > I just checked to see whether the DLLs are on my
> > system already and they
> > > are
> > > of course. 7.1, 8.0, 9.0, and 10.0 plus related
> > patches.
> > >
> > > I will look into the WDK.
> > >
> > > This seems a good place to start:
> > > <http://msdn.microsoft.com/en-us/windows/hardware/gg487463>.
> > > The release notes are interesting. Hmm, 619.77
> > MB ISO Image. OK, time to
> > > go
> > > do other chores while the download happens.
> > >
> > > - Dennis
> > >
> > > -----Original Message-----
> > > From: Mathias Bauer [mailto:Mathias_Bauer@gmx.net]
> > > Sent: Thursday, November 03, 2011 01:13
> > > To: ooo-dev@incubator.apache.org
> > > Subject: Re: Need a current build for WinXP 32bit
> > >
> > > On 31.10.2011 20:18, Dennis E. Hamilton wrote:
> > > > Regina,
> > > >
> > > > I would like to find an already built Win32 WinXP
> > version too. I
> > > > despair of ever succeeding in building one myself
> > without extensive
> > > > practice with the tools that I am expected to
> > operate to accomplish
> > > > that.
> > > >
> > > > I don't know how to deal with the ATL
> > dependencies. I thought that it
> > > > was going to be made available independently, but
> > it is apparently
> > > > still tied to VC++ 200xy non-express editions.
> > >
> > > As I already wrote on this list some weeks ago, you
> > can get ATL headers
> > > by installing the Windows driver SDK. It might require
> > to add paths to
> > > your build environment, but basically it should work
> > with VS Express.
> > >
> > > It might be an idea to install the driver SDK, get the
> > necessary stuff,
> > > move it into a suitable location, adapt include path
> > and library path of
> > > your build env and then deinstall the otherwise
> > useless SDK again.
> > >
> > > Regards,
> > > Mathias
> > >
> >
> >
RE: Microsoft Tools for Windows Builds
Posted by Ross Gardler <rg...@opendirective.com>.
Your goal is certainly the ideal.place to be. So no MSDN at t his time,
remember it is there if you brick walls.
Thanks
Sent from my mobile device, please forgive errors and brevity.
On Nov 20, 2011 6:02 PM, "Dennis E. Hamilton" <de...@acm.org>
wrote:
> Hi Ross,
>
> The goal is to be able to do the Windows Build with the free tools that
> Microsoft has available. That includes the free-to-download Microsoft
> Visual Studio Express software (specifically the Visual C++ Express
> Edition), the Microsoft SDK, and the Windows DDK. This assures that anyone
> can do a build for Windows without having to have an MSDN Subscription or a
> commercially-sold version of Visual Studio, so long as they can meet the
> configuration requirements for building on a Windows PC.
>
> A secondary problem, independent of how one acquires the Microsoft
> developer tools, is that the toolset and build structure for OO.o looks,
> walks, and talks like a Unix/Linux build. To have the build process work
> on Windows, cygwin (which provides a bash work-alike and a large set of
> Unix-style utilities) has to have access to the Microsoft tools as if they
> were installed on a Unix system that has provisions for executing Windows
> software.
>
> The experiment I did yesterday was a proof-of-concept demonstration that
> finding the Microsoft tools from cygwin is easier than digging around in
> the Windows registry, since (1) firing up cygwin preserves the environment
> variables and path that are set in Windows at the time and (2) all of the
> Windows developer tool sets that run from the command-line have scripts
> that setup environment variables and path for their command-line operation.
> I just connected those dots. There is more to do to make an easily
> customizable bridge script, especially for running on a localized version
> of Windows. But the concept works. It also puts the Windows-configuration
> binding outside of the build itself, so it can be performed and customized
> prior to starting cygwin and then initiating a build. It's also easy to
> build checks into the scripts (as I did just for locating the VC++
> compiler) so that an user knows the configuration is located properly
> before even attempting the build.
>
> This may get us over some of the gnarlies that seem to be in the way of
> easily setting up a Windows build. But it is just a proof-of-concept at
> this point.
>
> - Dennis
>
> -----Original Message-----
> From: Ross Gardler [mailto:rgardler@opendirective.com]
> Sent: Sunday, November 20, 2011 02:05
> To: dennis.hamilton@acm.org; ooo-dev@incubator.apache.org
> Cc: Regina Henschel
> Subject: Re:Microsoft Tools for Windows Builds
>
> We used to have free MSDN licenses for Apache projects. I can't remember
> the details and I'm not sure if the donation is still valid. Would this
> provide what is needed in a convenient way? If so I'll find or what the
> status is.
>
> Ross
>
> Sent from my mobile device, please forgive errors and brevity.
> On Nov 20, 2011 6:07 AM, "Dennis E. Hamilton" <de...@acm.org>
> wrote:
>
> > Another conversation came up (on [libre-office]) on how to find the
> > installed
> > VC++ software from within cygwin. The attempted approach involved
> > mucking-about in the Windows Registry in order to track down the tools.
> > That
> > struck me as the long way around. The Windows Developer Tools themselves
> > are
> > able to bootstrap command-line environments using a few environment
> > variables
> > and some batch scripts as levers.
> >
> > I also confirmed that when cygwin starts up, it absorbs the path and
> > environment variables that exist at the time.
> >
> > This preconditioning seems much healthier than attempting to reach out
> from
> > cygwin into the Windows environment.
> >
> > Here's how I demonstrated it working.
> >
> > 1. I have batch scripts that I use to launch console windows with the
> > Visual
> > C++ environment all set up. One is the attached MyVC++.bat.txt (with the
> > .txt
> > removed). It creates the correct path, environment variables, etc., for
> a
> > VC++ command-line build.
> >
> > 2. The second batch script, VCygwin.bat.txt (without the .txt) is placed
> > in
> > my C:\cygwin folder where I can run it whenever I want a cygwin
> environment
> > that is already set up to use VC++. (A copy of MyVC++.bat is placed in
> the
> > same folder with the original cygwin.bat script and the modified
> > VCygwin.bat.)
> >
> > 3. What I get when the cygwin is started using VCygwin.bat is shown in
> the
> > attached PNG file. (In the illustrated case, I am using a MyVC++.bat
> that
> > sets up VC++ 2010 Express Edition, what I have installed on the same
> > machine I
> > just added cygwin to.)
> >
> > 4. This same principle can be used to create a setup that uses
> additional
> > included files and libraries of the Windows SDK and the ATL include files
> > and
> > libraries of the Windows DDK. It is setup before cygwin is started and
> the
> > settings and tools are then available for the entire session.
> >
> > That's how I would do it. (I need to test the same idea to see if it
> works
> > with the bash shell in the Windows Posix SUA subsystem.)
> >
> > There's more too it of course because of the way the Windows file system
> is
> > mapped for access under cygwin and how commands to the VC++ command-line
> > compiler are created. But that must be done somehow either way.
> >
> > - Dennis
> >
> > -----Original Message-----
> > From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> > Sent: Sunday, November 06, 2011 20:49
> > To: ooo-dev@incubator.apache.org
> > Cc: 'Regina Henschel'
> > Subject: RE: Need a current build for WinXP 32bit
> >
> > Thanks Mathias,
> >
> > I found the ATL headers in the WinDDK/.../inc/atl71/, and libraries too.
> > There is also the ATL Reference Guide and other materials available at
> MSDN
> > on-line, along with some books in a very dusty corner of my office
> shelves.
> > That is one heck of a dependency. I wonder how much of it actually adds
> to
> > OO.o to do a static binding [;<).
> >
> > It would be interesting to see how much could be replaced by
> plain-vanilla
> > COM
> > dependencies. Not something I will be in any hurry to dig into though.
> > Just
> > something to nag my mind while I concentrate on simpler things first.
> >
> > - Dennis
> >
> > -----Original Message-----
> > From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> > Sent: Sunday, November 06, 2011 11:44
> > To: ooo-dev@incubator.apache.org
> > Cc: 'Regina Henschel'
> > Subject: RE: Need a current build for WinXP 32bit
> >
> > Thanks Mathias,
> >
> > I missed your earlier response.
> >
> > I just checked to see whether the DLLs are on my system already and they
> > are
> > of course. 7.1, 8.0, 9.0, and 10.0 plus related patches.
> >
> > I will look into the WDK.
> >
> > This seems a good place to start:
> > <http://msdn.microsoft.com/en-us/windows/hardware/gg487463>.
> > The release notes are interesting. Hmm, 619.77 MB ISO Image. OK, time
> to
> > go
> > do other chores while the download happens.
> >
> > - Dennis
> >
> > -----Original Message-----
> > From: Mathias Bauer [mailto:Mathias_Bauer@gmx.net]
> > Sent: Thursday, November 03, 2011 01:13
> > To: ooo-dev@incubator.apache.org
> > Subject: Re: Need a current build for WinXP 32bit
> >
> > On 31.10.2011 20:18, Dennis E. Hamilton wrote:
> > > Regina,
> > >
> > > I would like to find an already built Win32 WinXP version too. I
> > > despair of ever succeeding in building one myself without extensive
> > > practice with the tools that I am expected to operate to accomplish
> > > that.
> > >
> > > I don't know how to deal with the ATL dependencies. I thought that it
> > > was going to be made available independently, but it is apparently
> > > still tied to VC++ 200xy non-express editions.
> >
> > As I already wrote on this list some weeks ago, you can get ATL headers
> > by installing the Windows driver SDK. It might require to add paths to
> > your build environment, but basically it should work with VS Express.
> >
> > It might be an idea to install the driver SDK, get the necessary stuff,
> > move it into a suitable location, adapt include path and library path of
> > your build env and then deinstall the otherwise useless SDK again.
> >
> > Regards,
> > Mathias
> >
>
>
RE: Microsoft Tools for Windows Builds
Posted by Pedro Giffuni <pf...@apache.org>.
FWIW;
It would be really nice to have a Windows buildbot.
http://ci.apache.org/buildbot.html
cheers,
Pedro.
--- On Sun, 11/20/11, Dennis E. Hamilton <de...@acm.org> wrote:
...
> Hi Ross,
>
> The goal is to be able to do the Windows Build with the
> free tools that Microsoft has available. That includes
> the free-to-download Microsoft Visual Studio Express
> software (specifically the Visual C++ Express Edition), the
> Microsoft SDK, and the Windows DDK. This assures that
> anyone can do a build for Windows without having to have an
> MSDN Subscription or a commercially-sold version of Visual
> Studio, so long as they can meet the configuration
> requirements for building on a Windows PC.
>
> A secondary problem, independent of how one acquires the
> Microsoft developer tools, is that the toolset and build
> structure for OO.o looks, walks, and talks like a Unix/Linux
> build. To have the build process work on Windows,
> cygwin (which provides a bash work-alike and a large set of
> Unix-style utilities) has to have access to the Microsoft
> tools as if they were installed on a Unix system that has
> provisions for executing Windows software.
>
> The experiment I did yesterday was a proof-of-concept
> demonstration that finding the Microsoft tools from cygwin
> is easier than digging around in the Windows registry, since
> (1) firing up cygwin preserves the environment variables and
> path that are set in Windows at the time and (2) all of the
> Windows developer tool sets that run from the command-line
> have scripts that setup environment variables and path for
> their command-line operation. I just connected those
> dots. There is more to do to make an easily
> customizable bridge script, especially for running on a
> localized version of Windows. But the concept
> works. It also puts the Windows-configuration binding
> outside of the build itself, so it can be performed and
> customized prior to starting cygwin and then initiating a
> build. It's also easy to build checks into the scripts
> (as I did just for locating the VC++ compiler) so that an
> user knows the configuration is located properly before even
> attempting the build.
>
> This may get us over some of the gnarlies that seem to be
> in the way of easily setting up a Windows build. But
> it is just a proof-of-concept at this point.
>
> - Dennis
>
> -----Original Message-----
> From: Ross Gardler [mailto:rgardler@opendirective.com]
>
> Sent: Sunday, November 20, 2011 02:05
> To: dennis.hamilton@acm.org;
> ooo-dev@incubator.apache.org
> Cc: Regina Henschel
> Subject: Re:Microsoft Tools for Windows Builds
>
> We used to have free MSDN licenses for Apache projects. I
> can't remember
> the details and I'm not sure if the donation is still
> valid. Would this
> provide what is needed in a convenient way? If so I'll find
> or what the
> status is.
>
> Ross
>
> Sent from my mobile device, please forgive errors and
> brevity.
> On Nov 20, 2011 6:07 AM, "Dennis E. Hamilton" <de...@acm.org>
> wrote:
>
> > Another conversation came up (on [libre-office]) on
> how to find the
> > installed
> > VC++ software from within cygwin. The attempted
> approach involved
> > mucking-about in the Windows Registry in order to
> track down the tools.
> > That
> > struck me as the long way around. The Windows
> Developer Tools themselves
> > are
> > able to bootstrap command-line environments using a
> few environment
> > variables
> > and some batch scripts as levers.
> >
> > I also confirmed that when cygwin starts up, it
> absorbs the path and
> > environment variables that exist at the time.
> >
> > This preconditioning seems much healthier than
> attempting to reach out from
> > cygwin into the Windows environment.
> >
> > Here's how I demonstrated it working.
> >
> > 1. I have batch scripts that I use to
> launch console windows with the
> > Visual
> > C++ environment all set up. One is the attached
> MyVC++.bat.txt (with the
> > .txt
> > removed). It creates the correct path,
> environment variables, etc., for a
> > VC++ command-line build.
> >
> > 2. The second batch script, VCygwin.bat.txt
> (without the .txt) is placed
> > in
> > my C:\cygwin folder where I can run it whenever I want
> a cygwin environment
> > that is already set up to use VC++. (A copy of
> MyVC++.bat is placed in the
> > same folder with the original cygwin.bat script and
> the modified
> > VCygwin.bat.)
> >
> > 3. What I get when the cygwin is started using
> VCygwin.bat is shown in the
> > attached PNG file. (In the illustrated case, I
> am using a MyVC++.bat that
> > sets up VC++ 2010 Express Edition, what I have
> installed on the same
> > machine I
> > just added cygwin to.)
> >
> > 4. This same principle can be used to create a
> setup that uses additional
> > included files and libraries of the Windows SDK and
> the ATL include files
> > and
> > libraries of the Windows DDK. It is setup before
> cygwin is started and the
> > settings and tools are then available for the entire
> session.
> >
> > That's how I would do it. (I need to test the same
> idea to see if it works
> > with the bash shell in the Windows Posix SUA
> subsystem.)
> >
> > There's more too it of course because of the way the
> Windows file system is
> > mapped for access under cygwin and how commands to the
> VC++ command-line
> > compiler are created. But that must be done
> somehow either way.
> >
> > - Dennis
> >
> > -----Original Message-----
> > From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> > Sent: Sunday, November 06, 2011 20:49
> > To: ooo-dev@incubator.apache.org
> > Cc: 'Regina Henschel'
> > Subject: RE: Need a current build for WinXP 32bit
> >
> > Thanks Mathias,
> >
> > I found the ATL headers in the WinDDK/.../inc/atl71/,
> and libraries too.
> > There is also the ATL Reference Guide and other
> materials available at MSDN
> > on-line, along with some books in a very dusty corner
> of my office shelves.
> > That is one heck of a dependency. I wonder how
> much of it actually adds to
> > OO.o to do a static binding [;<).
> >
> > It would be interesting to see how much could be
> replaced by plain-vanilla
> > COM
> > dependencies. Not something I will be in any
> hurry to dig into though.
> > Just
> > something to nag my mind while I concentrate on
> simpler things first.
> >
> > - Dennis
> >
> > -----Original Message-----
> > From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> > Sent: Sunday, November 06, 2011 11:44
> > To: ooo-dev@incubator.apache.org
> > Cc: 'Regina Henschel'
> > Subject: RE: Need a current build for WinXP 32bit
> >
> > Thanks Mathias,
> >
> > I missed your earlier response.
> >
> > I just checked to see whether the DLLs are on my
> system already and they
> > are
> > of course. 7.1, 8.0, 9.0, and 10.0 plus related
> patches.
> >
> > I will look into the WDK.
> >
> > This seems a good place to start:
> > <http://msdn.microsoft.com/en-us/windows/hardware/gg487463>.
> > The release notes are interesting. Hmm, 619.77
> MB ISO Image. OK, time to
> > go
> > do other chores while the download happens.
> >
> > - Dennis
> >
> > -----Original Message-----
> > From: Mathias Bauer [mailto:Mathias_Bauer@gmx.net]
> > Sent: Thursday, November 03, 2011 01:13
> > To: ooo-dev@incubator.apache.org
> > Subject: Re: Need a current build for WinXP 32bit
> >
> > On 31.10.2011 20:18, Dennis E. Hamilton wrote:
> > > Regina,
> > >
> > > I would like to find an already built Win32 WinXP
> version too. I
> > > despair of ever succeeding in building one myself
> without extensive
> > > practice with the tools that I am expected to
> operate to accomplish
> > > that.
> > >
> > > I don't know how to deal with the ATL
> dependencies. I thought that it
> > > was going to be made available independently, but
> it is apparently
> > > still tied to VC++ 200xy non-express editions.
> >
> > As I already wrote on this list some weeks ago, you
> can get ATL headers
> > by installing the Windows driver SDK. It might require
> to add paths to
> > your build environment, but basically it should work
> with VS Express.
> >
> > It might be an idea to install the driver SDK, get the
> necessary stuff,
> > move it into a suitable location, adapt include path
> and library path of
> > your build env and then deinstall the otherwise
> useless SDK again.
> >
> > Regards,
> > Mathias
> >
>
>
RE: Microsoft Tools for Windows Builds
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Hi Ross,
The goal is to be able to do the Windows Build with the free tools that Microsoft has available. That includes the free-to-download Microsoft Visual Studio Express software (specifically the Visual C++ Express Edition), the Microsoft SDK, and the Windows DDK. This assures that anyone can do a build for Windows without having to have an MSDN Subscription or a commercially-sold version of Visual Studio, so long as they can meet the configuration requirements for building on a Windows PC.
A secondary problem, independent of how one acquires the Microsoft developer tools, is that the toolset and build structure for OO.o looks, walks, and talks like a Unix/Linux build. To have the build process work on Windows, cygwin (which provides a bash work-alike and a large set of Unix-style utilities) has to have access to the Microsoft tools as if they were installed on a Unix system that has provisions for executing Windows software.
The experiment I did yesterday was a proof-of-concept demonstration that finding the Microsoft tools from cygwin is easier than digging around in the Windows registry, since (1) firing up cygwin preserves the environment variables and path that are set in Windows at the time and (2) all of the Windows developer tool sets that run from the command-line have scripts that setup environment variables and path for their command-line operation. I just connected those dots. There is more to do to make an easily customizable bridge script, especially for running on a localized version of Windows. But the concept works. It also puts the Windows-configuration binding outside of the build itself, so it can be performed and customized prior to starting cygwin and then initiating a build. It's also easy to build checks into the scripts (as I did just for locating the VC++ compiler) so that an user knows the configuration is located properly before even attempting the build.
This may get us over some of the gnarlies that seem to be in the way of easily setting up a Windows build. But it is just a proof-of-concept at this point.
- Dennis
-----Original Message-----
From: Ross Gardler [mailto:rgardler@opendirective.com]
Sent: Sunday, November 20, 2011 02:05
To: dennis.hamilton@acm.org; ooo-dev@incubator.apache.org
Cc: Regina Henschel
Subject: Re:Microsoft Tools for Windows Builds
We used to have free MSDN licenses for Apache projects. I can't remember
the details and I'm not sure if the donation is still valid. Would this
provide what is needed in a convenient way? If so I'll find or what the
status is.
Ross
Sent from my mobile device, please forgive errors and brevity.
On Nov 20, 2011 6:07 AM, "Dennis E. Hamilton" <de...@acm.org>
wrote:
> Another conversation came up (on [libre-office]) on how to find the
> installed
> VC++ software from within cygwin. The attempted approach involved
> mucking-about in the Windows Registry in order to track down the tools.
> That
> struck me as the long way around. The Windows Developer Tools themselves
> are
> able to bootstrap command-line environments using a few environment
> variables
> and some batch scripts as levers.
>
> I also confirmed that when cygwin starts up, it absorbs the path and
> environment variables that exist at the time.
>
> This preconditioning seems much healthier than attempting to reach out from
> cygwin into the Windows environment.
>
> Here's how I demonstrated it working.
>
> 1. I have batch scripts that I use to launch console windows with the
> Visual
> C++ environment all set up. One is the attached MyVC++.bat.txt (with the
> .txt
> removed). It creates the correct path, environment variables, etc., for a
> VC++ command-line build.
>
> 2. The second batch script, VCygwin.bat.txt (without the .txt) is placed
> in
> my C:\cygwin folder where I can run it whenever I want a cygwin environment
> that is already set up to use VC++. (A copy of MyVC++.bat is placed in the
> same folder with the original cygwin.bat script and the modified
> VCygwin.bat.)
>
> 3. What I get when the cygwin is started using VCygwin.bat is shown in the
> attached PNG file. (In the illustrated case, I am using a MyVC++.bat that
> sets up VC++ 2010 Express Edition, what I have installed on the same
> machine I
> just added cygwin to.)
>
> 4. This same principle can be used to create a setup that uses additional
> included files and libraries of the Windows SDK and the ATL include files
> and
> libraries of the Windows DDK. It is setup before cygwin is started and the
> settings and tools are then available for the entire session.
>
> That's how I would do it. (I need to test the same idea to see if it works
> with the bash shell in the Windows Posix SUA subsystem.)
>
> There's more too it of course because of the way the Windows file system is
> mapped for access under cygwin and how commands to the VC++ command-line
> compiler are created. But that must be done somehow either way.
>
> - Dennis
>
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> Sent: Sunday, November 06, 2011 20:49
> To: ooo-dev@incubator.apache.org
> Cc: 'Regina Henschel'
> Subject: RE: Need a current build for WinXP 32bit
>
> Thanks Mathias,
>
> I found the ATL headers in the WinDDK/.../inc/atl71/, and libraries too.
> There is also the ATL Reference Guide and other materials available at MSDN
> on-line, along with some books in a very dusty corner of my office shelves.
> That is one heck of a dependency. I wonder how much of it actually adds to
> OO.o to do a static binding [;<).
>
> It would be interesting to see how much could be replaced by plain-vanilla
> COM
> dependencies. Not something I will be in any hurry to dig into though.
> Just
> something to nag my mind while I concentrate on simpler things first.
>
> - Dennis
>
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> Sent: Sunday, November 06, 2011 11:44
> To: ooo-dev@incubator.apache.org
> Cc: 'Regina Henschel'
> Subject: RE: Need a current build for WinXP 32bit
>
> Thanks Mathias,
>
> I missed your earlier response.
>
> I just checked to see whether the DLLs are on my system already and they
> are
> of course. 7.1, 8.0, 9.0, and 10.0 plus related patches.
>
> I will look into the WDK.
>
> This seems a good place to start:
> <http://msdn.microsoft.com/en-us/windows/hardware/gg487463>.
> The release notes are interesting. Hmm, 619.77 MB ISO Image. OK, time to
> go
> do other chores while the download happens.
>
> - Dennis
>
> -----Original Message-----
> From: Mathias Bauer [mailto:Mathias_Bauer@gmx.net]
> Sent: Thursday, November 03, 2011 01:13
> To: ooo-dev@incubator.apache.org
> Subject: Re: Need a current build for WinXP 32bit
>
> On 31.10.2011 20:18, Dennis E. Hamilton wrote:
> > Regina,
> >
> > I would like to find an already built Win32 WinXP version too. I
> > despair of ever succeeding in building one myself without extensive
> > practice with the tools that I am expected to operate to accomplish
> > that.
> >
> > I don't know how to deal with the ATL dependencies. I thought that it
> > was going to be made available independently, but it is apparently
> > still tied to VC++ 200xy non-express editions.
>
> As I already wrote on this list some weeks ago, you can get ATL headers
> by installing the Windows driver SDK. It might require to add paths to
> your build environment, but basically it should work with VS Express.
>
> It might be an idea to install the driver SDK, get the necessary stuff,
> move it into a suitable location, adapt include path and library path of
> your build env and then deinstall the otherwise useless SDK again.
>
> Regards,
> Mathias
>
Re:Microsoft Tools for Windows Builds
Posted by Ross Gardler <rg...@opendirective.com>.
We used to have free MSDN licenses for Apache projects. I can't remember
the details and I'm not sure if the donation is still valid. Would this
provide what is needed in a convenient way? If so I'll find or what the
status is.
Ross
Sent from my mobile device, please forgive errors and brevity.
On Nov 20, 2011 6:07 AM, "Dennis E. Hamilton" <de...@acm.org>
wrote:
> Another conversation came up (on [libre-office]) on how to find the
> installed
> VC++ software from within cygwin. The attempted approach involved
> mucking-about in the Windows Registry in order to track down the tools.
> That
> struck me as the long way around. The Windows Developer Tools themselves
> are
> able to bootstrap command-line environments using a few environment
> variables
> and some batch scripts as levers.
>
> I also confirmed that when cygwin starts up, it absorbs the path and
> environment variables that exist at the time.
>
> This preconditioning seems much healthier than attempting to reach out from
> cygwin into the Windows environment.
>
> Here's how I demonstrated it working.
>
> 1. I have batch scripts that I use to launch console windows with the
> Visual
> C++ environment all set up. One is the attached MyVC++.bat.txt (with the
> .txt
> removed). It creates the correct path, environment variables, etc., for a
> VC++ command-line build.
>
> 2. The second batch script, VCygwin.bat.txt (without the .txt) is placed
> in
> my C:\cygwin folder where I can run it whenever I want a cygwin environment
> that is already set up to use VC++. (A copy of MyVC++.bat is placed in the
> same folder with the original cygwin.bat script and the modified
> VCygwin.bat.)
>
> 3. What I get when the cygwin is started using VCygwin.bat is shown in the
> attached PNG file. (In the illustrated case, I am using a MyVC++.bat that
> sets up VC++ 2010 Express Edition, what I have installed on the same
> machine I
> just added cygwin to.)
>
> 4. This same principle can be used to create a setup that uses additional
> included files and libraries of the Windows SDK and the ATL include files
> and
> libraries of the Windows DDK. It is setup before cygwin is started and the
> settings and tools are then available for the entire session.
>
> That's how I would do it. (I need to test the same idea to see if it works
> with the bash shell in the Windows Posix SUA subsystem.)
>
> There's more too it of course because of the way the Windows file system is
> mapped for access under cygwin and how commands to the VC++ command-line
> compiler are created. But that must be done somehow either way.
>
> - Dennis
>
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> Sent: Sunday, November 06, 2011 20:49
> To: ooo-dev@incubator.apache.org
> Cc: 'Regina Henschel'
> Subject: RE: Need a current build for WinXP 32bit
>
> Thanks Mathias,
>
> I found the ATL headers in the WinDDK/.../inc/atl71/, and libraries too.
> There is also the ATL Reference Guide and other materials available at MSDN
> on-line, along with some books in a very dusty corner of my office shelves.
> That is one heck of a dependency. I wonder how much of it actually adds to
> OO.o to do a static binding [;<).
>
> It would be interesting to see how much could be replaced by plain-vanilla
> COM
> dependencies. Not something I will be in any hurry to dig into though.
> Just
> something to nag my mind while I concentrate on simpler things first.
>
> - Dennis
>
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> Sent: Sunday, November 06, 2011 11:44
> To: ooo-dev@incubator.apache.org
> Cc: 'Regina Henschel'
> Subject: RE: Need a current build for WinXP 32bit
>
> Thanks Mathias,
>
> I missed your earlier response.
>
> I just checked to see whether the DLLs are on my system already and they
> are
> of course. 7.1, 8.0, 9.0, and 10.0 plus related patches.
>
> I will look into the WDK.
>
> This seems a good place to start:
> <http://msdn.microsoft.com/en-us/windows/hardware/gg487463>.
> The release notes are interesting. Hmm, 619.77 MB ISO Image. OK, time to
> go
> do other chores while the download happens.
>
> - Dennis
>
> -----Original Message-----
> From: Mathias Bauer [mailto:Mathias_Bauer@gmx.net]
> Sent: Thursday, November 03, 2011 01:13
> To: ooo-dev@incubator.apache.org
> Subject: Re: Need a current build for WinXP 32bit
>
> On 31.10.2011 20:18, Dennis E. Hamilton wrote:
> > Regina,
> >
> > I would like to find an already built Win32 WinXP version too. I
> > despair of ever succeeding in building one myself without extensive
> > practice with the tools that I am expected to operate to accomplish
> > that.
> >
> > I don't know how to deal with the ATL dependencies. I thought that it
> > was going to be made available independently, but it is apparently
> > still tied to VC++ 200xy non-express editions.
>
> As I already wrote on this list some weeks ago, you can get ATL headers
> by installing the Windows driver SDK. It might require to add paths to
> your build environment, but basically it should work with VS Express.
>
> It might be an idea to install the driver SDK, get the necessary stuff,
> move it into a suitable location, adapt include path and library path of
> your build env and then deinstall the otherwise useless SDK again.
>
> Regards,
> Mathias
>
Re: Microsoft Tools for Windows Builds
Posted by Andre Fischer <af...@a-w-f.de>.
Hi Dennis,
On 21.11.2011 18:37, Dennis E. Hamilton wrote:
> Andre,
>
> I have my own interests in this kind of construction setup for Windows builds. I offered my snippets in case they are also useful in streamlining the Windows build case for Apache OpenOffice.
>
> I only did a little proof of concept to confirm that the settings are conveyed into a cygwin session properly. There could always be a show-stopper later on. Something I didn't dig into was setting up the command-line parameters to the tools such that tool-understandable paths (not cygwin ones?) are used. I assume that already has a solution and the make processor that is run under cygwin has no problem.
>
> - Dennis
>
> MORE ARM-CHAIR ANALYSIS
>
> It seemed to me that the way cygwin is used to find the necessary dependencies among the Microsoft development tools is fragile and, seemingly, too much black art. I based that on observation of some folks having difficulty with getting builds to work in various cases (at LO and here).
>
> It seems easier, and better for those who just want to do builds for QA,
I am not sure how a QA build differs from a developer build (other then
in a debug flag maybe)
> to establish the tool-dependency connections before starting the build under cygwin at all.
configure should basically do that, making sure that everything needed
for a build exists before starting the actual build. If you or anybody
else finds a better way to detect the right MS tools than we should
adapt the automake/configure tool chain accordingly. What we not should
do is to have two different detection routines that may lead to
different results. Otherwise the first check may tell the user that
everything is OK and then configure complains about eg a missing compiler.
> This can be by setting up and confirming the tool-required
environment variables and path settings first. It is relatively easy to
do and the Microsoft tools already have scripts that help without any
registry dependencies required. It should also be easier for an user to
trouble-shoot.
It would be great if the Windows tools detection could be improved.
>
> That way an user can choose which versions of the tools to use when many are installed side-by-side on the same system and also know before starting a build process that the tools are reachable.
Ah, are you talking about an interactive tool? Which lists all sane
combinations of tools and when the user has made her choice, configure
is run with the selected values and prepares the build?
I would like that.
-Andre
PS: I am sorry about broken formatting of quotes. My mail application
(Thunderbird) can not handle your long lines very well :-)
>
> - Dennis
>
> -----Original Message-----
> From: Andre Fischer [mailto:af@a-w-f.de]
> Sent: Monday, November 21, 2011 00:51
> To: ooo-dev@incubator.apache.org
> Subject: Re: Microsoft Tools for Windows Builds
>
> Hallo Dennis,
>
> I am not sure that I see the problem here (I do not read the
> libre-office mailing list but maybe I should).
>
> The configure script already detects which compiler to use. This works
> well on my Windows machine with cygwin and VC++ and the MS SDKs. The
> only problem I have encountered so far is when several versions of
> visual studio or the SDKs (old and new, 32bit and 64bit) are installed
> at the same time and configure has to make a choice. But this is may
> not be auto-detectable by any means. For this we have options with
> which to tell configure which version to use.
>
> But maybe I misunderstand the problem entirely?
>
> Best regards,
> Andre
>
> On 20.11.2011 07:06, Dennis E. Hamilton wrote:
>> Another conversation came up (on [libre-office]) on how to find the installed
>> VC++ software from within cygwin. The attempted approach involved
>> mucking-about in the Windows Registry in order to track down the tools. That
>> struck me as the long way around. The Windows Developer Tools themselves are
>> able to bootstrap command-line environments using a few environment variables
>> and some batch scripts as levers.
>>
>> I also confirmed that when cygwin starts up, it absorbs the path and
>> environment variables that exist at the time.
>>
>> This preconditioning seems much healthier than attempting to reach out from
>> cygwin into the Windows environment.
> [ ... ]
>
RE: Microsoft Tools for Windows Builds
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Andre,
I have my own interests in this kind of construction setup for Windows builds. I offered my snippets in case they are also useful in streamlining the Windows build case for Apache OpenOffice.
I only did a little proof of concept to confirm that the settings are conveyed into a cygwin session properly. There could always be a show-stopper later on. Something I didn't dig into was setting up the command-line parameters to the tools such that tool-understandable paths (not cygwin ones?) are used. I assume that already has a solution and the make processor that is run under cygwin has no problem.
- Dennis
MORE ARM-CHAIR ANALYSIS
It seemed to me that the way cygwin is used to find the necessary dependencies among the Microsoft development tools is fragile and, seemingly, too much black art. I based that on observation of some folks having difficulty with getting builds to work in various cases (at LO and here).
It seems easier, and better for those who just want to do builds for QA, to establish the tool-dependency connections before starting the build under cygwin at all. This can be by setting up and confirming the tool-required environment variables and path settings first. It is relatively easy to do and the Microsoft tools already have scripts that help without any registry dependencies required. It should also be easier for an user to trouble-shoot.
That way an user can choose which versions of the tools to use when many are installed side-by-side on the same system and also know before starting a build process that the tools are reachable.
- Dennis
-----Original Message-----
From: Andre Fischer [mailto:af@a-w-f.de]
Sent: Monday, November 21, 2011 00:51
To: ooo-dev@incubator.apache.org
Subject: Re: Microsoft Tools for Windows Builds
Hallo Dennis,
I am not sure that I see the problem here (I do not read the
libre-office mailing list but maybe I should).
The configure script already detects which compiler to use. This works
well on my Windows machine with cygwin and VC++ and the MS SDKs. The
only problem I have encountered so far is when several versions of
visual studio or the SDKs (old and new, 32bit and 64bit) are installed
at the same time and configure has to make a choice. But this is may
not be auto-detectable by any means. For this we have options with
which to tell configure which version to use.
But maybe I misunderstand the problem entirely?
Best regards,
Andre
On 20.11.2011 07:06, Dennis E. Hamilton wrote:
> Another conversation came up (on [libre-office]) on how to find the installed
> VC++ software from within cygwin. The attempted approach involved
> mucking-about in the Windows Registry in order to track down the tools. That
> struck me as the long way around. The Windows Developer Tools themselves are
> able to bootstrap command-line environments using a few environment variables
> and some batch scripts as levers.
>
> I also confirmed that when cygwin starts up, it absorbs the path and
> environment variables that exist at the time.
>
> This preconditioning seems much healthier than attempting to reach out from
> cygwin into the Windows environment.
[ ... ]
Re: Microsoft Tools for Windows Builds
Posted by Andre Fischer <af...@a-w-f.de>.
Hallo Dennis,
I am not sure that I see the problem here (I do not read the
libre-office mailing list but maybe I should).
The configure script already detects which compiler to use. This works
well on my Windows machine with cygwin and VC++ and the MS SDKs. The
only problem I have encountered so far is when several versions of
visual studio or the SDKs (old and new, 32bit and 64bit) are installed
at the same time and configure has to make a choice. But this is may
not be auto-detectable by any means. For this we have options with
which to tell configure which version to use.
But maybe I misunderstand the problem entirely?
Best regards,
Andre
On 20.11.2011 07:06, Dennis E. Hamilton wrote:
> Another conversation came up (on [libre-office]) on how to find the installed
> VC++ software from within cygwin. The attempted approach involved
> mucking-about in the Windows Registry in order to track down the tools. That
> struck me as the long way around. The Windows Developer Tools themselves are
> able to bootstrap command-line environments using a few environment variables
> and some batch scripts as levers.
>
> I also confirmed that when cygwin starts up, it absorbs the path and
> environment variables that exist at the time.
>
> This preconditioning seems much healthier than attempting to reach out from
> cygwin into the Windows environment.
>
> Here's how I demonstrated it working.
>
> 1. I have batch scripts that I use to launch console windows with the Visual
> C++ environment all set up. One is the attached MyVC++.bat.txt (with the .txt
> removed). It creates the correct path, environment variables, etc., for a
> VC++ command-line build.
>
> 2. The second batch script, VCygwin.bat.txt (without the .txt) is placed in
> my C:\cygwin folder where I can run it whenever I want a cygwin environment
> that is already set up to use VC++. (A copy of MyVC++.bat is placed in the
> same folder with the original cygwin.bat script and the modified VCygwin.bat.)
>
> 3. What I get when the cygwin is started using VCygwin.bat is shown in the
> attached PNG file. (In the illustrated case, I am using a MyVC++.bat that
> sets up VC++ 2010 Express Edition, what I have installed on the same machine I
> just added cygwin to.)
>
> 4. This same principle can be used to create a setup that uses additional
> included files and libraries of the Windows SDK and the ATL include files and
> libraries of the Windows DDK. It is setup before cygwin is started and the
> settings and tools are then available for the entire session.
>
> That's how I would do it. (I need to test the same idea to see if it works
> with the bash shell in the Windows Posix SUA subsystem.)
>
> There's more too it of course because of the way the Windows file system is
> mapped for access under cygwin and how commands to the VC++ command-line
> compiler are created. But that must be done somehow either way.
>
> - Dennis
>
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> Sent: Sunday, November 06, 2011 20:49
> To: ooo-dev@incubator.apache.org
> Cc: 'Regina Henschel'
> Subject: RE: Need a current build for WinXP 32bit
>
> Thanks Mathias,
>
> I found the ATL headers in the WinDDK/.../inc/atl71/, and libraries too.
> There is also the ATL Reference Guide and other materials available at MSDN
> on-line, along with some books in a very dusty corner of my office shelves.
> That is one heck of a dependency. I wonder how much of it actually adds to
> OO.o to do a static binding [;<).
>
> It would be interesting to see how much could be replaced by plain-vanilla COM
> dependencies. Not something I will be in any hurry to dig into though. Just
> something to nag my mind while I concentrate on simpler things first.
>
> - Dennis
>
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> Sent: Sunday, November 06, 2011 11:44
> To: ooo-dev@incubator.apache.org
> Cc: 'Regina Henschel'
> Subject: RE: Need a current build for WinXP 32bit
>
> Thanks Mathias,
>
> I missed your earlier response.
>
> I just checked to see whether the DLLs are on my system already and they are
> of course. 7.1, 8.0, 9.0, and 10.0 plus related patches.
>
> I will look into the WDK.
>
> This seems a good place to start:
> <http://msdn.microsoft.com/en-us/windows/hardware/gg487463>.
> The release notes are interesting. Hmm, 619.77 MB ISO Image. OK, time to go
> do other chores while the download happens.
>
> - Dennis
>
> -----Original Message-----
> From: Mathias Bauer [mailto:Mathias_Bauer@gmx.net]
> Sent: Thursday, November 03, 2011 01:13
> To: ooo-dev@incubator.apache.org
> Subject: Re: Need a current build for WinXP 32bit
>
> On 31.10.2011 20:18, Dennis E. Hamilton wrote:
>> Regina,
>>
>> I would like to find an already built Win32 WinXP version too. I
>> despair of ever succeeding in building one myself without extensive
>> practice with the tools that I am expected to operate to accomplish
>> that.
>>
>> I don't know how to deal with the ATL dependencies. I thought that it
>> was going to be made available independently, but it is apparently
>> still tied to VC++ 200xy non-express editions.
>
> As I already wrote on this list some weeks ago, you can get ATL headers
> by installing the Windows driver SDK. It might require to add paths to
> your build environment, but basically it should work with VS Express.
>
> It might be an idea to install the driver SDK, get the necessary stuff,
> move it into a suitable location, adapt include path and library path of
> your build env and then deinstall the otherwise useless SDK again.
>
> Regards,
> Mathias