36
General Software Discussion / Re: Stay Away From Microsoft VISTA
« on: September 09, 2007, 09:40 AM »
IMO, programs should not be modifying files in any location that gets virtualised in the first place. If it causes problems then the program was probably wrong to start with, and had been wrong for a long time (NT4). (I still run plenty such programs, though, and I'm glad they worked by default when I switched to Vista.)
Adding manifests to things is usually easy (there are some exceptions, like InstallShield exes) and programmers have had to do that since XP, anyway, in order to get the new-look controls. It's just another line in the same manifest file.
The virtualisation stuff can be confusing, I agree, but I think it makes sense given the alternatives. Hopefully it can go away in the next version of Windows after Vista forces developers to *finally* pay attention to the rules about where to store data (which, when ignored, usually meant those programs didn't work without admin rights in NT4, Win2k and XP).
The only thing like this that I feel MS messed up with is the way 64-bit works. Apparently with the aim of making it as easy as possible to recompile apps with hardcoded "System32" paths and so on (which should not be hardcoded in the first place; there's an API to get the system directory), they've given us a weird OS where different apps see completely different folders/registry and 32-bit binaries are in directories whose names end in "64" while 64-bit binaries are in directories ending in "32". God knows what 128-bit Windows will look like. :)
Maybe MS were worried nobody would port apps to 64-bit if it wasn't trivial but it turns out people are having to port anyway as their users are going to 64-bit Vista (sometimes for good reasons, sometimes just because 64 is a bigger number than 32, heh). It also turns out that doing a search & replace for "System32" in your code (or even making the code call the API like it's supposed to) is a trivial job compared to inspecting and testing for all the other 64-bit errors that come from bad pointer casts (almost always due to the archaic way Win32 casts everything to LPARAM/WPARAM/BOOL/etc.).
Adding manifests to things is usually easy (there are some exceptions, like InstallShield exes) and programmers have had to do that since XP, anyway, in order to get the new-look controls. It's just another line in the same manifest file.
The virtualisation stuff can be confusing, I agree, but I think it makes sense given the alternatives. Hopefully it can go away in the next version of Windows after Vista forces developers to *finally* pay attention to the rules about where to store data (which, when ignored, usually meant those programs didn't work without admin rights in NT4, Win2k and XP).
The only thing like this that I feel MS messed up with is the way 64-bit works. Apparently with the aim of making it as easy as possible to recompile apps with hardcoded "System32" paths and so on (which should not be hardcoded in the first place; there's an API to get the system directory), they've given us a weird OS where different apps see completely different folders/registry and 32-bit binaries are in directories whose names end in "64" while 64-bit binaries are in directories ending in "32". God knows what 128-bit Windows will look like. :)
Maybe MS were worried nobody would port apps to 64-bit if it wasn't trivial but it turns out people are having to port anyway as their users are going to 64-bit Vista (sometimes for good reasons, sometimes just because 64 is a bigger number than 32, heh). It also turns out that doing a search & replace for "System32" in your code (or even making the code call the API like it's supposed to) is a trivial job compared to inspecting and testing for all the other 64-bit errors that come from bad pointer casts (almost always due to the archaic way Win32 casts everything to LPARAM/WPARAM/BOOL/etc.).