Windows 7 gets built in XP mode
Microsoft's new OS comes with compatibility insurance policy (sort of)
Microsoft is adding a "Windows XP Mode" to Windows 7, in a move to encourage users to make the switch to the software vendor's forthcoming operating system.
The firm has built its XP mode into Windows 7 by using the Windows Virtual PC technology Microsoft acquired in 2003, to make the OS compatible to run apps designed for Vista's predecessor.
Redmond was keen to emphasise in a blog post late on Friday that it's hoping to woo small businesses to move to Windows 7 by bigging up the XP mode feature.
"Windows XP Mode is specifically designed to help small businesses move to Windows 7," said Microsoft. "Windows XP Mode provides you with the flexibility to run many older productivity applications on a Windows 7 based PC."
Users can install apps directly into the virtualised XP environment. The applications are then published to the Windows 7 desktop and they can be run from within that OS.
Microsoft said it will release a beta of Windows XP mode and Windows Virtual PC for Windows 7 Professional and Windows 7 Ultimate "soon" but wasn't more specific about when the test builds will land.
When Microsoft released Vista over two years ago, many businesses and individuals complained about compatibility snafus with applications that simply wouldn't work within the new OS.
Presumably Redmond has built in its virtualised XP insurance policy into Windows 7, a release candidate for which is expected on 30 April, to avoid some of the problems that dogged Vista from day one. ®
Re: @INI vs Registry
"Many programs waste tons of CPU cycles reading the same registry keys over and over again."
Again, that's a result of lazy programmers. Reading the same registry key over and over again is a complete waste of time - I totally agree. Which is why RegNotifyChangeKeyValue exists. Read the registry keys you're interested in on startup and watch for changes.
"You can't add security to an insecure API without breaking old apps."
And so you forcibly ensure the machine is as insecure as possible by running as Admin all the time. Nice... Which applications do you work on, btw? Just so I know which ones to avoid...
I hate to say it but its programmers like you who are the reason for holding back advances.
You actually set your apps process prioty to realtime? lol
Ive been programing in various langs in multiple OSes including Linux and UNIX since the mid 80's, there is never an excuse to set process prioity that high on a permanant basis.
You remind me of programmers i met when nt 4.0 just came out and they were still trying to program for it as if its 3.51. "This is easier because i dont have to learn anything new"
You could double your efficiency by multi threading the app and not increasing the process priority and thats staying with 32bit not even to mention moving up to 64 bit could do. none of whcih requires admin access for the process.
Also as far as the registry, alot of programmers even for major houses dont follow proper practice, an app should only have to read the registry once copy the data to memory when it starts and only write to it if something has changed that they are storing there. Only a moron would program and app to poll the registry over and over unless the apps purpose is to monitior the registry for changes and thats only special purpose apps as it is often easier and more effecient to monitor process requests to add info to the registry instead.
There is 0 reason to have an app require admin acesss, natively. Thats completely undfefendable and only shows your lack of experience and training.
If for certain functions the app may need admin or higher or differnt user access(and alot of cases it may be needed like accessing a network resource that the current user doesnt normally have access to or for per session resouces and many others), then program the app to interface with the api and with user input to define the username and password required to access that resouce and of course encrypt the user data to prevent security issues or if using the full api is posible let the OS handle the request and the security, whch of course is the preferable way.
As far as the API least for the windows side, vista and 7 the api didnt chaneg at all, the functions have existed in the api since nt 4, just many amatuer programmers never looked at those functions as they didnt have to, it wasnt forced, now it is. it was of course extended to encompass the added capibility the OSes have over XP.
XP was heavily critized as a step backwards in security due to the fact all apps were run with admin, and that descion by MS is why XP is so ridden with spyware, malware virus vulnerablities, as any app can modify system files and directories. it was a throwback and combonation of the highly insecure 9x code base and the more secure nt4/2000 code base.
it also of course allowed the bad programming practices that were prevelant in windows 9x to continue.
Is MS to blame for allowing bad amaturish programming to continue of course they are. They shoudl have put thier foot down on this issue with xp and not waited 6 years to fix it (vista was relased in 2007), and this move with windows 7 is a way to mitigate the results of that failure, of letting programmers like you get away with this bs for all these years.
This remind anyone else of OS/2 and its Windows 3 compatibility? Only this time, Microsoft is doing it to itself.
MS lost the way on Vista, from the get-go, because its primary beneficiaries were not the users, but MS itself, promising itself a full round of upgrade income, and "premium content providers", wasting gobs of resources on Trusted Computing and trying to create uncopyable data streams just to sooth the likes of the MPAA and RIAA. Which of the three pillars of Longhorn actually made it into Vista when the calendar said it was time to ship? Why the one that treats all users like copyright thieves, of course.
What's the big marketing slogan of Windows 7? Now! 40% Less Annoying!