Jeremy White wrote:
A while ago, Rob and I were in a discussion about how to allow a single
compiled ppm of Win32-GUI to manage to work with all the available
features to a particular OS, dependant on the platform at runtime. There
is definitely a severe trick here in that for the most part, the
decision of which OS's capabilities to embrace has been defaulted to
95/NT4 level to ensure compatibility backwards to those platforms.
Windows 95 - does anyone still use that?:) For my Win32-GUI project I
use functionality that limits my users to Win 2000+ (which in my case
isn't a problem). I would have thought win 98 should be the minimum
supported platform?
Agree, but think that Win98 ahould still be considered as there's lots
of people (including me) still using it.
However there are some nice little features available in 2000+ such as
the NotifyIcon's balloon tip (which we all know and hate because of that
annoying icon we've all got that is constantly popping useless crap).
While the data structure to use this feature is easily implemented via
Win32::API, or simply a mess of pack/unpack, the problem comes down to
the fact that the PPM was indeed compiled with a WINVER of 0x0400,
meaning 95/NT4.
When you say compiled PPM what do you mean? Would a PPM built by Win98
be different from one built by XP?
That would not be my intention. One PPM is my goal.
As for new functionality, I'm sure there are features in Win32-GUI now
that would only work on 2000/XP (such as various options for dialog's)
so why would NotifyIcon's balloon tip support be any different?
Because supporting them will break Notify icon support for Win98 (well
actually it will break any win32 version with Shell.dll less than
version 5.0, which breaks win98 if it doesn't have IE 5 or greater
installed), as the NOTIFYICONDATA structure has different sizes.
I'm not adverse to adding these features (in fact quite the opposite,
and it is in my plan), but wanted to have a general mechanism in place
that we can use to (hopefully) gracefully fall back to earlier version's
behaviour, or at least provide warnings, without crashing.
For this particular example the MS documentation on the NOTIFYICONDATA
structure explicitly tells you how to check the library version (care
needed, as the function that gives the information is not present in
early versions), and how to set the structure.
What I'd like is a mechanism to check the dll version that doesn't get
called within every method (although that might be a starting point),
but gets called once at object initialisation time.
Regards,
Rob.
