Update on turning off 64-bit Windows builds

[Benjamin Smedberg]

After I announced my decision to disable 64-bit Windows nightlies, there
was significant negative feedback. After reviewing that feedback, and
consulting with Release Engineering, I believe that we can keep a set of
users happy by making a modification to the original plan.

Most importantly, it seems that there are users who regularly run into
the 4GB memory limits of 32-bit builds. These users often have hundreds
or even thousands of tabs. These users are using the 64-bit nightlies
not primarily to be part of our testing community, but because those
builds are the best product available.

At this point, the Mozilla project does not have the resources to
actively support this use case. Making these builds, however, is not a
significant burden on our Release Engineering group. Therefore I have
modified my original plan in the following way:

* Migrate all existing users of win64 nightly channel builds to the
win32 nightly channel builds via automatic update.
* Continue to build win64 Nightly builds and updates on the nightly
channel. Users who need the 64-bit builds will have to download it after
the migration point (date TBD).
** Change the default first-run and update page for win64 builds to
explain to users that they are not supported.
** Disable the crash reporter for win64 builds
** Enable click-to-play plugins by default in the win64 builds.
* Discontinue the win64 tests and on-checkin builds to reduce release
engineering load. By default, do not generate win64 builds on try.
* win64 builds will be considered a �tier 3� build configuration. [1]

We will continue to test the win32 builds and make sure that they work
well on both 32-bit and 64-bit versions of Windows. Specifically, all of
our testing on Windows 8 is planned to be done on the 64-bit version of
Windows 8.

I do hope that the projects and developers who are interested in win64
will work together to maintain this build configuration. I am interested
in hearing from volunteers who want to become the 64-bit build
maintainer. I will also set up a discussion list specifically for win64
issues, if that would be valuable.

--BDS

Please post followups to to mozilla.dev.apps.firefox

[1] https://developer.mozilla.org/en-US/docs/Supported_build_configurations

[Yuhong Bao]

On Dec 21, 1:43 pm, Benjamin Smedberg <benja...@smedbergs.us> wrote:
> * win64 builds will be considered a �tier 3� build configuration. [1]

Something is broken here.
Yuhong Bao

[Chris Ilias]

On 12-12-21 8:10 PM, Yuhong Bao wrote:
> On Dec 21, 1:43 pm, Benjamin Smedberg <benja...@smedbergs.us> wrote:

>> * win64 builds will be considered a �tier 3� build configuration. [1]
> Something is broken here.

It says win64 builds will be considered a "tier 3" build configuration.

[realit...@gmail.com]

Couldn't you just make the migration optional? Forcing users to download a 32-bit version they obviously don't want given the feedback seems a little... bandwidth unfriendly, to say the least.

[byte...@gmail.com]

On Saturday, December 22, 2012 3:26:11 PM UTC-5, realit...@gmail.com wrote:
> Couldn't you just make the migration optional? Forcing users to download a 32-bit version they obviously don't want given the feedback seems a little... bandwidth unfriendly, to say the least.

Agreed. It seems to be a little heavy handed to turn everybody running 64-bit code to 32-bit code, only to allow us to have to go through and download it again.

[spec...@gmx.de]

Am Freitag, 21. Dezember 2012 22:43:25 UTC+1 schrieb Benjamin Smedberg:
>
> ** Disable the crash reporter for win64 builds
>

Why not fix this bug?
https://bugzilla.mozilla.org/show_bug.cgi?id=811051

[Matthew Turnbull]

Well, if you can think of a way to facilitate that process, that doesn't
involve significant changes to the update system, then by all means
please speak-up.

The goal is to get people off of the win64 builds because they are
unsupported. I'm guessing the percentage of win64 users who regularity
exceed 4GB is on the smaller side, so I doubt this will hurt Mozilla in
the bandwidth department.

If you're concerned about your own bandwidth, then by all means turn off
updates. Download a new win64 build after the migration happens.

> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>

--
Bluefang-Logic Networks:

Scaled for your pleasure.

[Robert Kaiser]

spec...@gmx.de schrieb:

> Why not fix this bug?
> https://bugzilla.mozilla.org/show_bug.cgi?id=811051

1) Because it's the wrong thing to do, IMHO.
2) Because we don't have the resources for that.

Robert Kaiser

[Robert Kaiser]

