Hacker News Reader

Comment by mkesper | Hacker News Reader

So why did you start so late / why does it take so long?

A lot of businesses I talk to have a lot of legacy applications which work well under XP, but break for whatever esoteric reason (for example, an old Access database, or VB6 app) under Windows 7/8. An equally large pain the ass is a ton of intranet sites break when switching to IE9 and above (heck, a lot of companies still force IE6/7 and below with Group Policy). It's difficult to make a case to management when everything is working well (it's hard to explain the nuances of "end of support life cycle" to someone who needs help "getting to the Google").

Also, there are a fair number of desktop software products which don't even support Windows 8 yet. Hard as it may seem for the crowd here, most of the software world is not on the HTML5/Ruby/OMGMVCJAVASCRIPTBRO bandwagon yet.

I can't speak to the websites having problems with IE9 and above, however the desktop application compatibility situation has ended up being overblown in my experience. Sitting down with "Process Monitor" and weakening permissions or spending a few minutes figuring out how to apply the existing Application Compatibility shims the OS provides has sorted out almost every problematic desktop application. For the few applications that failed to yield the "Windows XP Mode" VM (which comes with Windows 7 Professional licenses) has worked fine (albeit the multiple users per PC "story" for "Windows XP Mode" is terrible and having a bunch of XP VMs to support adds complexity).

What's wrong with the OMJB framework? I've written hundreds of large-scale multi-optional dynamic polymorphic backend front-end GUI shell's on legacy mainframe infrastructure with it.

Because XP probably does everything they need and the upgrade will be reluctant.

I have a Windows XP VM on my computer that runs my client connection to a piece of essential hospital software. It cannot be run on a machine that has .NET 3.5.1 and > 4.0 installed simultaneously, or it throws assembly compatibility errors. The ActiveX components seemingly only work in IE8, not even IE9 in compatibility mode. The vendor will probably only fix this compatibility problem when the piece of software has even less support than VB6 (i.e., virtually none). Because healthcare.

Making sure all the software and custom apps work with conversion of those that don't takes a fair amount of time in a big organization. I remember one place going from NT 3.51 to NT 4.0 and all the fun of the "new interface" back then.

Reply on news.ycombinator.com