<div dir="ltr">If we are forced to use ancient toolchains to maintain support for Win9x, then I fully support the idea of dropping support for this platform altogether, or to create a separate toolchain just for this.<div><br></div><div>After all, we have a separate toolchain and build target for the old OS X builds (although these are BE...).</div><div><br></div><div>I really don't think that anyone is using Win9x any more, other than in really ancient PCs. Nowadays, you can get a Raspberry Pi 3 for $35 or a Raspberry Pi Zero for $5, so there's really no compelling reason to use ancient hardware with Win9x these days.</div><div><br></div><div>If you're still doubtful, do a web search for OS usage, e.g. this wikipedia article:</div><div><a href="https://en.wikipedia.org/wiki/Usage_share_of_operating_systems">https://en.wikipedia.org/wiki/Usage_share_of_operating_systems</a><br></div><div><br></div><div>If you read stats on Windows version usage, you'll see that anything older than XP is basically non-existent nowadays (and for good reason). Also, there isn't any decent browser that works under Windows 9x any more:</div><div><a href="http://www.cnet.com/forums/discussions/modern-browsers-for-windows-98-systems-363040/">http://www.cnet.com/forums/discussions/modern-browsers-for-windows-98-systems-363040/</a><br></div><div><br></div><div>So, again the only hardware that people would run ScummVM with Win9x would be very (very) old 486 or Pentium PCs with 32MB of RAM, but you can get a system that's many orders of magnitude faster than that for $5 (Raspberry Pi Zero).</div><div><br></div><div>Thus, I really don't see why we should maintain support for operating systems that are 18-21 years old now, and noone's using them, since there are tons of very cheap and vastly superior alternative options.</div><div><br></div><div>Regards</div><div>Filippos</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 7, 2016 at 5:59 AM, Travis Howell <span dir="ltr"><<a href="mailto:kirben@optusnet.com.au" target="_blank">kirben@optusnet.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 6/03/2016 10:08 PM, Eugene Sandulenko wrote:<br>
> On 5 March 2016 at 23:48, Travis Howell <<a href="mailto:kirben@optusnet.com.au">kirben@optusnet.com.au</a><br>
</span><span class="">> <mailto:<a href="mailto:kirben@optusnet.com.au">kirben@optusnet.com.au</a>>> wrote:<br>
><br>
>     Only for release builds, and only if no major code changes are required<br>
>     for continued Windows 9x/ME support. I would have to provide the<br>
>     additional build, as I doubt buildbot has the disk space for another<br>
>     large tool chain.<br>
> We have 2 buildbots now (another one is in preps), and that another one<br>
> has twice disk space that our main one. Thus, if it is possibble to set<br>
> up a chain, that would be lovely.<br>
<br>
</span>Basically the tool chain and extra libraries offered on the current<br>
MinGW compile guide on the ScummVM wiki, but I doubt they could be just<br>
swapped into a cross-compiler environment.<br>
<span class=""><br>
>     I don't think this will be viable in the long term though, since ScummVM<br>
>     will move to SDL2 in the future, which completely lacks any support for<br>
>     Windows 9x/ME.<br>
><br>
> We are discussing switching to SDL2 as primary backend, but there are no<br>
> plans to drop SDL1 support, thus some ports like Win9x/ME, could still<br>
> use SDL1.<br>
<br>
</span>That is good to know, as it would make future builds for Windows 9x/ME<br>
much easier, if they were to continue for release builds.<br>
<span class=""><br>
> Can we now try to do the following:<br>
><br>
> As I understand it is matter of toolchain, so we mark current build as<br>
> Win95/ME+, then create another build with the new toolchain, and name it<br>
> scummvm-1.8.0a, and mark is as WinXP+. By doing this now we could start<br>
> gathering statistics on downloads already now, and by 1.9.0 make an<br>
> informed decision.<br>
<br>
</span>It would be best to wait for ScummVM 1.8.1, to be on the safe side. I<br>
just switched to updated tool chain (GCC 4.9.3) for MinGW, recompiling<br>
all required libraries due to ABI changes, and I would rather these<br>
builds have a little more overall testing.<br>
<br>
------------------------------------------------------------------------------<br>
Transform Data into Opportunity.<br>
Accelerate data analysis in your applications with<br>
Intel Data Analytics Acceleration Library.<br>
Click to learn more.<br>
<a href="http://makebettercode.com/inteldaal-eval" rel="noreferrer" target="_blank">http://makebettercode.com/inteldaal-eval</a><br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Scummvm-devel mailing list<br>
<a href="mailto:Scummvm-devel@lists.sourceforge.net">Scummvm-devel@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/scummvm-devel" rel="noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/scummvm-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">"Experience is the name every one gives to their mistakes" - Oscar Wilde </div>
</div>