Benjamin Smedberg schrieb:

> ** Disable the crash reporter for win64 builds

One possible alternative to that would be to put the build onto a
nightly-* channel (e.g. "nightly-win64") and not plain "nightly" - as
then Socorro will just ignore those in the stats while we'd still have
reports around for those who want to investigate them.

Robert Kaiser

[realit...@gmail.com]

[byte...@gmail.com]

On Saturday, December 22, 2012 3:26:11 PM UTC-5, realit...@gmail.com wrote:

> Couldn't you just make the migration optional? Forcing users to download a 32-bit version they obviously don't want given the feedback seems a little... bandwidth unfriendly, to say the least.

[WaltS]

On 12/22/2012 03:41 PM, byte...@gmail.com wrote:

So you think *everybody* is going to download the 64-bit version again?

I sure wouldn't want to do my banking, credit card transactions, or any
other sensitive transactions on an experimental, non-supported test
build, be it a 64-bit or 32-bit build.

Unfortunately I get the idea that some are using it for production purposes.

--
Fedora 17 (64-bit) KDE 4.9.4
Thunderbird Release

[chris.m...@bigpond.com]

I don't think that you have taken a rational approach to the decision of dropping Firefox64 at all. I will outline my reasons for this below....

1) 64 bit code is the future of computing - Mozilla should be dropping support for the 32 bit version as it is 'dead code', has the least longevity and is a drain on resources - 32 bit code is on its last legs and will be gone in the next few years. Why is Mozilla wasting time and resources on this? It is a more 'viable' option to put those resources into the development of Firefox64.
2) Security - 64 bit code brings better security. Running 32 bit code in a 64 bit OS causes a gaping security hole while it is running in compatibility mode - not even Microsoft recommend this approach because 'native code is far more secure'. In this case that means 64 bit code should be used not 32 bit.
3) Mozilla is further wasting resources with FirefoxOS - even if a miracle was to occur and it reached 0.1% it would still be a wasted effort - seriously what do you think FirefoxOS will achieve in the long run? I will tell you - NOTHING!
4) Those that think 64 bit is 'only for memory usage' or that '32 bit is good enough' have the wrong attitude for I.T and should be shown the door as they are only dragging you down. Mozilla needs to continue moving forward not embracing the past.
5) There is simply no valid reason given by Mozilla to drop support for the 64 bit version - all the reasons given (that I have read) would only make sense if they applied to dropping the 32 bit version.

I use Firefox64 simply because it is 64 bit, has better security, renders pages faster and crashes less often (for me the crashes are less). I have no issues with 64 bit plug-ins not being available as all the plug-ins I use are 64 bit already and have been for a few years now. Even game makes are porting their engines to 64 bit as they too can see the end in sight for 32 bit code.

[Wayne]

> * win64 builds will be considered a “tier 3” build configuration. [1]

>
> We will continue to test the win32 builds and make sure that they work
> well on both 32-bit and 64-bit versions of Windows. Specifically, all of
> our testing on Windows 8 is planned to be done on the 64-bit version of
> Windows 8.
>
> I do hope that the projects and developers who are interested in win64
> will work together to maintain this build configuration. I am interested
> in hearing from volunteers who want to become the 64-bit build
> maintainer. I will also set up a discussion list specifically for win64
> issues, if that would be valuable.
>
> --BDS
>
> Please post followups to to mozilla.dev.apps.firefox
>
> [1] https://developer.mozilla.org/en-US/docs/Supported_build_configurations

This sounds appropriate and well reasoned. Thank you.

[chris.m...@bigpond.com]

[kylet...@gmail.com]

I have to agree with Chris M, most major software makers, especially graphics and modelling, are starting to drop support for 32bit software. I don't even think they are many 32bit hardware systems even being built any more. Most new systems and operating systems are 64bit.

It's seems like a strange decision to stick with 32bit in light with current prevailing practices.

Just my two cents worth..

[kyle...@gmail.com]

This is the type of heavy-handed decision making that caused me to abandon the official project for the Waterfox project over a year ago.

[kylet...@gmail.com]

On Monday, December 24, 2012 4:14:36 AM UTC+1, chris.m...@bigpond.com wrote:

[kyle...@gmail.com]

This is the type of heavy-handed decision making that caused me to abandon the official project for the Waterfox project over a year ago.

