Hi,
On Sun, May 08, 2005 at 03:47:52PM -0500, Dustin Navea wrote:
Figures.. they are always FUBAR'ing things lol..
That's just normal in software development. But MS does seem to have some special skills there ;)
Instead, maybe we should implement cards16.dll and cards.dll. Then maybe there would be the possibility to programmatically advise the user to move the cards16.dll .so to the cards.dll .so in case he requires the 16bit version?
Nah, its not worth the trouble to most users. They just expect it to work.
True. And since NT-based systems most likely only supply the 32bit version, this is what we should do as well.
I think I wouldn't feel too uncomfortable with providing the 32bit cards.dll only, even though this is a less preferrable situation.
I agree here too, as 16-bit support is being phased out (Longhorn wont run any 16-bit apps), so theres no need for us to keep supporting it. If someone wants to play with a 16-bit program, they can make a 200mb DOS/Win3.11 Partition lol...
Do we want to throw out the baby with the bath water? In this case it's an obvious conflict between 16bit and 32bit, and note that it's even with a very rarely used DLL, thus it's easy to give up on it.
In all other cases in which 16bit and 32bit can happily co-exist I don't see much reason why we should discard 16bit support.
Andreas