Yes, I know. But the resource dll doesn't check whether the build number matches - it checks whether its internal revision id matches the id passed by the caller of DllVersion().

If it doesn't match then the resource dll shows a message box saying "Resource file version mismatch." in the appropriate language (although the caption of that box is seems to be always in the system default language) and fails the call whereupon vfp8?.dll aborts the load and either vfp8?.dll or the loader stub shows another message box ("Visual FoxPro cannot start. Could not load resources.").

So it could be possible that a resource dll loads even if its build number diverges slightly. But for practical purposes it is sufficient to check the build number since the dlls seem to come always in matching sets.

Note: the loader stub determines the runtime dll version only insofar as it looks for vfp8r.dll or the VisualFoxProRuntime.8 registry key by default. You can force it to use another runtime dll via the /D switch - even VFP6/VFP7 dlls if you are so inclined. Nice for quick&dirty benchmarking without recompiling an app. The runtime dll in turn determines which resource dll it wants unless you use the /L switch.