On Friday, December 21, 2012 4:43:25 PM UTC-5, Benjamin Smedberg wrote:

[Gavin Sharp]

This discussion and proposal is really not about changing our development
focus (though a lot of people have tried to make it about that). This is
now very specifically about making our Nightly test audience focus on the
existing development focus (32 bit Windows builds), because testing builds
that aren't being worked on has proven to be a poor use of those resources.

Graphics and modelling software have different memory use constraints than
web browsing software in the common case, so it's not unexpected that they
would make different decisions about where to focus their development
efforts. The prevalence of 64bit hardware is just one factor, and its
really not a significant one given its compatibility with 32bit software.
https://groups.google.com/d/msg/mozilla.dev.planning/aeTXSZ_WFAs/BZITJLjhrAEJgoes
into more detail about the various factors that we've evaluated.

This decision does not mean that we're "sticking with 32bit" or "abandoning
64bit builds" long term; those characterizations represent an overly
simplistic view of a more complicated issue. Communicating these nuances
broadly is challenging, and so unfortunately (but perhaps not
unexpectedly), confusion and misunderstandings have pervaded this thread.

Gavin

[Robert Kaiser]

realit...@gmail.com schrieb:

> Couldn't you just make the migration optional? Forcing users to download a 32-bit version they obviously don't want given the feedback seems a little... bandwidth unfriendly, to say the least.

Using Nightly in the first place is already bandwidth-unfriendly as it
gets updates daily and those also should be downloaded and installed daily.
And making it optional would be 1) way more work and 2) not effective at
our strategy of getting the vast majority of Nightly users back to
32bit, which is supported, and only have those on 64bit who realize it's
experimental and mostly unsupported (or not yet supported if you will).

Robert Kaiser

[alex_mayorga]

Mr. Smedberg,

Personally I started using Nightly for win64 the moment my work OS was upgraded to be 64-bit a couple years ago.

I have never hit the 4GB memory limitation, but I stuck to those builds hopping I was somehow helping mozilla fix https://bugzilla.mozilla.org/show_bug.cgi?id=558448

The only plug-in I use is Flash, in general I believe plug-ins are bad for the open web so I try to stay away from them.

Now I commend you on reconsidering this and in the hopes of being constructive I'd like to volunteer to be the maintainer for the build if no one more fitting steps in. I use win64 because it is forced onto me at work, I'm a GNU/Linux kind of guy and mostly build things on UNIX like OSes (RHEL, Solaris, AIX) using shell scripts, Ant and Maven to pay the bills so I might need a lot of hand holding at 1st.

Regards,
Alex

[alex_mayorga]

On Friday, December 21, 2012 3:43:25 PM UTC-6, Benjamin Smedberg wrote:

[realit...@gmail.com]

And that is user-unfriendly. As I said, the bandwidth usage is "the least". Effectively choosing such an option for the user counter to their deliberate choice to download a 64-bit variant which is already labeled unstable everywhere goes against every developer-bone in my body. It would be like SumatraPDF bundling Adobe Reader with its installer: it's giving the user a product they specifically did not choose. I can't condone such a move, regardless of the technical requirements of attempting to shift the userbase.

[realit...@gmail.com]

Bandwidth usage does warrant its own response, though it may be a simple one - There is a giant difference between using and wasting bandwidth, as anyone on a limit like mine (12 GB per 30 days, a standard ratio of allowance on ANY satellite internet, and often much less due to incompetent usage tracking software and overzealous limit-enabling.) will attest. I choose to use my bandwidth downloading nightly variants of Firefox x64 because I think it's worth the usage. I would never choose to WASTE my bandwidth on a 32-bit version which in my personal use, is about as pointless as 16-bit, thanks to the amount of memory I regularly use in my own development work. The vital difference between me choosing to use up my bandwidth and it being wasted in an update I would never ask for is the same as the difference between me choosing to load anything over anything else - it's my bandwidth, my decision, my money, my time, and my computer. That you should have any say in the matter is beyond reproach.

[jande...@gmail.com]

I have just started learning your source code, and the reason is that your browser is the only browser for Windows we can get a 64 bit version of Webgl working.
In our company, we produce some very large models in Webgl, and regularly exceed 6GB in Memory. To help our customers, we have decided on pushing FireFox into these corporations for the future use of our software (which is what produces these large models)

