![java ide on for surface rt java ide on for surface rt](https://m.media-amazon.com/images/I/81OTWypr+UL._AC_SL1500_.jpg)
- #Java ide on for surface rt 64 Bit#
- #Java ide on for surface rt 32 bit#
- #Java ide on for surface rt code#
If you're talking cruft, then it's that COM stuff and. Event pumps and windowing callbacks are going to exist no matter what API they build.
#Java ide on for surface rt code#
That is to say, Win32 can be compiled on ARM, and then I compile my code that uses the Win32 API to get a window and event loop, and the "legacy" compatibility isn't an issue. Besides, you don't see wagon wheels on a formula-1 car, eh? It's crazy as hell to do this, yes, yes, I'm glutton for punishment, ha ha, you jest, "re-invent every wheel", I know, but game developers are allowed to throw away every best practice in the name of performance.
#Java ide on for surface rt 64 Bit#
It simply means "Not the old 16 bit API" I write all my widgets from scratch, and I talk to OpenGL directly, no SDL, no freeglut3, no MFC, just straight Win32 and OpenGL to make the lightest weight most efficient programs, even on 64 bit systems.
#Java ide on for surface rt 32 bit#
You may have failed to realize that Win32 doesn't mean 32 bit windows API.
![java ide on for surface rt java ide on for surface rt](https://images.idgesg.net/images/article/2020/02/img_20200110_150014_bokeh-2-100829035-large.3x2.jpg)
There's no legacy compatibility story to begin with, even if the restriction on MS-signed-only desktop binaries weren't there in the first place. We are talking specifically about Windows RT running on ARM here.
![java ide on for surface rt java ide on for surface rt](https://developers.refinitiv.com/content/dam/devportal/articles/coding-and-testing-with-wsl/vscode-with-wslx-terminal-java.png)
Legacy compatibility and a huge installed base of applications are Microsoft's primary competitive edge If Microsoft gets rid of the "Win32 cruft dating back to the 80s and 90s", then there will be no reason for anyone to choose Windows over any other operating system. (Of course, any competent programmer could write a better version of Notepad in a month, so that's really not a factor.) And if Microsoft ever releases a slimmed-down "Office" for iOS and/or Android, then those products will probably be written from scratch, and will not be 100% backwards compatible with anything other than OOXML. Office for MacOS is almost a completely different product, done by a separate business unit. At this point, the Office codebase is probably so FUBARed with 20+ years of spaghetti code and the need for backwards compatibility with 500 different document types that I doubt they could rewrite it completely even if they wanted to. If Microsoft could have ditched legacy API usage for Office that easily, I think they would have done so already in the first release of Surface. but Microsoft can easily rewrite them in the future. That cruft does exist now and is used to run things like Office and Notepad etc. Legacy compatibility and a huge installed base of applications are Microsoft's primary competitive edge, but Ballmer seems to have forgotten this in his Ahab-like quest to chase down Apple. Microsoft locked Windows RT down because it wanted to slowly get rid of the Win32 cruft dating back to the 80s and 90s.