[ros-dev] Targeting multiple Windows versions

[Timo Kreuzer]

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