Slashdot Mirror
Latest EMET Bypass Targets WoW64 Windows Subsystem (threatpost.com)
msm1267 writes: Backwards compatibility, a necessary evil for Microsoft and its need to support so many legacy applications on Windows, may be its undoing as researchers have found a way to exploit this layer in the operating system to bypass existing mitigations against memory-based exploits. Specifically in this case, researchers slid past Microsoft's Enhanced Mitigation Experience Toolkit, or EMET, a suite of more than a dozen freely available mitigations against memory attacks. The soft spot, the researchers said, is the Windows on Windows, or WoW64, Windows subsystem that allows 32-bit software to run on 64-bit Windows machines. The researchers said 80 percent of browsers in their sample size were 32-bit processes executing on a 64-bit host running WOW64, meaning they're all vulnerable to this attack.
by constantly breaking the ABI.
...for legacy applications, especially true in the closed source world where simple recompiles are not possible to do lack of source. Still one would think that Microsoft would have provided protection against holes that exist in its legacy systems. Perhaps even a simple walled chroot would suffice? Very few if any honest user applications really need access to system level permissions.
Time is what keeps everything from happening all at once.
The sandboxed web browser will keep this from happening as it will only occur virtually. Close the browser and - poof - its normal again.
I assume that if you run a native 64 bit web browser, it will avoid this vulnerability. For chrome, on https://www.google.com/chrome/... you can select "Download Chrome for another platform" to get the 64 bit version.
As it is, Windows 8 broke a lot of compatibility w/ Windows 7. There really was no reason to have a 32-bit version of either Windows 8 or 10. All win32 applications were XP applications, so all that could have simply been run on XP-Mode or Hyper-V on Windows 10 platforms.
WoW64 should really be deleted, and only 64-bit Windows programs should be developed. VirtualPC should be brought back to Windows 10, and all win32 applications should be run only under that, and not under native win64 systems like Windows 10 or 8.
For firefox you'd either have to choose one of their nightly 64-bit versions or settle with Waterfox which usually lags behind a few versions.
Not so. Pale Moon, my personal choice. They deliberately lag a few versions behind on the user interface rather than accepting the broken shit Firefox foists on everyone.
How is the Riemann zeta function like Trump rallies? Both have an endless number of trivial zeros.
See how simple it can be when you have source? For those who invested in the Microsoft ecosystem, I wish them the best of luck.
To suggest that Firefox for Windows is not open-source is disingenuous. You can compile Firefox yourself on Windows, too. It's not that difficult and can be done using the free version of Visual Studio.
This would kill the usefulness of Windows 10 for existing games, practically all of which are 32-bit. Without remaining a strong platform for gaming, it would be difficult (to say the least) to upsell a large portion of the existing user base. I suppose you can argue that native 32-bit versions should be discontinued, but that's a totally different argument from saying that WoW64 should be discontinued.
How is the Riemann zeta function like Trump rallies? Both have an endless number of trivial zeros.
I noticed Visual Studio is only 32 bit only, and defaults to making 32 bit builds. I don't think Microsoft is big on the whole 64 bit thing.
Fun fact: your 32 bit DLLs are in syswow64 and your 64 bit ones are in system32. Legacy makes such a mess when you don't plan ahead...
I think World of Warcraft has been a 64-bit application for quite some time now.
Fight for your bitcoins!
I just compile Firefox from source since this is a Gentoo system.
The ability to compile Firefox from source isn't exclusive to Gentoo, you can do it on Windows or OSX as well if you want.
For those who invested in the Microsoft ecosystem, I wish them the best of luck.
It's not that hard, just follow the guides here or here.
If you want a platform that breaks older shit, well then go ahead and find one. However many of us would like our software to keep working. WoW64 has been a great success because 32-bit apps run seamlessly and very fast. So you can just use whatever software you want. This has made widespread 64-bit adoption possible. If suddenly 80+% of your programs stop working because there's no compatibility layer, people just won't want to use it. Many, many programs these days are still 32-bit. You may not like that or agree with the choice, but it is what it is. I want to be able to run my software, I don't care about ideological purity.
Also you might want to do your research a bit better, VirtualPC -IS- back. It's called Hyper-V now and it is MS's all encompassing virtualization solution. You can have it on the desktop all the way up to big clusters of servers.
There can't be that many browsers to "sample". Browsers aren't like the population of field mice in the world. You don't use a statistical process to analyze a random sample of them, then declare a ridiculous statistic like "80 percent of them". In the real world there are four or five or eight (some finite quantity). Any declaration should read something like: "five of the seven browsers examined..."
Linux (and I assume *BSD) can run mixed mode with no problems. What's the deal?
Download link, Download link for the EME-free version.
I think that they aren’t offering it yet from the main download page because they want to prevent non-tech savvy people from downloading it and finding out that flash doesn’t work. To me, that’s actually a plus.
"80 percent of browsers in the researchers’ sample size were 32-bit processes executing on a 64-bit host running WOW64, putting them all at risk. ref
What were the names of these browsers with no 64-bit versions?
"Duo Security, a cloud-based access security provider" ref
The fact that distributions no longer ship old libraries, or that the community of developers has a certain tendency to introduce new “frameworks” and deprecate existing ones, shouldn’t be confused with an alleged technical inability of the Linux kernel or its traditional GNU userspace to maintain backwards compatibility.
Main reason not to do this is the fact that you would still need to build and provide 32 bit versions for users on 32 bit only systems (eg windows xp still has about 10% share and its all 32bit). Then you also get bonus support issues when users download the wrong version, it doesnt work for obvious reasons and they explain it in some completely incomprehensible way to your support (or just drop your app altogether).
Would it now? I agree with OP here. Vista should not have had 32-bit support. 32-bit should be the XP support. And as we see now, the decision to not do this is still haunting them, when there is legacy for 4 different 32-bit supported OS.
Windows did something far weirder than focus on the ABI.
The WoW64 folder holds the 32 bit DLLs while the System32 folder holds the 64bit DLLs. There is then black magic that usually redirects 32 bit applications to the different Wow64 folder.
The idea was not binary compatibility but source compatibility. Someone in the hierarchy must have dictated that C programs must be able to be recompiled in 64bit with zero code changes. Only an MBA with zero programming background could think that this largely impossible mandate justifies permanently twisting the system with weird rules.
Don't get me started on Program Files (X64) ...
Not as long as people insist on using archaic programming languages such as C.
Programs are distributed 32 bit, and often rely on 3rd party add ons that are 32 bit. And never the two shall be combined into a single process, even if the actual memory requirements are small. That is why Office is normally run in 32 bit mode -- the add ins.
A better idea would have been to allow 32 bit windows to run with more than 4 gig of ram, and 4 gig per process rather than 2. That would have pushed off the 64bit day quite a bit.
This is not a problem with .Net (or Java) of course. They Jit compile, optimized to the specific machine. No 64bit issues, no opaque type issues. And Java can even reference 32 gig of memory with 32bit pointers (by enforcing alignment) which almost halves the amount of memory a 64bit application needs.
The problem is not Microsoft. The problem is C. But given C, to kill 32bit would have been to kill Windows. (And even Linux allows 32 bit programs on 64bit O/S.)
As to WoW64, that was entirely gratuatous, as per my other post above. And given COM it should also have been possible to run 64bit programs in 32bit processors, albeit restricted to 4 gig. (There had to be something potentially good about COM.) But that is not how it is.
Then what happens to people with perfectly functional machines lacking x64 support -- run an unsupported and vulnerable XP forever? I'm personally quite glad there's a 32-bit Windows 7, or my mother's laptop would be scrap.
How is the Riemann zeta function like Trump rallies? Both have an endless number of trivial zeros.
Oh, please... The reason I stopped using Linux was because I got fed up with trying to get my development enviroment up and running after every new update/upgrade of the OS.. And maybe Firefox has it's stuff in order for recompiling on linux, but a lot of applications don't, they break because they can't find the specific stuff in the repositories you have set on your machine..
I've tried many times, but everytime I stumbled upon another crap thing with Linux which prevented me from doing stuff, you need a very thourough understanding of Linux to do anything, and even most of the times it's just illogical (but that's due to the nature of the actual developers who don't seem to understand userfriendliness)..
uhh, please get a reality check..... For windows 10 to succeed it needs 'native' support of legacy applications, otherwise there would be no business that would adopt Windows 10..
A LOT of business applications being used are still 32-bit (because they were developed in older languages), and porting a lot of those applications doesn't make real sense if the actual port isn't performing as good, or doesn't do anything different.. If it ain't broke, don't fix it..
It's all to easy to just say, 'oh they should just develop 64bit application', but you are really naieve if you think like that..
The problem isn't the 32bit applications themselves, even 64bit layers can have it's security problems.. So fixing this security problem is what needs to be done, nothing else..
You are really a moron if you think 64bit applications are more secure than a 32bit application... and any layer in any OS can be a potential security risk..
In the end the legacy applications will be replaced with newer (multiplatform/cloud) applications, but that will take a long time..
As I said, there is no reason to spend a few millions dollars on redeveloping an application just for the sake of it being 64bit.. Let's not forget, 'older' languages doesn't mean it's crap, and newer languages doesn't mean it's better..
The fun with the System and System32 folders was not done for source compatibility. It was done for programs that hardcoded the path/folder name instead of querying the system for it.
Well, there was a 64 bit Windows XP but I don't imagine that many of those are running today.
"So long and thanks for all the fish."
I get email every day, pretty much, telling me about the new vulnerabilities in my operating system of choice. It's Linux. There are all sorts of serious security holes, popping up all the time. Hell, I get updates a couple of times a day, some days.
"So long and thanks for all the fish."
Um, yes, that is what source compatibility is all about. Some source would have needed to be change for programs that hard coded the System32 folder name, among other things. I have never seen a non-trivial 32 bit program that could be run 64 bit without changes.
OTOH, what about a 32 bit program that is expected to remain 32 bit. It might also have hard coded System32. And that is where weird and dangerous hacks refer some, but not other, file references to WoW64!!! One thing that is for sure is that 32 bit programs should have remained compatible with running in 32 bit mode.
It was a surreal design decision that says a lot about the company that made it. I don't think that Gates ever made a dumb decision like that, but then he started as an engineer so knew what code actually was.
It would be a stupid move. The greatest advantage of Windows over other OS is exactly the ability to continue supporting legacy applications that are fundamental to a lot of people. Virtualization is an option, but it is important to note that not everyone have the computational resources required to use a VM and rarely these VMs have all the features that baremetal offers (as example, running a DirectX 9 game in a VM is currently impossible or very, very slow).
Religion: The greatest weapon of mass destruction of all time
Well... Sorry but you just proved his point that Linux depends on a lot of work to keep running while Windows usually just works. I also used Linux to work until I have become tired of fixing things that break at each update.
Religion: The greatest weapon of mass destruction of all time
You were wrong before, and you're wrong here too. WoW64 serves a purpose, and most Windows Apps are not COM servers. I have no idea what warped fantasy you have regarding COM, but it's just that -- a fantasy.
> Not as long as people insist on using archaic programming languages such as C.
The "archaic" programming language C is not the problem. The problem is the fact that there are way too many 3rd-party libraries that are only available as 32-bit binaries. For simplicity often the developers of the application then also compile for 32-bits.
> A better idea would have been to allow 32 bit windows to run with more than 4 gig of ram, and 4 gig per process rather than 2. That would have pushed off the 64bit day quite a bit.
Running 32-bit applications on more that 4GB of ram is impractical at best due to address space limitations. The 2-2GB split itself is imposed by the operating system and has little to do with the final application.
> This is not a problem with .Net (or Java) of course. They Jit compile, optimized to the specific machine. No 64bit issues, no opaque type issues. And Java can even reference 32 gig of memory with 32bit pointers (by enforcing alignment) which almost halves the amount of memory a 64bit application needs.
Bytecode languages like C# and Java are no holy grail, there are plenty of brand new releases made in these languages that come with a 32-bit interpreter because again of some 3rd-party binary library. These interpreters in fact, cannot access more than what the operating system allows. A 32-bit interpreter just like any other application cannot access anything beyond the 32-bit address space (4GB).
You might wonder about PAE but that was in fact a hack supported by 36-bit addressing mode and paging done by the operating system.
> The problem is not Microsoft. The problem is C. But given C, to kill 32bit would have been to kill Windows. (And even Linux allows 32 bit programs on 64bit O/S.)
Running 32-bit applications on a 64-bit processor has never been a problem. The problem lies in the libraries that are used by the program, for 32-bit applications there must be 32-bit libraries available in order for it to run.
> And given COM it should also have been possible to run 64bit programs in 32bit processors, albeit restricted to 4 gig. (There had to be something potentially good about COM.) But that is not how it is.
You cannot run 64-bit applications on 32-bit processors. I enjoy the praise you give to COM but even COM will not allow you to do what you suggest. COM is nothing more than a non-standard approach to what in many languages are called "interfaces" or "inheritance". COM objects are pointers to vtables that contain pointers to function calls.
I'm not sure how your post got modded up being factually incorrect.
Linux has very good backwards compatibility as peppepz pointed out... The fact that most distros don't include the necessary ancient libraries is because this backwards compatibility is very rarely needed, so those using it are a very small niche who still have the option to install the libs.
The vast majority of linux software comes with sourcecode, and almost all of it has already been compiled for 64bit systems as well as other architectures like arm or mips. It's extremely rare that you would need to be using an old linux binary, and even if you are running old software there is usually nothing stopping you from recompiling it assuming someone else hasn't already done so. I regularly run several applications which date from as early as 1994, recompiled for a 64bit host. They compile and run fine on 64bit, as 64bit hardware (alpha/mips) was available in 1994 anyway.
Any software that doesn't compile and run cleanly on 64bit hosts is usually fairly easily fixed and is very rare as the unix world has had access to 64bit cpus for a long time now.
I run several 64bit linux servers with custom kernels, they have support for 32bit (and a.out) binaries turned off because i have absolutely no use for this feature.
By contrast, most windows software comes only as 32bit (or 16) binaries and cannot be recompiled or easily modified. To get a 64bit binary you are relying on the goodwill (and continued existence) of the original vendor, and quite often even if a 64bit version is available it will only be the more recent versions which is no good if you're stuck with an old version for whatever reason.
Backwards compatibility is essential for windows, if you're going to ditch compatibility you might as well just switch to linux anyway.
Backwards compatibility is a tiny niche for linux, hardly anyone ever uses it.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
I see these advisories too, but it's very hard to compare windows to linux by number of vulnerabilities reported...
Linux (and most application software for it) is developed in the open, so issues discovered during development are publicised, microsoft dont publish any vulnerabilities discovered during internal development.
A typical linux distribution supplies far more software than microsoft do, there are hundreds of applications any of which could have vulnerabilities discovered. The linux package managers typically cover a huge range of software like this, and can update it centrally.
Linux is more modular so although all this software is available, almost all of it can be removed if you dont want it.
There are multiple linux distros, so a single vulnerability is often covered by multiple distro announcements.
Most software is cross platform, but vulnerabilities in something like apache will only be announced by linux distros, microsoft wont announce it even if the same issue is exploitable when running apache on windows.
The linux kernel includes drivers, whereas windows generally does not - vulnerabilities in drivers will usually be counted against linux but not windows.
Based on my own experiences, my linux servers which have had unnecessary software removed very rarely require updates, in most cases i dont need to update all of them at once and usually dont need to reboot (i dont use ksplice or similar). windows on the other hand almost always requires updating and rebooting at least once a month, even a core install.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
You mean like Microsoft releasing a 64-bit DRIVER FOR ITS OWN 32-BIT ACCESS DATABASES? You can praise MS for their maintaining the ability to run legacy apps, but in some very meaningful instances, they're no different than phone companies refusing to patch Android phones just to cynically move more merch.
"Linux has very good backwards compatibility as peppepz pointed out"
You're making fun of me? Look, you are assuming several terribly wrong things:
The vast majority of linux software comes with sourcecode
Correct, but good luck trying to make it work. Things like Freetype2 are easy, now try to compile Firefox or LibreOffice (is a nightmare). And a tip: You are NOT the original developer of the thing (so if you do not have a really good documentation you will spend days trying to understand what's going wrong).
It's extremely rare that you would need to be using an old linux binary
Yeah, rigth. I have to develop and maintain a lot of things that do not have the privilege to keep changing libraries, especially libraries fucking unable to maintain compatibility between a smaller version and another.
You linux types keep forgetting the crucial detail that most of your users are NOT Linux developers or are not even developers, most of them DO NOT know how to build an application or can not waste time doing it, and those who try (like me) invariably run into some absurd compilation problem or dependency needs of those who can not understand the computer is not exclusive to his application.
And now you will suggest me to use a friendly distro for users, right? The problem is that this only works if the user limits itself to use only what exists in the repository, and only as long as the developer of the application that the user need maintains a professional attitude about compatibility. The moment you try to install something out of the repository like I did, and this thing is slightly more complex, you're screwed.
Backwards compatibility is a tiny niche for linux, hardly anyone ever uses it.
It is because of this that Linux is a niche system.
Religion: The greatest weapon of mass destruction of all time
Back in the day, each operating system had to be "different". If they weren't, AT&T and IBM would sue your ass for stealing from Unix or System/360. In case you didn't know, MacOS (classic, not X) used colons as directory separators. At least backslash looked somewhat familiar and didn't require holding Shift as part of the keystroke.
Even Microsoft employees joked about WinME at launch, saying that the line for MS employees to receive their copy would be the longest anywhere. They were probably right, too.
What was wrong with Win2k? It was the best version of Windows available until XP SP3 came out.
Exchange is a good piece of software. It has its issues, but everything that large does. And there still isn't a suitable FOSS replacement for it.
Vista got a bad rap because of vendors' shitty drivers. It actually improved things drastically in Windows-land.
This is just Windows-for-ARM. Every ARM port of Windows has WinCE to thank. And WinCE is still around. It's known as Windows Embedded Handheld now.
There's no reason to limp along with 32-bit hardware in late 2015. Core 2 came out in 2006 and signalled the "fast enough" era we still live in today... anything older is just wasting electricity and time.
Schools and businesses sell off Core 2 hardware for next to nothing. Craigslist will also yield good deals.
Your mother deserves better.
Do what thou wilt shall be the whole of the Law
The idea was not binary compatibility but source compatibility. Someone in the hierarchy must have dictated that C programs must be able to be recompiled in 64bit with zero code changes. Only an MBA with zero programming background could think that this largely impossible mandate justifies permanently twisting the system with weird rules.
Remember Windows95? The OS that took MS from a bit player to world domination? Yeah, the entire focus of Win95, including the reason it was so unreliable, was this exact sort of compatibility between the 16-bit and 32-bit worlds. Win95 could run 16-bit shared-memory drivers in a 32-bit, protected-memory OS (not safely, but they would work).
Backwards compatibility with 0 code changes is the entire reason anyone today has even heard of MS. Their decline started about the time they abandoned backwards compatibly as a priority.
Socialism: a lie told by totalitarians and believed by fools.
Oh boy... Your comment is so, so stupid it's no surprise that you've made it as AC. Learn to to understand what you are reading before you try to answer anything, as it is obvious to me that you did not understand nothing from what I wrote (or you did not want to understand, what is worse). Otherwise you would have realized that I not only know very well how to compile (and write code, by the way) as I was also talking about something completely different that it is the problems that you encounter when trying to solve obscure compilation problems in third-party code or code dependent from obscure/unstable libs. Now, take advantage of the momentum to make a reality check too, you are really needing one.
Oh, another thing. I work for the goverment/military, so i cannot be as unprofessional as you looks...
Religion: The greatest weapon of mass destruction of all time
Microsoft has always been big on backward compatibility. When Windows 95 was being programmed, Raymond Chen made it a personal quest to make sure every program that ran on 3.1 would run on 95.
Had Vista been 64-bit only, with no 32-bit support, a very large amount of software would have ceased to work. As Chen put it, if you get a new OS and your old stuff fails to run, you blame the OS. If the 32-bit support was limited to running XP, the computer would need to have two full OSes loaded, and XP would have been talking to the Internet and all the things you don't want XP doing.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Bah, we'll lump an exploit in IE, Outlook, Office, even Adobe products all in with Windows vulnerabilities. It's not like we're unbiased! *chortles*
I don't know how they compiled the stats but, suffice to say, Windows has come a long ways. I'm truly impressed. I'm not going to switch back to Windows but I'm impressed with their progress. Security was not the reason I left Windows. Collecting telemetry data was not the reason that I left Windows. I left mostly because I prefer Linux. I started in the Unix realm. I poked at Linux when it came out. I poked again in the late 1990s. I kept a partition with Linux installed, pretty much all the time. I moved to Windows in 1999 or so. I stayed there but kept my partition. I went back to Linux in the mid 2000s. I then got back on the Windows bus and stayed there for a while. Over the past few years, I'd been finding myself using it less and less. Finally, I just said to hell with it and got rid of all my installs, deleted TERABYTES of Windows software, and just stopped using it. I may do the same thing shortly only this time moving to BSD land - that will probably wait until I get home.
So, I'm kind of agnostic? It's not like I hate Microsoft. I did let my MSDN subscription lapse. However, there are scads of exploits for Linux - daily. I update daily - sometimes multiple times in a day, and there's almost always something new when I 'sudo apt-get upgrade' or whatnot. (I'm in the Debian camp, for the most part. Specifically, in the Ubuntu family.) I guess, I agree that it is not a very easy comparison.
I remembered what the image looked like (I think someone had linked the image) and I've since (just now) read the article. It's actually pretty good and I'm not going to say that I'm sure that I'm qualified to give an opinion. This looks like a fairly unbiased set of research combined with a fairly decent article - I was able to recognize the image of the graph! >:-)
http://www.gfi.com/blog/most-v...
That's for last year. Grouping all of Windows together seems a bit unfair so they've separated them. They only include the Linux Kernel in one section - they do delve into distro specific vulnerabilities.
It's well worth a read if you get a minute. It's not bad, not bad at all. It almost looks objective.
"So long and thanks for all the fish."
Dude, you are the only clueless moron here... :-) In the company where I work my colleagues laughed a lot when they saw your comment, you know? I will said again: Learn how to understand what others wrote, THEN try to comment my clueless friend ;-)
Oh, P.S: I comment Using my ID because unlike you I have confidence in what I write. Grow up.
Religion: The greatest weapon of mass destruction of all time
Thing is, she likes it. It's a ThinkPad, so I can't say I blame her for that. If there had been no replacement for 32-bit XP at the EOL for XP, she would have just gone on using it anyhow, in a defiant "why should I replace a working computer" stance. For the netbook I bought in 2009, I could deal with a switch to some flavor of Linux, but she would not.
How is the Riemann zeta function like Trump rallies? Both have an endless number of trivial zeros.
Somewhat apples & oranges. When Microsoft introduced Windows 95, it was an immediate migration from Windows 3.1, and there were no existing 32-bit applications (other than win32s apps like Freecell). Also, at the time, hardware was more expensive, and virtual machines hadn't caught on as a major concept: VMware was still new, and working to establish the proof of concept.
It's very different now. I don't recall whether Vista had VirtualPC or not, but in Windows 7, the way to run native XP apps that hadn't been ported to Windows 7 was to run XP Mode/VirtualPC. So there really wasn't a good reason to make Windows 8 or 10 themselves 32-bit, since they were starting fresh w/ those Metro apps, and just supporting Vista/7 apps. So here is what they could have done: support 64-bit apps of Windows 7 or Vista, but require VirtualPC for 32-bit apps - be it XP, Vista or 7. Don't have WoW64, but just run things in separate sandboxes altogether.
Windows is the only platform where an application from 10 years ago is highly likely to run and likely to do it without any efforts.
Meanwhile, OS X breaks something with every incremental release.
And then you have Linux where constant maintenance of all applications are constantly required and nothing is ever done.
Linux = write once, perpetually maintain it or in 6 months it won't work. Windows = write once, it will likely work in 25 years. This is a major advantage and why the appeal of the stability of Windows isn't just only an enterprise thing.
As far as web browsers go, I am uncertain of what remaining web browsers are 32-bit. But no doubt it is a rapidly declining number.
First point is false. Years ago, I had an Adobe Acrobat 6 CD, which I ran on my computer w/ XP. Later, when I upgraded it to 7, it couldn't run on that: I had to run it under XP Mode (No, I wasn't gonna buy another more recent Acrobat version). Which was my point above: just have VirtualPC, w/ the ability to have any historical Windows VM - from Windows 95 to 32-bit Windows 7, and make that the default way for Windows to run win32 programs.
Discussions about OS-X or Linux is a non-sequitur to this discussion
That's why I suggested bringing back VirtualPC, not Hyper-V
And the support would remain w/ sandboxes under VirtualPC, based on what I suggested
Such systems cannot be upgraded in the first place, and would probably remain w/ XP. What if you have an old computer w/ 256MB of RAM? There is no way Windows 10 will run on it - be it 32-bit or 64-bit. Also, the claim of legacy support the way you describe it is false: I was forced to use XP-Mode to run Acrobat 6.0 under Windows 7. Anything that can run Windows 10 can also run VirtualPC, and support 32-bit w/ that.
sandboxes isn't like native, it has it's limitations and especially it's another performance hit.. I buy a new computer to have the current software run faster, not to have it run slower due to sandboxing and emulation/virtualisation..
There is nothing wrong with most 32bit applications as most applications won't need to address 64bit memoryspace anyway..
Which doesn't mean a new application should be developed for 32bit when all your customers are running 64bit, but that's not the case, a lot of customers still have 32bit OSses and older hardware (as they don't have the money to upgrade or it's running perfectly for what they need it for)..
Well, why the user would migrate to Windows 7/8.1/10 in this situation? If he have only 256MB of RAM he could just continue with XP if it keeps working. And the simple fact that you can ask the system to use compatibility mode for a particular application is a valid form of support for legacy, as far as I know this way works and does not need to use a VM. And perhaps I was not clear enough, at any moment I'm saying that everybody has to migrate to Windows 10 (which is a disturbing deviation pattern of ways used so far successfully on Windows, I do not recommend to anyone that migration), I'm just saying that the one reason for the windows success is the ability to run legacy applications, I am not citing any particular version.
Religion: The greatest weapon of mass destruction of all time
Dammit. Fucking google translator, I meant that I would not recommend to anyone migrating to Windows 10
Religion: The greatest weapon of mass destruction of all time
That's the point. People who have limited computing resources should not migrate. Only people who should migrate are those who have multi-core x64 CPUs w/ at least 4GB of RAM as far as 64-bit goes. For 32-bit, the most your computer can have is 2GB of RAM, and that's fine uptil Windows 7. Also, the compatibility mode you suggested did not work for me in my above example: I was forced to run a VM. Why burden an OS w/ multiple ways of running legacy stuff? Recognize that there is a cutoff point, and support older stuff only to run as fast as, but not faster than, newer stuff on the newer 64-bit platforms
Also, the compatibility mode you suggested did not work for me in my above example:
Well, is well known that not all applications can run in a compatibility mode, especially applications where the really sloppy developer did stupid things like put the path to a system folder in a hardcoded way or worse. Compatibility mode it's also a more efficient way to do the job and works in almost all cases, then why create a entire emulation (the VM) with the costs that this entails?
The point is that using a VM for this is a really expensive activity in terms of hardware resources and has only recently become feasible, remember that this compatibility mode was created when VMs were still just a really expensive idea and without no hardware assistance.
Religion: The greatest weapon of mass destruction of all time
My point about source compatibility was to emphasize why binary backwards compatibility is a rarely used feature.
Binary compatibility on linux is actually much better than windows too, it's just required far less often and thus not enabled by default in most distros. Providing you have the appropriate libs (and these libs often wont be installed by default because they waste space if not required), even very early linux binaries will still run on the latest kernels.
Windows does include backwards compatibility libs, and its more common for applications to come bundled with third party libs rather than using the system provided ones, which is horribly inefficient.
The default linux approach of system wide libraries with only the current versions installed is far more efficient, but this approach only works if all of your applications are compiled and linked against current library versions.
This approach is practical with linux because virtually all software comes with sourcecode, it is not practical if you are going to be running old precompiled software.
As always, linux gives you the choice, and the default option is superior. Very few linux users ever have the need to run old precompiled software.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!