Developing for different versions of windows

[Blight]

Ok, as we all know, there are functions that work under Windows XP that would not work under Windows 98. The problem is there are also functions that would work under Windows 98, but not under Windows 95 or NT4.

What is the best way to debug your program to know if it would run under a specific version of windows... Is it possible to test this without having to install every version?

And if you must install each version, what is the best way to do it? VMWare? What would have the least negative overall effect on your system?

[gircobain]

I believe the most reliable way to test compability is debugging the software under the target os environment, especially when it comes to heavy hardware interaction, as to video/audio related softwares. Just setup each os in a separate partition.
The easiest way, of course, is emulating the target os with help of softwares such as VMWare. Those keep each os completely encapsulated with almost no impact on your system, other than perhaps a few virtual network adapters.

[Pyscrow]

If your writing new software, only write it for current operating systems, which means mostly XP. If you are writing comercial software, NT4 SP6 might get a gong, as a few comercial users still run it. Otherwise you run the risk of seriously crippling your software, (IE no direct X compatability for one), or doing considerable programming to use the new bells and whistles while still being able to run under old OS's (IE mouse wheel scrolling) to satisfy a shrinking user base.

If your maintaining old software, I would not be adding functionality to older OS compatable versions, just keep a win98 and an NT4 version available at existing functionality.

Your other issue is of course that systems running older OS's also tend to be old slow systems, which can also affect performance of your software, you might have to actually disable some functionality to make your software usable under these conditions.

[Nic]

gircobain is right really, the only way to be 100% sure is too test under all the operating systems...using vmware, if you can else you'll need multiple boot partitions.

I disagree with psycrow (no offense), one because I feel WinXP is not the majority OS at present (imagine writing the app just to use GDI+, people wouldn't be happy) and I also think you should write with as many standard API functions as you can to keep it as compatible as possible.

There's a shame there isn't a program that doesn't run through an executable and list all the API function calls you might be using that aren't compatible...if I ever get time ill write one. :)

-Nic

[Blight]

nic:
There is such an application, it's called AQTime, I tried it, but it doesn't really report anything special and yet the program doesn't work...

I may have to install Win95 :(

[Pyscrow]

Originally posted by Nic


I disagree with psycrow (no offense), one because I feel WinXP is not the majority OS at present (imagine writing the app just to use GDI+, people wouldn't be happy) and I also think you should write with as many standard API functions as you can to keep it as compatible as possible.

-Nic

Yeah I am a bit biased, most of what I write is pretty processor intensive, so I would really prefer users to be running a computer less than 3 years old!, (XP has been out 3 years now!), back when it was released a 1 gig unit was pretty classy!

I to try and write with standard API functions, h@ll I hate even using third party components!

[Nic]

@Blight: No Luck, If you find a solution, please let us know :)

@Psycrow: I know what you mean, I love it when my boss tells me the next app I am to write is only for Win2k+. Recently wrote something that used TransparentBlt, didnt realise the app needed to run on NT4. Ended up having to write my own TransparentBlt, not hard, just a pain in the a** ;)

-Nic

[Haaan]

or you can just use dynamic loading when you use 2000 or XP api with a good old LoadLibrary (or GetModuleHandle for GDI32, KERNEL32, USER32 and module that you assume they are loaded) and a GetProcAddress