If you were Acer and you had a prototype Windows on ARM device and you knew the performance was going to suck would you risk being party to a lawsuit where Intel sued Qualcomm and Microsoft for violating one of their 400 patents that was analogous to the one MIPS sued Lexra over?
Or would you think "Yeah, I think we'll pass on Windows on ARM".
I think that's what Intel is going for.
Or maybe they want to make sure that Microsoft agree not to emulate any instructions recent enough to be patented. I.e. the 486 instruction set and probably MMX is OK, x64 and SSE or later is not. That would mean you could only run x86 binaries and not x64 ones. And things like Photoshop are going to really suck.
Intel don't need to win a lawsuit for it to have an effect. All they need is to hint a blog that one might be coming and they can scare off hardware vendors from launching devices and Microsoft from adding SSE support to their emulator.
Amusingly the MIPS vs Lexra lawsuit means that even if you don't implement instructions that would violate a patent and do an illegal instruction trap, you can still be sued because hypothetically someone could write a trap handler which emulated them. That's some real 'through the looking glass' lawyering right there.
Though you can not patent an instruction set, you can patent machines and methods that are necessary to implement a particular unusual instruction that is part of the instruction set. That legally blocks competitors from creating a fully compatible clone of your processor. There are four instructions in the MIPS-I instruction set that were protected by one US patent, 4,814,976. These instructions, lwl, lwr, swl, and swr are known as the unaligned load and store instructions. These instructions are useful in systems in which memory is scarce. In such systems, it is often useful to pack 16-bit or 32-bit data values in to memory in such a way that they are aligned to arbitrary byte boundaries, and not necessarily to natural 16-bit half-word or 32-bit word boundaries. Accessing such unaligned variables requires at least two bus clock cycles, whereas accesses to aligned data can be performed in a single cycle. Most assembly programmers and compilers for modern systems align data to their natural address boundaries in order to gain the system bus performance benefit of aligned loads and stores, and so they never use the lwl, lwr, swl, and swr instructions.
Prudent high tech companies study their competitors' patent portfolios, and Lexra was no exception. Lexra was well aware of the patent on unaligned loads and stores that was owned by MIPS Computers Systems, then by Silicon Graphics, and later by MIPS Technologies. To avoid infringing, Lexra chose not to implement unaligned loads and stores in its processor design.
When MIPS filed its S-1 IPO prospectus form in 1998 it sued Lexra for copyright infringement. The suit was settled after a few months with Lexra agreeing not to use MIPS trademarks without attribution and to state in its documentation and in its public statements that it implemented "the MIPS-I instruction set except for unaligned loads and stores". MIPS Technologies agreed to the settlement, apparently acknowledging that Lexra did not execute unaligned loads and stores.
If a Lexra processor encountered an unaligned load or store instruction in a program then it did the same thing that it would do for any other invalid opcode, it took a reserved instruction exception. In the second lawsuit between MIPS Technologies and Lexra, filed November 1999, MIPS Technologies claimed that because exception handler software could be written to emulate the function of unaligned load and store hardware, using many other instructions, Lexra's processors infringed the patent. Upon learning of this broad interpretation of the patent, Lexra requested that the US Patent and Trademark office (USPTO) reexamine whether the patent was novel when granted. Almost every microprocessor ever designed can emulate the functionality of unaligned loads and stores in software. MIPS Technologies did not invent that. By any reasonable interpretation of the MIPS Technologies' patent, Lexra did not infringe. In mid-2001 Lexra received a preliminary ruling from the USPTO that key claims in the unaligned load and store patent were invalid because of prior art in an IBM CISC patent. However, MIPS Technologies appealed the USPTO ruling and, in the mean time, won a favorably broad interpretation of the language of the patent from a judge. That forced Lexra into a settlement that included dropping the reexamination request before MIPS Technologies might have lost its appeal.
It was never determined that processors that execute the MIPS-I instruction set, but treat unaligned loads and stores as reserved instructions, infringed the '976 patent. The patent expired on December 23, 2006 at which point it became legal for anybody to implement the complete MIPS-I instruction set, including unaligned loads and stores.
Extremetech mused on the case and came up with the tech industry analyst equivalent of 'it's a game of two halves mate. It could go either way'.
Frankly if I were Microsoft and someone suggested adding support for non native kernel mode code I'd say "What an excellent idea. Why not suggest it to Dave Cutler, right now!". And then that would be last you'd see of them.
It's not 'a patent'. The Intel graph shows loads of patents on each instruction set - 1600 over 13 instruction set extensions or about 123 average for each one.
They claim around 400 patents for MMX, SSE and SSE2, though most of these are for SSE and SSE2.
And Intel's claim is that if executing an instruction uses a patented process it doesn't matter if you execute it in hardware or translate the instruction and execute that - you still need a patent license or you will be sued.
A colleague of mine rescued an Alpha AXP machine from a dusty closet. Upon booting up the system, he discovered that it was running a 64-bit version of Windows from early 2000. How is that possible?"
I happened to have one of these machines in my office then. In its prime, this machine was a force to be reckoned with. It was about the size of a small refrigerator and generated about as much noise as a vacuum cleaner. It contained four-count 'em, four!-Alpha AXP processors, each running at a mind-boggling 400 MHz. It had one gigabyte of RAM and thirteen gigabytes of hard drive space, striped over a dozen fast SCSI drives. This may sound puny today, but back in the 1990s, these Alpha AXP machines were the envy of the block and made you the popular kid at the lunch table.
In 1999, when Compaq announced it would no longer support Windows on the Alpha AXP, a lot of Alpha AXP systems were suddenly left sitting around Microsoft with no official duties. Some of these machines, however, were pressed into a variety of unofficial duties. I used my Alpha AXP system to index the entire Windows source code. You can imagine how convenient it can be for a programmer to be able to identify all callers of a function in just a few seconds or to locate the source code for a function or dialog box that shows up in a debug trace.
But even for the simple task of indexing the Windows source code, the Alpha AXP was soon overshadowed by x86-class machines. These were cheaper and faster, they offered more hard disk space, and they had more memory. So for this reason, my machine soon joined its forgotten brethren. It was assumed that the end of support for the Alpha AXP was the end of these machines, but then they were given an opportunity to go out in a blaze of glory, breathing their last breaths in service of the next generation.
The 64-bit Windows project was already well under way, and of the 64-bit processors under consideration, only the Alpha AXP was actually available in physical form. The Intel Itanium was still under development and ran only in a simulator, and the AMD64 architecture hadn't even been invented yet. As a result, 64-bit Windows was initially developed on the Alpha AXP.
When Compaq announced that they would no longer support Windows on the Alpha AXP, all these Alpha AXP machines that previously had been used for 32-bit Windows 2000 development and testing got repurposed and began serving a secret life as test machines for a 64-bit operating system that will never ship in that form. The Alpha AXP was merely a proof-of-concept platform.
The Alpha AXP machines served that role well, giving the 64-bit Windows team real hardware to work with instead of having to run the operating system on an Itanium simulator. (You can imagine how slow that was.) Sure, the Alpha AXP wasn't the final target hardware, but it was a big help. And when physical Itanium CPUs began showing up, the niche filled by the Alpha AXPs vanished, and they were once again retired into dusty closets.
The original x64 specification made support for SSE and SSE2 mandatory, but of course some applications might require later versions.
It's pretty clear that Intel are saying that if you write an emulator to run patented SIMD instructions on non Intel hardware and don't have a patent license, they may sue.
x64 is a nice pragmatically designed extension to x86 but it is almost covered by patents from both Intel and AMD.
You can't patent or copyright an ISA. Most of their patents would cover hardware implementations of various features.
Intel claim patents on SIMD instruction sets and say that those preclude anyone who doesn't have a license executing those instructions even in emulator
Intel carefully protects its x86 innovations, and we do not widely license others to use them. Over the past 30 years, Intel has vigilantly enforced its intellectual property rights against infringement by third-party microprocessors. One of the earliest examples, was Intel's enforcement of its seminal "Crawford '338 Patent." In the early days of our microprocessor business, Intel needed to enforce its patent rights against various companies including United Microelectronics Corporation, Advanced Micro Devices, Cyrix Corporation, Chips and Technologies, Via Technologies, and, most recently, Transmeta Corporation. Enforcement actions have been unnecessary in recent years because other companies have respected Intel's intellectual property rights.
However, there have been reports that some companies may try to emulate Intel's proprietary x86 ISA without Intel's authorization. Emulation is not a new technology, and Transmeta was notably the last company to claim to have produced a compatible x86 processor using emulation ("code morphing") techniques. Intel enforced patents relating to SIMD instruction set enhancements against Transmeta's x86 implementation even though it used emulation. In any event, Transmeta was not commercially successful, and it exited the microprocessor business 10 years ago.
Only time will tell if new attempts to emulate Intel's x86 ISA will meet a different fate. Intel welcomes lawful competition, and we are confident that Intel's microprocessors, which have been specifically optimized to implement Intel's x86 ISA for almost four decades, will deliver amazing experiences, consistency across applications, and a full breadth of consumer offerings, full manageability and IT integration for the enterprise. However, we do not welcome unlawful infringement of our patents, and we fully expect other companies to continue to respect Intel's intellectual property rights. Strong intellectual property protections make it possible for Intel to continue to invest the enormous resources required to advance Intel's dynamic x86 ISA, and Intel will maintain its vigilance to protect its innovations and investments.
The graph above shows that SSE and later is still covered by extant patents. SSE is actually part of the x64 architecture - you need to execute SSE instructions to have floating point, and floating point is not optional. The x64 ABI actually requires SSE. I.e. to emulate x64 instructions you need a licence for the SSE patents.
This probably also means that if an emulator supports SSE instructions in x86 mode Intel will sue too.
Of course they might be bluffing about suing and will come to an arrangement with Microsoft and Qualcomm or the hardware vendors of Windows on ARM devices to license the patents. Or maybe they're not but they'd lose in court.
Their blog post is clearly designed to make Microsoft, Qualcomm and the vendors think that a lawsuit is possible though.
There is no technical reason, why thou could not just emulate the drivers too.
Suppose you've got some x86 code in running on an ARM in kernel mode. It will expect everything it sees to have the x86 structure alignment. E.g. if it does an mov eax, [ebx+n] and that is translated into LD R0, [R1,#n] then you'd best hope that the structure R1 points to has the exact same thing at offset n in ARM windows that it does on x86 windows.
There are going to be some weird corner cases where that won't be the case, and then you've got kernel mode corruption. Actually if the ARM is running a 64 bit kernel and the driver is x86, that's guaranteed to be the case and you need to thunk all the structures. However I think even if you have x64 code being emulated on ARM64 there are going to weird corner cases where the layout of a kernel mode structure is going to be different.
Another issue is alignment. x86 and x64 code handles misaligned pointers transparently, though occasionally at a enormous performance hit if they span a page boundary. ARM code does not. In user mode that's no problem - you get an alignment fault, the kernel fixes it up and you go on you way, with a performance hit.
However NT kernels are architected so that you can't have page faults when you're running a raised IRQL, because if you're doing that you hold a spinlock. The page fault handler needs to acquire a whole bunch of spinlocks when it fetches a page and allowing to run at a raised IRQL risks a deadlock and a frozen system. So an NT based OS will BSOD with IRQL_NOT_THAN_LESS_OR_EQUAL in this case - what that means is that IRQL is not <= PASSIVE_MODE.
But suppose you have some x86 kernel mode code at a raised IRQL doing an unaligned pointer access. The emulator runs it and it faults. And in NT that fault is instant death. Sure you could hack the kernel so that it first tries to do an alignment fixup. However you've introduced a load of complexity to a design that was pitiless and pure initially - if kernel mode code causes a page fault at raised IRQL then it dies instantly and the solution is for users to track down the company, for the company to track down the developer and for the developer to fix his shitty code.
Actually another option would be for the emulator to check for misalignment and handle it in by avoiding the fault. This would probably work, but there's an overhead you'd need to pay on every pointer access, even the aligned ones, where you'd need to check the low order bits to make sure enough of them were zero to make it aligned before you dereferenced it.
In practice this limitation prevents one from running any game with copy protection.
Copy protection drivers are a bit like anti virus software anyway. What they're doing is grovelling around in undocumented structures and doing rootkit type shenanigans. And the idea that you're going to try to run a copy protection meant for x86 or x64 on a completely different processor architecture is a fool's errand first place. The whole point of them is to try to work out if there's something a bit hinky going on. Nothing is more hinky than running kernel mode code on the wrong CPU architecture with a bunch of hacks that tries to hide the differences and doesn't completely manage it.
Who is Reverend Green? He's a character I created to explore some experimental political viewpoints. He's religious, unambiguously communist, socially conservative, and perhaps outspoken. Yet I hope his words are sometimes not far from the truth. Brothers and sisters - look around you, open your eyes, write your own narrative. || FWIW, I have a low-UID/. account in my real name. I used to post regularly. Yet the chilling effect of the current social climate in America is such that I am no longer feel comfortable posting political thoughts under my own name.
I'm not sure why you're criticising me for going off on a tangent from the Vietnamese Communist Party to their enablers in the West given that Hal_Porter is also a character I created to explore 'experimental political views' without getting the real me blacklisted for criticising the left and explaining their opponents when I feel they're being unfairly criticised.
And Trump. Trump is basically Batman - a billionaire who works a bit outside the rules to take down psychopaths who threaten the livelihood of the regular folks.
NT on Alpha could run 32 bit x86 code because Dec wrote a very clever emulator called FX!32.
That hooked into NT's process spawning when you tried to run a non native binary and run the code via Dec's FX!32. However it also did profiling. Once it knew which parts of the x86 binary were executed most frequently it would JIT them to native Alpha code.
At one point the platform which could execute x86 code was an Alpha running it via FX!32's JIT.
Back in the days NT run on Risc it was able to run x86 code, but only 16 bit x86 code. That's because the emulator was in the Windows On Windows (WOW) layer. Back then WOW was a way to run 16 bit code on a 32 bit OS. On an x86 chip it run the node natively. On Risc it used an emulator, which Microsoft had licensed from Insignia Solutions.
So on a MIPS R4000 machine you ended up with this
1) You could run Win16 and Dos x86 applications because those run in the WOW layer or in NTVDM, the NT virtual Dos machine 2) You couldn't run Win32 x86 binaries, you needed native MIPS ones 3) You couldn't run x86 drivers, you needed native MIPS ones
The R4000 was 64 bit capable but NT never run in 64 bit mode on it. Though it did on Alpha for while until that was discontinued. 64 bit mode lives on now for x64, ARM64 and maybe Itanium if you ask MS very nicely.
Now move forward to 64 bit Windows 10. The kernel is 64 bit code. WOW is used to run 32 bit binaries. On x64 it runs 32 bit code x86 code natively. On ARM it uses an emulator. So an ARM64 machine you end up with this
1) You can run Win32 applications because those run in the WOW layer. There's no NTVDM or support for 16 bit code in 64 bit Windows because that would need WOWOW - Windows on Windows on Windows. 2) You can't run Win64 x64 binaries, you need native ARM64 ones 3) You can't run 32 bit drivers, you need native ARM64 ones
Ironically given how wonderfully quirky ARM32's instruction set was and how Steve Furber reckoned that 'MIPS was clean but the cleanness lead to poor code density which hurt them they competed with us in the embedded world', (I'm paraphrasing a bit, the interview is here).ARM64 is much more similar to MIPS than it is to ARM32. I.e. no conditional execution, load/store multiple, no free shift with every instruction and no Thumb mode with two byte instructions. RIP Sophie Wilson's wonderfully devious instruction set. Still I can see why they did it - something stripped down like MIPS or ARM64 must be a lot easier to implement as out of order superscalar design than ARM32.
So the situation with WIndows on ARM is better than Windows RT on 32 bit ARM of course - that had no x86 emulator and actually blocked Win32 ARM binaries from running unless they were signed by Microsoft. This was part of Microsoft's evil plan to move people from Win32 to Windows Store applications.
What I think will be more of an issue for Windows 10 ARM is performance. A Snapdragon 835 is comparable to an Atom natively but emulation will add some overhead - some benchmarks imply a lot.
E.g. a Snapdragon 835 running x86 code gets a mere 818 single core score on Geekbench
Intel have threatened Microsoft and Qualcomm with a lawsuit if they convert SIMD instructions from SSE or AVX to NEON. So you could run 32 bit Photoshop but the emulator can't support any SIMD instruction set. And you're running on a chip which is more like an Atom than an i5/i7. That's going to suck. You can't run x64 binaries, even though most software is x64 now.
It'll run something like 7zip or Firefox OK, and those will probably have a native ARM64 binaries too, but if you try to run the x86 version of Photoshop on it the experience will be dreadful.
Outside of Microsoft everyone ignored the non x86 platforms for NT. There's a fair chance that apart from open source stuff people will ignore Windows on ARM too. It's hard to see Adobe spending much engineering time getting Photoshop to run well on Windows on ARM.
When the captured Hue the Commies sent death squads with a list of names of anyone who'd backed the South Vietnamese government. 2,800 and 6,000 people or 5-10% of the population of the town was murdered . Some of them were buried alive. The Communists never prosecuted anyone for this.
It happened around the same time as the My Lai massacre where US troops killed civilians. However some US troops tried to stop the massacre and the people who did it were eventually court martialled.
Of course the US media portrayed the My Lai massacre as something the US did deliberately and ignored the Hue massacre. The media claimed the US was 'losing the war' even though it actually won the Tet Offensive.
Eventually the US pulled out and the Communists overrun South Vietnam. Congress halved military aid to the South when it was being overrun to hasten its collapse. Millions of South Vietnamese were killed or sent to concentrations camps and fearing Hue city massacres or camps million of others fled as boat people.
The media claimed that 'no one wanted to fight for South Vietnam' even though the ARVN soldiers here are fighting pretty hard
As well they would actually - they're buying time for their families to get on a boat to the US rather than ending up in a camp or a mass grave. And if the anti war movement had managed to get Congress to cut off military aid to the UK in WWII, the UK would have gone under too. The fact that an allied government collapses when you cut off support to it doesn't mean it was illegitimate.
In Cambodia the Khmer Rouge took over and killed spectacular numbers of people even by Communist standards. The media downplayed it. Chomsky claimed it was propaganda and blamed the deaths on US bombing. Here he is on Vietnam - bear in mind he's talking about a country where millions fled, were killed or ended up in camp
"The drab view of contemporary Vietnam provided by Butterfield and the establishment press helps to sustain the desired rewriting of history, asserting as it does the sad results of Communist success and American failure. Well suited for these aims are tales of Communist atrocities, which not only prove the evils of communism but undermine the credibility of those who opposed the war and might interfere with future crusades for freedom."
and on Khmer Rouge run Cambodia, the country of the Killing Fields where government policies resulted in the death of up to 25% of he population - probably the worse democide the world has ever seen
"The response to the three books under review nicely illustrates this selection process. Hildebrand and Porter present a carefully documented study of the destructive American impact on Cambodia and the success of the Cambodian revolutionaries in overcoming it, giving a very favorable picture of their programs and policies, based on a wide range of sources. Published last year, and well received by the journal of the Asia Society (Asia, March-April 1977), it has not been reviewed in the Times, New York Review or any mass-media publication, nor used as the basis for editorial comment, with one exception. The Wall Street Journal acknowledged its existence in an editorial entitled 'Cambodia Good Guys' (November 22, 1976), which dismissed contemptuously the very idea that the Khmer Rouge could play a constructive role, as well as the notion that the United States had a major hand in the destruction, death and turmoil of wartime and postwar Cambodia."
Hildebrand and Porter's book deserves examination. One simple fact provides a clue to the authors' sympathies: The book does not contain
There's a funny screenshot here from Spyro : Enter The Dragon (Playstation) where a fairy tells you you're playing with a hacked copy and 'may experience problems'. Spyro : EOTD had a multiple checksum routines. If the pirates patched some but not all of them the game would crash
At one point Microsoft had an unkillable elite with a laser sword which wasn't actually a player - it was a software bot which targeted pirates (Halo?/XBox?)
Windows Phone was a major step back from Windows Mobile. Windows Mobile had quite an ecosystem of Win32 apps, a good custom Rom scene and manufacturers like HTC making devices like the HD2.
So you could buy an HD2, flash a custom Rom and find pretty much any software you wanted - e.g. iGO for navigation, Pleco's Chinese dictionary and so on. Once they announced that Windows Phone wouldn't run any of the old apps most of the ISVs decided to move to Android and/or iOS. And so did almost all the users. Windows Phone never really stood a chance. Still they kept it going for a fair bit of time. Windows Phone 7 was released in November 8, 2010.
In October 2017, it was revealed that Microsoft had discontinued active development of Windows 10 Mobile due to its low market share and the lack of third-party development for the platform, and that the operating system will only receive patches and maintenance releases going forward.
It's a shame really. If they'd launched a Nokia Communicator type device with an Atom running desktop Windows in 2010 or so, they might have had a chance. Of course now Android and iOS are so dominant it's hard to see that MS could do anything that would dethrone them.
I think desktop Windows will survive but people that run it use heavy weight applications and need a powerful CPU. A netbook class device isn't really usable these days - I'd say you need an i5 and 13 inch screen minimum. Which means a Nokia Communicator type clamshell with an Atom is not really going to be much use.
The worst thing is that they fucked up the rather nice UI of Windows 7 trying to get people to write and use Metro apps in order to strengthen Windows Phone. Actually Windows Phone is dead and the clumsy tablet interface put people off Windows 8. I.e. merging mobile and desktop ended up weakening the desktop, not strengthening mobile, which died anyway.
Though admittedly Windows 10 isn't actually half bad. I think in the long run they'll kill of Metro/UWP/whatever the current name is. Win32/Win64 will survive though.
Well back when I was choosing a degree I looked up a list of majors by salary, found Electronic Engineering was number 1 and decided. But to be honest I'd probably have done it anyway. You can usually do OK if you're willing to contract doing software and some hardware knowledge comes in handy if you're doing low level stuff.
Back in 2011 when I had a Windows Mobile phone they sent out this rather sad email
From: Microsoft Date: 9 June 2011 at 04:23 Subject: Shut-Down of Windows Marketplace for Mobile and My Phone To: Hellacious Bastard Porter <hal.b.porter@porterindustries.com> *
Shut-down of Windows Marketplace for Mobile Web Site and My Phone Service Notification
June 8, 2011 Dear Windows Mobile 6.x customer:
Microsoft will be discontinuing the My Phone service for Windows Mobile 6.x. We will also be discontinuing the Windows Marketplace for Mobile web site. Because you may be affected, please review the details below:
Windows Marketplace for Mobile Web Site To Be Discontinued
The Windows Marketplace for Mobile web site at http://marketplace.windowsphone.com/ will no longer be available starting on July 15, 2011. After July 15, 2011, you will no longer be able to browse, buy or download applications for Windows Mobile 6.x phones via the Windows Marketplace for Mobile web site.
The Windows Marketplace for Mobile service will continue to be available on your phone, however. You will continue to be able to browse, buy and download applications for Windows Mobile 6.x on your phone.
My Phone To Be Discontinued
They killed those off so they could replace them with the Windows Phone equivalents. Now those are being killed off too. This is Microsoft's way of telling people not to invest in their platforms, technologies or APIs. Mind you I never actually bought anything from the marketplace, Windows Mobile was more of a 'find hacked.cab files and roms on dodgy websites' type of OS, and My Phone was a free cloud backup service.
* Some names and email addresses have been changed to protect the the guilty.
It puts Microsoft off implementing my MS Insecticide idea.
This is why we need Tort Reform - it would allow megacorps to play amusing practical jokes on people who pirate their stuff and if someone of those people are humiliated or indeed killed, there'd be no lawsuit.
What is "Medium Mode" I can't find any setting in uBlock Origin to set the "mode". I run it with its default settings and the site loads fine.
It just means "Block third party scripts and frames by default". You need to check "I am an advanced user" and then enable the two global blocks as explained here
The Arabs invented the condom in 700 BC, using a goat's lower intestine. In 1873 the British somewhat refined the idea by taking the intestine out of the goat first.
Slashdot Mirror
If you were Acer and you had a prototype Windows on ARM device and you knew the performance was going to suck would you risk being party to a lawsuit where Intel sued Qualcomm and Microsoft for violating one of their 400 patents that was analogous to the one MIPS sued Lexra over?
Or would you think "Yeah, I think we'll pass on Windows on ARM".
I think that's what Intel is going for.
Or maybe they want to make sure that Microsoft agree not to emulate any instructions recent enough to be patented. I.e. the 486 instruction set and probably MMX is OK, x64 and SSE or later is not. That would mean you could only run x86 binaries and not x64 ones. And things like Photoshop are going to really suck.
Intel don't need to win a lawsuit for it to have an effect. All they need is to hint a blog that one might be coming and they can scare off hardware vendors from launching devices and Microsoft from adding SSE support to their emulator.
Amusingly the MIPS vs Lexra lawsuit means that even if you don't implement instructions that would violate a patent and do an illegal instruction trap, you can still be sued because hypothetically someone could write a trap handler which emulated them. That's some real 'through the looking glass' lawyering right there.
Yeah. Lexra got screwed
http://probell.com/lexra/
Though you can not patent an instruction set, you can patent machines and methods that are necessary to implement a particular unusual instruction that is part of the instruction set. That legally blocks competitors from creating a fully compatible clone of your processor. There are four instructions in the MIPS-I instruction set that were protected by one US patent, 4,814,976. These instructions, lwl, lwr, swl, and swr are known as the unaligned load and store instructions. These instructions are useful in systems in which memory is scarce. In such systems, it is often useful to pack 16-bit or 32-bit data values in to memory in such a way that they are aligned to arbitrary byte boundaries, and not necessarily to natural 16-bit half-word or 32-bit word boundaries. Accessing such unaligned variables requires at least two bus clock cycles, whereas accesses to aligned data can be performed in a single cycle. Most assembly programmers and compilers for modern systems align data to their natural address boundaries in order to gain the system bus performance benefit of aligned loads and stores, and so they never use the lwl, lwr, swl, and swr instructions.
Prudent high tech companies study their competitors' patent portfolios, and Lexra was no exception. Lexra was well aware of the patent on unaligned loads and stores that was owned by MIPS Computers Systems, then by Silicon Graphics, and later by MIPS Technologies. To avoid infringing, Lexra chose not to implement unaligned loads and stores in its processor design.
When MIPS filed its S-1 IPO prospectus form in 1998 it sued Lexra for copyright infringement. The suit was settled after a few months with Lexra agreeing not to use MIPS trademarks without attribution and to state in its documentation and in its public statements that it implemented "the MIPS-I instruction set except for unaligned loads and stores". MIPS Technologies agreed to the settlement, apparently acknowledging that Lexra did not execute unaligned loads and stores.
If a Lexra processor encountered an unaligned load or store instruction in a program then it did the same thing that it would do for any other invalid opcode, it took a reserved instruction exception. In the second lawsuit between MIPS Technologies and Lexra, filed November 1999, MIPS Technologies claimed that because exception handler software could be written to emulate the function of unaligned load and store hardware, using many other instructions, Lexra's processors infringed the patent. Upon learning of this broad interpretation of the patent, Lexra requested that the US Patent and Trademark office (USPTO) reexamine whether the patent was novel when granted. Almost every microprocessor ever designed can emulate the functionality of unaligned loads and stores in software. MIPS Technologies did not invent that. By any reasonable interpretation of the MIPS Technologies' patent, Lexra did not infringe. In mid-2001 Lexra received a preliminary ruling from the USPTO that key claims in the unaligned load and store patent were invalid because of prior art in an IBM CISC patent. However, MIPS Technologies appealed the USPTO ruling and, in the mean time, won a favorably broad interpretation of the language of the patent from a judge. That forced Lexra into a settlement that included dropping the reexamination request before MIPS Technologies might have lost its appeal.
It was never determined that processors that execute the MIPS-I instruction set, but treat unaligned loads and stores as reserved instructions, infringed the '976 patent. The patent expired on December 23, 2006 at which point it became legal for anybody to implement the complete MIPS-I instruction set, including unaligned loads and stores.
Extremetech mused on the case and came up with the tech industry analyst equivalent of 'it's a game of two halves mate. It could go either way'.
Hmm, I see what you mean about unaligned pointers and ARM. Support was added in ARMv6 and it's still there in ARMv8 AArch64 mode
AArch64
https://www.realworldtech.com/...
ARMv6
http://infocenter.arm.com/help...
Frankly if I were Microsoft and someone suggested adding support for non native kernel mode code I'd say "What an excellent idea. Why not suggest it to Dave Cutler, right now!". And then that would be last you'd see of them.
It's not 'a patent'. The Intel graph shows loads of patents on each instruction set - 1600 over 13 instruction set extensions or about 123 average for each one.
They claim around 400 patents for MMX, SSE and SSE2, though most of these are for SSE and SSE2.
And Intel's claim is that if executing an instruction uses a patented process it doesn't matter if you execute it in hardware or translate the instruction and execute that - you still need a patent license or you will be sued.
The 32 bit port of NT for Alpha was released but the 64 bit one was internal only - they used Alphas until they got Itaniums
https://technet.microsoft.com/...
A colleague of mine rescued an Alpha AXP machine from a dusty closet. Upon booting up the system, he discovered that it was running a 64-bit version of Windows from early 2000. How is that possible?"
I happened to have one of these machines in my office then. In its prime, this machine was a force to be reckoned with. It was about the size of a small refrigerator and generated about as much noise as a vacuum cleaner. It contained four-count 'em, four!-Alpha AXP processors, each running at a mind-boggling 400 MHz. It had one gigabyte of RAM and thirteen gigabytes of hard drive space, striped over a dozen fast SCSI drives. This may sound puny today, but back in the 1990s, these Alpha AXP machines were the envy of the block and made you the popular kid at the lunch table.
In 1999, when Compaq announced it would no longer support Windows on the Alpha AXP, a lot of Alpha AXP systems were suddenly left sitting around Microsoft with no official duties. Some of these machines, however, were pressed into a variety of unofficial duties. I used my Alpha AXP system to index the entire Windows source code. You can imagine how convenient it can be for a programmer to be able to identify all callers of a function in just a few seconds or to locate the source code for a function or dialog box that shows up in a debug trace.
But even for the simple task of indexing the Windows source code, the Alpha AXP was soon overshadowed by x86-class machines. These were cheaper and faster, they offered more hard disk space, and they had more memory. So for this reason, my machine soon joined its forgotten brethren. It was assumed that the end of support for the Alpha AXP was the end of these machines, but then they were given an opportunity to go out in a blaze of glory, breathing their last breaths in service of the next generation.
The 64-bit Windows project was already well under way, and of the 64-bit processors under consideration, only the Alpha AXP was actually available in physical form. The Intel Itanium was still under development and ran only in a simulator, and the AMD64 architecture hadn't even been invented yet. As a result, 64-bit Windows was initially developed on the Alpha AXP.
When Compaq announced that they would no longer support Windows on the Alpha AXP, all these Alpha AXP machines that previously had been used for 32-bit Windows 2000 development and testing got repurposed and began serving a secret life as test machines for a 64-bit operating system that will never ship in that form. The Alpha AXP was merely a proof-of-concept platform.
The Alpha AXP machines served that role well, giving the 64-bit Windows team real hardware to work with instead of having to run the operating system on an Itanium simulator. (You can imagine how slow that was.) Sure, the Alpha AXP wasn't the final target hardware, but it was a big help. And when physical Itanium CPUs began showing up, the niche filled by the Alpha AXPs vanished, and they were once again retired into dusty closets.
Intel have a handy graph of when each SIMD instruction set was patented here
https://newsroom.intel.com/edi...
MMX is 1996
SSE is 1999
SSE2 is 2001
SSE3 is 2004
and so on
The original x64 specification made support for SSE and SSE2 mandatory, but of course some applications might require later versions.
It's pretty clear that Intel are saying that if you write an emulator to run patented SIMD instructions on non Intel hardware and don't have a patent license, they may sue.
x64 is a nice pragmatically designed extension to x86 but it is almost covered by patents from both Intel and AMD.
You can't patent or copyright an ISA. Most of their patents would cover hardware implementations of various features.
Intel claim patents on SIMD instruction sets and say that those preclude anyone who doesn't have a license executing those instructions even in emulator
https://newsroom.intel.com/edi...
Intel carefully protects its x86 innovations, and we do not widely license others to use them. Over the past 30 years, Intel has vigilantly enforced its intellectual property rights against infringement by third-party microprocessors. One of the earliest examples, was Intel's enforcement of its seminal "Crawford '338 Patent." In the early days of our microprocessor business, Intel needed to enforce its patent rights against various companies including United Microelectronics Corporation, Advanced Micro Devices, Cyrix Corporation, Chips and Technologies, Via Technologies, and, most recently, Transmeta Corporation. Enforcement actions have been unnecessary in recent years because other companies have respected Intel's intellectual property rights.
However, there have been reports that some companies may try to emulate Intel's proprietary x86 ISA without Intel's authorization. Emulation is not a new technology, and Transmeta was notably the last company to claim to have produced a compatible x86 processor using emulation ("code morphing") techniques. Intel enforced patents relating to SIMD instruction set enhancements against Transmeta's x86 implementation even though it used emulation. In any event, Transmeta was not commercially successful, and it exited the microprocessor business 10 years ago.
Only time will tell if new attempts to emulate Intel's x86 ISA will meet a different fate. Intel welcomes lawful competition, and we are confident that Intel's microprocessors, which have been specifically optimized to implement Intel's x86 ISA for almost four decades, will deliver amazing experiences, consistency across applications, and a full breadth of consumer offerings, full manageability and IT integration for the enterprise. However, we do not welcome unlawful infringement of our patents, and we fully expect other companies to continue to respect Intel's intellectual property rights. Strong intellectual property protections make it possible for Intel to continue to invest the enormous resources required to advance Intel's dynamic x86 ISA, and Intel will maintain its vigilance to protect its innovations and investments.
The graph above shows that SSE and later is still covered by extant patents. SSE is actually part of the x64 architecture - you need to execute SSE instructions to have floating point, and floating point is not optional. The x64 ABI actually requires SSE. I.e. to emulate x64 instructions you need a licence for the SSE patents.
This probably also means that if an emulator supports SSE instructions in x86 mode Intel will sue too.
Of course they might be bluffing about suing and will come to an arrangement with Microsoft and Qualcomm or the hardware vendors of Windows on ARM devices to license the patents. Or maybe they're not but they'd lose in court.
Their blog post is clearly designed to make Microsoft, Qualcomm and the vendors think that a lawsuit is possible though.
There is no technical reason, why thou could not just emulate the drivers too.
Suppose you've got some x86 code in running on an ARM in kernel mode. It will expect everything it sees to have the x86 structure alignment. E.g. if it does an mov eax, [ebx+n] and that is translated into LD R0, [R1,#n] then you'd best hope that the structure R1 points to has the exact same thing at offset n in ARM windows that it does on x86 windows.
There are going to be some weird corner cases where that won't be the case, and then you've got kernel mode corruption. Actually if the ARM is running a 64 bit kernel and the driver is x86, that's guaranteed to be the case and you need to thunk all the structures. However I think even if you have x64 code being emulated on ARM64 there are going to weird corner cases where the layout of a kernel mode structure is going to be different.
Another issue is alignment. x86 and x64 code handles misaligned pointers transparently, though occasionally at a enormous performance hit if they span a page boundary. ARM code does not. In user mode that's no problem - you get an alignment fault, the kernel fixes it up and you go on you way, with a performance hit.
However NT kernels are architected so that you can't have page faults when you're running a raised IRQL, because if you're doing that you hold a spinlock. The page fault handler needs to acquire a whole bunch of spinlocks when it fetches a page and allowing to run at a raised IRQL risks a deadlock and a frozen system. So an NT based OS will BSOD with IRQL_NOT_THAN_LESS_OR_EQUAL in this case - what that means is that IRQL is not <= PASSIVE_MODE.
But suppose you have some x86 kernel mode code at a raised IRQL doing an unaligned pointer access. The emulator runs it and it faults. And in NT that fault is instant death. Sure you could hack the kernel so that it first tries to do an alignment fixup. However you've introduced a load of complexity to a design that was pitiless and pure initially - if kernel mode code causes a page fault at raised IRQL then it dies instantly and the solution is for users to track down the company, for the company to track down the developer and for the developer to fix his shitty code.
Actually another option would be for the emulator to check for misalignment and handle it in by avoiding the fault. This would probably work, but there's an overhead you'd need to pay on every pointer access, even the aligned ones, where you'd need to check the low order bits to make sure enough of them were zero to make it aligned before you dereferenced it.
In practice this limitation prevents one from running any game with copy protection.
Copy protection drivers are a bit like anti virus software anyway. What they're doing is grovelling around in undocumented structures and doing rootkit type shenanigans. And the idea that you're going to try to run a copy protection meant for x86 or x64 on a completely different processor architecture is a fool's errand first place. The whole point of them is to try to work out if there's something a bit hinky going on. Nothing is more hinky than running kernel mode code on the wrong CPU architecture with a bunch of hacks that tries to hide the differences and doesn't completely manage it.
It's bold in terms of jerking people around but, uh, I may have gone too far in places
Who is Reverend Green? He's a character I created to explore some experimental political viewpoints. He's religious, unambiguously communist, socially conservative, and perhaps outspoken. Yet I hope his words are sometimes not far from the truth. Brothers and sisters - look around you, open your eyes, write your own narrative. || FWIW, I have a low-UID /. account in my real name. I used to post regularly. Yet the chilling effect of the current social climate in America is such that I am no longer feel comfortable posting political thoughts under my own name.
I'm not sure why you're criticising me for going off on a tangent from the Vietnamese Communist Party to their enablers in the West given that Hal_Porter is also a character I created to explore 'experimental political views' without getting the real me blacklisted for criticising the left and explaining their opponents when I feel they're being unfairly criticised.
And Trump. Trump is basically Batman - a billionaire who works a bit outside the rules to take down psychopaths who threaten the livelihood of the regular folks.
NT on Alpha could run 32 bit x86 code because Dec wrote a very clever emulator called FX!32.
That hooked into NT's process spawning when you tried to run a non native binary and run the code via Dec's FX!32. However it also did profiling. Once it knew which parts of the x86 binary were executed most frequently it would JIT them to native Alpha code.
At one point the platform which could execute x86 code was an Alpha running it via FX!32's JIT.
Back in the days NT run on Risc it was able to run x86 code, but only 16 bit x86 code. That's because the emulator was in the Windows On Windows (WOW) layer. Back then WOW was a way to run 16 bit code on a 32 bit OS. On an x86 chip it run the node natively. On Risc it used an emulator, which Microsoft had licensed from Insignia Solutions.
So on a MIPS R4000 machine you ended up with this
1) You could run Win16 and Dos x86 applications because those run in the WOW layer or in NTVDM, the NT virtual Dos machine
2) You couldn't run Win32 x86 binaries, you needed native MIPS ones
3) You couldn't run x86 drivers, you needed native MIPS ones
The R4000 was 64 bit capable but NT never run in 64 bit mode on it. Though it did on Alpha for while until that was discontinued. 64 bit mode lives on now for x64, ARM64 and maybe Itanium if you ask MS very nicely.
Now move forward to 64 bit Windows 10. The kernel is 64 bit code. WOW is used to run 32 bit binaries. On x64 it runs 32 bit code x86 code natively. On ARM it uses an emulator. So an ARM64 machine you end up with this
1) You can run Win32 applications because those run in the WOW layer. There's no NTVDM or support for 16 bit code in 64 bit Windows because that would need WOWOW - Windows on Windows on Windows.
2) You can't run Win64 x64 binaries, you need native ARM64 ones
3) You can't run 32 bit drivers, you need native ARM64 ones
Ironically given how wonderfully quirky ARM32's instruction set was and how Steve Furber reckoned that 'MIPS was clean but the cleanness lead to poor code density which hurt them they competed with us in the embedded world', (I'm paraphrasing a bit, the interview is here).ARM64 is much more similar to MIPS than it is to ARM32. I.e. no conditional execution, load/store multiple, no free shift with every instruction and no Thumb mode with two byte instructions. RIP Sophie Wilson's wonderfully devious instruction set. Still I can see why they did it - something stripped down like MIPS or ARM64 must be a lot easier to implement as out of order superscalar design than ARM32.
So the situation with WIndows on ARM is better than Windows RT on 32 bit ARM of course - that had no x86 emulator and actually blocked Win32 ARM binaries from running unless they were signed by Microsoft. This was part of Microsoft's evil plan to move people from Win32 to Windows Store applications.
What I think will be more of an issue for Windows 10 ARM is performance. A Snapdragon 835 is comparable to an Atom natively but emulation will add some overhead - some benchmarks imply a lot.
E.g. a Snapdragon 835 running x86 code gets a mere 818 single core score on Geekbench
https://www.windowslatest.com/...
That's about half the native performance which around comparable with an Atom. I.e. great for phone but terrible compared to an i5.
https://www.slashgear.com/asus...
Intel have threatened Microsoft and Qualcomm with a lawsuit if they convert SIMD instructions from SSE or AVX to NEON. So you could run 32 bit Photoshop but the emulator can't support any SIMD instruction set. And you're running on a chip which is more like an Atom than an i5/i7. That's going to suck. You can't run x64 binaries, even though most software is x64 now.
It'll run something like 7zip or Firefox OK, and those will probably have a native ARM64 binaries too, but if you try to run the x86 version of Photoshop on it the experience will be dreadful.
Outside of Microsoft everyone ignored the non x86 platforms for NT. There's a fair chance that apart from open source stuff people will ignore Windows on ARM too. It's hard to see Adobe spending much engineering time getting Photoshop to run well on Windows on ARM.
The Vietnamese Communist Party is completely ruthless
https://en.wikipedia.org/wiki/...
When the captured Hue the Commies sent death squads with a list of names of anyone who'd backed the South Vietnamese government. 2,800 and 6,000 people or 5-10% of the population of the town was murdered . Some of them were buried alive. The Communists never prosecuted anyone for this.
It happened around the same time as the My Lai massacre where US troops killed civilians. However some US troops tried to stop the massacre and the people who did it were eventually court martialled.
Of course the US media portrayed the My Lai massacre as something the US did deliberately and ignored the Hue massacre. The media claimed the US was 'losing the war' even though it actually won the Tet Offensive.
Eventually the US pulled out and the Communists overrun South Vietnam. Congress halved military aid to the South when it was being overrun to hasten its collapse. Millions of South Vietnamese were killed or sent to concentrations camps and fearing Hue city massacres or camps million of others fled as boat people.
The media claimed that 'no one wanted to fight for South Vietnam' even though the ARVN soldiers here are fighting pretty hard
https://www.youtube.com/watch?...
As well they would actually - they're buying time for their families to get on a boat to the US rather than ending up in a camp or a mass grave. And if the anti war movement had managed to get Congress to cut off military aid to the UK in WWII, the UK would have gone under too. The fact that an allied government collapses when you cut off support to it doesn't mean it was illegitimate.
In Cambodia the Khmer Rouge took over and killed spectacular numbers of people even by Communist standards. The media downplayed it. Chomsky claimed it was propaganda and blamed the deaths on US bombing. Here he is on Vietnam - bear in mind he's talking about a country where millions fled, were killed or ended up in camp
http://www.mekong.net/cambodia...
"The drab view of contemporary Vietnam provided by Butterfield and the establishment press helps to sustain the desired rewriting of history, asserting as it does the sad results of Communist success and American failure. Well suited for these aims are tales of Communist atrocities, which not only prove the evils of communism but undermine the credibility of those who opposed the war and might interfere with future crusades for freedom."
and on Khmer Rouge run Cambodia, the country of the Killing Fields where government policies resulted in the death of up to 25% of he population - probably the worse democide the world has ever seen
"The response to the three books under review nicely illustrates this selection process. Hildebrand and Porter present a carefully documented study of the destructive American impact on Cambodia and the success of the Cambodian revolutionaries in overcoming it, giving a very favorable picture of their programs and policies, based on a wide range of sources. Published last year, and well received by the journal of the Asia Society (Asia, March-April 1977), it has not been reviewed in the Times, New York Review or any mass-media publication, nor used as the basis for editorial comment, with one exception. The Wall Street Journal acknowledged its existence in an editorial entitled 'Cambodia Good Guys' (November 22, 1976), which dismissed contemptuously the very idea that the Khmer Rouge could play a constructive role, as well as the notion that the United States had a major hand in the destruction, death and turmoil of wartime and postwar Cambodia."
Hildebrand and Porter's book deserves examination. One simple fact provides a clue to the authors' sympathies: The book does not contain
This one
https://www.inverse.com/article/12807-the-13-most-hilarious-anti-piracy-traps-in-video-games
There's a funny screenshot here from Spyro : Enter The Dragon (Playstation) where a fairy tells you you're playing with a hacked copy and 'may experience problems'. Spyro : EOTD had a multiple checksum routines. If the pirates patched some but not all of them the game would crash
https://www.gamasutra.com/view...
At one point Microsoft had an unkillable elite with a laser sword which wasn't actually a player - it was a software bot which targeted pirates (Halo?/XBox?)
Probably also illegal. Just because someone has done something illegal, doesn't give you the right to do something illegal yourself in response.
It works for Batman.
Microsoft have admitted they're not going to develop the platform further
https://www.cnet.com/news/wind...
Windows Phone was a major step back from Windows Mobile. Windows Mobile had quite an ecosystem of Win32 apps, a good custom Rom scene and manufacturers like HTC making devices like the HD2.
So you could buy an HD2, flash a custom Rom and find pretty much any software you wanted - e.g. iGO for navigation, Pleco's Chinese dictionary and so on. Once they announced that Windows Phone wouldn't run any of the old apps most of the ISVs decided to move to Android and/or iOS. And so did almost all the users. Windows Phone never really stood a chance. Still they kept it going for a fair bit of time. Windows Phone 7 was released in November 8, 2010.
https://en.wikipedia.org/wiki/...
And it was only in October 2017 that they announced they were throwing in the towel
https://en.wikipedia.org/wiki/...
In October 2017, it was revealed that Microsoft had discontinued active development of Windows 10 Mobile due to its low market share and the lack of third-party development for the platform, and that the operating system will only receive patches and maintenance releases going forward.
It's a shame really. If they'd launched a Nokia Communicator type device with an Atom running desktop Windows in 2010 or so, they might have had a chance. Of course now Android and iOS are so dominant it's hard to see that MS could do anything that would dethrone them.
I think desktop Windows will survive but people that run it use heavy weight applications and need a powerful CPU. A netbook class device isn't really usable these days - I'd say you need an i5 and 13 inch screen minimum. Which means a Nokia Communicator type clamshell with an Atom is not really going to be much use.
The worst thing is that they fucked up the rather nice UI of Windows 7 trying to get people to write and use Metro apps in order to strengthen Windows Phone. Actually Windows Phone is dead and the clumsy tablet interface put people off Windows 8. I.e. merging mobile and desktop ended up weakening the desktop, not strengthening mobile, which died anyway.
Though admittedly Windows 10 isn't actually half bad. I think in the long run they'll kill of Metro/UWP/whatever the current name is. Win32/Win64 will survive though.
Well back when I was choosing a degree I looked up a list of majors by salary, found Electronic Engineering was number 1 and decided. But to be honest I'd probably have done it anyway. You can usually do OK if you're willing to contract doing software and some hardware knowledge comes in handy if you're doing low level stuff.
As a fellow Brit I demand that you don't send him back to us. He's smarmy cunt.
You could however prosecute him for undermining the US constitution.
Back in 2011 when I had a Windows Mobile phone they sent out this rather sad email
They killed those off so they could replace them with the Windows Phone equivalents. Now those are being killed off too. This is Microsoft's way of telling people not to invest in their platforms, technologies or APIs. Mind you I never actually bought anything from the marketplace, Windows Mobile was more of a 'find hacked .cab files and roms on dodgy websites' type of OS, and My Phone was a free cloud backup service.
* Some names and email addresses have been changed to protect the the guilty.
That's baaaaaaad.
It puts Microsoft off implementing my MS Insecticide idea.
This is why we need Tort Reform - it would allow megacorps to play amusing practical jokes on people who pirate their stuff and if someone of those people are humiliated or indeed killed, there'd be no lawsuit.
What is "Medium Mode" I can't find any setting in uBlock Origin to set the "mode". I run it with its default settings and the site loads fine.
It just means "Block third party scripts and frames by default". You need to check "I am an advanced user" and then enable the two global blocks as explained here
https://github.com/gorhill/uBl...
And then you need to work out what exceptions you need to make to get a site to work.
E.g. for slashdot I had to add a local whitelist entry for fsdn.com
https://i.imgur.com/0MVTaqq.pn...
The Arabs invented the condom in 700 BC, using a goat's lower intestine. In 1873 the British somewhat refined the idea by taking the intestine out of the goat first.