On 2013-03-19 Tuesday at 12:42 +0100 Bram Moolenaar wrote: > Mike Williams wrote: > > >> Following discussion in another thread this patch moves the minimum > > >> version of Windows supported in a default build of VIM up to Windows XP. > > >> This should make it easier to use features in newer versions of > > >> Windows. > > >> > > >> Changes are only in the various Windows make files that mention WINVER - > > >> bc5, cygwin, ming, and MVC - but I only have VS so have not tested the > > >> other compilers. Can others try the patch with other compilers and > > >> report any problems please. > > > > > > What effect does this change really have on the generated binary? > > > Besides no longer being able to run it on Windows NT and Windows 2K? > > > > The setting for WINVER filters the content of the Windows include files > > to remove newer APIs added in later version of Windows. That way the > > binary does not accidentally try to use a non-existant API. In the case > > of cleartype support, since this did not exist in Win2k and using a > > WINVER value of 0x0400 for Win2k meant the cleartype functionality did > > not get compiled in. Leaving WINVER at 0x0400 will mean a lot of new > > Windows functionality cannot be used that easily. > > > > Note WINVER is meant to control what Windows APIs are available at build > > time, not a means of deciding what platform you are currently running on > > - the code in modify_fname() in eval.c based on _WIN32_WINNT (set to the > > same as WINVER) is most likely the wrong solution. I wouldn't be > > surprised if the #undef of WIN32_WINNT in if_ruby.c is also related fallout. > > > > > I don't see anything getting simpler yet. The docs I find for WINVER > > > are not very specific. > > > > > > If we go this way we need to make a binary for Windows 95 available > > > somewhere. I don't want to leave any user without their editor. > > > This can be as simple as telling users which old version to use. > > > > If we want to continue building for Win95/98/SE then that should be a > > build option that sets WINVER appropriately. > > > > The alternative would be hard code copies of Windows APIs into VIM and > > work out at runtime what VIM can actually use by querying which platform > > it is currently running on. > > I should build and release a 7.4 binary soon, we are running out of > patch numbers :-). > > So how about this: 7.4.000 will be released with MS-Windows binaries > that still support the old systems. Once it's out and it looks OK we > drop support for older systems. That way 7.4 is what needs to be used > for old systems. It includes a lot of bug fixes since the last binary > release. And then 7.4.001 and further can add stuff that is not > possible when building for the older systems.
Prior to dropping support for w2k please consider: (1) w2k is known to be the least faulty OS version released by its vendor so far, because the phrase “based on NT” was a lot more than just an advertising, the development history of this OS version differed significantly from all other OS versions of this vendor (2) when running as kvm or qemu guest, w2k yields best performance among all OS versions of this vendor For this two reasons IMHO support for w2k remains useful, even more than a decade after release of w2k. -- Thanks Roland Eggner
pgpkaMB5Qe2ru.pgp
Description: PGP signature
