[Bf-committers] Blender on Windows - some thoughts about XP and32bit
kuzsasha at gmail.com
Fri Dec 6 18:46:43 CET 2013
The problem is the most of the developers don't have Windows XP on their
machines. I think the best course of actions is to support XP for the
next 2-3 releases using existing vc 2008 libs. Also we should make a
big notice on the download page that support for xp is coming to the
end. (And see if there will be an uproar) . MS will drop support for XP
in April. We don't even support Mac OS 10.5, which is as old as Vista.
If someone is willing to support XP libs, so much the better. I see 3
1) Compile blender and libs with vc 2008 or 2010. However, we are
missing a lot of the new functionality and speed. (by dropping, we can
possible move to c99 and c++11 and remove #ifdef and part of boost)
2) Compile with mingw.
3) Compile with vc 2013 with v120_xp toolset selected. But we need to
make sure that all libs are compiled with this flag (this might be very
complicated with different build systems).
On the bright side, we can easily drop Windows XP x64.
On 12/6/2013 9:56 AM, Ton Roosendaal wrote:
> I think we can keep supporting Windows XP (and any OS), for as long:
> 1) At least one developer helps building and supporting it
> 2) It's not holding back current and approved projects.
> This we can communicate well though.
> XP users should be happy 2.69 is working well even.
> Further, we can simply keep our code to be 32 bits compliant for a while. Also this is relatively easy to support and not really holding us back now.
> Ton Roosendaal - ton at blender.org - www.blender.org
> Chairman Blender Foundation - Producer Blender Institute
> Entrepotdok 57A - 1018AD Amsterdam - The Netherlands
> On 5 Dec, 2013, at 19:17, Sergey Sharybin wrote:
>> We would need to drop XP at some point, but it should not be ASAP. It
>> should be a clear for everyone process with defined release when we're
>> dropping. Ideally it should be connected with switching to a new official
>> compiler for windows. Meaning, when we're considering MSVC 2013 as a
>> default to build blender on windows then we might stop maintaining old
>> libraries and let XP support fade down naturally.
>> As for dropping support of 32bit -- i don't see good reason for this just
>> yet. It might be 2-3 people who supports libs on windows, but i only know
>> one who supports all the libs libs on linux. It's not much of hassle if we
>> update libs only when we need this (meaning not just to be on a leading
>> edge with brand-new libs).
>> Dropping 32bit windows builds would mean we're dropping atom support as
>> well? It might be still useful to be able to run blender on a netbooks i'd
>> say. Also, you might want to use PAE on 32bit platform because of some
>> better load balance and so.
>> On Fri, Dec 6, 2013 at 12:07 AM, Thomas Dinges <blender at dingto.org> wrote:
>>> Hi Mitchell,
>>> this is strange, maybe its due to some compiler flags?
>>> Maybe Visual Studio 2013 doesn't suffer from this, otherwise it would be
>>> bad. Needs investigation.
>>> Best regards,
>>> Am 05.12.2013 18:10, schrieb Mitchell Stokes:
>>>> The last time I checked, vc11 created slower Blender builds than vc9 for
>>>> the game engine. Not that I would like to stick to vc9, but vc11 isn't
>>>> always faster. For a specific example, I've found OpenMP to be rather
>>>> It's been a while since I last ran some tests, but I seem to remember the
>>>> difference being at least 20%.
>>>> --Mitchell Stokes
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>> With best regards, Sergey Sharybin
>> Bf-committers mailing list
>> Bf-committers at blender.org
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers