Windows Bridge for iOS | Hacker News Reader

Windows Bridge for iOS

github.com

417 pointsjmsaunders142 comments

In the late '90s, NeXT/Apple actually had a Cocoa runtime for Windows. It was called Yellow Box (but only shipped as part of Enterprise WebObjects, IIRC). It was closed source, of course, and 3rd parties couldn't ship apps using it.

In this bizarro world we live in, Microsoft has rebuilt essentially the exact same thing and has released it as MIT-licensed open source.

A version of this (called YellowSubmarine) ended up shipping in iTunes and Safari for Windows. You should be able to find a libobjc.dll, CoreFoundation.dll, etc. if you look around your filesystem.

TIL, interesting. I wonder if they are keeping it just in case one day they need to ship other apps in Windows (e.g. Xcode, Mail, Reminders, etc)

Yellow Box was something slightly different, NeXT had an actual shipping product called OPENSTEP Enterprise targeting Windows NT. It did allow third parties to build and ship apps using it. Apple discounted it and continued to sell it for a while. See

http://www.prnewswire.com/news-releases/apple-cuts-prices-on...

Safari for Windows used to ship with a lot of the CoreFoundation / NS* libraries in very obvious places (i.e., CoreFoundation.dll).

I still have the WebObjects 4.5.2 (and 4.5.1 I think) boxes somewhere - the last version to support Objective-C on the desktop (that is Windows).

I was really overwhelmed with joy, when I saw how one can add say middle-wheel support to a whole system, without recompiling, or doing some low-level drivers, hacking, etc. - but by just extending it with OO - this is the code I'm talking about - http://www.rubicode.com/Software/Legacy.html#RCWinMouseWheel

It's probably not safe to do things like this nowadays (security), but I still like the whole idea of one being able to replace classes with others without recompiling everything from scratch.

I have not debugged iTunes on Windows, but I have a feeling that there is at least some AppKit wrapping going on (perhaps akin to UXKit) for Windows.

iTunes on Windows is as much AppKit as it is on OS X; which might be to say, not much, maybe… but definitely a lot of ObjC and Foundation.

I thought it used to be C/C++ and only based on Carbon. Has that changed?

Proably, Xcode 6 saw the death of the Carbon tools.

Wasn't a lot of it ported to Cocoa / AppKit a few years ago?

It would be even more bizarro, but perhaps also magical, if this eventually forms the basis for an alternative to GNUStep.

Is the main missing chain a lack of WinRT and XAML support in Mono?

Yes, and it came with Mail.app also (which is from NeXT, and the ancestor of Apple's current Mail app on Mac OS X, and maybe a few other desktop programs.

I remember using it as my email client for a while, on Windows NT.

Looks like they took the MIT-licensed PSTCollectionView without any attribution: https://twitter.com/steipete/status/629364240063799296

Compare: https://github.com/Microsoft/WinObjC/blob/106d8b2738101872a1... and https://github.com/steipete/PSTCollectionView/blob/master/PS...

Edit: They added the license https://github.com/Microsoft/WinObjC/commit/611e9e5a4b837360...

>Edit: They added the license https://github.com/Microsoft/WinObjC/commit/611e9e5a4b837360....

And also apologized:

https://twitter.com/windowsdev/status/629379957018394624

Is attribution required by that license? The copyright notice has to stay in the software, but I don't see an attribution clause.

License: https://github.com/steipete/PSTCollectionView/blob/master/LI...

In the source file referenced, the PSTCollectionView strings are all ifdef'd out. Lawyers would be required to tell if text not used in the software is part of the software.

Is the copyright notice still anywhere? It says Copyright Microsoft on the top of the file.

Copy and paste the first paragraph into Google. Looks like someone didn't understand the nuances of the MIT license, no biggy and easy to fix.

Is it just me or is the code in question basically commented out so it will never execute?

They could still attribute this guy, but they included it in a public repo so they should either delete or acknowledge this guy.

Edit: It isn't commented out but it's in a compile if statement that shouldn't execute.

Why did they change a lot of the variable class types to id? Is that an optimisation I haven't heard of?

`instancetype` is relatively new addition to Objective-C/Clang. I assume their version just doesn't support it yet, since the regression to `id`.

`instancetype` was a few years ago. I'd be worried if they're only supporting ObjC without any modernisations like that and subscripts etc.

But that's not what I'm talking about. Here they've literally replaced all type declarations with `id` (not just return types where you'd normally see `instancetype`). Seems odd.

I haven't read the code. But maybe they did that during porting. It's easier to get code to compile and come back to fix it later. Maybe they haven't gotten around to it?

Is this not vulnerable to the horrible precedent on copyrightability of APIs, established by Oracle vs Google and which the SC just refused to review?

https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google....

https://www.eff.org/deeplinks/2015/06/bad-news-supreme-court...

I've read that both Microsoft and Apple have agreed not to sue each other in court.

That's convenient, but I don't think they made the same deal with Google (Project Astoria, the Android variation).

Imagine how well it would go over for Google if they started a copyright suit from the position that they heavily argued against in Oracle.

I'm not saying they wouldn't (or even shouldn't, since they lost the case), but I'd be amused as all get out. And it'd prove what we all know deep down: Google's position will always be whatever is the best position for Google.

Personally, I find it more amusing that you speculate a situation that hasn't happened, and has no precedent from Google's history, and then use that to confirm a speculation which "we all know deep down" :)

Well, I said "it'd", which is short for "it would". As in, it would confirm, if they did.

Can Oracle sue Microsoft?

No definitely not. It's not their code. They can't sue for others without their cooperation. And Apple doesn't need Oracle to fight their battles.

Wouldn't this be translating one API to another, versus implementing an API as in Oracle vs. Google? Wonder if that makes a difference.

It looks like they took an approach similar to GNUStep, with its inverted layers compared to Apple's implementation. CF on top of Foundation on top of UIKit.

Looking a little deeper, it's missing some things... KVC/KVO are entirely absent. libdispatch looks to be pretty broken. NSNull is wrong in about 3 ways. There are several classes which are just stubs. Most of the NSLock subclasses are missing.

It's a good start, but I don't see it becoming the ObjC standard library by any stretch of the imagination.

Ack. I recall Apportable did something similar in their first cut, then redid it with the correct architecture. (I wouldn't say Foundation is on top of UIKit in Microsoft's implementation though?)

I am surprised they didn't use any of Apple's open source code, such as libdispatch or CoreFoundation.

Apportable basically used a heavily modified fork of GNUStep originally, but yes, then they did switch to a correctly layered architecture.

You're right, -[NSProcessInfo physicalMemory] for example is layered on +[UIDevice _deviceTotalMemory].

http://blogs.windows.com/buildingapps/2015/08/06/windows-bri... has some more details. Projections look cool!

Sorry for the totally n00b question, but does this enable running iOS apps on Windows or the opposite?

You'll be able to run Objective-C based applications on Windows as long as they have the completed APIs for the bridge (the documentation shows a list of things not there yet). It's pretty neat! You won't be able to download an application directly off your iPhone and run it on Windows though (at least I don't think you'll be able to at any point) as you basically have to recompile using this tool.

In other words, this project is to CoreFoundation as winelib is to win32?

I think so but I haven't dug into it enough to say for certain. So I would defer to anyone else who's dug into it :)

They are also working on translating over Swift.

Most importantly, the ability to develop iOS applications on a Windows box.

This is a welcome sign for those that do not want to buy Apple hardware and have struggled working with Hackintosh VMs or cloud-based OSX desktops.

Is it still policy for Apple to require XCode and therefore force you into buying Apple hardware (one way or another) in order to deploy to the App Store?

Yes. Unfortunately, as far as I'm aware, you can't deploy an app to the app store without a Mac. But you can (at least in theory) do iOS development on a Windows machine.

Isn't it that you just need your build to be signed by a registered copy of XCode/OSX (don't know specifically what it is)?

So you can actually just send the code developed on your windows box off to a third party build server, which will be an actual registered mac - you get the compiled binary back and then submit that to the app store, no worries.

I'm not sure if the rules around this have changed but IIRC from a couple of years ago when I last checked, this is what Adobe were doing with their phonegap build server - you send them up your phonegap project which can be written on anything (windows, linux, etc), they compile it to apps for various platforms and send you back those binaries, you then just submit these to the various platform app stores. Again, IIRC, this included iOS apps.

You are correct, and if I remember clearly, I think this is how Xamarin does it as well.

There's always Cordova/PhoneGap and possibly Ionic Framework. It's much easier to build apps that look good on all different device sizes with hybrid tech. You'll want to use Visual Studio 2015 for that too since Microsoft now has an Android Emulator which is faster than any other.

Looking to the future, there's React Native.

If you don't want to buy Apple hardware, why are you bothering with iOS?

This here won't really help you do that. It's for bringing code written for iOS to a windows runtime.

You could do that before; see e.g. https://stackoverflow.com/questions/22358/how-can-i-develop-... and https://maniacdev.com/2010/01/iphone-development-windows-opt...

Not really. You still need a Mac to sign the app, and a Mac to deploy to iOS hardware.

Probably not if the device is jailbroken.

Makes it easier to port an iOS app to Windows.

Actually, Windows 10 - so if I understand it correctly this is about universal apps and as such would mean that if you port your app succesfully it would immediately run on all phones/desktops/tablets/whatever running Windows 10? If so it seems like this could be a major thing given the amount of complaints I read about the lack of apps for windows phones, i.e. in the long run if this works out then it's goodbye Android/iOS-only apps and welcome Android/iOS/Windows apps?

Though oddly enough, the beta version only works for x86/64 architectures. So not Windows Phones.

I don't know how odd that is. Windows 10 Mobile isn't released yet, and Windows 10 has been released. Nobody is going to DEVELOP these on Windows Mobile devices, so it still needs to work on Windows 10 for dev and testing. So developers can start working on using this now, and a later update will add phone support, so they can deploy there as well.

The Candy Crush app is claimed to be a ported iOS app, already available on Windows Phone 8. And I kinda thought the whole Universal Apps thing was architecture-independent.

So I'm going to assume this ultimately a way to prop up windows phones by making it much easier for developers to put something on the windows store. What surprising (to me) is that they didn't go the Android route given it's open source to begin with, and they already have patent licenses in place.

This makes me think of the ol' OS/2 downfall. OS/2 could run Windows applications; this meant no-one developed specifically for OS/2, so they never got the developer mindshare, so there were no OS/2 killer apps, so users saw no benefit to using OS/2 over Windows.

But OS/2 wasn't hardware. If Microsoft can sell phones that match features, speed, ram, look good, etc but can also run all the apps you want, then that's a more competitive situation than running a significant subset of apps out there (just look at their marketshare which is pathetic for a company with all their resources).

Microsoft is working on 4 Bridges of which this is one of them.

Android is another:

https://dev.windows.com/en-us/uwp-bridges/project-astoria

The other two are for web apps, and legacy win32 apps.

They all take different apporaches. So this one for iOS is a recompile and modify approach, Android is more of an Android SubSystem within the OS approach (like the old Unix subsystem that they had)

Because Google has a "Fuck Microsoft" approach to mobile, so I'm guessing they're just taking a page out of Google's playbook.

Microsoft is an Android patent troll. Of course they would have a "Fuck Microsoft" attitude.

I hope when Swift becomes open source, MS will add a bridge for Swift as well. I am really looking foreword to making Swift my go to language for web app and utility development. It's a very neat language.

It's almost as good as C#!

There might be a problem with this. They are currently using ObjFW, an old implementation of the ObjC runtime, but Swift needs some ugly hacks in the ObjC runtime to support the Swift "additions" and "extensions". Will be interesting to see the MS runtime expand as well.

Swift is open source as of WWDC, and Microsoft is working on bringing Swift on as part of this project.

It's not. It's only promised to be. Kinda like FaceTime was promised to be an open standard.

Unlike Facetime nobody rised patent issues regarding Swift.

Interesting... So they are using ObjFW as their ObjC runtime, which is relatively an old implementation. So if your app has some Obj C Runtime use, you may see trouble here. It would be interesting to test their other implementations.

Hum, excuse me, but since when is the ObjFW runtime old? It supports modern ObjC quite fine and is still in active development with the last changes being from this year. However, the one used here seems to be from 2012 for some reason, instead of one from 2015.

I think they took it directly from here: https://webkeks.org/objfw/ which does say 2012 as the last release. I see on GH they have commits from as recent as last month.

The problem is not the syntax support. The ObjC runtime had many changes to it done internally over obscure flags to support Swift and other compiler features. These are not readily documented on Apple open sources. (Perhaps more documentation exists in LLVM.) Once the runtime contains ABI changes, it makes it difficult to port apps that (ab)use the runtime. Not a problem for some apps, but a big problem for others.

I'm surprised they didn't use Apple's libobjc nor CoreFoundation; a quick look at the Foundation/CoreFoundation code suggests it's nowhere near as complete as Apportable's. The rest looks impressive though and it's great the open sourced it. Instead of complaining I suppose one should just fix things! (For example, where is CFGetTypeID()?)

Also, not using Apple's libobjc misses out on years of optimisation. e.g. compare the implementations of objc_sync_enter() (not that @synchronized is necessarily that common).

Couldn't find their implementation of objc_msgSend, interestingly...

It appears their strategy is now "embrace everything".

and extend anything! and... (gosh)

Not an iOS developer, but, say they did extend this, what's to stop a developer taking the (presumably MIT licensed code), using it within his app to get that on iOS too? I guess this doesn't work if it's being backed by some Windows feature, but otherwise?

That doesn't make much sense because iOS already comes with implementations for all these frameworks. You're kinda asking "what's to stop a developer from including wine into his windows app so it can run on windows?"

No, he is saying extended the iOS API - say to read from a heat sensor. Then it will only work on the windows/ios hybrid, not on the true iOS app.

Yes totally pointless so long as they were strictly replicating iOS, but people seem to fear Microsoft extending the APIs.

Ah, now I get your point. Yeah, unfortunately you can be pretty sure that any interesting "extended API" would be a small wrapper around a windows-specific OS-provided service and thus unportable. That was the big issue with the MS Java extensions too I believe.

iOS developers already deal with this every year apple extends the Apis and there are various techniques to using the extended Apis and falling back to the old ones

I'm loving the openness of this new Microsoft. They keep launching cool stuff!

Some open, some not.

http://blogs.windows.com/buildingapps/2015/08/06/windows-bri...

"(we’re not open sourcing the compiler)"

The compiler is the Clang front end over their MSVC backend, http://blogs.msdn.com/b/vcblog/archive/2015/05/01/bringing-c... . I guess I wouldn't be too surprised if it was open sourced later as that seems to be the direction they are generally moving in.

Interesting, new SDK released today includes `TARGET_OS_WIN32` in many headers. Is Apple planning a surprise?

`TARGET_OS_WIN32` has been there since a very long time ago.

Really? I haven't seen them in so many years. Either my brain blocked WIN32 or...

I hope you can statically link cocoa into a window exe someday.

Wow, this must've been enormously complicated to implement

More like grunt work.

A lot of UIKit is nuances, documented or otherwise. Just discovering most of them (I'm sure they haven't) is a very difficult task.

Trust me, I have.

Some of this code is just... WTF? For example, https://github.com/Microsoft/WinObjC/blob/106d8b2738101872a1... ; even setting aside the fact that some minutes don't have 60 seconds, 30.42 days per month?!

365 / 12 = 30.42

Well, yes, but you cannot do any useful math on months with that fact. Late in January, plus one "month", gives you early in March; early in July, plus one "month", gives you late in July. I can't imagine what useful intent could lead to this code being correct.

I expect they had to write something that looked good to meet the deadline, even if it was completely broken.

One minute is 60 seconds by definition. Minutes with more than 60 seconds are just one (hacky?) way to support leap seconds.

"No autolayout support"

Guess I'm gonna hold off this until the final version is released.

Would be cool if they added SpriteKit, the games would work on iOS, Mac Os and Xbox One (Windows)

Interesting how they built their UIView/CALayer stuff on top of Xaml to the point where you can apparently just add any random Xaml windows component into an UIView.

Reminds me about the whole Visual J embrace-and-extend thing in the old MSJava debacle.