So yes, there are people out in the world that are starting to expect that these kind of memory limits are available, especially in the world of Cad/engineering graphics.

Because of the firefox being 64 bit available, we dropped Chrome in favour of FireFox when the models started breaking this kind of boundary.

Just thought I would let you guys know how someone else in the world is using your great software.

Cheers
Jason Anderssen

[jande...@gmail.com]

[kron...@gmail.com]

it appears that x64 nightly builds have been stopped since 09JAN13 by neglect. a bug filed for the failure has been commented that someone who cares should fix it. the comments then go on to suggest that it should not be fixed because of the initial decision here to kill them & doesn't mention this thread where that decision was changed. looks like they prefer the propaganda that 'x64 was not killed, it just broke and we'll fix it some date in the future when we get around to it' to 'we killed x64 because we don't think anyone needs it.' the break doesn't affect the x86 32-bit builds so no one is bothered.

[Benjamin Smedberg]

On 1/25/2013 10:00 AM, kron...@gmail.com wrote:
> it appears that x64 nightly builds have been stopped since 09JAN13 by neglect. a bug filed for the failure has been commented that someone who cares should fix it.

Can you provide the bug number?

I don't know the exact situation, so I can't comment specifically.

As noted in my original email Win64 is now considered a tier-3 build
configuration. This means that module owners are not required to fix or
back out changes which break the win64 build: this is the responsibility
of the port maintainer or other people from the community who want to
provide patches. Modules owners *should* accept patches which fix win64.

--BDS

[kron...@gmail.com]

[alex_mayorga]

On Friday, January 25, 2013 10:26:32 AM UTC-6, Benjamin Smedberg wrote:

Mr Smedberg,

The bug I followed for the missing Nightly win64 updates is https://bugzilla.mozilla.org/show_bug.cgi?id=829738

The root cause and fix is apparently https://bugzilla.mozilla.org/show_bug.cgi?id=830676

Regards,
Alex

[alex_mayorga]

On Friday, January 25, 2013 10:26:32 AM UTC-6, Benjamin Smedberg wrote:

[kron...@gmail.com]

it's OK - someone got around to fixing it. nightly x64 is again in amongst the x86s again. fixing the pgo also fixed the nightlys. i was a bit frustrated at some of the comments in the bug implying lack of concern & the two-week plus time. now moot. thanx for the reply.

[kron...@gmail.com]

On Friday, 25 January 2013 16:26:32 UTC, Benjamin Smedberg wrote:

[Al]

I modified your plan for better security:

> * Migrate all existing users of win32 nightly channel builds to the
> win64 nightly channel builds via automatic update.
>
> * Discontinue to build win32 Nightly builds and updates on the nightly
> channel. Users who need the 32-bit builds will have to build it after

> the migration point (date TBD).
>

> ** Change the default first-run and update page for win32 builds to
> explain to users that they are insecure and thus not supported.
>
> ** Enable click-to-play plugins by default in all builds.
>
> * Discontinue the win32 tests and on-checkin builds to reduce release
> engineering load. By default, do not generate win32 builds on try.
>
> * win32 builds will be considered a "tier 9" build configuration. [1]

I'm not kidding. ASLR is easy to defeat in a 32-bit process.
You simply don't have enough bits to do a half-way decent job.
Heap spraying is trivial in a 32-bit process, especially when
the OS has more physical RAM than the process has virtual memory.

[Al]

[arm...@gmail.com]

On Friday, December 21, 2012 4:43:25 PM UTC-5, Benjamin Smedberg wrote:

...
> * Discontinue the win64 tests and on-checkin builds to reduce release
> engineering load. By default, do not generate win64 builds on try.
>
Only this last point has been tackled now on bug 814009.

This means that we still generate Win64 *nightly* updates on mozilla-central.

We left builds per-checkin on mozilla-central and try trees to allow anyone that wants to support win64 to continue working there.

I had to tackle this without further delay since we were falling behind in our infrastructure's capacity to build win32 builds. Win64 represented 1/3 of our infrastructure load.

[arm...@gmail.com]

[jmic...@yahoo.com]

