I've been using Windows 8 as my primary desktop operating system for the past few weeks. You can pretty much avoid Metro after logging in, just hit WINKEY + D to take yourself to the desktop. From there it's pretty much Windows 7 with better multi-monitor support.

There's a handful of areas where it could be more polished, but you can't complain about them in the context (preview release).

You can't avoid seeing Metro entirely, but it's not something you have to work with. In Windows 7, if I have to launch something that's not pinned to my taskbar my workflow is WINKEY + Type the program name + ENTER. Windows 8 preserves this workflow. You'll be typing the program name into a Metro search bar, but at the end of the day the same program starts up on the Windows 8 desktop.

The application was originally written in 1993 and there's been various levels of pragmatism applied to new development and maintenance between then and now. There are "proper" ways of manipulating data in an RDBMS invariant manner, but the application was never designed for it.

As it stands we're looking to get rid of support for JET and use SQL Server. For our application SQL Server does everything we want it to, therefore interoperability with other database platforms isn't a high priority.

Perhaps when we've rewound our application to only support the one provider and get rid of all the JET crud (no pun intended) we'll more easily be able to add an abstraction layer.

I'm well aware of the Express edition, but it's a bit heavy for our customers to install and manage. They're not very technically minded. LocalDB looks to be a good replacement for our customers using Microsoft JET.

Further, our application is meant to be run on a desktop and to have a full blown copy of SQL Server Express running in the background just for our application is not ideal.

your app probably needs a standalone database server.

Several of our larger customers (10GB - 250GB of data) use SQL Server 2005 Enterprise and SQL Server 2008 Enterprise very successfully.

Our thousands of smaller customers (50MB - 250MB of data) use Microsoft JET mostly successfully. But for development it's a pain in the ass, and as I said above, LocalDB seems to be a good replacement for Microsoft JET.

Whoops, I cut myself off...

The point I was trying to make is that we already have many places in our application where we go "if MSSQL, do this, else do that" to accommodate for Transact-SQL and JET-SQL. We're not after a third SQL dialect in our application (even if it is a close implementation of ANSI92 SQL).

To use some of SQLite's words, we're after for a drop-in database engine that's small, fast and reliable. SQL LocalDB fits the bill pretty well, with no major modifications to our application.

As for libraries for consuming SOAP web services, the endpoint we're talking to is a little bit liberal when it comes to the SOAP standards, so when we find a library that can talk to it (and deal with the protocol violations) that's what we use. So at the moment it's ATL/SOAP, and WSSAPI is also looking good. We haven't really evaluated other SOAP libraries in too much depth, other than WCF which is too standards-compliant (Microsoft standards compliant?!) for the version of "SOAP" we deal with.

Our application supports SQL Server and (unfortunately) Microsoft JET as database backends. Both database engines have their own proprietary syntax for some things, and our application is literally littered with:

if (sqlServer)
execute(

Unfortunately Windows 3.11 says that FreeDOS is "incompatible" and will refuse to run (wrong version). Hrmph.

I believe this is because Windows 3.11 relies on the implementation details of Microsoft's own DOS (certain things will always be in this exact memory location) and FreeDOS' implementation is not identical down to that level.

It's now Subsystem for UNIX-based Applications and it appears to be deprecated as of Windows 8.

I'm a developer at an ISV. Personally, I am waiting for XP to go. Microsoft has some great technology (WWSAPI, SQL Server 2012 LocalDB) that looks like it will solve some of the problems we need to solve with our application, but it's not available on XP. (Technically WWSAPI is, if you're willing to pay for the support contract.)

As it stands, while XP is still supported (mainstream, extended or otherwise) and we have customers on it we are unable to use these new technologies.

In the context of my job I don't think Vista is any different from 7 in terms of the technology available and the support effort.

At home I find 7 to be superior to XP and Vista. I don't think Vista fills any niche, XP has the 5-year-old-low-powered-device market, but anywhere else really should be using 7.

Where will this particular avenue lead us?

Space Elevators.

How does this invalidate my point? Have you tried opening a 100 page ODT file with tables and indexes made by OpenOffice in the various open software packages that support ODT and seen the results? The problem is universal - if OpenOffice was found to be infringing on this patent there will be similar issues.

First - I know i4i states OO does not infringe on the patent. If you would have been paying attention you would have seen the second word in my post. Second - The DOCX format is a standard.