Someone with enough Cocoa knowledge should use it as the basis for an OS X implementation of UIKit. And for other OSes like GNU/Linux using GNUstep.

Very interesting stuff, diving into the Frameworks directory in the repo.

I think Apple might be doing this themselves, dig into Photos.app on Mac Os.

On Channel9 Microsoft introduced Islandwood (building Windows app with ObjC) in this video:

https://channel9.msdn.com/Events/Build/2015/3-610 (start at 35 mins)

It's an interesting (and funny) video. Some things Microsoft _might_ work on are:

- Swift support might be on the roadmap

- Export (changes) to Xcode project might be on the roadmap

- There's interop between ObjC and C++ / C# using some sort of event system.

- Visual Studio 2015 has autocomplete and syntax colouring for ObjC

Maybe once Tengu (http://www.tengu.com/) comes out of closed beta, developers will be able to use Objective-C as a cross-platform language targeting all major mobile platforms. The only question is how native the UI will feel on the non-iOS platforms.

sysctlbyname() implementation in Frameworks/CoreFoundation/CFMisc.mm does not check the destination buffer size.

You know what's great about open source? You can contribute to it! :)

Heh. They already fixed it. Nice one MS.

I'm very impressed with the technical prowess involved in shipping this, that being said, I feel like OSS this is somewhat disingenuous. To use it you'll still need VS2015 (EDIT: this tool which will only work in Windows 10 according to the spec). While Windows 10 is a free upgrade, if you're developing iOS apps you probably don't have a windows license, (because Apple requires development to happen on OSX) so you're gonna need access to two closed source (and kinda expensive) pieces of software to see any real benefit from this, I guess at the very least there'll be an easy way to provide bug reports, feature and pull requests, etc (where usually for closed source you're SOL).

RE: The project itself: looks like they're still working on getting it to work on ARM, which is strange considering that iOS is ARM...

One kinda expensive piece of software - Windows 10. VS2015 Community is free, and more than capable for the use of this.

I'd imagine if you are a mac developer then the price of Win10 is practically insignificant compared to what you are used to paying for OSX stuff.

You need to re-imagine.

I'm used to paying $0 for the OS X stuff needed to do development. This includes the Enterprise Professional Plus Home edition of both OS X and Xcode. In the lifetime of my Mac I have upgraded the OS 2 times and soon 3 for $0. So $307 is a bit significant for Windows 10 Pro (need BitLocker = Home is no go).

If you could have done the same on your Windows platform then please give me your Windows stuff contact person as he is clearly much cheaper than the ones I usually deal with.

But just for being in the Apple is ripping you off mode I did pay a bit more for the initial purchase of the hardware (around $205 more in todays prices than a comparable Dell XPS 13).

My day job is doing software management on the Windows platform so I'm fully aware of the licensing cost here. Including the price of operating a Windows developer above Visual Studio community level with their VS Pro/Enterprise editions, MSDN subscriptions, Team Foundation servers, and $2,500 HP workstation laptops (initial consumer price for lowest configuration). Seeing these prices almost causes a heart attack each time...

If you run it in a VM on your Mac, you can take advantage of any host-level full-disk encryption and avoid needing Bitlocker. (Of course, you probably want to pay the $50 or so for VMware Fusion, if you're going that approach.)

Yes, hadn't thought of that actually.

But it was mostly an example. I already have all the Windows versions I want available through work.

Where are you getting the $307 figure for Windows 10 Pro? The full cost of a brand-new Win10 Pro license is $199 according to Microsoft's website.

In the Microsoft store for my country the price is 2099 DKK equal to 307.41 USD.

Yes everything is expensive here... :/

> RE: The project itself: looks like they're still working on getting it to work on ARM, which is strange considering that iOS is ARM...

Why is that strange? That iOS also runs on ARM doesn't help them very much for running stuff on ARM-based windows devices.

Err, VS2015 works fine on windows 7.

From the GitHub:

To use WinObjC, there are a few requirements. You need:

Windows 10

Visual Studio 2015 with Windows developer tools. Visual Studio 2015 Community is available for free here. Select (at least) the following components during installation:

MS should build an amazing version of Visual Studio that lets you build Android, iPhone, and Windows Phone apps. It's free if you release Windows Phone apps along with your Android or iPhone apps.

It's called VS 2015

Any chance of the MacOSX APIs coming along for the ride? Or how much extra effort would it be to use this and port the MacOSX apis as well?

I'd love to get Mac Apps on Windows.

Agreed — to me, the ability to compile my OS X projects for Windows is a far, far more interesting proposition than being able to port my iOS projects. To be quite honest, I don't really care that my iOS apps don't have a Windows Mobile port.

You don't care, but Microsoft does. Their Windows Phone/Mobile state is much more dire than the desktop/tablet Windows 10.

Can this be used to generate XAML from UIKit elements?

Let's say I want to see the Rendered XAML template of a standard UIButton?

Probably not. And if you could, then it'll only be because Microsoft re-implemented those UIKit elements in XAML.

does this mean we can compile iphone apps on windows now?

when are we getting windows spider solitare on ios

Forget that, I want Space Cadet pinball

"Embrace and extend" - Microsoft's long-standing strategy for overtaking & destroying the ahead-of-the-game competition. Provide high-quality tools cheap, seduce developers off the canonical platform and onto MS's highly compatible equivalents, then slowly fork the standard, leaving customers with the choice of abandoning their deeply-vested stake in MS toolsets etc or going all-in with MS.

AFAIK we ended up with C# because MS created a very nice Java IDE, started to fork it, developers vested in that IDE got mad at Sun Microsystems (developers & owners of Java standard), Sun sued MS, MS was told to cut it out, MS mutated Java into C#.

Let's hope this doesn't turn into MS trying to rip iOS developers/users away from Apple as done many times before.

As a former Netscapee, I'm probably first in line to call foul on Microsoft's Embrace-Extend-Extinguish strategy (See how much damage Active Directory did to Universal LDAP support - ever try and run Outlook/Windows domain on anything but a Microsoft Directory Server?) - but that's an old war. And it's over. The beginning started in 2007 with the release of the iPhone (some such as Benedict Evans might suggest the transition to Web Apps was the beginning, but IE tried to corner that market by injecting Active-X everywhere) and Android. Microsoft failed to release a high-quality mobile solution quickly enough, and the transition to mobile effectively ended the Microsoft Hegemony. The War was officially over with the departure of Balmer, and official declaration of defeat occurred when Nadella wrote off the vast majority of the Nokia acquisition.

In order to compete, Microsoft now has to play on, and support, platforms which it does not, and never will, control.

It's taking a while for me to adjust (16 years?), but I have to say - I really like this new Microsoft, and I'm looking forward to the great things that they are going to do now that they are no longer the Monopolistic behemoth that they were for so many years.

The war is over? As a former Netscapee you might remember the relevance of Microsoft in terms of Web Browsers before IE4.

That's where Microsoft is now with their mobile OS, and it's nearly exactly the same playbook: developer mindshare and one-way compatibility to make their lousy offer become less lousy.

Given that some XAML-in-UIKit stuff is discussed somewhere else here, they may already work on extending beyond iOS, probably hoping to keep Apple busy with eternal catch-up (since they're said to have cross licensing agreements, patent wars are likely out of the question here).

The key difference is, Microsoft was able to leverage their monopoly in one industry (Desktop) to destroy the competition in another (Browsers, though yes, that phoenix did rise from the ashes)

The war is over because Microsoft no longer has a monopoly they can leverage to do this again.

Microsoft is not, and will not be a force in the mobile phone world for the foreseeable future.

Re: "probably hoping to keep Apple busy with eternal catch-up"

You've got the causation going the wrong direction - Apple doesn't have to catch up to Microsoft any more, it's Microsoft that has to play catch up with Apple.

I can't describe it any better than Benedict Evans did, so I'll just share his analysis: http://ben-evans.com/benedictevans/2015/7/8/capitulation

> The war is over because Microsoft no longer has a monopoly they can leverage to do this again.

They're still a force on the desktop and the Universal App model of Windows 10 will help translating that elsewhere.

> Microsoft is not, and will not be a force in the mobile phone world for the foreseeable future.

WinPhone sales catch up with iOS in some European countries. They have attractive offers at the low end to rival Android in less wealthy regions. I wouldn't discount them yet.

> You've got the causation going the wrong direction - Apple doesn't have to catch up to Microsoft any more, it's Microsoft that has to play catch up with Apple.

For now. Just like they had to with HTML on IE4 and Java for a while. At some point, they built a "better HTML than HTML" (XMLHttpRequest still survives) and a "better Java than Java" (at least they saw it that way, and it was enough of a threat that Sun took the legal route, which both Apple and Google can't easily take in this case).

They need the apps, so they provide enough support to make it work. I suppose that through a mixture of superior tools (MSVC), marketing aid ($$$) and Embrace&Extend (P/Invoke, XAML-in-UIKit) they will try to make those apps work better on Windows than on other platforms, no matter if they're written in C#, Java or ObjC/Swift.

Sound familiar to me. Microsoft is the most dangerous when they're hungry, and they certainly are.

Re: "They're still a force on the desktop "

The desktop is increasingly becoming less relevant. It won't go away, but mobile platforms are where the revenue and activity is.

Re: "WinPhone sales catch up with IOS" - That battle is over. It's not even up for debate. There was a reason why Nadella has terminated the Windows "Services and Devices Business." and fired most of the Windows Phone engineers - and that's because Microsoft has been thoroughly and completed defeated by Android and iPhone.

There are going to be lots of places where Windows Phone will still be used, and, in fact, even be a popular choice. But there are also places in the world where Blackberry Phones are still used. But in all the key (and profit generating markets) - Android and Apple have carried the day handily.

By the way - I'm not saying the Microsoft isn't dangerous - they are wicked smart, have tons of cash, and have demonstrated that they are willing to make a significant adjustment to strategy "Devices and Services" to "Mobile first, Cloud First" and fire their CEO to do so.

What I am saying is that Microsoft is no longer in a position to "Embrace, Extend, Extinguish." as Microsoft no longer has the market power to extend important standards and have others adopt those extensions as people are increasingly less likely to be using one of their products, and, more importantly, are increasingly no longer required to use one of their products to get their job done.

To bring this conversation back to the beginning Microsoft has released a translation/recompilation layer that will let people who have written applications for iOS, quickly recompile them and release them for Windows, without having to write much, if any, new code. The objective is to have people write apps for Windows 10 and iOS using this mechanism, because currently, effectively 0% of people are writing first class apps for windows phone (there are, as always, small exceptions, but windows phone basically gets the dregs).

The problem with this strategy, is that now Microsoft is playing on Apples platform - and this further reduces the incentive for people to write native Windows phone Apps. Effectively, this is Microsoft giving up and saying, "If you won't write apps for our platform, as least we can emulate other ones and run those apps."

Thats not really how C# happened.

edit: also I think embrance,extend,extinguish wont work anymore in the dev space because Microsoft no longer have the monopoly on dev desktops and probably never will again - far from it infact.

Its more like they're trying to re-capture dev interest because very few decent websites are built/run on windows (other than StackExchange) and not much app development is happening on windows, etc etc.

> MS mutated Java into C#.

I'm not sure that's true. The Sun vs. MS litigation ocurred on 2001 (https://en.wikipedia.org/wiki/Visual_J%2B%2B#Sun.27s_litigat...)

On the other hand, C# first appeared in 2000

The litigation was settled in 2001 (according to that page) but occurred before then. MS shipped their Java implementation since at least 1997, which included P/Invoke and COM interop – things that encouraged integration with native (platform-specific) win32 libraries and look pretty much the same in C#.

I'd consider C# a much superior "fork" of Java. If that's the case here then I'm all for it.

If they are ripped away to something better, then I don't share your hope.

Both Apple and MS have been doing that for a while. MS got me when they came out with MS Word, which opened formats from just about every other word processor - Wordperfect being the main one. Apple got me when they introduced Bootcamp and I was able to run both OSs on one machine. Slowly but surely it got to be a pain to keep booting back and forth and I switched to OSX.

I'd imagine it's a similar story for a lot of us out there, just different apps, libraries, dev tools, etc, luring us back and forth between the various operating systems. I wonder if I could be lured back to the MS side?!

Reply on news.ycombinator.com