On Sunday, December 23, 2012 7:14:36 PM UTC-8, chris.m...@bigpond.com wrote:
> I don't think that you have taken a rational approach to the decision of dropping Firefox64 at all. I will outline my reasons for this below....
>
>
>
> 1) 64 bit code is the future of computing - Mozilla should be dropping support for the 32 bit version as it is 'dead code', has the least longevity and is a drain on resources - 32 bit code is on its last legs and will be gone in the next few years. Why is Mozilla wasting time and resources on this? It is a more 'viable' option to put those resources into the development of Firefox64.
>
> 2) Security - 64 bit code brings better security. Running 32 bit code in a 64 bit OS causes a gaping security hole while it is running in compatibility mode - not even Microsoft recommend this approach because 'native code is far more secure'. In this case that means 64 bit code should be used not 32 bit.
>
> 3) Mozilla is further wasting resources with FirefoxOS - even if a miracle was to occur and it reached 0.1% it would still be a wasted effort - seriously what do you think FirefoxOS will achieve in the long run? I will tell you - NOTHING!
>
> 4) Those that think 64 bit is 'only for memory usage' or that '32 bit is good enough' have the wrong attitude for I.T and should be shown the door as they are only dragging you down. Mozilla needs to continue moving forward not embracing the past.
>
> 5) There is simply no valid reason given by Mozilla to drop support for the 64 bit version - all the reasons given (that I have read) would only make sense if they applied to dropping the 32 bit version.
>
>
>
> I use Firefox64 simply because it is 64 bit, has better security, renders pages faster and crashes less often (for me the crashes are less). I have no issues with 64 bit plug-ins not being available as all the plug-ins I use are 64 bit already and have been for a few years now. Even game makes are porting their engines to 64 bit as they too can see the end in sight for 32 bit code.

I agree mostly. there are old windows 32-bit machines out there, which to stay up-to-date beyond 2014 could theoretically run win7 with just a video card upgrade. the installer should install the 64-bit version if a 64-bit version exists and a 32-bit version if a 32-bit OS exists. also, linux 64-bit systems exist also. these should be targeted by the compiler as well.

my browser is practically most of my development environment. so having all those tabs is critical.

64-bit isn't just the future's it's now.

I am one of those many engineers who actually uses the browser for what it's intended for, web development and debugging, and I have 70+ tabs (lost count) and around this it can cause a crash due to lack of memory in 32-bit space.

PLEASE make a 64-bit version available as well.
as far as the update system goes, I would use curl or gup to do the updates. they have a dll you can link to and use I think. curl simply gets a file off of the internet. tough part will be the transition from a 32-bit installation on a 64-bit OS. you will have to keep the old sqlite databases and such and xml files, and whatever else goes with the profile, have the plugin developers make sure they provide 64-bit versions, and replace the 32-bit version of a plugin with the 64-bit version of the plugin on install if os is 64-bit. lastly, the updater itself needs to be upgraded to 64-bit code if possible.

all of this upgrading could be done at *install*. in a last-upgrade-version static "label" notice for people on 64-bit OS's in help, about, by telling the user about "the new 64-bit firefox/tb, and to download and install it to upgrade" this would solve that problem.

[jmic...@yahoo.com]

On Sunday, December 23, 2012 7:14:36 PM UTC-8, chris.m...@bigpond.com wrote:
> I don't think that you have taken a rational approach to the decision of dropping Firefox64 at all. I will outline my reasons for this below....
>
>
>
> 1) 64 bit code is the future of computing - Mozilla should be dropping support for the 32 bit version as it is 'dead code', has the least longevity and is a drain on resources - 32 bit code is on its last legs and will be gone in the next few years. Why is Mozilla wasting time and resources on this? It is a more 'viable' option to put those resources into the development of Firefox64.
>
> 2) Security - 64 bit code brings better security. Running 32 bit code in a 64 bit OS causes a gaping security hole while it is running in compatibility mode - not even Microsoft recommend this approach because 'native code is far more secure'. In this case that means 64 bit code should be used not 32 bit.
>
> 3) Mozilla is further wasting resources with FirefoxOS - even if a miracle was to occur and it reached 0.1% it would still be a wasted effort - seriously what do you think FirefoxOS will achieve in the long run? I will tell you - NOTHING!
>
> 4) Those that think 64 bit is 'only for memory usage' or that '32 bit is good enough' have the wrong attitude for I.T and should be shown the door as they are only dragging you down. Mozilla needs to continue moving forward not embracing the past.
>
> 5) There is simply no valid reason given by Mozilla to drop support for the 64 bit version - all the reasons given (that I have read) would only make sense if they applied to dropping the 32 bit version.
>
>
>
> I use Firefox64 simply because it is 64 bit, has better security, renders pages faster and crashes less often (for me the crashes are less). I have no issues with 64 bit plug-ins not being available as all the plug-ins I use are 64 bit already and have been for a few years now. Even game makes are porting their engines to 64 bit as they too can see the end in sight for 32 bit code.

