Richard Campbell schrieb:
his may seem good, but down the road you'll run
into issues. Probably
one of the most obvious issues is if a user develops his application on
ROS. If he makes use of these vista only APIs then suddenly his app
doesn't work on Windows.
If you develop an app on Vista using Vista APIs, you
will find that it
won't work on XP. If you use .NET you will find it won't work on a
system without .NET installed. That's the way the cookie crumbles. A
developer should at least take a quick look at MSDN before using a
function and MSDN clearly says if a function or flag or whatever is
available on nt4, 2k, xp, 2003 or vista. If he doesn't care, his problem.
Our goal is that everything that works on windows also works on ros. But
noone ever said that everything that works on ros will also work on
windows. Sooner or later ros will be installable on an EXT2 filesystem
and probably others too. Does that wok with Windows?
Another reason is application developers do
funky things. They've been known to check for certain entry points in a
DLL. If said DLL has the entry point they may wrongfully assume they
are running on vista and start making use of VISTA APIs. If this
happens and ROS doesn't support ALL the vista APIs then the app will
more then likely crash.
I doubt that a developer would go that way. Instead the app should check
the windows version reported from GetVersion(Ex). And afaik we still
report NT 5.0. If we found some app does this, than this becomes a valid
point.
I don't even go into the issue of bloat (wasted
disk space, memory, etc.)
Compare the size of windows to ros. You still speak of bloat? Those few
additional vista apis don't make much disk space.
A solution to this would be to disable the compilation
of these items
unless a flag is turned on. That way vista compatibility could still be
enabled at a future date when the api is mature.
A variable for aimed compatibility in the config.rbuild or somewhere
else seems to be a good idea. So if you want Vista APIs, just change
that variable. It could also be used for other compatibility things like
syscall numbers. If we want to be compatible to win 2003, use 2k3
syscall ids, or if we want to be compatible to xp, use xp syscalls. Most
things should be uneffected, but we could in fact add some conditional
compiling here and there to achieve the maximum compatibility with one
windows version. Might be useful for testing, especially for
gdi32/user32 and not too much work. It would probably be the best choice
to make our user32 and gdi32 work on different platforms (currently xp
is the only platform with matching syscall ids) without much overhead
and still being fully compatible (some win32k apis change the numer of
parameters between different windows version, could mostly be solved by
a simple stub).
Regards,
Timo