If moving to 64 bit is a big deal then you're clearly doing something wrong. Not from the users' point of view; clearly this will bring some user benefits. But if rebuilding your application to work on a 64-bit runtime with 64-bit libraries takes anything more than recompiling the existing code with new compiler flags then what does that say about the code?
If this is a big deal for Microsoft then that implies that the code is riddled with assumptions and probably has terrible type casting discipline. It suggests that there are places where it has some constant that represents the size of some structure and if someone else were to change that structure it would break, because the constant is hard-wired rather than calculated by the compiler. It says that the code has insufficient and/or incorrect abstractions about the platform underneath it. It basically says that it's full of all the sorts of code smells that lead to bugs, instabilities and vulnerabilities.
Visual Studio has available for 24 years. The fact that it was a heavy lift to move to 64-bit probably has its roots in a code base that's quarter of a century old. At one level I'm just glad I'm not its product manger, but at another level I can't help thinking: if the people writing the IDE write code like this, do I really want to trust the development of my critical projects to their tools?
You are being a bit unfair here. Only in toy projects you switch a flag and everything works. Complex projects have to do architecture-specific optimisations, and the nature of being a real-world project (and a complex one, that is) implies that code quality is secondary to actually meeting deadlines and producing things that might entice people/organisations to buy your product, so that you can continue working on it. Features sell easier than bugfixes... (even if said features are bloat)
I believe this view to be largely incorrect. The move to 64-bit was probably intentionally delayed because 32-bit Windows builds were still being produced until May of last year and VS still needed to run on those versions of 32-bit Windows, Microsoft doesn't release a new VS version every year, and it's always a good idea to wait 6-12 months when managing a major decision like dropping support for a 32-bt OS to see which customers start yelling and for what reasons. It would kind of suck if 32-bit Window
WARNING TO ALL PERSONNEL:
Firings will continue until morale improves.
If moving to 64 bit is a big deal... (Score:3, Interesting)
If this is a big deal for Microsoft then that implies that the code is riddled with assumptions and probably has terrible type casting discipline. It suggests that there are places where it has some constant that represents the size of some structure and if someone else were to change that structure it would break, because the constant is hard-wired rather than calculated by the compiler. It says that the code has insufficient and/or incorrect abstractions about the platform underneath it. It basically says that it's full of all the sorts of code smells that lead to bugs, instabilities and vulnerabilities.
Visual Studio has available for 24 years. The fact that it was a heavy lift to move to 64-bit probably has its roots in a code base that's quarter of a century old. At one level I'm just glad I'm not its product manger, but at another level I can't help thinking: if the people writing the IDE write code like this, do I really want to trust the development of my critical projects to their tools?
Re: (Score:3)
You are being a bit unfair here. Only in toy projects you switch a flag and everything works. Complex projects have to do architecture-specific optimisations, and the nature of being a real-world project (and a complex one, that is) implies that code quality is secondary to actually meeting deadlines and producing things that might entice people/organisations to buy your product, so that you can continue working on it. Features sell easier than bugfixes... (even if said features are bloat)
Re: (Score:1)
I believe this view to be largely incorrect. The move to 64-bit was probably intentionally delayed because 32-bit Windows builds were still being produced until May of last year and VS still needed to run on those versions of 32-bit Windows, Microsoft doesn't release a new VS version every year, and it's always a good idea to wait 6-12 months when managing a major decision like dropping support for a 32-bt OS to see which customers start yelling and for what reasons. It would kind of suck if 32-bit Window