...and by the way, 64-bit has been now since about 2005 or so, which is 2013-2005=8 years. I think it's past due time for a 64-bit version.

all my programs except one msdos-only utility I compile for 32+64-bit, because I want everyone to be able to run it with as few limitations as possible and I want compatibility with everything. some of them are resource-intensive and need 64-bit when I am working with multi-TB disks, like the directory walking program.

[jmic...@yahoo.com]

have you considered parallelizing your builds? it makes nice use of those multicore processors.

[jmic...@yahoo.com]

> have you considered parallelizing your builds? it makes nice use of those multicore processors. to compare, on my old pentium 4 HT (1 core 2-thread) 2.8GHz with 3GB RAM 32-bit, I made my builds serially. it took several days to a week I think to do the batch build.

read this on make.
http://www.gnu.org/software/make/manual/html_node/Options-Summary.html#Options-Summary
http://www.gnu.org/software/make/manual/html_node/Parallel.html

I parallelized my 50+ builds to simply build each project as its own batch file, but the controlling batch file simply ran each as a background job. in windows you do this with the

start cmd.exe /c mybatchfile.cmd

command. but in linux you can do it like

make -f Makefile&

(to example your jobs, simple run the shell command

jobs

you can fg or bg the task by task number.

you can do this using gnu make with the -j option. your build time will cut to a fraction. think: you have say 8 threads, then use make -j 8 to cut to 1/8 the time.

I should mention that on my nice i7-3970x I just got, I can compile 50 complete programs (utilities) in 2 minutes (I was flabbergasted and overjoyed). you need to do system burn-in to make sure it can handle 100% load though. the cpu cooler must have the proper amount of thermal compound, closed-loop liquid cooling is a good idea, and testing with prime95 as a cpu burn-in test is a good idea for 4 hours, and having a PSU that can handle 100% load according to parts specs is a Really Good Idea. your case should have very very good cooling. all the fans you can spare. but at the very least, upgrading the proc on your build system make a HUGE difference. AND, if you can get one of those 80-thread HPC servers for doing builds, all the better. http://exxactcorp.com/index.php/solution/solu_detail/42

something like an HPC CPU system might reduce your build times by maxing out parallelization. it will most certainly peg your disk usage. at some point, there would be a limit on speed due to disk read/write speed and rotational latency and the number of files to compile. but then that's what EMC RAID systems are for? it depends upon how much you have to spend on hardware and how much need there is for speeding up the builds.

a little build server like that e7-based one could devote 6.4GiB RAM per job (512GiB total RAM). AND it fits in an office, has 4 10-core xeon procs (the procs are about $1-4k each).

and it requires SOME work to move to a new build system, especially when you are parallelizing builds. it requires editing files to make things work in serial+parallel rather than serial only.

hope this helps.

[jmic...@yahoo.com]

On Wednesday, December 26, 2012 9:11:15 AM UTC-8, Gavin Sharp wrote:
> This discussion and proposal is really not about changing our development
>
> focus (though a lot of people have tried to make it about that). This is
>
> now very specifically about making our Nightly test audience focus on the
>
> existing development focus (32 bit Windows builds), because testing builds
>
> that aren't being worked on has proven to be a poor use of those resources.
>
>
>
> Graphics and modelling software have different memory use constraints than
>
> web browsing software in the common case, so it's not unexpected that they
>
> would make different decisions about where to focus their development
>
> efforts. The prevalence of 64bit hardware is just one factor, and its
>
> really not a significant one given its compatibility with 32bit software.

actually, from what I read, 32-bit software on x64 windows is a security risk according to one person, according to this page, it's slower.

http://searchwindowsserver.techtarget.com/tip/Run-32-bit-applications-on-x64-Windows-servers


Jim Michaels