Drop support for Windows XP
Windows XP hit its end-of-life today (April 8, 2014).
We should identify and drop support code for Windows XP. This is mainly going to be a matter of identifying cases where we use LoadLibrary and GetProcAddress to find always-present-functions in always-present DLLs, and looking for opportunities to move from old busted APIs to fresh new ones.
I'm making this a separate ticket from legacy/trac#11444 (moved) (removing support from pre-XP versions) since the timing on the two can be argued to be separate. Nonetheless, if we agree to do both at once, that might be clever.
Activity
changed milestone to %Tor: unspecified in legacy/trac
added cleanup in Legacy / Trac component::core tor/tor in Legacy / Trac deprecate in Legacy / Trac milestone::Tor: unspecified in Legacy / Trac priority::medium in Legacy / Trac severity::normal in Legacy / Trac status::new in Legacy / Trac technical-debt in Legacy / Trac tor-relay in Legacy / Trac type::defect in Legacy / Trac windows in Legacy / Trac labels
Is there a particular difficulty involved in continuing to build on such a platform? We didn't have a 'drop support for irix' ticket, even though irix is long dead by most standards. And we try to make a habit of building and working everywhere (for the tor component that is -- for Tor Browser our hand is forced).
Trac:
Description: Windows XP hit its end-of-life today.We should identify and drop support code for Windows XP. This is mainly going to be a matter of identifying cases where we use LoadLibrary and GetProcAddress to find always-present-functions in always-present DLLs, and looking for opportunities to move from old busted APIs to fresh new ones.
I'm making this a separate ticket from legacy/trac#11444 (moved) (removing support from pre-XP versions) since the timing on the two can be argued to be separate. Nonetheless, if we agree to do both at once, that might be clever.
to
Windows XP hit its end-of-life today (April 8, 2014).
We should identify and drop support code for Windows XP. This is mainly going to be a matter of identifying cases where we use LoadLibrary and GetProcAddress to find always-present-functions in always-present DLLs, and looking for opportunities to move from old busted APIs to fresh new ones.
I'm making this a separate ticket from legacy/trac#11444 (moved) (removing support from pre-XP versions) since the timing on the two can be argued to be separate. Nonetheless, if we agree to do both at once, that might be clever.
imagine doing some research for a historical movie in the 19 century. you find a historical buiding from 1820 put in some chairs and a table from 1800 and put some plates and cutlery from 1915 on it. you think it might not be 100% historically accurate but it seems legit.
now imagine someone 200 years in the future who is trying to see how software in the early 21 century was. he gets a pc from 2020 and tries to install an os from 2000 to run software from 2015. as you might expect this will probably fail.
for people in the future this century will be the century of wastefulness. therefore i have no understanding for people who are even trying to speed this throwaway cycle up.
Trac:
Username: elyptermentioned in issue legacy/trac#13755 (moved)
mentioned in issue legacy/trac#13758 (moved)
moved from legacy/trac#11445 (moved)
added Bug label and removed 1 deleted label
Closing in favor of #11444 (closed)
added Technical Debt label and removed 1 deleted label
