Vista, YIKES. No wonder you hadn't upgraded! Were there any businesses (that had tested it) that actually installed that POS company-wide? Win7 came from a different team entirely, the ones who made NT which knew a little bit more about how computers (should) work than the Vista crew. Vista was one of the biggest failures in software. MS originally pulled the plug on XP after the Vista release and companies like Dell were still selling XP machines against MS wishes (they sold it with Vista licenses -technically- but had XP "upgrades"!), because no one wanted Vista! MS had to recant & keep supporting XP until they had an actual alternative! How embarrassing for the Vista team.
My last job was as a Windows Desktop App developer, and we all developed on XP machines, we had a Vista box for testing but no one wanted to use that OS on the development machine... IT SUCKS. Win7 is much better. Now that I'm at Kiva, I work on a Mac. The tower that runs my home plasma TV is a Win7 machine and I still have another Win7 tower machine to do KivaBank development, but that only gets switched on if I have something to upgrade or fix. I've been a Windows user since back to MS-DOS days, and until Kiva, all of my previous development has been on Windows machines (though I bought a MBP to do iPhone development). Mac (now that it's resting on Unix since OSX) is far superior to Windows in so many ways. Security on Windows is an
afterthought and makes many programs not work once implemented since everything on Windows was always a free-for-all open playground for the developers. You want to modify registry settings for an app you didn't write? NO PROBLEM! You want to delete/modify files that don't belong to you? NO PROBLEM! You want to replace critical system files (with potential viruses)? NO PROBLEM!
For Unix-based OSs, security was there from the start. In the early days of the web, IE let any website load an ActiveX control and run it in the browser without even asking the user if they wanted to install it (MS's naive thinking: "Ooo, too confusing for users and it makes creating websites for IE too hard! What Windows developer would ever do something
bad?"). That ActiveX control was running *without a sandbox* and could read/alter/delete
anything on your machine. The
only safeguard was that the ActiveX controls had to have a "safe bit" set in order to run in the browser. Who got to control whether or not the single "safe bit" was set? THE DEVELOPER! So any malicious developer could
easily set the "safe bit" to True (1) and execute any code they wanted to on your machine without restrictions and without your permission! That's how much Microsoft was thinking about security back then... IOW, not-at-all! MS had to introduce security (which breaks a bunch of existing programs due to the previous assumptions of "no restrictions"), Unix-based OSs had security from the start. So when people complain about how their programs don't work on newer Windows versions, it's because those programs were doing things they never would have been able to do in the first place on secure OSs. MS has had to balance usability and past-program compatibility with security. Even the whole "screen goes grey, user has to accept code to run" feature in Vista has known hacks around it. Essentially, it's only there to make the user feel-good about how secure things are, not because it actually is secure. Even Program-based permissions breaks down, because the Windows API allows a developer to load your DLL into the process space of
another process. So, I can get my code to run with all the permissions you've granted to other applications, and all without you knowing about it. It's remarkably easy. When I first installed Norton Internet Security years ago, where you had grant permission to access the internet on a per-application basis. I wrote a DLL, loaded it into IE's process and since IE can't work without internet access, I could do whatever I wanted without user permissions -- very easy! That "security" was all smoke and mirrors and only prevented dumb developers from not easily working around that "security".
On a separate but related note, MS doesn't even support Macros in Excel for the Mac. Ian, your spreadsheets do not work when running on the Mac-versions of Excel. Was this MS just being lazy or were the macro abilities so un-checked that trying to implement them on an OS that cared about the source of the code (and all the restrictions about what it could/couldn't touch on the machine) too much of a hurdle for them to overcome? I don't know the answer to that. But my guess is that when Excel is forced to run in an actually-secure environment, macro-security was just too much for the team to bear.
Paul
